我在京东做产品经理的448 天

这份前辈的职场经验，送给每个想进入大厂或者已在大厂的小伙伴，以下enjoy~

2018年4月9号，我坐上北京的亦庄线地铁到经海路下车，来到了五环外的京东总部

在此之前，我在上一家创业公司度过了 4 年的时间。从三四个人一直到最多时一百多人，那是一段激情燃烧的岁月。

4 年对于一段职业生涯来说已经不短了，对于那次从零开始的创业，虽然没有得到理想的结果，但过程足以让我成长。

2018年3月底，确定加入京东，休息一周后，我正式入职。

到今天，也就是2019年7月1号，我正式离开京东，这是我在这里度过的第 448 天。

一年多的时间不算长，但也是一段非常完整的经历。有些收获和想说的，算是对过去的一次总结。

这篇文章比较长，但基本能带你了解我在京东感受到的一切。

在京东工作是什么体验

01 找人

如果对比我之前在创业公司的工作体验，在京东的整体感觉就是事情的周期被拉长了。

在大公司工作过的人都有体会，一个很小的需求，从提出到落地的周期可能会超出你对这件事的预期。

类似这样的需求，我经历过很多个。可以理解成这是一种严谨性，因为有各种流程、各种评审、各种确认、各种排期。

也可以理解成是一种组织机构化和职能化带来的弊端，因为只要有流程，就能把出错的概率降到最小，这是一个大组织所需要的。

对于一个有超过3亿用户的产品，尽可能降低出错概率，才是首选。

整个集团有很多部门，开展工作的第一步就是找对人，如果你能非常高效的找到对的人，至少能帮你节省三分之一以上的时间。

最直观的感受就是，你找到A，A说这件事应该找B，然后B说这件事他不负责了，让你找C，C说你们这个事业部的需求是D负责，于是你找到D，D说沟通需求先在线上系统提交需求并发会议邀请邮件。

就这样，问题还没开始解决，你已经在内部沟通工具上打开了至少四个以上的聊天窗口，多的时候，可能是十几个，并且，大部分情况下无法马上进入具体的沟通环节。

京东内部使用一款叫“咚咚”的沟通工具，自己研发的，能搜索到集团除东哥外的所有人，但有些部门的名字跟部门内具体的人负责的事似乎又很难对应上，所以找人是一件非常痛苦的事。

如果是新人，这个痛苦的过程至少持续一个月以上，如果有“老人”的帮助，效率相对高一点。

02 升级

在组织结构上，从CEO下来，划分几个事业群，群主都是VP或者SVP级别，然后每个群有自己的多个业务部，业务部的负责人都是总监级，总监下直接就是经理了，然后就是普通员工。

当然，在内部组织结构明细中，不管是VP还是经理，都只有“机构负责人”这一个叫法，至少你能在内网查到的岗位显示的都是这个。

所以，需要根据组织结构的层级来划分到底是VP、总监、还是经理。

比如一级部门负责人，也就是事业群老大，和二级部门负责人，比如某事业群下属的一个业务部或者产品研发部负责人，都是叫“机构负责人”，只不过他们各自负责的“机构”大小不一样。

这种划分方式，会有一种扁平化的错觉，至少在内网看到的，除了普通员工外，就只有机构负责人这一个级别。

因为协作部门太多，当不同需求方对同一个部门的资源有占用时，就涉及到资源分配的决策了。简单说，就是到底先做谁的需求，以及是否追加资源赶工完成。

当双方的直接对接人无法达成一致时，内部有个说法就是“升级”，升级到高一级的领导去沟通和决策。

比如一线员工在需求沟通清楚的前提下要压缩排期或争取优先级，而实施方在现有资源下无法满足时，就会升级到他们各自的上一级去处理，如果还无法达成一致，就再升级一级，最高当然就直接到东哥那了。

这种“升级”机制保证了一件事情的顺利推进，避免过多的扯皮，至少别卡在那，所以大家习惯了有问题尽快“升级”，能保证事情的高效推进。

