来源：好夕雷

之前写年终复盘人都麻了，发现写完居然有 70+ 页 PPT 那么多。

不过在这过程中，我大致回顾了入行产品经理以来，所遇到的一些坑和经验。

分享出来，希望对你有所帮助。

产品经理的 5 个阶段

产品经理随着年限的增长，工作中所面临的问题一定是越来越复杂，相应的产品能力要求也越高。

理想的情况下，一个产品小白会沿着初级产品经理、中级产品经理、高级产品经理、产品总监，甚至公司 CEO 这条路径完成升职加薪。

理想很丰满，现实却很残酷阿~

实际上很多所谓的产品经理，只会 1 年经验重复用 3 年、甚至更久。到了跳槽面试时就掉链子了，问来问去发现只会画画简单的原型，业内俗称“原型仔”。

如何才能避免这种情况发生？

1-3 年左右的初、中级产品经理，一般都会经历 5 个产品阶段，掌握这些阶段的相应能力，才能往高阶产品经理迈进。

这五个产品阶段，分别是：实现业务需求、挖掘产品需求、规划产品路径、架构产品模型、推进产品决策。

阶段一：实现业务需求

很多刚做产品经理的童鞋，就是从接需求做方案开始的。

你可能会遇到老板的 P0 需求、销售或运营为了完成 KPI 而设的业务需求、财务风控需求、一些 BUG 修复、界面样式优化等。这个时候，一般都是业务说啥做啥，活脱脱产品工具人。

更离谱的是，我朋友还遇过老板亲自加班开会，专门看界面是否美观、各种交互是否流畅。

说实话哦，这种精神值得鼓励，但没必要。产品想要赚钱，真不是用户体验能决定的~

言归正传，在这个阶段的部分产品经理，可能简单的画几个原型，再复杂点上思维导图、流程图，稍微做做评审就开发去啦。

怎么避免成为这种弱鸡产品经理？

你需要赶紧学会这 3 点，分别是“掌握产品基础、识别需求价值、规范产品工作”。

掌握产品基础

作为一个产品小白，正处于入门产品的阶段。

你首先需要做的就是，学会“相关产品经理工具、补充产品经理知识、撰写产品需求文档”等，这里分享下我的一些心得。

个人常用  20+ 产品经理工具：

• 需求管理：多维表格、板栗看板；

• 产品设计：Axure RP 9、draw.io、Xmind ZEN；

• 项目管理：Teambition；

• 数据分析：Navicat、Tablaue；

• 笔记管理：Obsidian、Wolai、Typora；

• 浏览器：Vivaldi、Chrome、Edge；

• AI 相关：Coze、Kimi；

• 效率工具：飞书、Listary、WGestures、Snipaste、Quicker、AutoHotkey。

20+ 入门到进阶的产品经理书单：

• 入门产品（2 本）：《绝密原型档案》、《移动应用 UI 设计模式》

• 初级产品（2 本）：《用户体验要素》、《首席产品官 1》

• 中级产品（2 本）：《决胜 B 端》、《首席产品官 2》

• 数据分析（3 本）：《SQL 必知必会》、《数据分析思维》、《数据产品经理：实战进阶》

• 用户增长（3 本）：《硅谷增长黑客实战笔记》、《我在一线做用户增长》、《用户增长方法论》

• UML建模（3 本）：《图解产品》、《火球》、《大象》

• 产品策略（3 本）：《策略产品经理实践》、《策略产品经理：模型与方法论》、《搜广推策略产品经理》

• 其他相关（3 本）：《穷查理宝典》、《高维度思考法》、《金字塔原理》

一份涨薪 3 倍的需求文档撰写指南，涉及 9 个模块：

• 产品概览

• 产品结构

• UML相关

• 流程梳理

• 文档相关

• 消息推送

• 原型界面

• 功能交互

• 废纸篓等

识别需求价值

要想判断一个需求的价值高低，你可以从“战略契合、市场潜力、商业价值、符合目标、覆盖人群、使用频率、研发成本”等维度进行评估：

• 战略契合：并不是什么需求都必须要做，如果需求与用户画像冲突、年度战略规划不符，即使需求价值再高也不做；

• 市场潜力：相关需求的未来市场有多大？例如 iPhone 面世后，原先全球的手机用户，未来将面临更新换代的需求；

• 商业价值：通过落地需求方案，能直接、间接为公司带来多少增量收入；

• 符合目标：通过产品专业的需求挖掘，确保业务方提出的需求，符合其业务目标的占比有多大；

• 覆盖人群：需要考虑有同样需求的用户，到底是什么量级；

• 使用频率：推测出每个用户在一年中，遇到该需求的频率；

• 学习成本：提供的方案，对用户来说，是否能快速学会和易于上手；

