初级产品经理怎么做到C端产品的0到1

曼巴PM 2023-07-28 07:10:12

笔者有过完整的几次C端产品的0到1经验，对c端产品的0-1总结出了不少的经验。

同时，笔者也见识过不少产品经理在一开始就因为错误的选择方向，可能是市场调研环节没有挖掘出用户的真实需求，亦可能是老板的想法本身就有偏差确没有进行过市场验证就按照老板的想法开发产品，而导致了产品的无限延期；最后迫于成本压力，以拙劣的产品上市最终失败。

笔者通过自身经验的总结，及请教了不少同行业的朋友与大佬，总结了这么一篇干货内容希望与您一起分享。

一、黄金圈法则

产品经理，产品经理网站

笔者认为，产品经理想要最大程度的避免产品在战略层上的错误定位，必须要学会并运用黄金圈法则。

笔者所接触过的产品经理在产品设计上的思维都与黄金圈法则相悖，因此很容易出现抓不住用户真实需求的情况；即使最终的产品看着非常像样，却不被市场所接受。

我们在打造一个产品时，应由WHY（战略层：确定最终产品所要达到的目的，企业的愿景）到HOW（范围层，结构层：如何执行，怎样设计，怎样的流程）再到WHAT（框架层，表现层：输出的内容，验证和管理）。

二、战略层

1. 开始阶段：产生idear

产品的往往是由一个Idear开始的，它可能是你的BOSS或者公司的最上层管理层突然发掘某块市场具有较大的市场潜力而产生的idear。

这一类人往往有对市场机会有更敏锐的嗅觉，但市场机会转瞬即逝，任何人都不可能有十足的把握确定某一市场一定有待挖掘的潜力；因此我们产品人要做的便是验证产品研发投入市场的可行性，通过各大数据网站，或者企业内部已有的相关调研数据，研究目标市场的容量及竞争力水平；同时还需要了解目标用户群的容量、消费水平；分析头部竞品及相似度较高的竞品；该市场的现有商业模式。

产品六要素：

在上述任务全部完成后，整理形成《产品六要素》：①产品定位、②产品目标、③需求背景、④用户群体、⑤产品形态、⑥使用场景；综合分析产品的可行性。

产品经理在撰写产品六要素时应注意结合具体的数据：数据真实有效更能打动Boss或者Leader，产品的目标则最好分为用户角度、市场角度和公司角度（商业）。

竞品分析：

如果产品的可行性较高，下一步便是深度分析竞品，形成规范化的《竞品分析》，因为《竞品分析》是研究一个市场和一类产品最有效的途径。

了解对手的产品能达到知己知彼、百战不殆的目的，而且分析竞品也能为产品的设计提供建设性的意见，学习竞品的精华能有效降低获客成本，规避竞品的糟粕则能有效的降低市场风险，同时还能根据对手的核心功能挖掘用户的真实需求。

我们可以根据目标用户、使用场景、用户需求的趋同性将竞品划分为直接竞品（同用户、同场景、同需求），间接竞品（目标用户、场景、需求有一个不同），潜在竞品（目标用户、场景、需求不尽相同但借鉴性强）。

在竞品分析时，产品人要善于找茬，发现竞品不擅长的维度/领域，降维打击；分析自身的劣势，提升自己的短板，升维思考；最后形成规范化的《竞品分析》，留存备份。

注意事项：

竞品分析时应站在中立视角分析双方的优劣势，切勿主观评价。
联系用户的使用实际，结合场景，最好以全局的视角分析。
确保分析时产品都处于最新的版本。
所有的介绍都要有归纳总结或者说结论分析。
分析一定要以准确的数据作为支撑。
竞品分析不是只研究竞品，而是分析敌我双方的差异性。

BRD：商业需求文档

产品的开端一定要分析产品是否具有盈利性，或者是否具有长期盈利性，在未来的某一个时段实现盈利。

尽管产品处于未开发前的阶段，产品团队并不能撰写出有效性较高的商业文档，但boss或者投资人只有看到完整的商业报告才会评估确定产品是否值得投入成本进行开发。

