基于工作流程的产品方法论

刚工作的时候领导交待什么干什么，后来负责的工作多一点了，自由度高一点了，就总在想产品经理的工作方法论是什么，然后看了一些线上课程，也云里雾里的听了一些方法论。可是分析具体问题还是停留在表面，好像懂了又好像没懂。我曾经一度认为方法论就是一些“专家”用他们智慧的头脑舞弄出来的名词。谁也说不清楚或各有各的理解。便不再深究只埋头干活。

21年底，因要给部门同事分享产品方法论。我就又开始了我那久违的思考。踩过了很多坑，失望过、痛苦过、为取得了小小成果开心兴奋过。可是这些能成为我们的方法论吗。今年再整理再复盘，我想这么分享：

我不想列举让我或痛苦或深刻的，那些半夜做梦都在想解决问题的案例，痛苦挣扎可能是每个做产品的人都有过或者正在经历着。但案例千千万，其实解决问题的通用手段就那几种，所以我想抽离这些感性的情绪，基于工作流程、定位工作内容，微微结合我们祖辈“道、法、术、器、势”的经典理论，以每个环节的输入、输出、工具进行展开讨论，如有不当，欢迎大家一起探讨。

1. 规划阶段：产品规划 – 需求采集 – 需求分析

2. 设计阶段：产品设计

3. 研发阶段：研发测试

4. 发布阶段：产品（项目）验收 – 上线发布

5. 监控阶段：数据分析

6. 迭代阶段：产品迭代

如果你是自有产品，需要从0-1搭建，那恭喜你，产品侧工作全流程每个环节你都逃不脱，除非你的产品还没上线就被砍了。

如果你是项目外包，产品侧工作则需要从需求采集至项目验收。

无论是哪一种，产品工作都需要了解解决每个具体需求，抽象共性问题进行产品规划–进而建设产品体系，最后又回到了一个个具体的问题中。

输出一套分析问题、解决问题的流程，让我们按照成体系、有重点、分步骤的去工作，了解每一环节我们应该输入什么、使用哪些工具、输出什么、有哪些注意事项。都清楚后是不是就会缓解产品工作的纠结和痛苦呢。

一、产品规划

1. 概述

基于公司的目标和战略 ，确定具体的产品类型、重点关注的业务市场，明确业务方向及用户场景。其实这也是经典方法论中的“势”，是根据当前的客观条件和形势（即行业所处的大环境）判断发展方向和做成概率比较大的时机，也就是常说的在风口上猪都能飞起来的时候。所以一定要输入 ↓

2. 输入

行业报告：从宏观层面了解行业近况及未来趋势，从顶层俯瞰行业发展潜力。

（1）洞见研报：https://www.djyanbao.com/index

（2）发现报告：https://www.fxbaogao.com/

（3）艾瑞咨询、易观千帆（APP）

竞争对手：通过竞争对手可以很好地理解行业核心需求是什么

• 官网获取
• 各个行业报告中获取
• 直接咨询（只要你够大胆和讲究方式方法）

不会的时候要先学会吸收行业已有的成果，不要轻视友商的资料。

项目需求：各项目中产品现状梳理、复盘。

负责的项目中，能抽象出哪些关键的方向？这些方向里面包含了哪些关键要点和节点 这些要点和节点，如何数据量化其表现？通过这些数据表现，哪些方面做的不及预期，哪些方面做的很优秀？整理完后，可能我们就会有答案了。

用户需求：与用户和潜在用户交流（问卷、用户访谈等）。

3. 工具

PESTLE分析：

• P：政治（Politics）
• E：经济（Economy）
• S：社会（Society）
• T：技术（Technological）
• L：法律（Legal）
• E：环境（Environmental）

使用PESTLE分析法，对趋势更准确的解读，形成了所谓的“大环境分析”。

SWOT分析：

SWOT分析竞品的优势、劣势、机会、威胁，进而得出竞品切入某个行业的机会和优势，取长补短。

通过试用渠道体验竞品：

• 百度是首选
• 知乎、简书找文章思路
• 知网、万方找专业信息
• 哔哩哔哩找视频资料
• CSDN、稀土掘金-开发者社区找技术资料

