产品方法论之“三位一体”法

爱吃糖炒栗子 2023-07-26 03:03:08

又到了一年一度的秋季晋升了，评审期间翻出往期的晋升文档，发现其中有好多内容其实可以拿出来分享给大家的，毕竟来自真枪实弹的方法论，更接地气，也更有人情味~

一、我要分享一个什么样的方法论？

这次分享的方法论来自我还是初级产品经理时，根据工作内容总结的一套方法论。

彼时，我作为初级产品经理，已经开始负责一些中小型的项目了，并且开始根据业务提出的需求，结合自己的产品sense，凝结成产品需求，进行评审上线。

此时，一直有个很靠谱的产品大拿在带我，我有什么问题也都和他知无不言（多说一句：这很重要，在我们还是小白的时候，一定不要不好意思，有问题一定要及时暴露，自己闭门造车是无法成长的）。不过，我也踩了很多坑，有过被质疑，有过自我怀疑。幸运的是，这些坑最终没有困住我，而是促成我发现了一些产品经理这个岗位的规律，并最终内化出了一套方法论。

这套方法论也成了我晋升材料中的一部分（当然也成功晋级啦）。现在我就结合我的经历，来拆解我的方法论。

二、需求来了，无从下手怎么办？

假设你是教育类APP的产品经理，这个产品姑且叫做【学习真好APP】。

在Q1的某一天，你们的学科老师提了个需求，要做引流课的活动，进行招生引流。而你是刚入职2个月的产品经理，产品业务以及产品流程都已了解，突然有这么个需求让你做，并且规定1周内给出方案，1个月内上线。

其实真实的业务场景就是这样的，业务的需求都是没有边界的。通常业务方只抛出个需求，也没有目标和价值，也没有具体的实现形式，只是说明这个功能的一个需求点，并简单交代了上线时间（有时间还是那句最头痛的“越快越好”）。

这个时候应该怎么剖析这个需求呢？

其实这个时候，你要遵从你的内心，说出一句“什么玩意”。不是玩笑哦，如果你不清楚这个需求，首先要想的的不是怎么做，而是为什么。所以，需求来了后的第一步，就是求证。

对于产品经理来说，产品最重要的是什么呢？我认为是产生价值，没有价值的产品就是废品。

在需求层面，你是否了解它的价值呢？如果业务给的需求没有标的价值，你第一个要考虑的，就是这个需求的价值。

引流课对于公司的价值是什么呢？弄清楚了这个问题，才算是明白这个需求的价值。终于，你带着这这个问题，与学科老师一阵唇枪舌剑，彼此对于这件事情的价值达成了一致。

对于公司，引流课可以为公司在线课业务带来新的用户增长，增量用户作为用户池，为正价课导流。【学习真好】作为公司2C业务的重要的出口，做这个需求责无旁贷，学科老师需要为引流课输出内容，保障课程质量。

价值意识和业务对齐后，就进入到产品经理的主场了。产品经理这个时候无论title高低，都要有个大局意识。你不是一个人在战斗，你要利用一切资源完成需求的核心目标。在做需求的时候，你要考虑都涉及到哪些业务线，你的需求对各条业务线的影响是什么。

举个例子，引流课不是静悄悄的在APP上线就万事大吉了，如果用户都不知道有这么个活动，等到引流课结束，他都没有接触到这个活动，怎么能保证活动效果的最大化呢？没有庞大的流量，引流课做出来只能是效果寥寥。所以，这个时候就要考虑这个活动从前期预热->活动上线->用户维护->活动下架的整个环节中，都涉及到哪些业务线的参与。

比如针对这个活动，前期预热肯定需要产品运营的参与，在上线活动前吸引用户过来，更有条件的时候，也需要公司的市场部，针对线上线下的渠道进行广告的投放。

将每个环节的业务都串联起来后，就需要产品经理梳理出一张战斗部署图，一个项目就是一场战役，要有毕其功于一役的决心。这个时候需要作出各个时期的泳道图，把每个时期涉及的业务线和各业务线的关联划分清晰。即使此时还没有比较清晰的方案，也要做到心中有数，把主流程跑通。比如可以做个这样的泳道图：

