如何将一个需要变成一个落地的产品方案

编辑导语：产品经理在日常工作中经常会遇到做产品方案，而且是可落地的产品方案，在这个过程中需要经历多方的验证、需求分析等等；本文是作者分享的一个面试问题——如何将一个需要变成一个落地的产品方案，我们一起来看一下。

最近正在面试，面试官问到一些问题，自己做了思考，输出如下：

作为一个产品经理，拿到这个问题，我的第一想法是：这个需求论证过吗？

这里假设公司已经有一定规模用户，已经建立用户画像。

且已经做过需求论证，确定是我们的核心用户群体的需求。

一、确定关键指标——动手之前要先动脑

分析：这个需求的关键点是哪些？如何判断输出的产品方案是合适的？

所以要在产出之前制定针对结果的评判指标。

要最先摆出来关键指标，明确以下几点：

• 用户特征是什么？
• 在什么场景下用户有这个需求？
• 在该场景下，用户使用的关注点是什么？
• 在该场景下，用户的目标是什么？

关于1，不同公司/产品的用户群体不同，特征也不同，则对于产品好坏的评价标准会有差异；比如游戏公司的用户多为青少年、学生族、上班族。而古董、房产类电商产品用户多为中老年。

关于2，用户在什么场景中会有这个需求，不同场景下用户的操作行为和要求也会发生变化；比如打车产品，用户逛街逛累了、到陌生的地方旅游场景下会有这个需求；比如短视频类产品，用户在坐地铁、等车的场景下会有这个需求。

关于3，在不同场景，用户的关注点会有差别，关注点不同则产品设计的重点不同；比如在电商类产品中，用户在浏览商品的场景中，关注点是商品的质量、颜值、价格等信息，而在付款流程中，用户的关注点是地址信息、优惠信息、资金安全、消费风险等功能。

关于4，不同场景用户的目标不同（这里要明确区分用户目标和产品目标，是用户的心理预设目标）；比如电商产品中，在浏览商品的场景中，用户的目标是看到自己关注的、好看好玩、性价比高的产品；而在付款流程，用户的目标是流畅完成购买的操作，并确保资金安全。

在分析并解答这些问题后，对此次功能上线后的数据情况（用户量、日活、月活 ）会有初步的预测。

二、产品方案设计——不是无脑的抄抄

调研市面上是否已有该满足该需求的功能，在百度、贴吧等渠道寻找竞品。

如果已经有独角兽产品，则需要看该产品的用户评论和贴吧口碑。

最终选取口碑较好和独角兽的产品作为主要分析的竞品。

1.竞品分析

罗列竞品的产品关于该功能的产品结构，对比后梳理出共同的功能和差异的功能，即得到“基础功能”、“亮点功能”。

作为“基础功能“，我们的产品必然也要有。并且结合用户的负面评价进行优化。

而“亮点功能”则是各个产品的亮点，是运营宣传和吸引、留存用户的关键；所以我们也要想到自家产品的“亮点功能”。亮点功能的设计就要拿出前文的“关键绩效”，并结合公司已有资源来思考。

完成竞品分析后，脑中已经有了产品方案的雏形。

如果市场上没有该功能的竞品，那恭喜你，你可以做MVP，迭代优化后逐渐做大，充分展示产品经理的能力。

2. 输出业务流程图

工作中很多领导要求直接输出原型图，但是在我的经验中，这步操作很考验产品经理的逻辑能力，因为：

1）做原型图需要在脑中构建出业务流程图，产品结构图，还需要考虑交互设计、界面元素排布等事情；而原型图产出后，就会开会讨论，这个时候发现问题，就不只是产品经理复工，还会耽误大家时间。

2）业务流程图可以把流程展现出来，需要合并和缩短的流程一目了然，为后续功能模块的划分和相同页面的合并（关键页面）设计提供了便利；防止用户操作总是进入新页面，造成研发和设计团队工作量增大的问题。

3）业务流程图可以清晰的梳理、补全异常流程；异常流程的处理也很重要，上线初期会影响产品口碑，看微信的初期用户评价，有很多异常情况的负面反馈，这样就造成团队为了挽回用户快速迭代优化，大量加班。

所以建议产品经理谨慎的输出业务流程图，并反复琢磨；（建议分析竞品也采用这个方法，会受益良多）可以按照流程的层级输出多个业务流程图，某些自己闭环的功能可以另做一张图详细梳理，在主图中直接用模块替代。

3. 输出功能结构图

业务流程图梳理后，会很快产出功能结构图。

功能结构图的关键是各个模块应用边界清晰，防止之后迭代产生新功能时功能归属混乱，造成用户理解困难体验不好。

4. 关键数据指标的设计

在产品设计雏形出现后，需要思考：关键流程和页面埋点的设计。

当然需要先想到需要量化的指标，以及指标的计算方法，然后推理出需要埋点的位置和需要统计的字段。

1）关键节点的统计

根据文初的“关键点”设计数据指标。比如电商产品的成交量是一个关键节点，则该节点的pv、uv、订单量、付款量等数据是需要采集数据；最后根据采集到的数据进行用户质量、产品质量、ARPU等指标的计算。

2）关键流程的统计

