“三位一体”法的第一部分，我称之为【想透】

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

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

1）入里

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

2）出外

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

小结一下

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

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