但这种高效是相对的，如果升级层次太多，其实也是一种低效，因为每个级别上都相当于对事情的重复理解。

内部有个打趣的说法，“今天又要跟什么部门的谁谁谁撕一下”。或者是，“有问题尽快升级”。

03 业务方和产品经理

京东是一家业务驱动的公司，所谓的业务驱动，其实就是内部事务的推动和决策方，大部分情况下都是业务部门。

在京东，对业务部门有一个昵称，叫“业务爸爸”，当然，只是开玩笑的叫法。

作为一个电商平台，业务的目标通常比较明确，那就是GMV。并以此为核心衍生出很多不同阶段的细化指标。

当需要达成某一指标时，随之会产生一系列的产品需求，此时产品经理们就登场了。

在京东，产品经理分为很多种，像我们属于研发序列的，叫做“技术研发产品经理”，至少这是官方叫法。

之前还有“业务产品经理”，其实就是业务接口人，他们与真正的业务对接，梳理需求后统一跟技术研发产品经理沟通，然后技术研发产品经理再设计产品方案并对接研发。

相信你已经感受到了，技术研发产品经理在这个过程中是一个什么存在。上游对接业务人员和业务产品经理，平行对接UED设计，下游对接研发团队。通常情况下，这是一个理想流程。

实际情况下，大部分技术研发产品经理是夹在多方之间，对于一个需求，在业务期望、设计期望、研发期望之间权衡。

如果涉及到关键决策，最终需要经过业务负责人的拍板。

当然，会有声音提出，产品经理应该更懂业务，产品经理需要有独立的想法并能推动业务和研发。对于这种美好的期望，确实值得尝试，但一个组织自然形成的工作方法和共识，不是单方面的期望能改变的。

会有很多人不习惯甚至不适应这种氛围，产品没有决策权、没有话语权，做的都是定制化需求，没有成就感。

就算这样，在很多场景下，还是会归结到一个核心点上。产品决策权在哪一方，哪一方就是真正的产品经理，不取决于职能和职级。

如果产品比业务人员还懂业务，自己就是大产品经理，如果业务人员比产品经理还懂产品，那他来负责产品也顺理成章。

为什么现在越来越多的人强调全栈产品经理，并不是说产品经理要全能，而是在本职工作的全流程中，能运用专业知识进行有效决策。

04  产品经理的额外工作

在京东这样的大企业，有一个好处是小公司无法比拟的，那就是对于一件事的全流程严谨性把控。

前面有提到，通过机制去保证出错的概率最小。

尤其是一些对法规政策有依赖的业务，任何一个需求都需要先经过法务的评估。而在这个过程中，产品经理需要先与法务进行方案沟通，得到法务确认后方案才能继续往下进行。

比如我们做的医药业务，在线上进行处方药预约，国家是有严格控制的，不是由着业务或产品的自主发挥去随意调整的。

所以，当一个方案被提出时，产品经理需要让法务理解其内在诉求，法务会结合对法规的理解，做出专业的判断，以此将平台风险降到最低。

在这个过程中，产品经理有机会对这个行业规则有深入的理解，这看似是一件很枯燥的事，但这就是深入理解行业和业务的契机。

除此之外，一个需求在推进时，产品经理需要与财务、税务进行对接，因为是交易型业务，所以钱怎么收，收到那个主体，如何分账，如何开票，这些都是产品功能背后的业务逻辑。

至少，把这个流程走一遍，你会知道这个生意的全流程是怎么走完的。

搞定财税法之后，就会进入方案的可行性对接过程。这里就会涉及到如今非常火的一个概念，中台。

05  中台

如今，大公司都在做中台建设。从 2015 年阿里首次提出中台理念到现在已经过去了 4 年，包括阿里在内的腾讯、百度、滴滴、头条等大公司都在打造自己的中台。

去年是京东重点进行中台建设的一年。有一段时间，整个交易线的各个部门都在进行组件化升级，至于很多业务需求都为此让道，构建中台能力，是公司战略级调整。