比如学习平台的登录注册流程，是拉新指标的关键衡量流程，所以在用户操作的没一步都需要采集，之后做衰减图，分析定位造成用户流失的行为，来优化该位置。

数据量化是产品后续迭代重要的依据，可以量化的展示劣势和科学的提高关键指标，希望大家在产品设计时就开始规划。

5. 输出原型图

根据结构图，区分模块，根据流程图梳理出的关键页面，重点考虑交互的流畅度和元素排布的合理性；其中用户会从多条业务线进入关键页面，所以关键页面需要重点关注。

我的经验是，原型图设计有动态有静态，一般给客户展示（2B）需要做高保真动态原型图。

给团队研发同事看的需要具体沟通和公司的规定，有的研发会喜欢静态+描述的原型图。

6. 输出prd

prd的输出根据公司规定输出即可，有的公司做原型图+逻辑说明就可以，但是有的公司后台的逻辑比较多无法用界面描述，所以会需要prd。

三、产品方案论证——别着急找技术

产品经理拿着方案去找技术，这就走上了一条无法回头的战线，所以要慎重。

下面结合自己的经验，给出此阶段的自检方法。

自检问题：

• 设计的功能是否满足了需求？
• 这个设计是用户的首选方案吗？
• 用户选择使用这个功能有成本吗？
• 这个功能会给用户带来风险吗？

关于1，反思是否完成了设计的初衷。回头看最初的“关键点”中的需求，若解决了用户的需求问题，则通过。

关于2，需求是存在的，但是用户有很多解决办法，不一定要选择你提供的方法；如果用户有更加高效、优惠的方式，则你的用户量就会低于预期。

关于3，不少的解决方案是要求用户使用这个功能，但是没有考虑用户的成本；比如用户需要安装很多软件、插件等，这对于部分用户来说是需要考虑的成本。

关于4，对用户来说，是否有财务、心理、时间、社交的风险，这个时候就需要结合“关键点”中的用户画像来逐个分析风险的情况；相信大家都理解，这些问题对用户来说是会有负面的品牌印象。

四、对接研发——别用领导的态度

在工作到这一阶段，与研发同事沟通也是很多产品经理头大的一件事情。我的经验是：别用领导的态度和研发讲需求。

产品经理心里觉得：我忙乎半天终于搞出来产品方案了，直接输出给他们，他们赶紧干不就完了，为啥老是反问我，搞事情？

然鹅，研发的想法是：我们研发是公司的核心，你产品经理凭啥命令我们，我们为什么听你的？

这样就发现，研发同事并不是不认可你的产品方案（排除产品设计的确实很烂的情况），而是觉得产品经理的态度有问题。甚至有一些产品经理用某个领导说了要做什么来强制要求研发团队。所以团队中研发阻力很大的产品经理就要反观自己在与研发对接时的态度问题。

回到产品经理的初衷：希望产品完美的落地。奔着这个目标，我们可以更加友好的方式输出给研发。结合我的经验，方法如下：

1）讲故事的方式

通之以情晓之以理的声泪具下的描述用户的痛苦、用户的需求多么的迫切，让研发产生同感，由内心产生动力。

2）情商高的给研发展示的平台

产品经理拿着产品成果和领导汇报，而研发作为幕后人员，很少和大领导接触，所以如果产品经理在汇报时，增加篇幅表明研发同事的付出，自然而然的一点点建立与研发的友好关系；当然日常的邮件也要表明研发的配合工作并表示感谢。

当然，在开发过程中，异常情况也是产品经理与研发冲突的一个部分，这里就又要强调业务流程图的重要性了，请大家查看上文。

五、测试与上线前的把关——不要忽略细节

在研发完成后，需要产品经理在一线测试，除了要注意流程是否走通，还需要注意：

• 页面文字、提示语，是否有错别字。
• 冷启动资料是否准备充分。

有可能原型图没有错别字，但是设计师工作很多，没有注意到错别字；而研发直接用工具生成页面，则上线后这个错别字就会出现在用户面前，当然会影响产品的美誉度。

六、数据搜集——比对预期并反思

数据开始时不好也别着急，与运营部门一同发力，协作拉新、促活；数据特别好也别激动，有可能是运营活动做的好。

产品的数据在半年后才能显现，之前数据表现多是运营活动的效果，所以产品经理一定要稳住，多搜集用户评价、维护种子用户，多与第一批用户接触、做用户调研、搜集问题，快速迭代；等到半年到一年，数据表现的才是产品的优劣。

对比预测的数据，思考数据出现差别的原因，反思：

• 自己设计的功能是否有漏洞？
• 是否对用户群体特征的把握不够准确？
• 是否出现了强大的竞品？

到这里，落地的产品方案完成了，可谓路阻且长，行之将至。

产品方案的落地，并不是指产品经理的职责就完成了，建议大家多基于过程思考、基于结果思考，多提有目标指向的想法，自己发力，找到解决方案和优化方案。

如果大神路过，请过目我的思路，如若有激发您的灵感，欢迎留言评论。

 

本文由@宇智波冰 原创发布于人人都是产品经理，未经许可，禁止转载。

题图来自Unspalsh, 基于CC0协议。