产品经理需求池和版本树，相生相持，铺垫产品成就参天大树

Posted 2022-10-18 壹叁零壹

人人都是产品经理，但是产品经理的梯子上，各自的高度很不一样。有人才刚刚登上这架梯子，有人已经高入云端；有人费力攀爬，有人缓步款行；有人刻苦专研，有人冷静理智…正式成为产品三年，在产品的路上走了好长一段…更想着和同行交流沟通，帮助他人到我的境界，学习他人优长自我成长。

        各位看官，且看我先拆解产品经理。提前预告一下，进行产品的整体版本，我使用的方法是：先控制，后碎部，步步检核。

一、产品研发的极简过程

​树大根深

1，产品概述

产品就是一棵树的形象，从生长环境的泥土里吸收养分，一个阶段一个阶段的成长。产品也需要是一颗树的形象，在自己的成长中挺直主干，直冲苍天。在努力成长中，给人一片阴凉，呵护一方水土；即使在之后倒下，也能够提供自己的身躯，给他人以借鉴，再铺一段路桥。

2，需求池和版本树

                                                            需求池和版本树简版

抽象的需求池版本树形象，底部平台为需求池，上面分支生长开来为版本树。

借用简单的形象，就能从大局着手，看清楚一些最核心的内容。

在需求池上，本质是提供产品的生长环境。作为树的形象生长，就需要生长环境土壤肥沃，获取必要元素足够。那么，在实际的需求池构建上，就需要有广泛的意见收集，经过专业的筛选过滤，输出形成定版的需求。用户反馈，是产品深植的土壤，接触用户最大的需求及最深的痛点，最好的解决用户的问题；市场反馈 则提供当前市面的发展情况，需要相关的硬件、技术、市场环境、配套设施等多维度匹配；竞品分析，则很好地比对了自己这一个物种的情况。在信息发展跨越度很大，融合很深的现在，就需要扩展更广范围的竞品，将更多的风险和机遇预估在范围内，从而有效促进产品成长；战略规划，则是产品需要为公司的发展战略铺路，辅助公司整体战略的实现，也需要公司内部各部门的通力配合，维护产品的健康成长；技术趋势，则是紧跟技术发展，实时更新产品的内核，确保产品更具有生命力；产品设计，则是将所有的收集整理，整合到产品的具体实现上，是信息整合的升级提升。以上各个维度构建了需求池搭建的相对完善的框架，基于产品不同的生命周期、当前所处的阶段，需要给与不同维度不同的权重。

信息的权衡采纳，决定什么内容被产品当前版本吸收，这是很关键的一部分。当前范围的确定，从宏观上，确定了产品所需要的必要元素，从而筛选出来最有效的内容，促进产品快速成长。

3，需求池和版本树关键内容

在产品成长中，产品发展相似与树，但是又不同与树。树的生长经不起一段生命周期的内容完全剥离，且在树的生长过程中，原有的树干也会逐渐粗壮起来。也因此，延伸出来，产品的版本树需要能够在未来枝繁叶茂，需要在主干业务上搭建最强壮的框架。

之后的 业务会一直使用最初始的框架，也就决定了之后的产品是否能够走的更远，长得更好。这也符合，先控制后碎部的思想，更符合事情的二八定律。做好一件事情，做好最关键的部分，事情就算完成百分之八十。同样的，在产品树出现问题时，要敢于及时削掉不必要的部分。产品多余的部分在树上面就是个疙瘩，在实际的产品上，不只是消耗内部因为这个功能牵连的人力物力投入，更会在用户上消耗用户的好用度，会降低整个产品的品质。而这些最关键的部分就是，树要成长，产品需要不断版本升级来变得更好，那就需要落实，需要更高效的产品成长。也就是产品一个版本一个版本的实现，一个版本基于上一个版本的迭代升级。

在研发过程中，消耗最大的就是需求不确定，来回版本的更改。需求整理，需求讲解，UI设计，研发实现，测试验证，是一个个工作环节串联起来的。工作环节越往后靠，前面消耗的时间就越多，所以，最好的方式就是需求定版，从最开始的环节把控好需求的执行，确定最为清晰的目标。

需求池和版本树标准版本

二、需求池

（1）需求收集：战略规划、市场反馈、用户反馈、产品设计、竞品分析、技术革新

（2）需求整理：伪需求、表层需求、真实需求、兴奋需求、深层需求

（3）需求筛选：需求重要性、需求紧急度、影响范围、安全性、时间要求、技术难点

（4）需求设计：用户角色、使用场景、业务流程、使用流程、数据追踪、原型图设计、PRD文档维护

（5）项目管理：时间进度规划、产品质量验收

需求池和版本树豪华版本

1，需求整理

信息大爆炸时代，相比于信息匮乏年代的信息内容缺乏，信息的堆积和冗余并不会更简单更容易处理。经过需求池构建六个维度的信息收集，关于产品设计，我们获取了大量的信息。而从这些信息中筛选出来真实需求就十分必要。

需求整理，是对需求信息的遴选，是把非必要的需求信息剔除出去。

