PM 基础 · 第 1 篇

什么是产品经理

你可能在招聘网站上见过这个岗位，也可能听朋友说“我是做产品的”，但如果有人追问你一句——“产品经理到底是干嘛的？”——大多数人其实答不清楚。

这篇文章的目标很简单：让你读完之后，对“产品经理”这三个字有一个清晰、准确、不被忽悠的认知。

产品经理不是“经理”

这是新人最容易踩的第一个坑。

很多人一看到“经理”两个字，就觉得这是个管人的岗位——手下带团队，开会拍桌子，审批报销单。完全不是这样。

“产品经理”翻译自英文 Product Manager。这里的 Manager 不是“管理别人的人”，而是“管理某件事的人”。更准确地说，PM 是产品的负责人——你不管人，你管的是一个产品（或者产品的某个模块）从 0 到 1、从 1 到 100 的整个过程。

打个比方：如果产品是一部电影，产品经理更像是导演，而不是制片厂的行政经理。导演不会亲自写剧本、扛摄像机、演戏，但他要决定“这部电影讲什么故事、拍给谁看、用什么节奏呈现”，并且让编剧、摄影、演员这些专业角色协同工作，最终交出一部完整的作品。

一个刚入行的产品经理，通常一个下属都没有。你的“权力”不来自职级，而来自你对产品的理解深度和你推动事情的能力。

产品经理到底做什么

PM 的日常工作可以概括为四个阶段，形成一个不断循环的闭环：

1. 发现问题

产品经理的起点，永远是发现一个值得解决的问题。

• 用户调研：和真实用户聊天。比如你在做一个外卖 App，你可能会去访谈配送员，发现他们最头疼的不是导航，而是小区门禁进不去。
• 数据分析：看后台数据找异常。比如注册流程的第三步流失率突然飙到 60%，这背后一定藏着问题。
• 竞品观察：看看同行在做什么。不是为了抄，而是为了理解市场趋势。当你发现三个竞品都在做“拼团”功能时，你需要判断这是不是真正的用户需求，还是只是行业跟风。

这个阶段最重要的能力是判断力——不是所有问题都值得解决，PM 需要从一堆噪音中找到那个真正影响用户体验或商业价值的关键问题。

2. 定义方案

找到问题之后，PM 需要把“模糊的问题”变成“清晰的解决方案”。

• 写需求文档（PRD）：用文字和图表把“我们要做什么、为什么做、做成什么样”讲清楚。这是 PM 最核心的产出物之一。
• 画原型：用 Axure、Figma 或者纸笔画出页面的大致布局和交互流程，让团队直观地看到“最终产品长什么样”。
• 排优先级：资源永远是有限的。同时有 10 个需求摆在面前，你只能先做 3 个，选哪 3 个？这个决策直接决定产品的走向。

举个真实场景：你负责一个在线教育产品，同时收到三个需求——“增加课后习题功能”、“优化视频加载速度”、“上线学习打卡”。你通过数据发现 40% 的用户在视频加载超过 5 秒时直接退出，那“优化视频加载速度”显然应该排在最前面，因为用户连课都看不了，其他功能再好也没意义。

3. 推动落地

方案定了，但事情不会自己发生。PM 需要和多个角色协作，把方案变成真实的产品。

• 和设计师对齐视觉方案，确保设计既好看又好用；
• 和开发工程师评审技术可行性，确认排期；
• 和测试工程师一起过验收标准，保证上线质量；
• 遇到分歧时，PM 要拿出数据和逻辑来说服人，而不是靠“我是产品经理所以听我的”。

这个阶段最考验的是沟通能力。你会发现，PM 每天可能有一半时间在开会、对齐信息、处理突发问题。比如开发说“这个功能做不了”，你得判断是真的做不了，还是成本太高需要简化方案——然后快速做出调整。

4. 验证效果

产品上线不是终点，而是新一轮循环的起点。

• 看数据：功能上线一周后，核心指标有没有变化？比如你优化了注册流程，注册转化率是从 30% 升到了 45%，还是纹丝不动？
• 收反馈：去应用商店看评论，去客服后台翻工单，去用户社群里潜水，听听真实用户怎么说。
• 迭代优化：根据数据和反馈决定下一步——是继续优化这个功能，还是把精力投向更重要的问题。

好的产品经理有一个共同特质：对结果负责。功能上线了不代表成功，数据变好了才算。如果效果不达预期，PM 需要复盘原因，调整方向，而不是甩锅给开发“代码写得不好”或者设计“界面不够好看”。

PM 和相关角色的区别

刚入行的时候，很容易把 PM 和其他岗位搞混。这里做一个清晰的对比。

PM vs 项目经理（Project Manager）

