编辑导语：对于产品经理而言，每天做的最多的事情就是判断优先级的能力，诚然，产品决策并不是一件容易的事情，需要在正确的时间做正确的事情，这样的产品决策才是比较合适的。作者对于产品决策进行了深入探讨，一起来看看。
前段时间内推了一位交大的学弟，他毕业之后就进入互联网大厂，工作三年后即在公司做到了管理岗位，我在想，这样背景的人应该很得面试官的喜欢吧。
一面结束后，我主动找到面试官，想了解一下面试情况。得到的反馈是：他这个人的综合素质非常优秀，表达逻辑清晰说服力强，但给人的感觉是所有的思路是飘在空中，不扎实。
面试官继续给我打了一个比方：很多问题我想要得到的是一份文档，能够详细说明在产品设计中的思考，但是他给我的总是一份 PPT，框架完整，但是缺乏细节。
“在很多产品决策上，我希望他说得更具体一些，在那个阶段到底是怎么想的，面临着哪些冲突和博弈，但我得到的答案总是超出了一个产品经理的视角，是站在商业模式和团队协作角度上的考虑。这些固然是重要的，但我理解的产品经理，应该对于产品决策有更接近产品的思考。”
听到面试官的这些评价，其实我的内心也是深受触动的。对于我这样一个不带人并工作了五年的产品经理来说，我们可能正处于最好的做产品的时期：一方面不需要背负带人和管理的压力，另一方面在经验和见识上的积累，都能让我们带有更多的思考去做出产品决策。
我还记得之前从哪里听说过，对于产品经理的最高要求，是具有判断优先级的能力。而判断需求的优先级，就是我们每天所做的众多产品决策之一。
在我刚入行的时候，我工作的重点在于需求的落地。而方案本身则大多来自于对于竞品的参考，或者是老板。所以那个阶段更看重的是执行力，将确定好的设计方案推进上线，就是最大的成就感来源。
随着经验的增长，我开始为每一个需求独立地寻找产品方案，完成产品设计。成就感的来源，也从方案推进上线，前置到想出一个解决方案。但这时候也开始进入到一段痛苦的时期，一段经常被否定的时期。因为见识太少，所以在考虑上常常不周全，会被问到很多细节，总是有种“嗯？还有这个问题需要思考？”的感觉。
每每面临这样的质疑，都会回来重新思考自己的方案，不断修改，不断打磨，在这样一遍又一遍的磨炼中，逐渐培养出一种“使得产品逻辑更完善”的下意识。这种意识强调的是，你交付出去的方案，至少不能有逻辑漏洞。
当我以为完整的逻辑能够使得产品方案推进更顺利的时候，我又依次迎来了更多方案被否定的理由：业务价值不大、实现成本太高、跟整个产品当前战略不符，跟整个团队当前战略不符等等。
最终我体会到，产品决策是一件多么困难的事情，以至于它并没有绝对的正确性。很多在当时看来正确的决策，到最后由于外部环境的改变，或者是其他偶发的因素，变成了错误的决策。
错误的决策会让产品团队产生对于失败的恐惧，于是大家都慢慢养成听老板决策的习惯，甚至到后来，将重要决策的压力转交给老板，变成了一种潜规则：“天塌下来有老板顶着”，很多人会这么想。
但是在我看来，重要的事情由重要的人决策，跟你自己是怎么想的，这两件事并不矛盾，如果我们不能独立地思考每个重要决策，而是机械化地去理解上层的意思，我们做事情就很容易飘在空中，扎不到土里。
讲了这么多，到底什么是产品决策呢，用通俗的话讲，我将其理解为：在正确的时间做正确的事情。
与正确的时间相比，我们更容易找到正确的事情，因为它们更适合用某种单一的原则就能够判定。下面聊聊我心中，在做产品设计时那些正确的事情。
（1）产品逻辑完备
毫无疑问，这是对产品经理最基本也是最重要的要求。
所谓产品逻辑完备，是指当产品背后的代码开始运行后，不会出现严重的系统错误。例如某一天打开一个 app，发现页面报错，后来发现是因为产品经理忘记设计游客状态（专指用户未登录）的页面逻辑，那这个就是致命的逻辑问题。
对于新手来说，常见的逻辑完备性包括：
逻辑完备性问题经常涉及用户的非理性操作。当我们将用户作为理性人看待时，我们觉得他们应该不会这么操作，比如他们应该不会在一个富文本输入框一下子粘贴 10000 个以上的字符；但是从逻辑的角度来说，我们又无法绝对地判定用户就是不会这么操作，万一出现了这种状态该怎么办呢？
这就又涉及到一个产品经理所秉持的产品观，到底在多大程度上信任用户。
就我自己的实践和体会来说，我一直秉持的观点是：在保证系统运行稳定的基础上，给用户最大的信任。
例如偶尔会有设计同学质疑我，如果允许用户这么配置，那整个页面也太难看了吧。但我的理解是，如果他们这么配置不会导致系统崩溃，那为什么要平添各种提示、红色警示问题、校验逻辑呢？
当然，我的理解和设计的理解，是站在两个不同角色上的理解。具体到每个案例中，可能遇到的具体情况又不一样。
但我觉得，在遇到非常难以决策，并且没有现成案例可以参考，或者现成的案例本身也没有一个标准答案的时候，产品经理有时候需要有一些自己的价值坚持。
如果不是会导致系统崩溃的问题，我是倾向于信任用户的。
（2）满足用户诉求
当我做产品经理的第一天，我就被教育要站在用户的视角考虑问题。随着产品类型的不同，我们的用户也是不一样的，甚至他们的画像丰富到我们很难概括出他们到底是谁。
比如某个社交软件如果达到了一定体量的注册用户数，你便很难用一句话概括出它所有注册用户的精准画像。这时候产品经理往往会优先确定产品的目标用户是谁，他们是什么样的人，他们在哪里，他们还有哪些需求没有被满足。
满足用户诉求，很多人以为是满足单个用户的需求，比如张三觉得这个社交软件的按钮太小了，自己有时候很难看清楚，李四觉得这个软件整体的 UI 不够紧凑，每次都要向下滑动一些距离才能点击领红包的按钮。
我们经常遇到的情况是，不同用户之间的需求往往是相违背的，满足了一个人可能就得罪了另一个人，但站在每个人的角度，他们的吐槽，他们的需求却又是正确的。
这就是为什么当我们在说满足用户诉求这件事时，我们所说的不是满足某个用户的诉求，那样可能会陷入繁杂诉求的汪洋大海里。
事实上，我们说的往往是某一类用户有什么诉求，从个体推演到群体，去看看这个诉求对于群体的价值是什么，接着再去思考这个群体对于产品的价值有多大。
现实中的挑战在于，个体的诉求是明确的，群体的诉求是不明确的。推演这件事，就非常考验产品经理的功力，推演错了，就成了一个伪需求，推演正确了，就成了一次成功的迭代。
（3）合理的性价比
当产品经理在聊性价比这件事时，就好像在逛菜市场，拿着手头不确定的收益跟研发讨价还价，希望多做一些，让功能更完善一些。当我们在做产品设计的时候，总是有一种冲动，希望功能越做越多，解决方案尽可能复杂。
以过程的繁杂放大结果的价值，这是我们这个职业会经常陷入的误区。
当我们在思考成本这件事时，还是要回归到经济学的本质去思考：成本是放弃了的最大价值。
当我们决定做一个需求时，对应的研发、设计、产品同学都会花时间在这个需求上，成本并不是他们花的绝对工时，而是你们本可以用这个成本去做的其他的事情。
那我们是如何决定要做这个，不做那个的呢？这就需要一个相对统一的评判标准，这个标准就是投入产出比，即收益除以成本。
成本是很好评估的，最终都会换算成为投入在这件事上的员工的工时，再乘以对应员工的时薪，就是这件事的成本。
但收益是很难的，因为它跟产品本身的类型关系很大。例如，交易类的产品往往比工具类的产品更好衡量需求的现金收益。
但是在很多公司，在需求进行优先级评比的时候，就是会有不同收益类型的需求放在一起竞争资源，我经历过的情况是，能直接提升交易转化的需求往往会占据更多的研发资源，但是提升的效果往往又用 AB 测试的结果验证。长此以往，体验优化类的需求就会被搁置，导致很多产品越来越赚钱，却也越来越用。
我的观点是，资源需要先分配再竞争。
不同类型的需求必须要有对应的研发资源支持，可调节的是不同类型资源分配的占比。但是在每种类型的需求之间，是需要有 ROI 评估的。难以评估收益的和难以评估收益的一起 PK，对交易有直接提升的互相 PK。
如果在性价比这件事上粗暴地采用同一个标准（比如现金收益），那产品经理很有可能会在这样的规则下输出畸形的不考虑用户体验的设计方案。最直观的变化很有可能是，流量大的页面和模块，都会充斥着广告。
总结一下，产品逻辑完备、满足用户诉求、合理的性价比，是我心中一些做产品设计时的正确的准则。
但现实情况是，我们无法同时去做这三件正确的事情，因为很多需求如果按照某个准则去做了，就会违背其他两个准则。
所以很多时候需要取舍和平衡，但如何取舍、如何平衡，又没有一个普遍适用的准则，但又不可能 case by case 地去讨论。
为了解决这个矛盾，我认为需要考虑另一个重要的变量：产品的生命周期。
产品是有生命周期的，不同阶段的产品，所面对的主要矛盾并不相同。
正确的时间，并不是说产品本身所在阶段的正确性，因为阶段是一个相对客观的存在，我们在决策时是无法左右的；而是指我们所做的决策，是否能解决当前阶段的主要矛盾，可以解决那就是一个正确时间下的决策。
按照经典的生命周期理论，产品通常会有进入阶段、成长阶段、成熟阶段、衰退阶段等不同的阶段。不同阶段的主要矛盾大致包括：
（1）进入阶段：验证 PMF（product market fit）
这个阶段最重要的事情，是验证产品的市场价值，表现在能够找到产品的核心用户，能否通过满足核心用户的诉求让他们产生黏性。所以在这个阶段，对产品逻辑完备性的要求非常低，很多产品甚至只是最终形态的一个初阶版本。
但是在满足用户诉求上，必须要投入 100% 的精力，尤其是核心用户群体的诉求。只有这样，才能以最快的速度去验证产品是否具有市场价值，是否具备规模化的潜力。
最后，在性价比这件事上，因为这个阶段的资源都是 all in 在核心用户与功能上，如果保持聚焦，在我看来也没有必要考虑太多 ROI 的问题。
（2）成长阶段：增长
成长阶段最重要的问题就是增长，无论是获客还是留存，在这个阶段都是非常关键的增长指标。这个阶段对产品逻辑完备性的要求是很高的，尤其是在新用户大量涌入的情况下，当我们因为画像不清晰而无法预测用户路径时，我们需要保证每个用户在核心路径中的体验是闭环的。
当我们切换为用户视角去看待完备性问题时就会知道，如果我们本来就不是一款产品最初的目标用户群体，如果在使用体验上还存在明显的缺陷，那我们很有可能就会流失。这个场景在很多成长阶段的产品中不断重复：
在某个小众群体中传播，然后因为某个契机产品突然火了，逐渐有非常多的下载量和注册用户，最后因为核心路径上的体验缺陷，导致有不少流失用户，于是要想尽各种办法做召回，最后就逐渐衰退了。
虽然我们能理解在成长阶段需要尽快找到变现模式，需要让公司活下去，但以留存为目标的体验优化，也是必须要考虑的，所以才会说，资源需要在不同阶段动态分配。
当用户量激增时，一定会有很多的吐槽和反馈。
这时候是最难的，一方面我们的产品在逐渐被市场接受，另一方面我们受到的骂声和吐槽肯定比第一个阶段多很多。这个阶段对产品经理最大的考验，就是从大量的负面的用户反馈中，识别当前阶段最应该去做的事情。
另一方面，成长阶段的资源很可能是最稀缺的，因为人力的配置一般都是滞后于增长的，很多公司都是看到数据涨了，觉得任务多了忙不过来了，才开始申请 HC、面试、招人。而在稀缺的资源下，另一个矛盾是产品经理对于产品的规划和不确定的用户诉求会争夺资源。
依据我的经验，与规划匹配的用户诉求是最优先要被满足的，也是最理想的情况，如果不是这样，那产品经理需要从大量的反馈中得出洞见：你对于产品现阶段的规划是否合理。
反馈来自用户，但洞见来自产品经理。
（3）成熟阶段：商业最大化
在这个阶段，增长的速度可能有明显的下降甚至趋于平稳，但这也是产品跑通商业模式并实现最大化盈利的阶段。
实现最大化盈利的方式包括：放大单个经济模型的收益，降低成本。
我们经常听到的通过精细化运营提升用户的复购率，就是希望能够在单个用户身上赚取更多的经济利益，因为这个阶段已经过了用户规模快速增长的时期，所以就需要在单个用户身上实现更高的收益。这对应到日常工作中，就是我们要找到每个产品的 KA 客户或者超级个体。
而降低成本，在很多团队内的做法，就是将复杂的工作流程化，然后由机器、工具或者外包团队代替，而被代替的资源，又转移到新业务中，又开启了新产品的生命周期。
在这种背景下，在产品决策中我们就更偏向于考虑用户诉求和性价比，这个阶段的产品基本已经完善，但是在精细化运营中会有很多老用户的个性化诉求需要满足，这时候，满足这些诉求对于最终商业化目标的达成有多大帮助，就需要有明确的量化预期。
同时，因为一部分研发资源转移到新项目中，所以资源的分摊要求我们要更加考虑不同需求之间的优先级。在成熟阶段，由于产品规模逐渐扩大，现金流逐渐增多，公司可以做的事情更多了，能支持的需求更多了，这就要求产品经理更需要在看似无限的机会中，找到真正有价值的机会。
（4）衰退阶段：转型
首先有一点，每个产品都会有自己的衰退期，对于单一的产品形态来说，生命周期是不可逆转的规律。但我们能左右的是让这个产品转型变成另一个产品，从而开始一段新的生命周期。
如果产品进入了衰退阶段，也许是从营收指标，也许是从用户活跃度，或者是从市场占有率得出了这个结论，那我们需要思考的唯一一件事就是——转型。
转型意味着摸索，意味着不确定，也意味着很多沉没成本。在衰退阶段，我们需要通过尽可能小的成本来为当前产品探索出第二曲线，或者为整个公司找到第二增长点。
所以在转型中，产品逻辑一定是不完备的，如果你想要以非常完备的逻辑去打造一款为转型而生的产品，很有可能出现资金链的断裂，整个产品就彻底覆灭了。
这时候，很多公司会用的策略是，用极小的成本开辟不同的新业务，哪个业务跑起来，验证了模式，再在内部加大投入资源。
这个阶段讨论产品决策可能不太有意义了。事实上，很多中小公司在找第二曲线时，甚至在初期不会投入产研资源，而是通过低人工成本的运营，验证一个方向的潜力。
如果把这个阶段的公司比作一家投资公司，那转型期的探索就是天使轮，可能一次性会投入若干个新方向，但每个方向都不会投入很多资源。
如果一定要说产品决策在这个阶段的体现，那可能就体现在，我们要开辟哪些新业务。而这个层面的决策，就已经超出了普通产品经理的技能范围了。
本文之所以要讨论产品决策，是希望大家（包括我自己）在平时工作中注重每个产品决策背后的思考，因为惯性的力量是很可怕的，我见过很多成熟的产品经理总是以「我觉得」来开始他们的结论，却从来说不出背后的原因。
当我们是以自己的思考，而不是以自己的职级、经验、甚至权威来获得共识时，我相信这才是一个产品经理长久的生命力所在。
大力哥呀，微信公众号：大力哥，人人都是产品经理专栏作家。一个90后产品经理，已经写了6年的公众号，通过输出获得了许多意料外的成长。
本文原创发布于人人都是产品经理。未经许可，禁止转载。
题图来自Unsplash，基于CC0协议。
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。