PM 是什么：一份产品与项目经验分享

关于 PM，很多人第一反应是：PM 到底指什么？

• Product Manager？
• Project Manager？
• Program Manager？

其实在不同公司里，PM 的含义并不完全一样。下面这篇文章，主要聊的是我自己更熟悉的那类 PM：既要理解产品，也要推动项目落地的角色。它不一定严格对应所有公司的命名体系。

不同公司里，PM 分别是什么

比如在 Google，常见的是：

• Product Manager
• TPM，也就是 Technical Program Manager

在 Facebook，通常也是：

• Product Manager
• TPM

在 Microsoft，很多时候对应的是：

• Program Manager

在 Apple，则更常见的是：

• EPM

所以如果只说一句“我是 PM”，其实信息是不够的。因为不同公司、不同组织架构下，PM 的职责边界可能差很多。后面这篇分享，也主要是从“产品统筹 + 项目推进”这个语境出发来讲。

PM 面对的，从来不只是一个团队

一个项目里会有很多参与方。PM 要面对的，也从来不只是研发团队。

比如：

• 客户
• 用户
• 设计
• 开发
• 测试
• 运营
• 管理层

PM 本质上是站在很多角色中间，去推动事情往前走的人。

PM 要覆盖整个产品生命周期

我自己的理解是，PM 需要理解并推动产品生命周期中的关键环节，而不只是盯住某一个点。

flowchart LR
    A["市场机会"] --> B["市场分析"]
    B --> C["产品分析"]
    C --> D["项目规划"]
    D --> F["开发计划"]
    F --> G["执行与跟踪"]
    G --> H["测试与迭代"]
    H --> I["上线后的数据回收与评估"]
    I --> C

如果拆开来看，大概会包含这些阶段。

1. 市场机会与市场分析

产品不是拍脑袋做出来的，前面一定有市场机会判断。

市场分析里，至少要考虑这些问题：

• 国家政策
• 市场刚需
• 市场规模
• 竞争情况
• 产品现状

换句话说，你要先想清楚：这个市场值不值得做，这件事是不是用户真的需要。

2. 产品分析与功能规划

在产品分析阶段，我通常会关注这些内容：

• 用户需求
• 成本
• feature list
• 产品目的

这一阶段的重点，是把“想做什么”逐步变成“为什么做”和“先做什么”。

3. 项目规划

项目规划阶段，更偏执行落地，通常要包含这些内容：

1. 项目排期
2. 功能拆解
3. 用足够清晰的细节把产品说明白

这里很重要的一点是，文档不是为了写而写，而是为了让后续参与项目的人都能理解同一件事。

4. 开发计划

进入开发前，需要把大块的想法进一步拆开。

比如：

• 任务拆解
• 人力安排
• 节奏规划

很多项目后面跑偏，不是因为大家不努力，而是因为一开始没有把事情拆清楚。

5. 执行与跟踪

执行阶段我一般会借助 Jira 这类工具来做项目跟踪，核心工作包括：

• 项目追踪
• 进度汇报
• 跨团队协作
• 风险暴露

这一步里，PM 的价值不是“自己做了多少”，而是“有没有让团队持续朝正确方向推进”。

6. 测试、迭代与回收

测试并不是项目的最后一下收尾，而是持续迭代的一部分。

通常会包括：

• 测试计划和测试表格
• 产品设计迭代
• triage bugs

上线之后，也不是结束。还需要继续做这些事情：

• 用户数据收集
• 用户侧指标的衡量与评估
• 再一轮产品设计迭代

PM 真正管的是什么

总结下来，我理解 PM 需要覆盖的不只是项目管理本身，还包括这些方面：

• vision
• mission
• strategy
• 市场分析
• 客户分析
• 数据分析
• 功能优先级
• 规划和任务拆解
• 跨团队协作
• 常规项目推进

所以 PM 不是单纯的“写文档的人”，也不是单纯的“催进度的人”。PM 更像是把产品、团队和商业目标串起来的人。我常常说，PM 本质上是在做服务。

关于学习和积累

关于大家问到的一些问题，我也顺手整理一下。

书籍

这些书对我帮助比较大：