图1

业务线梳理完毕后，就到了产品专业的层面，从【学习真好】这款APP的产品定位，考虑需求的细则。

你要针对产品中的用户进行分层。比如，新用户和老用户，这两部分用户在引流课活动中的优先级肯定是不同的，因为他们能产生的价值是不同的。

新用户是我们最希望获得的群体，他们是我们产品能够持续存在下去的希望；老用户的心也不能伤害，要保证他们的粘性。针对新用户和老用户要制定不同的产品策略和产品流程。比如输出一个裂变玩法，每老带新一位，新老用户都可以减免学费或发放优惠券。再比如新用户完成引流课购买后，我们送他一些正价课的优惠券等等。

产品需求都明确之后，产品经理就要遇到一个问题，就是不清楚如何实现这种需求ROI最高。

不知道你有没有这种感觉，明明这个需求我知道是什么样子的，但就是不知道怎么做才好。比如页面内容是瀑布流展示，还是把内容聚合成一个个小集合进行显示。甚至是一些细节，比如一个商品到底展示哪些内容，都展示肯定不合适（用户没有重点，页面凌乱），展示少了又担心用户错过信息。

产品经理这个时候很容易陷入闭门造车的自我怀疑当中。其实，这个时候是考验产品经理经验的时候，有经验的产品经理做起这种确定性的需求如丝般顺滑，因为他都遇到过，他深深的知道哪种方案适合这种场景。但是，对于比较初级的产品经理，是没有这种经验的，万事开头难，到底要从哪里下手呢？

首先，建议产品经理多向外部看看，因为大部分的需求，市场上都有同样或相似形式的产品。可以货比好几家，看看其他家产品针对你接到的需求都有哪种实现形式。看的产品多了，你就会总结出很多共性的点，比如从功能框架到功能流程，有很多功能点都是约定俗成的，用户也是有使用习惯的。建议多看看主流的产品，不要追求标新立异去看比较小众新奇的产品。

主流的产品都经过市场验证，即使流程体验不佳，也都教育了用户，用户也有了使用习惯。小众新奇的产品不确定性高，如果产品体验没有被用户接受，你若参考他们的产品是有很大风险的。

当然，这个是针对初级产品经理的，由于经验少，一旦判断失误，是会减弱在研发侧威信，很容易让研发同事产生不信任感。而追随主流的方案，会在最大程度上规避风险。随着经验的积累，产品经理会逐渐总结出自己的经验，并沉淀出自己的方法论。最终在“向外部看看”这个环节，就可以不拘泥于主流产品，这个时候产品经理就可以博采众长，将其他产品的亮点为己所用。

在看过了大量竞品/同形式的产品后，还是要回到用户视角。这个时候要考虑，你的用户画像是什么样的，他们的习惯如何，你的产品上都有几类用户。

还是拿【学习真好】这款产品举例子，你产品定位是K12的教育服务平台，那么你的用户就包括了5~18岁的男生和女生，并且还要包括他们的父母。具体分析用户的颗粒度要做到精细化，比如：学生使用你产品的时间，学生家长所在的城市（一二线还是四五线），学生家长的收入情况，学生家长的职业分布等等。

在细分用户的过程也是拆解出用户痛点的过程。结合你上面参考的几种功能实现形式，就可以初步分析出你的目标用户的使用习惯，并制定针对性的产品方案。

那是不是说，我拿着制定好的方案就可以开干了呢？先等等，在敲定最后产品方案的时候，还有一个步骤要做，那就是模式分析，也就是你整个方案的策略。

在参考其他产品方案的时候，不要仅停留在“器”的方面，也要关心下“术”。一个好的产品策略，可以让方案的执行井井有条，并可提前预见到产品不同时间可能出现的情况。

那模式分析到底要分析些什么呢？其实这个模式分析，是一次针对整体方案的检验。

一个功能不是单独存在的，它一定是有着一套业务体系的，每个业务体系是环环相扣的。在上面输出的产品方案中（图1），可能只是整个产品模式中的一环。你要向上+向下去分析整个产品模式，看看有哪些环节在你的整体方案中有缺失，哪些环节会对最终的结果有重要的影响。