对于不同类型的汇报对象，我们需要突出商业报告中不同的核心要点。对于管理层级，我们需要给出产品的投资价值，市场趋势，和可能需要面临的风险（产品的投入总成本及回收周期分析）；对于研发团队，我们需要给出产品的主要价值，核心功能的方向；对于CFO，我们则要突出产品的研发经费。

总的来说，写商业需求文档的目的是为了说服团队，得到人员、资源、资本的支持。

2. 汇报阶段

第一阶段的汇报将会决定产品是否投入开发，产品经理通过内部邮件的方式，将第一阶段形成的所有文件传达给开发团队及上层管理层，确定会议时间、地点及汇报的主题；在此之前需要对之前整理的文档内容进行更新（市场的变化转瞬即逝）。

产品经理在汇报时应注意自己语调语气，结合整理的数据，清晰果断的发表自己的探索结果，注意细节内容的阐述；记录汇报时讨论出的问题及解决方案。产品开发通过后，第一时间制定甘特图。

收集需求：

因为产品设计的核心逻辑就是以用户为中心，围绕用户进行产品设计，所以在汇报完成后，就可以着手收集目标用户的需求和问题了。

首先，我们要知道，用户的需求是隐性的、模糊的、多变的；因此我们在收集用户需求时，尽可能的保证用户反馈的主观性，不可通过问卷设计及访谈主题误导用户。

此外，我们对于收集来的调研数据需要进行深度分析，数据分析方法有：聚合分析，相关性分析，回归分析，这里我就不一一列举了。

我们的需求来源可以是产品团队的想法（尽管产品经理并不能准确的抓住用户的实际需求，但不少产品经理都具备挖掘用户潜在需求的能力），也可能来自竞品的功能设计，在后期的需求评审会中，往往也能得出不错的点子。

在此，也为大家推荐几种获取需求的方法：

行业调研的分析报告，较为专业的行业报告具有指导意义。
业内专家与资深专业人士，这个时代是知识付费的时代，行业领先者往往具有更长远的眼光，对市场的分析更加准确。
定性研究—用户访谈，可以是焦点访谈、电话访谈、一对一访谈或者街头狙击访谈。
定量研究—用户问卷，调研问卷的数量不应太多，避免影响用户的主观性。

三、范围层、结构层

1. 用户需求（问题）分析阶段

当我们收集到足够多的用户需求后，我们就形成了一个需求池，这其中部分需求是假需求（即用户自以为需要却并非实际所需要的），还有部分需求不符合企业的价值或者说资源不匹配（可行性、盈利性、技术水平），因此我们需要对收集到的问题进行分析，提取需求，将用户需求变为产品需求。我们对于需求的分析核心点在于将用户需求转化为可执行的产品需求的过程，它是产品设计、迭代的主要依据。

我们需要建立起用户思维，即以用户为中心去思考问题，了解目标用户在何种场景会去怎么使用产品或者使用的过程是怎样的，之后再总结用户使用产品时会出现什么问题，提出最合理的解决方案并进一步验证。在验证需求时最好结合数据，通过频数分析和交叉分析得出结论。最后整理出需求清单和功能清单（根据问题得出解决的功能设计），必要的功能设计可以优先设计用户使用时的流程图。并对所有确定要开发的功能进行梳理并输出结构图。

2. 需求评审阶段

尽管产品团队已经层层筛选，得出了产品的功能清单，但最终开发的产品还需要财务、开发团队、上层BOSS的支持；因此，产品团队必须第一时间确定需求评审会议的时间，将之前所有整理好的文档信息和会议议程通过邮件的方式发布给公司的其他团队，前期的准备必须要完美，规定好产品原则（确定产品设计的方向性，这一点必须统一，不然将大大降低会议的效率）；确定好参会人员，确定以何种形式记录，需求讨论的关键核心点。

在需求评议时，产品经理需要尽快的切入主题，调动大家的情绪（可以提前确定讨论的方法：头脑风暴和六顶帽子讨论法）。

在进入正题后，介绍的优先级：项目背景，介绍本次主题的产品，产品的结构图，流程图，需求清单，原型图（如果是敏捷开发，则可以优先进入原型图开发），PRD文档讲解；最后记录提问环节的问题及讨论出的解决方案。