在过去一年多的时间里，我虽然没有深度参与到中台建设的战役中去，但作为协同方，也深刻感受到这一变革的发生。

那中台到底是什么？以我在实际工作中对接过的京东中台、以及自己的理解来看，主要有这么几点。

1、组件化

组件化是一个技术名词，通常是指将一些共同模块抽象出来实现复用。简单说，就是不重复发明轮子。

在大公司里，业务线非常多，涉及到的同类产品需求也很多，如果每次都开发同类模块，对研发资源的浪费是巨大的，而且也不利于后期维护和整合，尤其是对于复杂系统，高耦合直接导致系统可扩展性极低。

所以，将通用组件进行抽象，形成公共服务，将这种能力赋给其他业务使用，对垂直业务而言，只要接入这种能力，就能实现自己的大部分需求，而不必重复造轮子，进而节省资源、提高效率。

这样的好处主要体现的灵活性上。要知道，在大公司会形成一种“公地效应”，也就是同一个职能部门资源会被多个需求方使用。就像一块公共用地，大家都需要，但又都不对此负责。

比如作为京东系统核心的交易流程，内部称为“黄金交易流程”，也就是从商品详情页开始，涉及购物车、结算页、收银台、订单等核心交易模块。这些系统都是独立的团队在支持，而且会同时支撑多个业务。如果每次都为了实现业务需求和重复开发组件，那系统维护成本就非常高。

所以，将通用能力封装成组件并对外使用，降低自身复杂度的情况下，满足需求方的使用效率，就成了降本增效的首选方案。

2、平台化

说起中台，不得不聊聊京东的交易中台，也就是负责订单从生成到履约完成的各个部门集合。

如果对电商系统比较了解的同学知道，用户提交订单后，关于这个订单的生命周期变化，会有很多个阶段和状态。

最简单的，用户提交订单并支付成功，这个订单会被打上各种标记，这种标记主要是供下游系统来消费识别的，目的主要是区分业务类型和识别特殊规则。

因为业务太多，卖3C商品的业务和卖药品的业务可能存在很多不一样的业务规则，而这些不同的业务都使用京东的同一套交易系统，所以通过各种标记来区分和做特殊规则处理。

虽然有特殊性，但整个交易中台提供的服务都是一致的，不管是订单生成与流转还是订单拆分，在交易中台的核心系统逻辑里提供的都是平台服务，并不会为某一个业务做一套单独的订单服务，只会在区分业务逻辑的分支里做特殊处理。

所以，这就是中台的第二个特性，平台化。

不管是交易中台还是数据中台还是AI中台，提供的服务和能力都是通用型平台服务。涉及到具体的特殊业务逻辑，都会在满足平台规则的前提下做特殊处理，并不会因为特化的业务规则而去破坏平台属性。

为了保证平台性的特点有两个角色非常重要，一个是对系统逻辑非常了解的架构师，第二个是对业务规则非常熟悉的产品经理。

前者主要从系统架构的角度考虑平台的扩展性，不因为特殊业务需求而破坏平台规则，并且在不改变平台基础架构的情况下满足业务规则。

我经历过几个业务需求，提给中台后因为涉及到比较大的调整，最后就升级到各方的架构师进行评估，如果架构师还搞不定，就需要升级到集团的技术委员会了，那里就是京东的技术决策大脑。

后者主要对业务需求进行评估，通常情况下，需求方会带着自己的需求或者方案来与中台产品经理沟通，如果中台产品经理全部照做，那平台性无从谈起。

所以，中台产品经理在保证平台性的前提下，需要帮助需求方梳理方案，站在中台的角度提出可行的产品方案。

在过去这一年里，因为做的几个项目基本都是涉及到京东系统全流程的，所以我跟京东交易中台的各环节打交道比较多，对此感受还是很深的。

3、灵活性

中台最大的优势是什么？在我看来就是灵活性。