回归到开头的例子，引流课不只是在APP中banner位上有个入口，点击之后有个落地页等流程。还有私域流量的建立、裂变的玩法等助力活动效果的方案。这个时候就要去检验最开始制定整体方案时，有没有遗漏。因为项目是你发起的，其他兄弟部门只是配合，你不提出新的方案，他们很少有动力帮你完善（很现实~）。所以，这个时候通过对整个模式的再次梳理，把之前方案中有问题的环节进行修缮，把之前遗漏的环节补齐。

比如完善之后的泳道图可以是这样：

图2

这个时候，你的方案才做到了闭环完整，最大程度的保障落地效果。接下来就是项目立项，给各个合作部门落实需求，并制定统一排期上线了。

小结一下

上面的分析部分是“三位一体”法的第一部分，我称之为【想透】，【想透】的部分要从内到外的去考虑需求。正所谓“运筹于帷幄之中，决胜于千里之外”。我们就是每个项目中的军师角色，我们一定要保持头脑清醒，思路清晰，这是我们迈向专业化的重要一步。

我将【想透】这个过程抽离出两个部分：

1）入里

公司层面考虑价值：从公司层面出发，考虑需求对公司可以产生的价值，在很多公司的企业文化中叫做：向上一层思考。
业务线层面考虑依赖的端侧：梳理出所需要的各支持业务线，并初步梳理出实施方案。
产品层面考虑需求（用户体验）：需要从产品的用户出发，考虑需求是否符合产品定位，并对用户做好分层，具象出分层的用户需求，实现用户体验与业务需求的完美契合。

2）出外

需求层面考虑竞品/其他优秀产品：在具象出的需求中，有哪些在其他竞品中已经直接实现，或间接实现的。他们目前做的情况怎么样，有哪些方面是需要我们借鉴的，有哪些方面是我们需要规避的。
用户视角出发定位需求：在考察竞品/其他优秀产品实现的方案过程中，如何判定哪种实现方案适合我们呢？需要我们从自身的用户视角出发，通过我们对自身产品的用户画像，进行需求定位。
业务模式：竞品/其他优秀产品的业务模式都有哪些可借鉴的点。这个是产品实现形式中上一层的设计思路，是我们通过完成整个实现方案后总结出的模式。

三、需求都准备好了，怎么推进啊？

这个恐怕是很多产品经理在需求评审以及项目推进过程中一直盘旋在脑海中的问题。在产品经理生涯的初期，很容易因为在需求推进的过程中有所遗漏，导致项目出现风险，有些风险甚至会被定性为事故。这也是产品经理总是背锅的原因之一，排除其他人为因素，产品经理自身的考虑不充分，背锅真的是有苦难言。

判断一个产品经理是否“靠谱”，就是通过一次次需求的落地效果去强化个人标签的。

此时首先要考虑的，就是“人”。产品经理作为需求分发的统一出口，需要将信息传递到所有涉及的人员。其中，不止是所负责业务线的产品经理、技术人员、测试人员，还有相关联业务线的产品经理，以及相关的技术人员、测试人员以及其他相关联人员。

确认了人员后，就要保证信息的高效传递。

根据需求的大小，会有不同的传递信息的方式。如果是比较小的需求，可以在一次需求评审中将相关联的产品经理、技术人员、测试人员叫到一起进行需求的传递。然后根据传递后的结论同步到相关的人员即可，比如：业务人员、产品运营、相关联业务线的产品经理等。

如果涉及的业务线较多，就需要先和关键业务线的产品经理以及其他关键人员（比如：关键的技术owner、测试owner、产品运营、业务人员等）先同步需求，需求内容达成一致后，即可启动各业务线的需求评审，并制定后续的推进计划了。

在信息的传递过程中，需要按照顺序，由高到低（公司意志到业务内容，由高层到执行层的顺序），由浅入深（让受众循序渐进的了解需求）。比如针对不同的同步场景（是业务人员、产品人员的同步场景，还是技术人员的同步场景），制定不同的信息传递方式。不过无论是针对哪类人群，都是要把项目的背景、目标、价值传递到位。