评审结束后，及时输出更新后的BRD/MRD、PRD、流程图、页面清单、结构图、原型图等并整理会议内容通过邮件形式发给相关团队；将达成的共识、待修改的地方、待解决的部分一一罗列，整理出反馈时间表；将任务的完成日期落实清楚并确定相关负责人，以及后续的评审日期的确定。

会议结束后的应保持长期跟踪，推进产品的功能开发。

我们在整理最后得出的需求时，可以参考马斯洛需求层次和KANO模型对需求的优先级进行排序，以此作为产品迭代路径的参考。

四、框架层

1. 原型制作阶段

在上述所有的工作完成后，便可以真正的开始原型图的制作了。

笔者建议团队或者企业最好能形成规范化的设计原则（统一的设计方法论），产品原则（产品的优先价值观），企业价值（企业价值能让团队的目标趋于一致，减少摩擦）。

原型的交互设计一定要以用户为中心，笔者见过不少产品经理在原型的交互设计上并不按常理出牌（这与不少企业的产品经理多为企业内部的开发人员有关），好的产品经理必须要分析产品的功能结构和用户使用体验，以此为基础进行产品设计将大大改善用户的粘性也有利于企业盈利。

设计的原则基本点：所有的APP页面分两种状态，即初始状态（初始页面），变化后的状态（隐藏页面）；在交互说明中，不需要产品经理对跳转页面做具体的详述，应着重关注于产品的隐藏页面，下拉页面、选项弹框等。

3个细分原则：

按钮、图标等模块、操作以后的变化（可设置全局规则与页面规则进行统一阐述，避免重复说明导致页面杂乱，说清楚页面变化的规则和逻辑有利于提升与UI、程序员间的工作交流效率）。
该页面的文字显示、时间显示、刷新等页面规则（应注意网络延迟等情况制定刷新规则等，可将其详细写在全局规则页面）。
操作后出现错误提醒（弹窗提醒），发现越多的异常流程将大大提升用户的使用体验。

此外，我们还应注意：

① 少就是多，分清功能的优先级，越重要的功能应详细描述其交互规则及操作方法；学会做减法（减少约定俗成的说明，如：跳转键等）详略得当才能让UI更清楚重点，让程序员更能理解页面的规则逻辑。

② 文字格式可直接表现在展示的原型内（注意格式规范，以免误导UI设计师做出错误的设计，最终挨打）。

③ 页面原型中的布局应规范，不要求具体到多少尺寸，大致能使UI设计师明白页面设计的基本布局，布局以美观简洁为主，清晰的使用户了解重要功能，提升用户的使用体验。

④ 设计的行为习惯应与企业的风格相协调，了解程序员、UI设计师的喜好作为设计交互的风格（如：布局风格、价格显示格式、文字显示格式等）。

⑤ 合理运用和设计全局规则页面、页面规则、页面权限、使用场景，提升制作交互说明的效率；简约明了为宗旨。

⑥ 多种场景可以用表格的形式进行描述。

2. 原型评审会议阶段

原型评审时主要是对于原型设计的整体布局，功能设计的细节处理进行再一轮的头脑风暴；此外，产品经理还需要结合BRD进行演讲（此时的BRD较为详实，效度较高），BRD涉及到市场、用户、竞品的分析，还包含了对于产品迭代、产品运营、产品的商业性的深度分析。即产品的长远发展及竞争力水平的全方位分析。

产品的最终目标是实现企业的盈利性，所以在原型评审会议时应注重对于产品的盈利模式、玩法的深度讨论，优化产品的盈利水平和可持续盈利能力；此外对于产品开发的成本还需要进一步的优化，对于产品的运营投入和成本可以试着在会议前做一些局部的测试，分析哪一类的运营模式或者渠道更具性价比，达到产品快速获客和低成本获客的目的。

在评审会议结束后，更新产品的原型设计，并将最终得出的所有文档发布给相关团队，开发团队以此为基础进行产品的开发。

产品经理应注重1-N的管理及风险管控，及时与开发团队讨论产品的设计；同时着手进入产品迭代的计划，产品上线后短期内需要快速多次的微迭代。