阿里之所以做中台建设，起因于 2015 年马云带阿里高管去参观芬兰游戏公司Suppercell。关键启发在于他们的中台能力能快速支持不同游戏的开发，这种灵活性能让不同的作战小分队快速响应并推出自己的产品。

在京东，这种灵活性还没有完全建立起来，对需求的及时响应和快速支持还有一定的提升空间，但我觉得，这条路是对的，走下去就会日渐精进。

在“黄金流程”体系中，不同的模块也有自己的中台，比如购物车中台、结算页中台、订单中台。

在普通用户或者对电商产品不太了解的人看来，购物车和结算页就是两个页面，能体验到的功能也不多，但从产品和系统的角度来看，这两个模块是前端交易流程中比较复杂的两个模块了。

在京东，单拿购物车来说，购物车中台和前台是独立的两个部门，中台主要负责购物车的业务逻辑，购物车中台除了支持主站购物车外，还有很多垂直业务的购物车逻辑，比如我们做的医药业务。

光是京东主站的购物车，就有上千台服务器在支撑。如果想在主站购物车加一个按钮，就不仅仅是一个页面交互或视觉的变化了，而是整个购物车中台的承载能力和架构调整。这就是在大公司才能感受到的产品体验。

而购物车前台，也是我们经常打交道的部门。就是你们看到的功能层面的交互和视觉，这也是一个单独的部门。

只不过他们属于独立的前台体系，包括了商品详情页、结算页、订单这些模块的前台交互和逻辑，都是归属于前台体系。

06 闭环研发

在京东，有些业务有自己的特殊业务逻辑，对应的产品需求也比较个性化，所以会有些产品逻辑是自己独立开发的，然后以H5的方式接入到商城主站去。

比如我们做的医药业务，并不是和主站其他品类一样是纯粹的电商交易，还包括了例如问诊、处方上传等特殊逻辑，所以并不能完全复用主站的交易逻辑。

在产品上，我们的购物车和结算页以及对应的订单模块都是自己独立开发的，只不过看起来和主站的页面和流程长的一样。

但分属的产品设计、技术开发和维护都是在事业部内的产品研发体系，这种在事业部内的产研体系就叫做“闭环研发”。

每一个闭环研发体系，就像一家小创业公司一样，对应自己独立的业务，自己设计产品并研发，能复用京东主站能力的就尽量复用，比如接入中台能力。

所以闭环研发体系的产品经理，需要做很多对接工作，或者说叫“方案整合产品经理”。

在闭环研发体系内有个好处，就是一部分涉及自己业务的需求可以自主研发，要知道，如果依赖外部产研体系的需求，沟通需求和排期是一件很痛苦的事。

如果中台建设得足够好，相信未来“闭环研发”体系可能会逐渐被中台所取代。

07 数据

京东有 3 亿多用户，这次 618 全站交易额 2015 亿元。这个体量放在互联网圈已经是一个超级平台了。

不管是流量还是交易额，每天都会产生海量的数据。每一个产品细节的调整，很快就能得到数据上的反应，这就是大公司的好处，能通过海量用户去检验产品结果。

埋点、提数、看数，就成了我们平时工作中的一个必须环节，任何产品需求的上线都需要进行数据埋点，集团有专门支持数据埋点和处理的团队，也有专门的数据平台，或者说叫数据中台。

在京东，数据分为两部分，一部分是业务数据，比如交易额、订单量、毛利额、按品类分布的各项业务数据指标等；另一部分是产品数据，比如活跃度、点击量、页面转化率、跳出率等。

对于业务数据，有专门的经营分析部的数据工程师进行数据提取和分析，业务人员通过内部的数据平台分权限查看自己业务的数据。

而产品数据，可以通过自己埋点进行提取，至于具体要分析和验证哪些产品环节，可以根据自己的需求进行提数，也可以自行开发自己的数据可视化工具。

总体来看，京东还是一家比较注重数据的公司，尤其是对于一些业务决策或者产品决策，通常也会优先通过数据表现来做决定。

我在京东做了什么