• Making Things Happen：我觉得算是 PM 的经典书籍。
• StrengthsFinder 2.0：帮助发现自己和团队成员的 strengths 和 weaknesses，更好地扬长避短。
• Influence: The Psychology of Persuasion
• 100 Things Every Designer Needs to Know About People
• 《营销管理（15th Edition）》

积累方法

我自己的积累方式，核心就几条。

第一，持续记录和总结。
我一直有做笔记的习惯。无论是工作中遇到的事情，和别人交流得到的启发，还是从书里学到的东西，我都会整理到 Obsidian 里面。

第二，工作之后要学会主动学习。
工作中的学习，和学校里那种被动接受式学习差别非常大。很多时候，是你先遇到了问题，才知道自己缺什么知识。

第三，开会要有参与感，也要有专注度。
我个人的经验是，如果一个会议我从头到尾都不说话，那它大概率不值得我现在参加。而如果我决定参加，就要保持专注，手机最好放在一边。

第四，多和有经验的人交流。
认真听别人给的建议，再认真想一遍：这些建议怎么落到自己的工作里。

第五，重视连接。
PM 的成功，除了自身能力，很大一部分也依赖团队。花时间 build 好的 connections，并且持续维护这些 connections，很重要。我的理念一直是，在工作中交很多朋友。

关于进度维护和文档管理

如果说有什么比较大的经验，我会给三条建议：

1. 先搞清楚每份文档的受众，再决定需要 detail 到什么程度。
2. 尽量自动化 report，前期多花一点时间把流程理顺，把AI融入到工作流程中，后面会省很多力气。
3. 不需要过度追求所有文档都永远实时更新。

1. 所有 tracking 尽量自动化

开发任务、bug 跟踪，尽量全部进入自动化管理工具。

我自己的原则就是：

以无人值守为荣，以人工介入为耻。

能从系统里自动拉出来的，不要靠人手工维护。

2. Roadmap 和任务跟踪不是一回事

Roadmap 是 high-level 的，一般每个月或者每个季度更新一次就够了。

原因很简单：Roadmap 的 audience 和 task tracking 的 audience 根本不一样。

• Roadmap 是对上的，给 CEO 和管理团队看，要求是 high-level。
• Task tracking 是对执行团队的，要求是非常 detailed。

这两个文档不能混。

3. 具体执行过程要直接从工具里生成

具体执行过程里的进度跟进，最好直接从 Jira 或者其他工具生成。

同理：

• 性能测试如果是软件项目，尽量自动化
• 测试报告也尽量自动生成

不要把 PM 的时间花在重复搬运信息上。

4. 周报一定要先想清楚受众

我们团队一般会做两份周报。

第一份是给 executives 的，内容非常 high-level，通常只有四部分：

1. 项目总体状态：on track、with concerns 或 at risk
2. 项目 highlights
3. 项目 risks，以及需要 executive 特别关注的点
4. 项目里每个子项目的 high-level 进度

这份周报非常重要，因为它是让高层了解项目情况的关键 channel，所以值得团队认真花心思去写。

第二份是给执行团队的，一般可以从 Jira/Wiki 直接生成，内容会更细：

1. 当前 sprint 或 milestone 的完成情况
2. 剩余任务数
3. 标红 delay 的任务
4. 团队成员上周完成的任务数，以及剩余任务数

5. 功能规划文档天然会过时

项目功能规划文档，一般在 review 完的那个时刻，就已经开始过时了。因为功能一定会不断迭代。

所以我更倾向于这样处理：

1. 规划文档在 review 和 approve 时，把方向讲清楚。
2. 之后尽快 breakdown 成开发可执行的任务。
3. 后续所有变化，都在开发任务管理工具里 track，比如 Jira。

6. 遗留问题和 bug 统一管理

遗留问题、bug，最好全部放进同一个开发任务管理工具里，例如 Jira。

这样团队对信息源会有统一认知，不容易出现“到底哪份表才是最新的”这种问题。

最后

如果一定要用一句话总结我对 PM 的理解，那就是：PM 不是只负责某一个点，而是要尽可能看清楚产品从机会判断到落地迭代的整个链条，然后让合适的人，在合适的节奏里，把事情真正做成。

更重要的是项目的成败，而不是 PM 自己在项目里具体做了多少动作。有时候让自己闲下来，多想想问题到底在哪，比一直忙忙碌碌更重要。