需求挖掘中，对需求进行层次划分，细分为伪需求、表层需求、真实需求、兴奋需求、深层需求。其中伪需求、表层需求，就是最没必要的需求。这些只是用户痛点的遮盖布，我们都没有看到真正的病痛表现。

真实需求，就是直观的展示，看到的就是需要的，这种需求就需要再度识别，或许头疼就真的只是头疼。而对于兴奋需求、深层需求，就是掩藏在头痛下的根本，挖掘到根本，最后实现的产品才会真正接近用户的需要。头疼若不是头疼，可能只是需要你的关心，那就是兴奋需求。不需要管什么头疼，对她呵护备至、疼爱有加，她的头疼就不是产品的问题，而是产品的价值！头疼若不是头疼，而是其他脏器损坏的痛觉转移，那就是深层需求。不管如何去医治头疼，最后不解决脏器的问题，头疼问题就算解决，也还有其他疼痛问题。

常见的说明，都会是更快马车的真实需求，这里换工作的生活例子看看。老板需要日周月报？是需求，是真实需求，但只是需求的表象。老板需要的是日周月报，但其实他更需要的员工的有效工作权衡证据，若是及时反馈任务进度，及时反馈异常信息，那日周月报还需要？或许这还不足够，老板为什么需要进度，为什么需要他来监督进度？因为进度不如预期，至少在之前的所有工作中，进度都不如预期，或者说是，常常他以为是这样但现实却不是这样。在深挖一点就是，他没有安全感，他不信任，那么是谁给了他不安全感呢？是管理人员的管理能力不匹配？是项目安排执行不够精准？这估计就是职场，需要事事有回应、件件有着落的根本原因吧！

替换日周月报，更好的是目标、状态、进度、预期执行结果的统计表。本周正在做XX竞品分析，正常状态，进度50%，预期明天中午十二点结束。

2，需求筛选

经过需求整理，所留下来的需求都是真实的需求，百川终到海。而所有的需求又需要排列顺序，从而决定哪些需求优先做，逐渐形成需求的金字塔。

其中筛选的重要条件包括，需求的重要性，需求的紧急度，影响范围、安全性、时间要求、技术难点等要素。依据产品的不同的阶段，公司发展的状态，产业所处的行业，当前的生产环境等会给与需求不同要素不同的比重。

整体回馈，还是要依据先控制后碎部，步步检核的原则来设定。

技术难度、安全性会在很大程度成为一票否决权的情况，需要优先确定。之后依据重要度、紧急度、时间要素等综合，按照数字打分的方式对需求的权重进行数字化，从而辅助决策。

同时，在公司进行重大决策，重大变更时，也会协调相关的人力资源倾斜来实现，从而让项目管理落地到实处。实际的情况就是，当前要做的内容多，重要性都高，且最好都一次性上线，在这种高度挤压集中的情况下，产品就更应该集中精力把产品的设计、需求的完善落到实处。把人力不足，时间紧迫等相关问题交于项目管理来协调。专业的人办专业的事情，将是最为高效的。也就需要，在自己把控或者不属于自己管控范围内的，要迅速给与他人以合适的信息，让其他人共同协助实现。这也更是给与其他人实现自我价值的机会。

在没有那么紧迫，没有那么多需求堆积时，相对的处理也就更容易。

3，需求设计

经过前面相对较为“复杂”的过程，确保需求有效的被筛选出来，更关键的就是把需求做出来。在需求设计时，推荐用户角色，使用场景，业务流程，使用流程，数据追踪的方式进行整体的设计。

涉及一个需求的实现，我们需要完整的用产品思维整理出完善的使用场景。优先考虑有哪些角色使用当前功能，也就是确定人员类别，确定不同人员使用的场景。外卖平台会有下单用户，外卖跑腿用户，会有商家用户，会有平台管理用户；内容阅读平台会有内容阅读者，内容创作者，内容管理者，内容审核者，以及平台管理者。在角色范围确定时，常常会漏掉平台管理员的角色。

使用场景就是一个角色会在什么场景下使用这个需求功能，也就是确定功能范围。例如一个内容阅读者需要内容阅读；需要和内容进行交互，点赞、评论、分享、收藏；也需要和内容创作者有一定的关联，就需要关注、私聊、打赏；而这些所有的都是每个读者所独有的，就需要用户的账号体系；而伴随平台内容的广泛还是垂直，还会需要构建用户特色，栏目关注。

业务流程则是使用场景的整个过程的梳理完善。内容的阅读，是从筛选内容开始的，筛选内容，阅读内容，是否更多交互，是否和作者平台有关联；回退然后筛选新的内容，重复流程。阅读内容的往后延伸流程完成，还需要回退查看流程的另一端，即是内容的产生：已发布的内容，回退到内容审核，回退到内容的发布，回退到内容的编辑。依据这个主流程，再把每个环节细化，看看是否还需要扩展。

例如，已发布的内容是否有优先级顺序调整？整个过程会依据流程的逐步细化而完善，而精细化。整体业务逻辑梳理清楚，但作为步步检核的坚定执行者，还需要验核上面所有的流程是否真的完善，那就使用数据流检核。