拓宽搜索渠道，信息爆炸的时代，知识的获取方便快捷。

4. 输出

（1）《调研报告》

（2）《竞品分析报告》

竞品分析有一定的流程，可以从战略层-范围层-结构层-框架层-表现层这几个层面进行分析；行业发展状况，“有哪些竞品？”，竞品使用者和特性的描述，自己的产品与竞品之间的比较，通过分析得到的结论和信息等。

（3）《BRD 商业需求文档》

• 包括产品创意产生的背景、市场分析、方案介绍、产品规划、产品成本、产品收益、产品风险，通常是供决策层们讨论的演示文档，一般比较短小精炼，要注意其中没有产品细节。

二、需求采集

1. 概述

需求获取是一个由粗略到细致的过程，从概括性的项目背景说明深入到目标用户确认、业务现状、业务问题和期望效果的梳理。视项目实际情况，可能需要和基层执行者、中层负责人和高层领导分别进行沟通。

需求采集对应的就是“道”，是摸清规律，是周鸿祎的六字法则“刚需、痛点、高频”，是张小龙的极简主义，是俞军的用户模型、交易模型。

重点要理解用户，用户不是自然人，是需求的集合，要研究用户行为及其背后的意义。例如：

• G端客户的目标不是商业目标
• 政府客户期望产品能够帮助他们做好监管，规避风险，及时发现问题，能够树立标杆，体现政绩
• 发达地区追求标杆项目，其他地区追求地方特色

其次要理解产品：有效用、有利润、可持续。

2. 输入

招投标文件、合同、建设方案、干系人登记册（干系人信息）、调研大纲。

3. 工具

• 会议、访谈
• 问卷调查
• 焦点小组（征求某一领域专家的意见）
• 引导式研讨会（参加者是跨职能的）

焦点小组、引导式研讨会：例如深化某一智能应用的功能设计，可以先小范围的征求技术专家的意见，再用引导式研讨会的方式征求市场、运营的意见。

• 群体创新技术（头脑风暴）、群体决策技术
• 标杆对照
• 数据分析（已上线发布的产品）

4. 输出

（1）《调研记录》

（2）《调研报告》：应包括对使用者的描述、通过分析得到的结论等

（3）《会议纪要》

（4）《需求跟踪矩阵》

5. 注意事项

调研的人员：真正的使用者不一定是决策者，大部分是具体的执行人员在应用。

调研的深度：请教——刨根问底——核实，对用户的初步回答反复追问“为什么”，引导用户从表面的行为开始思索，清理出行为背后的动机。

沟通技巧：避免使用封闭式提问（即提问者提出的问题带有预设的答案，回答者的很难展开回答），封闭式提问容易忽略问题本质，停留在问题表象。

线上会议：提前5分钟进会。

会议记录：参会人里若有“–”单位人员，排序很重要

三、需求采集之学会提问

索命提问一：与市场/销售/项目经理沟通：问项目的业务背景是什么。

这样提问太抽象，太宽泛了，我们不要把想要得到的答案，直接当做问题描述就不加处理地询问别人。除非是很懂产品侧工作的人员才能明白，多数时候，我们想要获得答案，都需要拆解成若干问题：

• 问业务规模与可行性：该项目的当前进展如何？有没有签订合同？
• 问目标用户：该业务主要服务于哪些用户？
• 问产品筛选：该项目主要会使用我们哪些已有产品？
• 问竞品分析：除了我们外，客户还有没有和其他厂商沟通过？
• 问产品需求：客户有没有个性化的具有业务代表性的需求描述？
• 问业务流程：能简述下该项目他们核心的业务流程吗？

索命提问二：与客户沟通：直接问针对××事项您的需求是什么。

依然太宽泛，简短的问题可能会让回答者不知所措，或者面对这样粗暴的提问回答者并不想有条理的组织语言，我们与客户沟通更要用产品思维，学会结构化拆解，并且聚焦本质问题，表述清楚。（例如我们要做一个提高客户现在工作效率的系统），试试这样问：

1. 发现问题：要问清楚客户的工作流程是什么？做的过程中有什么不顺畅的地方？遇到了什么问题？
2. 分析流程：问客户现在用什么方法来解决这个问题？
3. 探索机会：为了更好地解决这个问题，问客户认为有什么办法能帮到自己？或者哪些地方可以优化一下？

