产品经理的角色复杂且要求多面，他们需要与公司内各个部门协作，处理纷繁复杂的需求，并在有限的时间里做出最优的产品决策。这篇文章深入探讨了产品经理的挑战、业务与产品之间的关联以及如何在不同的业务周期中成功导航。

聊的是产品，不是产品ER。

01

在研发部门里，经常能听到这样一句话：牛的产品经理太少了；

这句话对，但是对的不全面，不是牛的产品经理太少了，而是所有岗位牛的人都不多，因为大部分的我们，毕竟身处普通人之中，倒腾着相对普通的工作；

为什么这句话被提及的最多？

因为产品几乎聚焦了公司的全部业务场景，这句话背后的意思是，产品经理几乎要和公司所有部门的人打交道，毫无疑问：

人，才是最复杂的。

当公司的领导层，各个部门的话事人，都说有多个紧急的需求，此时研发部门又说有多个技术迭代要排期，在有限的时间内，需求数量和复杂程度呈指数增加。

抛开这些泼天的需求本身先不谈。

通常职级高则提出需求的优先级就高，在真正落地需求本身时，可能发现绕过了真正紧急且重要的需求，实现了一众花式转圈的水印功能。

等到复盘总结的时候，摆着苦瓜脸，看着惨淡的数据，不由自主的怼上一句：牛的产品经理太少；谁还会真正考虑，产品是所有人以身入局设计的，甚至是添乱添堵。

产品岗位的难度大，是一件众所不周知的事情。

有时候甚至连产品经理都不一定拎得清问题在哪里，然而冤的是，问题爆发的表层原因都是围绕产品这个具象的维度。

02

产品做的成功，是多个领域多个维度综合性的结果，做的失败，可能极个别维度就够了。

这就要求产品经理的能力要覆盖多个维度。

在老板眼里，产品经理要懂行，在销售眼里，产品经理要懂市场，在运营眼里，产品经理要懂营销，在研发眼里，产品经理至少要理解技术；在产品经理的眼里，虽然这些东西都需要去了解，但是这些提需求的人，未必有意识去了解产品。

这就是常说的：没有同频共振。

最骚的是，其他角色都指望产品经理去同频自己，很少去反思如何共振产品，使多方保持在同一个频道上，产品本质是要聚焦业务，只有都真正站位于业务本身，才有可能真正达成组织间的共识。

达成共识的最佳驱动角色就是：产品经理。

用户，业务，运营，研发，数据，销售，项目，通常都是由产品经理牵头团队间的沟通和协作；其中任何一项能做到出色已实属不易，而产品要从业务角度出发，快速的在不同维度对接和统筹，门槛相当的高。

没有用户哪来的业务？没有业务哪来的产品？没有运营哪来的用户？没有研发哪来的产品？没有数据哪来的方向？没有销售哪来的营收？没有项目管理哪来的效率？

没有佯攻，全是主攻。

互联网行业的黑话来表达：产品经理需要高认知，这种能力是极难构建的，门槛可能高到没有。

03

产品影响的最大因素，很多时候都是来自领导层，或者说是老板，通常来说越是懂产品的老板，产生的影响越大，围绕产品可以讲的故事太多了，注意力自然就会放在上面。

老板经常会说的话：

用户群体的核心需求，业务的核心商业模式，公司所能链接到的核心资源，以及实现整个业务流所需的成本和营收方式，构成商业的顶层逻辑。

至于所谓的使命，愿景，价值观，都是佯攻。

当这些顶层的商业设计集成到产品时，很容易导致产品被牵着方向迭代，从而降低其它维度的权重。

有很多失败的产品案例，最初的设计都是不顾一切先跑通核心业务流，然后想着经市场验证后再逐步迭代，这通常是来自领导层的意志，但是当下的互联网市场：

不会为一个紧赶慢赶才”初具人形”的产品买单。

于产品而言，实现业务流程的尺度如何把握，在此基础上如何做取舍来提高产品的成功概率，很考验对产品和业务周期的合理把控。

从业务考虑，产品初版做到什么形态符合用户预期；从产品考虑，业务孵化期做到什么程度满足用户需求；统筹管理好两者的进度，才有可能放大业务的可能性，提高产品的存活概率；

参考两个典型的产品：出行和办公；

某打车软件刚上线的时候，操作简单并且优惠力度极大，精准踩中用户的出行需求，快速完成市场的占领；某办公软件刚上线的时候，基于相对完整的生态体系和云端服务能力，极大提高了办公的协作效率。

有的产品走极简主义，但是精准解决用户出行难题，有的产品需要考虑整个业务场景，提供整套的解决方案。

当然，也有来回摇摆的产品，未上线就穿越到周期结尾：消亡。

04

在不同的业务周期中，会产生不同的需求，在迭代过程中，如果需求不能高质量的实现，产品经理也会时不时的吐槽几句：

影响”用户”体验。

这句话在讨论过程中，出口的频率略微偏高，但是更多时候大部分人都会陷在一个误区中，所谓的”用户”体验只是”产品”体验的一个维度，

产品体验包括用户，领导层，投资方，商务运营研发等等。

说一个很简单的产品设计逻辑，视频网站提供的高清追剧资源，这些是用户的核心需求，但是VIP是用户需求吗？SVIP是用户需求吗？全集且免费的视频直接抬出来才是用户的极致体验，这些产品所属的公司层面不知道吗？

都知道，但是做不到。

所以，在考虑需求的时候，不要轻易拿”用户”体验作为支撑的理由，把”产品”体验抬出来，既华丽又朴实。

如何迭代”产品”体验，才有可能穿越业务周期？在【孵化、验证、成长、成熟、衰退、转型】的不同阶段，周期变化的过程中，对于不同维度的依赖肯定是不一样的，前期看产品和业务，中期看运营和技术，后期看沉淀和方向，在这个过程中，基础原则就是：

客观，尊重常识。

从主观上的感觉来说，这个原则并不复杂，甚至比较简单，但是简单到一定地步就是极尽的复杂，大部分互联网的产品或者项目，都在各种想当然的主观意识中被优化掉。

这里也可以参考一个产品案例，国民级社交软件在发展阶段，是如何做到老老少少都会使用的，每次产品更新迭代都会被架在各种热搜上。

业务，产品，技术，运营，商务，都是主攻，只是在不同的阶段，适当演了下佯攻。

05

在很多产品周期中，都出现过这样一个魔幻的现象。

【哎…】团队的产品不行，技术不行，运营不行，在项目研发阶段，能应付的就先应付着，把很多复杂耗时的核心流程优化掉，就图一个：快。

团队搭建好的当天，产品就应该上线。

【哎?】随着产品研发进入深水区，或者上线验证用户群和市场时，发现很多核心需求的缺失，导致无法拿到关键的数据和结论，再想回过头找补，发现类似的竞品已经铺满了。

产品晚几天没上线，感觉天都能塌了，产品上线几天，发现天真的塌了。

【哎！】对于当下的互联网行业现状，一旦感觉产品成功的机会渺茫时，大多数企业都会选择直接裁掉项目组，从而避免投入到最后”打水漂”的风险，对于惨淡的当下和可能更惨淡的以后，只能选择及时止损。

而对于被裁掉的项目组，以及可能解散的企业来说：

在下个公司和产品周期中，还是要说一句：你看，又是产品的锅，重复了一遍又一遍。