我见过很多产品经理在和技术人员进行需求评审时，把背景和目标描述的不清晰，导致技术人员在不清楚背景和目标的情况下，提出利好自己的技术方案，导致最后项目的结果走样。其实在一个晋升体系完善的项目团队中，产品技术是可以做到心往一处使的，每个项目的背景、目标、价值都是独一无二的，一定要让受众感受到项目的价值、并了解到项目的背景、从而和产品经理达成一致的目标。这样后面需求内容的落地才能做到水到渠成，技术人员和其他相关联人员才会尽自己所能地去完成最后的目标，共同促进项目的顺利实现。

当然在信息传递的过程中，势必会有很多意料之中以及意料之外的事情发生的。

比如：你可能会预料到其他业务线最近项目比较多，可能没有时间配合你做这个功能，此时你在信息传递前就要做好项目优先级的排序，并做好方案的安排，保证在目标达成一致的前提下，进行合理的需求优先级排列。

针对意料之外的事情，比如：技术人员关于需求有不同的意见，其他业务线的产品经理觉得你的方案有问题等。当有人持有不同意见的时候，要找到分歧点的根源在哪，有时候根源可能不是方案有问题，而是在方案上针对其他业务线的部分考虑的不全面，导致项目有风险导致的。

找到分歧点后，需要进行充分的沟通，保证最后需求是朝着正确的方向前进，不要自说自话，要相信问题一定是有解决方案的，产品经理需要引导各个端口人朝向最终的目标迈进。

在各端达成一致后，要保证各端的时间是符合项目上线预期的，同时，也要尊重各端给出的时间。比如：技术开发功能的时间是按照功能点去排的，强行缩短时间，会导致提交代码的质量的不到保障。当然，缩短时间也可以靠增加人力去解决，但在不增加人力的情况下，最后结果交付质量需要时间去提供保障的。同时其他业务线可能同期有优先级更高的需求，这个时候产品经理一定要做好时间的取舍。

在需求中的信息同步完成后，项目就进入到了落地阶段。此时，产品经理切不可掉以轻心，虽然信息已经同步，但此时仍然存在变数，比如其他业务线有高优需求插入，技术侧发现重大BUG难以解决需要变更方案等。这些风险在项目落地阶段都有可能发生。

产品经理一定要做好时间表的维护，包括总体项目的进展，以及细化的每个业务线、产品经理、技术人员、测试人员的各个重要时间节点，包括：需求评审时间、提测时间、联调时间、测试时间等等。

同时一定要按照周期进行项目进展的跟进，比如：通常项目的周期是按照天进行的，那就要保证当天的一个固定时间点各个端口的负责人（通常是产品经理和测试人员）在一个统一的群组里面汇报当天的工作进展以及存在的问题和风险。通过这种每个周期性的项目跟进，最大限度的保证产品经理对项目进展做到心中有数。

小结一下

上面的分析部分是“三位一体”法的第二部分，我称之为【做够】。

【做够】的部分强调事无巨细，项目的执行阶段要把握好每一个环节。其中要处理好“人”和“事”的关系，在你每一次处理好项目落地过程中的每一个环节时，你会收获一个在工作中至关重要的标签，那就是人格魅力。这是产品经理的软实力之一，一旦建立起人格魅力，它既会帮助在面对技术人员、测试人员以及其他业务线的人员时，让他们因为你的人格魅力而对你产生信任，也会帮助你自身不断向更高的台阶跨越。

在【做够】这个环节中包含三个部分：

1）同步

人：直接相关人，包括本业务线的技术人员、测试人员等；间接相关人，包括其他业务线的人员。
事：针对不同的人，把项目的背景、价值和目标都传递到位。

2）决策

求同：在和相关人进行同步时，需要保持目标统一，并根据相关人事情的优先级进行需求的推进。
存异：当相关人有不同的意见的时候，要分析分歧点在哪，进行充分的沟通，要保证需求向着正确方向前进，最后结论要尊重各自时间（对内：要保证项目上线时间得到满足，对外：尊重客观时间）。

3）执行