这两个岗位的英文缩写都是 PM，但职责完全不同。

• 产品经理管的是“做什么”和“为什么做”——我们要不要做这个功能？它解决了什么问题？
• 项目经理管的是“怎么按时做完”——排期、资源分配、风险管控、进度跟踪。

一句话区分：产品经理决定“造一座什么样的桥”，项目经理确保“这座桥能在预算内按时造完”。

在一些小公司，产品经理可能需要兼任项目经理的职责。但在大厂，这通常是两个独立的岗位。

PM vs 设计师

• PM 决定“解决什么问题”——比如“用户找不到退款入口，我们需要让退款流程更容易被发现”。
• 设计师决定“用什么方式呈现”——是在首页加个醒目按钮，还是在订单详情页增加一个快捷入口，用什么颜色、什么交互方式。

PM 定义问题和目标，设计师负责视觉和交互层面的解决方案。两者是紧密合作的关系，而不是上下级。

PM vs 开发工程师

• PM 说清楚“为什么做”和“做成什么样”——需求背景、用户场景、验收标准。
• 开发负责“怎么实现”——用什么技术架构、写什么代码、如何保证性能。

一个常见的反模式是 PM 跑去告诉开发“你应该用 Redis 缓存这个数据”——这叫越界。PM 要做的是把需求讲清楚，技术方案应该由开发来决定。

PM vs 运营

• PM 负责“造产品”——把产品从无到有做出来，持续迭代。
• 运营负责“让产品被人用起来”——拉新、促活、留存、转化。

比如你做了一个读书 App，PM 设计了“每日阅读打卡”功能，运营则策划“连续打卡 7 天送会员”的活动来拉动用户使用这个功能。产品是工具，运营是让工具发挥价值的手段。

产品经理需要哪些能力

这可能是新人最关心的问题。好消息是：PM 不需要某个特定专业背景，也不要求你会写代码。但以下几项能力是真正拉开差距的关键。

逻辑思维

产品经理每天都在做决策，而决策的质量取决于你拆解问题的能力。

比如老板说“我们的日活在下降，你去看看怎么回事”。逻辑思维强的 PM 会把问题拆开：日活 = 新增用户 + 留存用户 - 流失用户。先看是哪一段出了问题，再往下钻——如果是流失增加，是哪个渠道来的用户在流失？流失发生在使用的第几天？流失前用户的最后行为是什么？一步步缩小范围，直到定位到根因。

同理心

同理心不是“我觉得用户会怎样”，而是真正站在用户的处境去感受。

举个例子：你在做一个老年人健康管理 App。你自己 25 岁，手机玩得飞起，觉得“在设置里加个字体大小调整就行了”。但如果你真正去观察你爷爷奶奶用手机，你会发现他们可能根本找不到“设置”在哪里。同理心强的 PM 会把默认字体直接设大，而不是藏一个功能让用户自己去找。

沟通协作

PM 是一个“没有实权但要推动所有人”的角色。你不能命令设计师改稿、不能要求开发加班，但你需要让所有人理解目标并愿意配合。

这要求你能做到三件事：讲清楚为什么（让别人理解这件事的价值）、拿出依据（数据、用户反馈，而不是“我觉得”）、尊重专业（在设计和技术问题上给专业角色足够的空间）。

数据敏感度

“我觉得这个功能很好”和“上线后核心指标提升了 15%”，在产品团队里的说服力完全不同。

PM 不需要成为数据分析专家，但你至少要做到：能看懂基础的数据指标（DAU、留存率、转化率、ARPU）、能用数据验证自己的假设、能在数据和直觉冲突时选择相信数据。

技术理解

PM 不需要会写代码，但你需要理解技术的边界。

比如开发跟你说“这个需求需要两周”，你得能大致判断这是合理评估还是过度估算。当你了解前后端的基本分工、接口的概念、数据库的基本逻辑后，你和技术团队的沟通效率会成倍提升——你也更不容易提出“技术上根本不可能”的需求。

一句话总结

如果有人问你“产品经理到底是什么”，你可以这样回答：

产品经理就是那个代表用户在公司内部说话、同时平衡商业目标的人。 他不写代码、不画设计稿、不拉用户，但他决定产品往哪走——然后说服所有人一起往那个方向走。

这个角色的门槛看起来不高——不要求特定学历、不要求技术背景——但天花板极高。因为你需要同时具备理性的分析能力和感性的用户洞察，还要在复杂的组织环境中推动事情前进。

如果你是一个喜欢思考“为什么”、喜欢把模糊的问题变清晰、喜欢和不同角色的人打交道的人，那产品经理可能是一个值得认真考虑的方向。

下一篇，我们聊聊产品思维——产品经理最核心的底层能力。