在京东这一年多的时间里，收获还是挺大的，在一个大平台的好处是每一次调整都能通过用户的反馈和数据来验证。

此外，对京东整个系统有了一个全面的了解，知道一个大平台的产品和技术体系协作是如何完成的。

我在京东这段时间，做过的项目大大小小也不少。

刚去的时候接手的是京东医药旗下B2B业务“药京采”的一个地勤人员移动CRM工具，刚接手时，这款产品基本处于不可用状态，地勤人员反馈也不好，所以我的策略就是重构。

在产品结构、业务逻辑、交互和视觉层面整体重构，大概花了一个多月的时间重构完成，地勤人员的反馈和工作效率直线提升。

后来又接手了一个与宿迁医院合作的项目，主要是基于微信服务号提供在线问诊和购药，这个项目后来因为没有运营起来，一直处于搁置状态，算不上一个好结果。

最后，我参与程度最深也是负责时间最长的项目，就是京东大药房。

京东大药房是一个B2C的医药电商模式，兼顾京东自营和开放平台（内部叫POP）。如果你在京东上买OTC的药品或者预约处方药，使用的就是我们的产品。

不同于京东上的其他品类，药品是一个很特殊的品类，因为涉及到人们的用药安全，国家对这块的监管和要求比较严。比如，药品有独立的医药仓，跟其他商品不能共用一个仓；医药的ERP和WMS（仓储管理系统）需要符合专门的医药系统规范（GSP）。

这个业务体量在近两年增长比较快，在医药电商领域的直接对标就是阿里健康大药房。

业务层面，有独立的业务运营团队，主要包括采销和运营人员，一方面与供应商对接，另一方面进行线上线下的营销。

产品层面，京东大药房虽然是在京东主站（App、PC、微信、手机QQ）内，但除了商品详情页以外，涉及到购物车、结算页、收银台、订单等模块都有定制化或自主研发。

除了用户端之外，还有一些后台运营系统，比如处方审核后台等。

回顾过去这段经历，在京东大药房这款产品上，我主要做了三件事。

第一件，让江苏宿迁的用户在京东买药能使用医保支付，也是大型医药电商平台首次实现在线医保支付，未来也在拓展新的城市接入。

第二件，京东大药房OTC商品的交易系统整体接入京东主站，能实现和主站商品共同结算。

第三件，京东大药房处方药在线预约全流程的体验升级，包括对功能、交互、视觉的整体改版。

做产品，唯价值至上。我一直认为产品经理的使命就是创造价值，而价值具体体现在用户价值和商业价值上。

实现在线医保支付具备战略价值，OTC接入京东主站具备业务价值，京东大药房处方药全流程体验升级具备用户价值。

其中，前两者是商业价值的具体体现，而最后一点是用户价值的落地。怎么理解呢？

医药零售是一个规模超过万亿的市场，而医药电商的渗透率目前还不高，随着国家医改的深入，医院处方外流已经成为趋势，这给很多医药电商平台带来了机会，京东大药房正是在这样的背景下诞生。

而在线购药如果能使用医保支付，不管是从用户获取还是业务拓展都会给平台带来先发优势，随着更多城市的接入，这个优势会逐步放大，所以这是一个具备战略价值的事情。

如果你之间在京东上买过OTC的药品，一定知道之前药品和普通商品是不能一起结算的。这样不仅需要重复支付运费，而且很多促销活动也不能同时享受。

实现OTC药品和普通商品一起结算，不仅从用户体验上实现提升，而且对业务实现增量发展带来了机会，是一件具备业务价值的事。

京东大药房处方药预约流程体验升级主要为用户带来更好的用药体验，这一点就不多说了。

这几个项目都牵涉了内部大量团队的参与，最多涉及十几个团队上百人耗时三个月的协作，是一个比较大的项目了。

在这个过程中，我和团队小伙伴几乎要和商城涉及到交易系统的团队和部门全部沟通一遍，并且要与他们确认新方案以及与线上方案的兼容。