任何时候，都请记住，不要抽象地提问，一定要进行拆解、聚焦可视化的问题，抽象而不聚焦的提问，总是让人一头雾水，捉摸不透，似乎在告诉对方：你猜，我想问你的是什么？

四、需求分析

1. 概述

对获取的原始需求进行伪需求的过滤，梳理得到真实需求并进行汇总，完成产品定义，核心业务流程、确定功能范围、优先级等。

• 需求分析之“法”，“法”是一般性的原则，我们要使用各种工具遵循需求分析之法。
• 需求来源一般来自政策、领导、业务人员，在回复上优先级依次从高到底，实际落地做产品时需重新划分优先级。
• 需求可行性=（需求的当前价值 未来价值）/（需求的实现成本 维护成本）。

2. 输入

《调研记录》、《调研报告》、《会议纪要》、《需求跟踪矩阵》

3. 工具

宏观角度，基础功能>交互优化>亮点模块>利益相关>战略协作。

• 用户模型：理解用户、理解产品、理解公司。
• KANO模型：一定要有“必备属性”，持续完善“期望属性”，积极探索“魅力属性”。

四象限法则：从推动角度，有重点地把主要的精力和时间集中地放在处理那些重要但不紧急的工作上。

思维导图：xmind、visio。

4. 输出

（1）《产品需求文档》

（2）《需求功能清单》

（3）《主要业务流程图》

（4）《功能结构图》

（5）《需求跟踪矩阵》

5. 注意事项

核对合同需求和用户需求（项目外包）：梳理出真实需求后，根据实际项目要求和资源限制，还需要从技术、成本、收益和风险等方面进行分析。

国家政策（G端）：关注国家相关条文政策，围绕主轴核心业务来设计。

需求review：不要抱着需求获取阶段已经进行了充分沟通的心态，一定要进行“再确认”。

五、产品设计

1. 概述

从业务流程-任务流程-用户体验三个层面逐一输出产品想法，完善产品思路，最终完成产品原型的设计，UI设计师完成效果图的设计。

产品设计之术：术是执行方法，产品侧的工作面对的是如何执行一个具体功能的设计，建议我们可以用封装思维做原型，多使用母版，避免重复性的改动工作。

2. 输入

《产品需求文档》、《需求功能清单》、《主要业务流程图》、《功能结构图》、《需求跟踪矩阵》

3. 工具

原型设计工具：Axure、墨刀。

产品组件库：例如轮播组件、时间选择组件等，使用产品通用小组件，提高效率。

产品设计页面复用：例如积累通用设计页面登录注册、个人中心等，领域设计页面信息填报等，进行复用提高效率。

视觉动线：控制读者的视觉动线，强制让他去看你想让他看到的东西。

4. 输出

（1）产品需求原型

（2）高保真原型（UI效果图）

（3）《产品需求文档（PRD）》

（4）《需求跟踪矩阵》

5. 注意事项

模拟真实数据：产品需求原型尽量用真实数据来设计，避免过于理想化。

设计方法：按用户故事设计思路来设计用户的使用场景。

需求规范的内容格式：“原型 备注”形式的需求文档。

平台的设计规范：多人协作时注意尺寸、字体、颜色、组件的统一规范。

产品周期和时效性（G端）：当年的政策影响以及当下的重点事件都会是产品跟进的方向，落实政府需求时，设计上考虑当下热点的同时，要兼顾热点过后平时的使用场景，考虑用不同的模态，尽可能拿到更多的未来预算。

六、 产品设计之评审

1. 概述

产品经理组织项目组成员参与并依据需求原型进行需求宣讲，使产品、UI、前端、后端、测试等同事对需求的理解达成一致。

2. 输入

产品需求原型/高保真原型（UI效果图）、《产品需求文档（PRD）》、《需求跟踪矩阵》

3. 工具

• 会议
• 六顶思考帽

如果你的评审会上有人一直提出质疑、否定、甚至全是不满。请不要沮丧，你就当你使用了六项思考帽，这个人扮演的是黑色思考帽。

4. 输出

（1）《产品需求评审报告》（书面文档或邮件形式）