心中有数：需求确定后，要明确关键时间节点（提测时间，联调时间，上线时间），并按项目周期跟进项目进度，及时暴露问题并解决问题。

四、需求成功上线了，真的就结束了吗？

其实无论需求上线后的结果如何，我们都要做好复盘。针对正向的结果，我们要做好数据的沉淀，并将方案做成案例沉淀到个人的知识库中。针对负向的结果，不要避重就轻，一定要深挖问题的根源在哪，并找到解决问题的办法，并制定风险预防机制，防止下次出现同样的问题。

对于项目复盘后产生的经验，最好能够输出一套外化的内容，输出到其他业务线。这种行为模式在组织影响力中称为：知识传承。这种能力是产品经理成长为高级产品经理必备的能力之一，如果在初期就有这种能力沉淀，后期的职业生涯会顺畅许多。

其中关于项目经验和数据的部分，可以作为案例沉淀下来，放到公共的知识库中，作为案例的结果支撑。有些项目本身在上线后是具备复用能力的，比如：在教育行业中的拍照判题能力，这种能力就要考虑是否可以打包成通用能力输出到其他业务线，帮助其他业务线更快的抓住市场机遇。

如果项目上线后没有通用能力可以沉淀，那么项目中所采取的方法是否可以做成方案输出到各业务线呢？比如：获客的运营方案，项目中所采用的技术方案，甚至项目管理方案，都可以打包成解决方案输出到各业务线。

以上只是引子，每次项目上线后对产品经理的价值往往体现在复盘环节中能够总结出什么。完成每次的总结，你会体验到从量变到质变的过程。总结过程不止是个人成长，你也会在外化经验的过程中获得更多的认可，何乐而不为呢？

小结一下

上面的分析部分是“三位一体”法的第三部分，我称之为【反哺】。

【反哺】这个环节对产品经理自身的成长有着至关重要的作用。产品经理不仅可以在【反哺】的过程中收获到个人经验的积累，还能帮助产品经理养成良好的个人习惯，正所谓：“君子博学而日参省乎己，则知明而行无过矣。”个人习惯的养成更加重要，是一个人受用终生的能力。

【反哺】包含两个部分：

1）内化（正反辩证）

针对项目正向和负向的反馈进行归纳总结，正向的反馈作为成功经验储备，负向的反馈要分析问题的根源在哪，以及如何解决，如何预防下次不再发生同样的问题。

2）外化（虚实结合）

虚：项目的内化经验可以作为案例给更多业务线借鉴，项目产生的数据可以作为案例的指导凭证。
实：项目是否可以作为通用能力复用到更多的业务线和业务场景，项目所采用的方法是否可以同样用到更多的业务线。

五、何为“三位一体”法？

上面说了那么多，各位看官可能已经发现，我围绕产品的生命周期输出了三个阶段的方法论，分别是:需求产生期的【想透】，需求落地期的【做够】，需求上线后的【反哺】。下面我就通过一张图来说明这三者的关系吧：

“三位一体”指的就是三个阶段构成了一次产品的生命周期，每个项目都是一次循环，产品经理要在这个循环的各个时期，不断打磨自己，让自己更加专业。

六、彩蛋

能看到这里的看官都是真爱了，哈哈~

由于最近整理晋升文档，发现自己之前的方法论都散落在不同的PPT中，没有系统的总结过，故总结内容结合心得方得此篇文章。

以前作为小白特别喜欢看一些关于产品经理的有关书籍，对于里面的内容在阅读时都是一知半解，直到工作一段时间之后，才逐渐理解里面说的内容。其实各位看官也不用拘泥于我说的方法论，每个人都会有自己的方法论，我的蜜糖，可能是你的砒霜。只期望我的方法论可以给你灵光一闪的启发足矣。后续我会持续更新我的方法论，这里我先透露下一个方法论的预告吧。

你是否听说过“人货场”理论？“人货场”真的是因为新零售才有的概念吗？产品设计和“人货场”有哪些奇妙的联系？下一篇方法论中，都会给你解答。其实华丽的词藻都是基于最简单朴实的底层逻辑，掌握了底层思维，再去听大佬们描绘的新业态，你就会淡淡一笑，嗯，我懂！