• 研发成本：一个需求开发落地，所需要的工作日时间。

在日常工作中，接到新需求不一定都要考虑这么多因素，你可根据实际情况，进行删减部分。

一些小功能需求，稍微考虑“覆盖人群、使用频率、研发成本”也够了。

规范产品工作

产品经理的工作并不只有画原型和思维导图，我认为只要能提高产品价值产出，都可以成为一个产品经理的工作职责。

之前分享过一个大厂产品都在用的产品工作流：接需求、懂业务、理流程、选方案、建模型、定状态、画原型、补交互。

学会这套 SOP 产品流程，我相信你一定可以更稳定、高效地产出高质量的产品方案。

有人就会问，工作 SOP 化有这么重要吗？

我也是前不久，才突然意识到工作 SOP 化的重要性，一套成熟的 SOP ，它决定了产出内容的平均质量。

没有经过 SOP 化的工作流程，就像刚玩游戏的菜鸟。你需要乱跑地图，去偶遇散落各地的怪物，刷怪升级赚金币。

你甚至不知道这是如何完成的，也不清楚改进空间，只能一味重复试错。

阶段二：挖掘产品需求

产品需求和业务需求的区别是，产品需求的提出人是自己。

说起来简单，做起来可不容易。

做了 2 -3 年那么久的产品经理了，你应该试着从实际业务出发，分析当前产品遇到了哪些问题，可以通过系统去规模化解决。

在这个阶段，你需要从一个被动的需求接收方，成为需求发现者。

刚开始你可能会找不到感觉。这是正常现象，俗话说熟能生巧，做多了你也就会了~

只要能解决用户需求，小到一个 BUG 修复、功能优化，你都可以去尝试看看。

阶段三：规划产品路径

一个公司的产品负责人，一般需要根据公司战略、市场机会，来规划团队未来的产品演进路线图。

这种规划至少半年以上，才算及格。

此外，你还需要平衡好各大小版本，应该在什么时间、什么节点、什么节奏、用什么方案，完成它才合适，而且 ROI 收益最高。

在这里，我分享一些关于版本规划的经验：

• 资源超级充裕时：你可以 C 端、后台功能自研；

• 当资源略显不足：C 端进行自研，功能可以通过数据库配置，减少后续迭代维护成本；

• 如资源异常紧张：你还可以借用 A 项目接口，实现 B 项目上线。

• 资源完全不够用：这个时候就要动点脑瓜子，发挥下产品经理的脑洞，直接用现成的开源项目，拼接组装出一套可用的解决方案。 

上面提到的“实现业务需求、挖掘产品需求、规划产品路径”等三个阶段，是初阶产品经理迈向中阶，需要去面对和解决的问题。

我们可以用这张图，来概括它们。

业务需求、产品需求，提高的是产品经理的解决能力，而产品规划则对应了产品经理的管理能力。

阶段四：架构产品模型

产品经理做久了，你可以尝试提出自己的产品模型，它用于持续满足某一类特定需求的产品方案。

俞军老师曾在《俞军产品方法论》一书中，定义了什么是交易模型。

之前由于概念抽象，我一直无法完全理解。

闲来无事又看了《About Face 4: 交互设计精髓》，发现模型真的无处不在。

1. 用户模型：用户了解用户需求和目的

2. 呈现模型：设计合理的交互体验和呈现方式，以便符合用户的心理模型

3. 系统模型：研发开发的系统功能细节 

那产品领域的模型是什么？

作为产品经理，你需要不断满足琐碎的业务需求，有可能每个需求都会衍生出各自的方案和功能。

然而一旦你使用模型的概念思考，就可以设计出一类需求集的通用模型来解决问题。

常见的如 ERP、CRM、PMS 等系统，都是产品模型的一种。

这些系统诞生的原因，就是为了解决某些特定领域的业务问题。

阶段五：推进产品决策

产品经理的大坑之一，就是容易陷入业务的节奏，老是接完需求，就屁颠屁颠干活去了~

据我以往的产品经验，需求是永远做不完的，所以你需要花更多时间思考和决策。

在这个阶段，你需要用 80% 精力，找到这一年最重要的事情，并完成相关产品落地。

这有点像你在玩一款射击排位游戏，每盘比赛系统只给玩家有限的子弹，每个靶子的射击难度都类似，但分数有可能相差几十上百倍。

你需要在限定的时间内，与其他玩家争抢这些靶子，并尽可能获得更高分数。

那么在游戏获胜的关键，就是如何快速分辨，并打到那些更高分的靶子。

一般来说越高分的靶子，数量越是稀少。

这说明，二八法则同样适用于产品领域。

那些能影响公司营收的高价值需求，可能只占了 1%。

而你需要做的是，为这些需求的推进，进行决策把关。