（2）依据评审结果修订的需求文档、原型设计

5. 注意事项

内部评审：

• 需求要提前下发：评审会议上用到的文档、原型要提前1天发给相关人员，并且说明评审的目标。
• 准备要充分：尽可能考虑到所有细节，最好能做到面对大家的疑问，都能有理有据的应答。
• 逻辑条理要清晰：从“项目背景&目的、业务场景”扩展到“业务流程、功能架构”，最后再详细展开“具体页面和功能”——即结构性思维。
• 态度要谦卑：用谦卑的态度，接受大家的意见或建议，查缺补漏。
• 必要时要坚定：针对刚需功能、老板/客户重视的功能、未来扩展预留的功能考虑上，在可做可不做、效果可好点差点之间要坚持原则。

外部评审 （汇报对象要搞清）：

• 高层关注：定义整个产品需要达到的目标 —— 目标性需求。
• 中层关注：定义整个产品必须完成的任务 —— 功能性需求。
• 执行人员关注：定义了完成每个任务的具体的人机交互 —— 操作性需求。
• 评审后的跟踪工作：根据评审人员提出的问题进行分析整理，以确定哪些问题是必须纠正的，哪些可以不纠正。

七、内部评审之“拷问”产品经理的几个问题

一问：你这个方案设计得不合理，应该怎样怎样设计。（上来就否定产品侧的设计并提出了新方案）。

• 产品经理能力不够：把相关的细节问清楚，去调整方案，准备充分再讨论。一定要尽量避免产生这种情况，会降低大家的信任度。
• 提问者掌握的信息不够：产品经理和提问者对整体业务的掌握程度不同，所以大家的想法就不同，讲明缘由就好。
• 偏好性的问题：两个方案效果差不多，讲明自己这么设计的原因，肯定其他人的方案，达成共识。

二问：你的设计不够完整，缺了很多东西。

不要紧张，要求提问者具体说一下缺哪些东西，然后一一地对一下。

三问：你这个地方能不能简化成XXX？

要求提问者现场给出简化的说明，大家一起讨论，达成一致。

四问：感觉你这个功能没什么用啊，为什么要做？

产品经理需要把需求产生的背景、需求的目的说清楚，让提问者清晰地知道为什么要做这个需求，这个需求是解决什么问题的。这样就能和提问者在信息层面保持一致，能更好地达成共识。

五问：你设计的时候有没有考虑过后面XXX的情况？

• 已考虑：但还是要按顺序把前面的讲清楚再回答问题，掌握节奏，不要轻易打乱节奏回答问题。
• 未考虑：表明不清楚，最后再集中讨论，把能确定的都先确定下来。若时间长会后考虑。

六问：这个设计改动太大了，真要改吗？

• 之前工作白干的潜台词：开发的工作量太大，这么改产品有没有想清楚；产品经理肯定果断一点回答就可以了。
• 改动涉及的地方比较多，怕出现其他问题：尽可能地多留一点时间给开发。

※ 经验表明，尽量不要搞折中方案，折中方案往往后续需要花更多的时间去补救这个问题。

七问：你这个设计又改回原来那版了，改来改去在干嘛？

客观地说就行，不需要额外的去解释。提问者只是有点烦了，但是其实也知道做还是要做的，产品经理需要做的是安抚他们，然后给台阶。

八、研发测试

1. 概述

研发与产品经理根据产品设计和项目周期，确定开发计划表并进入研发阶段，产品经理提供各种支持；产品经理根据产品设计测试系统，保证核心业务流程及功能准确性。

2. 输入

需求文档/高保真原型设计

3. 工具

project：项目进度管理工具。

鱼骨图（质量工具）：寻找问题根本原因。

帕累托图（二八原理）：百分之八十的问题是百分之二十的原因所造成的。找出产生大多数问题的关键原因，用来解决大多数问题。

4. 输出

（1）《开发计划》

（2）《开发计划跟踪表》

（3）《测试记录》

（4）《产品白皮书》

（5）《产品操作手册》

5. 注意事项

进度跟踪：对于项目进度要做到心中有数，关注各主要功能的实际开发与产品设计的偏差，将自己看到的潜在问题尽量扼杀在萌芽中。