这个体验好比在一辆快速行驶的汽车上逐个把零件都换掉。当然，参与过后，收获也非常多。

我离开以后，京东大药房接下来如果深入打磨，其实还有很多事情可以做，最优价值的一件事我认为就是引入健康科普内容，作为辅助用户决策的一个产品，可以极大提升用户体验和业务转化率。

这段产品经历，算不上做了多大贡献，但从年初制定的产品方向来看，这个业务和产品都在朝着既定的方向在前进。

过程中难免有困难和纠结，只要在保持做正确的事，哪怕慢一点，也是在做价值增量的事。

京东的产品文化

2018年5月份，京东举办了首届产品经理文化节，试图打造产品文化，鼓励产品经理能具备更多的主动性，希望通过产品驱动业务发展。

期间，在一个论坛上，一众产品技术和业务负责人大谈产品经理文化，很多灵魂拷问至今还印象深刻。

后来，这届产品经理文化节就真的成了“首届”。

说实话，京东并没有打造出来一个合适的产品文化，产品经理更多还是一个业务辅助角色，并不是说这种形态不好，可能这是符合这艘航母前进的最佳组织方式。

在内部，产品经理的话语权并不高，至少在我能接触到的范围内，产品经理话语权往往都在业务之下，说白了，关键决策还是得听业务的。

京东不是个例，我接触过很多产品经理，其实在很多业务主导的公司里，产品经理和业务的定位始终如此。

这个问题的核心，在于资源掌握在哪一方，以及谁在为公司创造直接价值。

京东是一个超级货架，现在是一家以技术为主导的零售服务商，尤其是京东的自营业务，其实就是传统零售业务的线上化，而零售业务的参与主体以及决策主体就是业务执行者。

因此，对应的企业资源和主导性自然由业务执行者掌握，而产品经理和技术人员则是为达成业务目标保驾护航的关键角色。但主导性不是由主观意志而转移的。

同理，其他行业应用公司也是如此。所以，刻意去在乎产品驱动或者产品主导其实意义不大，最终状态下，产品经理主导业务，那产品本身就已经成了业务。这是一个动态协作的过程。

在京东做产品算不上特别幸福，但这个痛苦的过程也能收获很多如何做生意的知识。

除此之外，京东也是一家过度依赖老板的公司，我经历过很多关键产品决策，最后都是自上而下的结果，动员基层的创新机制不足。

似乎大家都习惯了“升级”，很多大小决策最后都通过这种机制来完成，无疑也降低了主观能动性。

产品文化不是一句口号，也不是一个理想状态，如果产品对业务理解足够深刻，这种自我感觉的“被动”或许也不会存在。

如果业务能更多信任产品，能形成产品思维，创造的价值也一定会更大。

接下来的计划

离开京东的原因，是因为这个业务和产品接下来的发展，与自己的擅长和接下来的规划会有一些冲突。

如果你有互联网医疗背景的产品经验，且对京东感兴趣的话，我可以帮忙推荐。

未来，我仍然会在产品路上奋力前行。也希望尝试更多的产品类型，以此去拓展自己的边界。

做产品这么长时间以来，在互联网医疗领域深耕了5年，对互联网医疗各个环节的业务和产品都算比较了解了。

在这个过程中，对于产品的通识能力也得到了很好的实践。接下来，希望能把这套产品框架应用在更多的产品领域。

接下来，我会选择先沉淀一段时间，也算是对过去几年的一次复盘。把自己做产品的思维、方法、心得和踩过的一些坑系统化梳理一下，能形成一些可供参考的经验或者分享。

希望自己能对这个行业做一些贡献，不仅是通过产品去创造价值，也希望能通过自己的经历去帮助更多人。

这段时间，我也会关注新的机会，说不定哪天，你会在一个新的领域发现我。

以上，就是我在京东 448 天的一些感受，言论仅代表个人。

最后，作为一个京东人，感谢这个大家庭的善待。祝福京东健康，祝福京东！

凡是过去，皆为序曲！