在产品工作中，大家或多或少有自己的一套工作流程与产品方法论。作者结合自己的工作流程，复盘总结了自己过去的一些经验，与你分享其相关方法论。
刚工作的时候领导交待什么干什么，后来负责的工作多一点了，自由度高一点了，就总在想产品经理的工作方法论是什么，然后看了一些线上课程，也云里雾里的听了一些方法论。可是分析具体问题还是停留在表面，好像懂了又好像没懂。我曾经一度认为方法论就是一些“专家”用他们智慧的头脑舞弄出来的名词。谁也说不清楚或各有各的理解。便不再深究只埋头干活。
21年底，因要给部门同事分享产品方法论。我就又开始了我那久违的思考。踩过了很多坑，失望过、痛苦过、为取得了小小成果开心兴奋过。可是这些能成为我们的方法论吗。今年再整理再复盘，我想这么分享：
我不想列举让我或痛苦或深刻的，那些半夜做梦都在想解决问题的案例，痛苦挣扎可能是每个做产品的人都有过或者正在经历着。但案例千千万，其实解决问题的通用手段就那几种，所以我想抽离这些感性的情绪，基于工作流程、定位工作内容，微微结合我们祖辈“道、法、术、器、势”的经典理论，以每个环节的输入、输出、工具进行展开讨论，如有不当，欢迎大家一起探讨。
1. 规划阶段：产品规划 – 需求采集 – 需求分析
2. 设计阶段：产品设计
3. 研发阶段：研发测试
4. 发布阶段：产品（项目）验收 – 上线发布
5. 监控阶段：数据分析
6. 迭代阶段：产品迭代
如果你是自有产品，需要从0-1搭建，那恭喜你，产品侧工作全流程每个环节你都逃不脱，除非你的产品还没上线就被砍了。
如果你是项目外包，产品侧工作则需要从需求采集至项目验收。
无论是哪一种，产品工作都需要了解解决每个具体需求，抽象共性问题进行产品规划–进而建设产品体系，最后又回到了一个个具体的问题中。
输出一套分析问题、解决问题的流程，让我们按照成体系、有重点、分步骤的去工作，了解每一环节我们应该输入什么、使用哪些工具、输出什么、有哪些注意事项。都清楚后是不是就会缓解产品工作的纠结和痛苦呢。
基于公司的目标和战略 ，确定具体的产品类型、重点关注的业务市场，明确业务方向及用户场景。其实这也是经典方法论中的“势”，是根据当前的客观条件和形势（即行业所处的大环境）判断发展方向和做成概率比较大的时机，也就是常说的在风口上猪都能飞起来的时候。所以一定要输入 ↓
行业报告：从宏观层面了解行业近况及未来趋势，从顶层俯瞰行业发展潜力。
（1）洞见研报：https://www.djyanbao.com/index
（2）发现报告：https://www.fxbaogao.com/
（3）艾瑞咨询、易观千帆（APP）
竞争对手：通过竞争对手可以很好地理解行业核心需求是什么
不会的时候要先学会吸收行业已有的成果，不要轻视友商的资料。
项目需求：各项目中产品现状梳理、复盘。
负责的项目中，能抽象出哪些关键的方向？这些方向里面包含了哪些关键要点和节点 这些要点和节点，如何数据量化其表现？通过这些数据表现，哪些方面做的不及预期，哪些方面做的很优秀？整理完后，可能我们就会有答案了。
用户需求：与用户和潜在用户交流（问卷、用户访谈等）。
PESTLE分析：
使用PESTLE分析法，对趋势更准确的解读，形成了所谓的“大环境分析”。
SWOT分析：
SWOT分析竞品的优势、劣势、机会、威胁，进而得出竞品切入某个行业的机会和优势，取长补短。
通过试用渠道体验竞品：
拓宽搜索渠道，信息爆炸的时代，知识的获取方便快捷。
（1）《调研报告》
（2）《竞品分析报告》
竞品分析有一定的流程，可以从战略层-范围层-结构层-框架层-表现层这几个层面进行分析；行业发展状况，“有哪些竞品？”，竞品使用者和特性的描述，自己的产品与竞品之间的比较，通过分析得到的结论和信息等。
（3）《BRD 商业需求文档》
需求获取是一个由粗略到细致的过程，从概括性的项目背景说明深入到目标用户确认、业务现状、业务问题和期望效果的梳理。视项目实际情况，可能需要和基层执行者、中层负责人和高层领导分别进行沟通。
需求采集对应的就是“道”，是摸清规律，是周鸿祎的六字法则“刚需、痛点、高频”，是张小龙的极简主义，是俞军的用户模型、交易模型。
重点要理解用户，用户不是自然人，是需求的集合，要研究用户行为及其背后的意义。例如：
其次要理解产品：有效用、有利润、可持续。
招投标文件、合同、建设方案、干系人登记册（干系人信息）、调研大纲。
焦点小组、引导式研讨会：例如深化某一智能应用的功能设计，可以先小范围的征求技术专家的意见，再用引导式研讨会的方式征求市场、运营的意见。
（1）《调研记录》
（2）《调研报告》：应包括对使用者的描述、通过分析得到的结论等
（3）《会议纪要》
（4）《需求跟踪矩阵》
调研的人员：真正的使用者不一定是决策者，大部分是具体的执行人员在应用。
调研的深度：请教——刨根问底——核实，对用户的初步回答反复追问“为什么”，引导用户从表面的行为开始思索，清理出行为背后的动机。
沟通技巧：避免使用封闭式提问（即提问者提出的问题带有预设的答案，回答者的很难展开回答），封闭式提问容易忽略问题本质，停留在问题表象。
线上会议：提前5分钟进会。
会议记录：参会人里若有“–”单位人员，排序很重要
索命提问一：与市场/销售/项目经理沟通：问项目的业务背景是什么。
这样提问太抽象，太宽泛了，我们不要把想要得到的答案，直接当做问题描述就不加处理地询问别人。除非是很懂产品侧工作的人员才能明白，多数时候，我们想要获得答案，都需要拆解成若干问题：
索命提问二：与客户沟通：直接问针对××事项您的需求是什么。
依然太宽泛，简短的问题可能会让回答者不知所措，或者面对这样粗暴的提问回答者并不想有条理的组织语言，我们与客户沟通更要用产品思维，学会结构化拆解，并且聚焦本质问题，表述清楚。（例如我们要做一个提高客户现在工作效率的系统），试试这样问：
任何时候，都请记住，不要抽象地提问，一定要进行拆解、聚焦可视化的问题，抽象而不聚焦的提问，总是让人一头雾水，捉摸不透，似乎在告诉对方：你猜，我想问你的是什么？
对获取的原始需求进行伪需求的过滤，梳理得到真实需求并进行汇总，完成产品定义，核心业务流程、确定功能范围、优先级等。
《调研记录》、《调研报告》、《会议纪要》、《需求跟踪矩阵》
宏观角度，基础功能>交互优化>亮点模块>利益相关>战略协作。
四象限法则：从推动角度，有重点地把主要的精力和时间集中地放在处理那些重要但不紧急的工作上。
思维导图：xmind、visio。
（1）《产品需求文档》
（2）《需求功能清单》
（3）《主要业务流程图》
（4）《功能结构图》
（5）《需求跟踪矩阵》
核对合同需求和用户需求（项目外包）：梳理出真实需求后，根据实际项目要求和资源限制，还需要从技术、成本、收益和风险等方面进行分析。
国家政策（G端）：关注国家相关条文政策，围绕主轴核心业务来设计。
需求review：不要抱着需求获取阶段已经进行了充分沟通的心态，一定要进行“再确认”。
从业务流程-任务流程-用户体验三个层面逐一输出产品想法，完善产品思路，最终完成产品原型的设计，UI设计师完成效果图的设计。
产品设计之术：术是执行方法，产品侧的工作面对的是如何执行一个具体功能的设计，建议我们可以用封装思维做原型，多使用母版，避免重复性的改动工作。
《产品需求文档》、《需求功能清单》、《主要业务流程图》、《功能结构图》、《需求跟踪矩阵》
原型设计工具：Axure、墨刀。
产品组件库：例如轮播组件、时间选择组件等，使用产品通用小组件，提高效率。
产品设计页面复用：例如积累通用设计页面登录注册、个人中心等，领域设计页面信息填报等，进行复用提高效率。
视觉动线：控制读者的视觉动线，强制让他去看你想让他看到的东西。
（1）产品需求原型
（2）高保真原型（UI效果图）
（3）《产品需求文档（PRD）》
（4）《需求跟踪矩阵》
模拟真实数据：产品需求原型尽量用真实数据来设计，避免过于理想化。
设计方法：按用户故事设计思路来设计用户的使用场景。
需求规范的内容格式：“原型+备注”形式的需求文档。
平台的设计规范：多人协作时注意尺寸、字体、颜色、组件的统一规范。
产品周期和时效性（G端）：当年的政策影响以及当下的重点事件都会是产品跟进的方向，落实政府需求时，设计上考虑当下热点的同时，要兼顾热点过后平时的使用场景，考虑用不同的模态，尽可能拿到更多的未来预算。
产品经理组织项目组成员参与并依据需求原型进行需求宣讲，使产品、UI、前端、后端、测试等同事对需求的理解达成一致。
产品需求原型/高保真原型（UI效果图）、《产品需求文档（PRD）》、《需求跟踪矩阵》
如果你的评审会上有人一直提出质疑、否定、甚至全是不满。请不要沮丧，你就当你使用了六项思考帽，这个人扮演的是黑色思考帽。
（1）《产品需求评审报告》（书面文档或邮件形式）
（2）依据评审结果修订的需求文档、原型设计
内部评审：
外部评审 （汇报对象要搞清）：
一问：你这个方案设计得不合理，应该怎样怎样设计。（上来就否定产品侧的设计并提出了新方案）。
二问：你的设计不够完整，缺了很多东西。
不要紧张，要求提问者具体说一下缺哪些东西，然后一一地对一下。
三问：你这个地方能不能简化成XXX？
要求提问者现场给出简化的说明，大家一起讨论，达成一致。
四问：感觉你这个功能没什么用啊，为什么要做？
产品经理需要把需求产生的背景、需求的目的说清楚，让提问者清晰地知道为什么要做这个需求，这个需求是解决什么问题的。这样就能和提问者在信息层面保持一致，能更好地达成共识。
五问：你设计的时候有没有考虑过后面XXX的情况？
六问：这个设计改动太大了，真要改吗？
※ 经验表明，尽量不要搞折中方案，折中方案往往后续需要花更多的时间去补救这个问题。
七问：你这个设计又改回原来那版了，改来改去在干嘛？
客观地说就行，不需要额外的去解释。提问者只是有点烦了，但是其实也知道做还是要做的，产品经理需要做的是安抚他们，然后给台阶。
研发与产品经理根据产品设计和项目周期，确定开发计划表并进入研发阶段，产品经理提供各种支持；产品经理根据产品设计测试系统，保证核心业务流程及功能准确性。
需求文档/高保真原型设计
project：项目进度管理工具。
鱼骨图（质量工具）：寻找问题根本原因。
帕累托图（二八原理）：百分之八十的问题是百分之二十的原因所造成的。找出产生大多数问题的关键原因，用来解决大多数问题。
（1）《开发计划》
（2）《开发计划跟踪表》
（3）《测试记录》
（4）《产品白皮书》
（5）《产品操作手册》
进度跟踪：对于项目进度要做到心中有数，关注各主要功能的实际开发与产品设计的偏差，将自己看到的潜在问题尽量扼杀在萌芽中。
果断决策：可能会存在需求不明确或者其他没考虑到的地方，产品经理要及时与相关方沟通，果断决策，避免出现大的工期延误、功能缺陷。
数据安全：很重要，强调数据的安全性和保密性。
需求新增：对于高层领导新增需求要及时响应。可纳入的立刻排期设计，不能纳入的给出合理理由。
数据统计：针对大屏的数据统计要精确且及时。
与开发的bug沟通：注意方法方式。
验收研发完的产品是否符合设计标准、符合合同要求，产品经理主导/配合准备验收汇报PPT、 系统演示脚本，保障产品（项目）验收
《产品白皮书》、《产品操作手册》
专家判断：外包项目验收请行业专家，听取专家意见形成验收报告。公司产品级验收请公司相关方领导，形成验收报告。
（1）可交付的产品
（2）验收报告（文档、邮件）
（3）各资料归档
系统准备：提前检查系统，确保演示功能的流畅性和完整性。
演讲脚本：按角色、按业务场景准备演讲脚本，最好准备可解决其痛点的真实业务场景，准备逐字稿（不要嫌麻烦或者不好意思而不准备逐字稿，任何的侃侃而谈大部分是因为前期充足的准备）
样例数据：准备故事脚本所需的样例数据，最好使用真实数据进行系统演示。
完成准备工作按期发布，产品经理负责产品的使用培训、推广。
《产品白皮书》、《产品操作手册》、可交付的产品
培训。
（1）《版本发布日志》
（2）《培训记录》
（3）《问题反馈记录》
产品宣讲培训：产品定位、价值、使用流程等。
常见问题准备：系统常见问题文档的准备。
产品录屏准备：配合推广，准备产品核心功能的操作录屏。
产品经理负责监控产品上线后的效果，关注基层业务人员使用系统提出的问题和疑问，收集并分析反馈信息，形成新的需求。
《版本发布日志》、《培训记录》、《问题反馈记录》
（1）《运营数据分析报告》
（2）《产品迭代规划》
数据埋点（C端）：通过埋点数据完成用户行为分析。
收集用户反馈（B端/G端）：反馈类型：BUG（可继续按功能模块分）、功能建议、内容建议、提问、评价、紧急事项。
根据产品总体规划和收集到的各种信息，根据需求的优先级、重要性，规划进迭代的版本里，逐一实施。
《运营数据分析报告》、《产品架构图》、《产品路径图》、《功能全景图》、《产品迭代规划》
（1）《产品迭代计划说明书》
（2）《更新的功能清单》
（3）《PO冲刺待办列表》
复盘分析：“学习-思考-实践-总结-再学习”，反思自己的设计和系统是否达到预期，如果没有达到预期，思考应该更注重哪一方面。
产品架构图要有高度：从架构层面看产品全貌 —— 领导层关注。
产品路径图要可执行：从时间线上看产品的路径 —— 领导层关注。
功能全景图要可落地：从具体功能点看产品的细节 —— 执行人员关注。
控制节奏：不可一次性做太多，工期拉太长，也不可无周期的频繁更新，导致出错的风险增大。
分享了产品侧的工作流程，以及每个环节的输入、输出、工具和注意事项。汇总起来产品经理所要具备以下的几种能力。
“工欲善其事，必先利其器”
必备工具：
（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/
（1）百度指数：https://index.baidu.com/
（2）SPSS：https://www.spsspro.com/
（3）艾瑞指数：https://index.iresearch.com.cn/
问：学习了一些知识，看过一些课程和书籍，可是分析具体问题还是停留在表面，好像懂了又好像没懂，怎么论证。
答：实践
问：产品经理工作的边界在哪里？
答：不要轻易预设自己的工作边界，不设边界地发现问题、识别问题，并且推动着解决问题，让问题到你为止。
问：需求评审，主要领导都在时不提问题，评审完之后，技术人员在做的时候，就会各自提简化要求（因研发强势、时间紧张、功能复杂等），如何规避。
答：需要技术人员给出简化的说明，是否是自身考虑不周或只是在找借口，基本原则上是不妥协。
答：若技术人员强势，要坚持自己的态度，通过不断沟通和提升自我角度，讲清楚是业务主要流程或是合同需求，得到技术人员尊重和信任，进而改进问题。
答：因工期时间紧张而要简化：可以接受当前简化，但后期要持续跟进完善和补充功能。
问：由于外部因素（客户需求反复/客户负责人变化）、内部因素（开发实际效果不理想）等原因，出现同一功能反复返工，如何处理。
答：外部因素：重新跟客户对接明确需求，进行评估并向上反馈，再次进入研发阶段要注意与技术人员解释清楚变更的原因背景，以及这次调整作为产品侧认真做了哪些专业的规划设计，让技术人员减少对产品侧的不认同或者对于返工厌烦的情绪；
答：内部因素：不要只听一个人说，多方听取意见，寻找问题根本原因，判断是否是技术能力问题，推动协调其他人解决。
问：客户相关人员较多，如何管理不同相关方提的需求。
答：可根据干系人权利/利益方格中对项目结果的影响程度，对干系人花费不同的沟通成本和时间成本。
老子的《道德经》，“器”服务于“术”，“术”符合于“法”，“法”根基于“道”，“道法术器”整个体系又在“势”的裹挟下不断演进并驱动“势”的前进和变化。
产品工作者的“道、法、术、器、势”即：“产品技能”服务于“产品设计”，“产品设计”是基于“需求分析”的结果，“需求分析”的根基是“需求采集”，整个体系自然是在“产品规划”的前提下推动的。经典方法论的思考框架适用与任何情况。
以上工作流程和内容，作为产品侧的工作人员可以根据情况进行裁剪。希望我们越来越少的纠结、痛苦，可以更加坚定的做自己。文章可能有很多不足，欢迎大家一起探讨补充。
在此鸣谢小葵花岛主、似水流年，有一些想法是和我的两个好朋友讨论和吐槽中产生的。
本文由 @机械小7 原创发布于人人都是产品经理。未经作者许可，禁止转载。
题图来自Unsplash，基于CC0协议。
该文观点仅代表作者本人，人人都是产品经理平台仅提供信息存储空间服务。
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。