果断决策：可能会存在需求不明确或者其他没考虑到的地方，产品经理要及时与相关方沟通，果断决策，避免出现大的工期延误、功能缺陷。

数据安全：很重要，强调数据的安全性和保密性。

需求新增：对于高层领导新增需求要及时响应。可纳入的立刻排期设计，不能纳入的给出合理理由。

数据统计：针对大屏的数据统计要精确且及时。

与开发的bug沟通：注意方法方式。

九、产品(项目)验收

1. 概述

验收研发完的产品是否符合设计标准、符合合同要求，产品经理主导/配合准备验收汇报PPT、 系统演示脚本，保障产品（项目）验收

2. 输入

《产品白皮书》、《产品操作手册》

3. 工具

专家判断：外包项目验收请行业专家，听取专家意见形成验收报告。公司产品级验收请公司相关方领导，形成验收报告。

4. 输出

（1）可交付的产品

（2）验收报告（文档、邮件）

（3）各资料归档

5. 注意事项

系统准备：提前检查系统，确保演示功能的流畅性和完整性。

演讲脚本：按角色、按业务场景准备演讲脚本，最好准备可解决其痛点的真实业务场景，准备逐字稿（不要嫌麻烦或者不好意思而不准备逐字稿，任何的侃侃而谈大部分是因为前期充足的准备）

样例数据：准备故事脚本所需的样例数据，最好使用真实数据进行系统演示。

十、上线发布

1. 概述

完成准备工作按期发布，产品经理负责产品的使用培训、推广。

2. 输入

《产品白皮书》、《产品操作手册》、可交付的产品

3. 工具

培训。

4. 输出

（1）《版本发布日志》

（2）《培训记录》

（3）《问题反馈记录》

5. 注意事项

产品宣讲培训：产品定位、价值、使用流程等。

常见问题准备：系统常见问题文档的准备。

产品录屏准备：配合推广，准备产品核心功能的操作录屏。

十一、数据分析

1. 概述

产品经理负责监控产品上线后的效果，关注基层业务人员使用系统提出的问题和疑问，收集并分析反馈信息，形成新的需求。

2. 输入

《版本发布日志》、《培训记录》、《问题反馈记录》

3. 工具

• 定量分析：通过数据分析，了解产品基本面、关键指标的表现，透过现象看本质。
• 定性分析：用户访谈，通过用户的反馈，了解产品功能使用情况。

4. 输出

（1）《运营数据分析报告》

（2）《产品迭代规划》

5. 注意事项

数据埋点（C端）：通过埋点数据完成用户行为分析。

收集用户反馈（B端/G端）：反馈类型：BUG（可继续按功能模块分）、功能建议、内容建议、提问、评价、紧急事项。

十二、产品迭代

1. 概述

根据产品总体规划和收集到的各种信息，根据需求的优先级、重要性，规划进迭代的版本里，逐一实施。

2. 输入

《运营数据分析报告》、《产品架构图》、《产品路径图》、《功能全景图》、《产品迭代规划》

3. 输出

（1）《产品迭代计划说明书》

（2）《更新的功能清单》

（3）《PO冲刺待办列表》

4. 注意事项

复盘分析：“学习-思考-实践-总结-再学习”，反思自己的设计和系统是否达到预期，如果没有达到预期，思考应该更注重哪一方面。

产品架构图要有高度：从架构层面看产品全貌 —— 领导层关注。

产品路径图要可执行：从时间线上看产品的路径 —— 领导层关注。

功能全景图要可落地：从具体功能点看产品的细节 —— 执行人员关注。

控制节奏：不可一次性做太多，工期拉太长，也不可无周期的频繁更新，导致出错的风险增大。

• 产品架构图是一个分层结构，可分为数据层、存储层、算法层、能力层、平台层、接口层、服务层、应用层。（根据实际情况裁剪）
• 产品路径图，是把产品架构图里面的一个个模块，拆出来，形成一个以时间线为主轴的路径图。时间线上的每个节点，包含时间、模块、核心功能、用户价值、商业价值。
• 所谓功能全景图，其实就是功能清单。

十三、产品技能

分享了产品侧的工作流程，以及每个环节的输入、输出、工具和注意事项。汇总起来产品经理所要具备以下的几种能力。