内容的数据流，主要是内容的产生到内容的消逝，就会发现之前的流程设计，还缺乏内容的撤销和删除。基于每一个功能拆解数据的产生，数据的流转过程，数据的消逝，以及所有数据的统计分析，从而验证功能设计的完善性。

最终输出就是原型图，最好能够整理PRD文档。基于当前很多公司是实际执行情况，建议把PRD文档的内容完善补充到原型图中，然后配合问题列表，实现文档的高效化使用，以及内容的可追踪性。

三、版本树

（1）核心业务实现，业务框架的搭建

（2）登录注册用户体系搭建

（3）业务商城推广

（4）活动模板构建

（5）数据运营挖掘

（6）产品监控自我优化

之前的过程，实际已经将产品的关键执行顺序融入。在当前版本树的执行中，基于需求设计完善的基础，产品更多的参与是确定需求宣讲落到实处，让研发、测试能够统一理解需求，争取接近100%的需求理解。

从实际的经验中来，需求讲解，其他相关人员参与度不一定很高。而在需求讲解中，给其他人不确定的提问，有助于帮助集中所有成员的注意力。更是通过提高他的信息输出来倒逼他的信息输入。在相对规范的公司，会需要所有人员再写需求确认，从而实现需求的传达一致性。在过去从事的项目执行中，配合先控制后碎部，步步检核的理论，整理出来如下项目管理的模型，期许能够辅助大家将项目执行更好的落地。

整个项目的执行，主要分为阶段，应用里程碑作检核；把阶段拆解为任务，用检查表来检核。一般的版本升级迭代，阶段划分可以分为需求整理阶段，UI设计阶段，研发实现阶段，测试测试阶段。各个阶段的里程碑是对过去的一个阶段的整理，也是两个阶段的交接，更是阶段产物的验核。

对产品来说，需求设计完成的阶段，需要交给下一个阶段需求设计原型图，若是输出完整的PRD文档是最恰当的。通过需求评审，进行需求设计的再一次检核，集大家的智慧完善需求，确保需求设计考虑完善。

需求设计阶段中的任务拆解，就可以使用之前的环节，包括需求收集，需求整理，需求筛选，需求设计，而对应各个任务的检查表就是对应任务的结果。需求收集，得到的结果应该是一张需求统计表，记录当前所有有可能需要执行的需求；需求整理，则是将哪些需求屏弃掉，将精力锁定在最关键的需求上；需求筛选，得到的结果是用什么样的理由决定了哪些需求当前版本优先执行，且各自的执行顺序是怎样的；需求设计也就是原型图设计，达到能够很好传递信息给后续环节的目标。

​项目管理的理论整合

​项目管理

在项目的执行中，也要求项目做结项处理。从而形成项目经验，让后续新项目的执行基于当前项目进行维度升级。同时，项目中的执行文档、检查表、项目阶段规划，都是相关项目的实例，可依据这个内容抽取形成模板，构成每个参与者的勋章。

四、产品自我优化

（1）产品自我审视：版本树复盘

（2）用户行为研究，大数据分析

（3）用户直接反馈渠道

（4）MVP：最小最有价值产品版本

用心

一个产品就是在这样的流程下，产品逐渐变得越来越好；一个团队，也就是在这样的项目执行下，变得越来越专业，越来越高效。

在项目都在推行项目复盘的情况，那么每一次的需求实现及运行，也需要对产品进行需求复盘，对“枝丫”需求进行适当的删减，对“主干”进行适当的补充完善，使其更加茁壮成长。

在产品运营过程中，也需要监控产品本身。依据产品用户群体的活跃度、留存率等来辅助确定产品的朝向；用各个页面的使用率及使用路径跟踪，确定产品的设计优化，辅助产品进行内容改版和升级；用产品的版本对比、时间对比、峰值、数据量等多方面变化来检核产品，进行自我的辩证认知。大数据的分析和挖掘，将能辅助产品走的更远，走的更稳。

产品还是需要根植于用户，构建用户的反馈渠道，就能更直接的和用户接触，也更能发现那些细节问题、特殊情况问题，也是另一个坚持，步步检核。

在整个整理过程中，会发现，需求的整理及实现，花费了大量的时间和精力。在实际的执行中，因为需求池的明确，需求筛选之前的很多事情都省掉。最关键是，所有的需求按照深度思维都是可以不断挖掘的，但是在实际的情形中，会因为生命周期、产品阶段，会存在部分功能隐藏较深，不被使用的情况。

所以，产品在初期的需求设计中，不必尽善尽美。在完成核心业务逻辑的实现后，需要尽快投入市场，依据市场的反馈，更加及时的修改，以确保产品深耕于用户群。这就是产品最小最有价值版本设计的方法，即是MVP，也确实是MVP。

​需求池和版本树的进化

一个人可以走很快，一群人可以走很远！当前的内容分享，主要跟大家沟通一个实际工作的大框架，将自己的工作范围锁定下来。后续会逐步将各个环节细化，走向更加专业的深耕。也是如此，整个内容框架适合整个方向的工作，而个人需要依据实际情况，进行方法的筛选，截取对自己最有效的部分，执行正确的内容，并正确的执行。

向阳生长，和有趣的人同行。别怂~