1. 文档能力

• 分析报告：市场调研报告、竞品分析报告。
• 调研文档：调研大纲、调研记录、用户调研报告。
• 需求文档：商业需求文档（BRD）、需求跟踪矩阵、需求功能清单、产品需求文档（PRD）
• 流程图：业务流程图、页面流程图。
• 思维导图：功能结构图。
• 需求原型： 产品需求原型。
• 产品手册：产品白皮书、产品操作手册。
• 培训文档：培训记录、问题反馈记录。
• 迭代文档：运营数据分析报告、产品迭代计划说明书。
• 其他文档：会议纪要、临时性其他文档。

2. 工具能力

“工欲善其事，必先利其器”

必备工具：

（1）Axure / 墨刀 等原型工具。

（2）visio / 亿图 等流程图工具。

（3）xmind / mindmanager 等思维导图工具

常用网站：

（1）矢量图标库：https://www.iconfont.cn/

（2）echarts（找图表）：https://echarts.apache.org/

（3）花瓣（找灵感）：https://huaban.com/

（4）站酷（找设计）：https://www.zcool.com.cn/

3. 数据分析工具

（1）百度指数：https://index.baidu.com/

（2）SPSS：https://www.spsspro.com/

（3）艾瑞指数：https://index.iresearch.com.cn/

十四、困惑与问题

1. 产品经理的困惑与问题

问：学习了一些知识，看过一些课程和书籍，可是分析具体问题还是停留在表面，好像懂了又好像没懂，怎么论证。

答：实践

问：产品经理工作的边界在哪里？

答：不要轻易预设自己的工作边界，不设边界地发现问题、识别问题，并且推动着解决问题，让问题到你为止。

问：需求评审，主要领导都在时不提问题，评审完之后，技术人员在做的时候，就会各自提简化要求（因研发强势、时间紧张、功能复杂等），如何规避。

答：需要技术人员给出简化的说明，是否是自身考虑不周或只是在找借口，基本原则上是不妥协。

答：若技术人员强势，要坚持自己的态度，通过不断沟通和提升自我角度，讲清楚是业务主要流程或是合同需求，得到技术人员尊重和信任，进而改进问题。

答：因工期时间紧张而要简化：可以接受当前简化，但后期要持续跟进完善和补充功能。

问：由于外部因素（客户需求反复/客户负责人变化）、内部因素（开发实际效果不理想）等原因，出现同一功能反复返工，如何处理。

答：外部因素：重新跟客户对接明确需求，进行评估并向上反馈，再次进入研发阶段要注意与技术人员解释清楚变更的原因背景，以及这次调整作为产品侧认真做了哪些专业的规划设计，让技术人员减少对产品侧的不认同或者对于返工厌烦的情绪；

答：内部因素：不要只听一个人说，多方听取意见，寻找问题根本原因，判断是否是技术能力问题，推动协调其他人解决。

问：客户相关人员较多，如何管理不同相关方提的需求。

答：可根据干系人权利/利益方格中对项目结果的影响程度，对干系人花费不同的沟通成本和时间成本。

老子的《道德经》，“器”服务于“术”，“术”符合于“法”，“法”根基于“道”，“道法术器”整个体系又在“势”的裹挟下不断演进并驱动“势”的前进和变化。

产品工作者的“道、法、术、器、势”即：“产品技能”服务于“产品设计”，“产品设计”是基于“需求分析”的结果，“需求分析”的根基是“需求采集”，整个体系自然是在“产品规划”的前提下推动的。经典方法论的思考框架适用与任何情况。

以上工作流程和内容，作为产品侧的工作人员可以根据情况进行裁剪。希望我们越来越少的纠结、痛苦，可以更加坚定的做自己。文章可能有很多不足，欢迎大家一起探讨补充。

在此鸣谢小葵花岛主、似水流年，有一些想法是和我的两个好朋友讨论和吐槽中产生的。

版权声明

本文来自互联网用户投稿，文章观点仅代表作者本人，不代表本站立场。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如若转载，请注明出处。如若内容有涉嫌抄袭侵权/违法违规/事实不符，请点击 举报 进行投诉反馈！