第1章 产品经理到底是个啥
你以为产品经理就是画原型的？做了3年才知道，画原型只是产品经理工作中不到10%的环节。真正拉开差距的，是那90%看不见的思考。
我是怕浪猫，一个从代码堆里爬出来、在产品坑里摸爬滚打多年的老兵。这个系列，我准备把产品经理从0到1的所有核心能力，一次性讲透。
1.1 互联网与互联网产品
1.1.1 互联网行业概览与发展脉络
要理解产品经理，先得理解互联网行业本身。
互联网行业的发展可以用三个阶段来概括：
第一阶段：信息互联网（1995-2008）
这个阶段的互联网本质是"信息搬运工"。新浪把新闻搬上网，搜狐把分类信息搬上网，百度把搜索搬到线上。核心逻辑是：线下有什么，线上就有什么。产品形态以门户网站、搜索引擎、BBS为主，商业模式主要是广告。
这个阶段的产品经理，更像是"内容编辑"——决定页面放什么内容、怎么排列、用户往哪看。技术门槛低，但信息组织能力要求高。
第二阶段：消费互联网（2008-2018）
智能手机普及后，互联网从PC端走向移动端，从"信息获取"变成"生活服务"。淘宝让你不用逛街就能购物，微信让你不用见面就能社交，美团让你不用出门就能吃饭。核心逻辑是：线下有什么体验，线上就替代什么体验。
这个阶段的产品经理数量井喷，因为每多一个App，就多出几个产品经理的坑。2015年前后，"人人都是产品经理"这句话被喊得震天响。
第三阶段：产业互联网（2018至今）
消费互联网的流量红利见顶后，互联网开始向产业深处渗透。不是做个App替代线下，而是用数据和技术重构整个产业链。智能制造、数字医疗、智慧城市，都是这个阶段的产物。同时，AI的爆发让"产品经理"这个角色再次被重新定义。
互联网的每次进化，都不是简单的技术升级，而是对人类协作方式的根本重构。产品经理的价值，恰恰在于理解这种重构，并在其中找到自己的位置。
互联网行业现状一览
| 维度 | 现状 | 趋势 |
|---|---|---|
| 用户规模 | 中国网民超10亿 | 增速放缓，存量竞争 |
| 商业模式 | 广告/电商/游戏/订阅 | 混合模式增多 |
| 竞争格局 | 头部集中，尾部长尾 | 中小公司差异化求生 |
| 技术驱动 | AI/大数据/云计算 | 从工具到基础设施 |
| 人才需求 | 产品经理岗位萎缩 | 高端产品经理更稀缺 |
1.1.2 互联网产品的定义与特征
什么是互联网产品？很多人会说"就是App"，但这个回答太窄了。
互联网产品是：通过互联网技术，为特定用户群体解决特定问题，并创造商业价值的解决方案。
这个定义里有四个关键词：
特定用户群体——产品不是给所有人用的。微信给社交用户用，钉钉给办公用户用，即便都是即时通讯，用户群体完全不同。产品经理最重要的决策之一，就是"不做谁的生意"。
特定问题——产品解决的是问题，不是需求。用户说"我想要一匹更快的马"，需求是更快的马，问题是出行效率。产品经理要穿透需求，看到问题。
互联网技术——技术是手段，不是目的。用户不在乎你用的是什么架构，在乎的是问题有没有被解决。但产品经理必须理解技术的能力边界，否则设计出来的方案要么做不出来，要么成本失控。
商业价值——没有商业价值的产品是公益项目。产品经理不是理想主义者，必须在用户价值和商业价值之间找到平衡。
互联网产品有五个核心特征：
第一，网络效应。 用户越多，产品越有价值。微信一个人用没意义，十亿人用才有意义。产品经理需要思考：我的产品有没有网络效应？如何设计机制让网络效应更快显现？
第二，边际成本递减。 多服务一个用户的成本几乎为零。这意味着互联网产品天然追求规模，而产品经理需要在规模和体验之间做权衡。
第三，快速迭代。 传统产品上市后再改很难，互联网产品可以每天发版。快速迭代不是乱改，而是基于数据和反馈的持续优化。
第四，数据驱动。 一切可测量，一切可优化。产品经理必须学会用数据说话，而不是凭直觉决策。
第五，平台化趋势。 优秀的产品会从工具变成平台。微信从通讯工具变成社交平台，淘宝从电商工具变成交易平台。产品经理需要思考：我的产品有没有平台化的可能？
产品不是功能堆砌，而是问题的最优解。功能多不等于产品好，能精准解决问题才是好产品。
1.1.3 互联网产品的类型与分类
理解产品类型，是产品经理的基本功。不同类型的产品，设计思路、核心指标、商业模式完全不同。
按用户类型分
| 类型 | 典型产品 | 核心关注 | 关键指标 |
|---|---|---|---|
| C端产品 | 微信、抖音、淘宝 | 用户体验、增长 | DAU、留存率、时长 |
| B端产品 | 钉钉、飞书、Salesforce | 效率、流程 | 续费率、NPS、使用率 |
| 平台产品 | 淘宝、美团、滴滴 | 生态平衡 | GMV、供需比、匹配效率 |
按业务形态分
| 类型 | 典型产品 | 核心逻辑 | 变现方式 |
|---|---|---|---|
| 工具型 | 美图、WPS、剪映 | 用完即走，提高效率 | 增值服务/订阅 |
| 内容型 | 抖音、B站、知乎 | 内容消费，时长为王 | 广告/会员/打赏 |
| 社交型 | 微信、微博、Soul | 人与人连接 | 广告/游戏/增值 |
| 交易型 | 淘宝、京东、拼多多 | 商品/服务交易 | 佣金/广告/金融 |
| 平台型 | 美团、滴滴、 Airbnb | 供需匹配 | 佣金/广告 |
按产品阶段分
| 阶段 | 特征 | 产品经理重点 |
|---|---|---|
| 探索期 | PMF未验证 | 快速试错，找方向 |
| 成长期 | PMF已验证，高速增长 | 增长策略，体验优化 |
| 成熟期 | 增长放缓，竞争激烈 | 精细化运营，商业化 |
| 衰退期 | 用户流失，市场萎缩 | 转型或收缩，延长生命周期 |
看懂产品类型，比看懂功能列表重要一百倍。类型决定了你的设计思路、指标体系和商业模式。
1.2 产品经理的角色与职责
1.2.1 产品经理的起源与角色定位
产品经理这个角色，最早来自宝洁。1931年，宝洁的Neil McElroy写了一份著名的备忘录，提出"Brand Man"（品牌经理）的概念——一个人对品牌的整体表现负责，从市场调研到产品开发到销售推广。
互联网行业的产品经理，继承了这种"端到端负责"的精神，但工作内容完全不同。宝洁的品牌经理管的是实体产品的全生命周期，互联网产品经理管的是数字产品的全生命周期。
在中国互联网，产品经理角色的演化经历了几个阶段：
2010年前后：运营型产品经理。 这个阶段产品经理大量来自运营转岗，核心能力是"管需求"——运营提什么需求，产品经理就写什么PRD，研发就做什么功能。
2015年前后：设计型产品经理。 移动互联网爆发，交互设计成为核心竞争力。这个阶段的产品经理要会画原型、写PRD、做竞品分析，核心竞争力是"把功能设计好"。
2019年前后：数据型产品经理。 增长黑客概念兴起，产品经理必须懂数据。A/B测试、漏斗分析、留存模型成为基本技能。
2023年前后：AI型产品经理。 大模型爆发后，产品经理需要理解AI的能力边界，设计AI驱动的产品体验。提示词工程、RAG、Agent成为新的核心技能。
产品经理的角色定位，本质上是一个"翻译器"：
- 把用户需求翻译成产品方案
- 把商业目标翻译成功能设计
- 把技术约束翻译成体验取舍
- 把数据洞察翻译成迭代方向
产品经理不是决策者，而是"最佳方案的发现者和推动者"。你的权力不是来自职位，而是来自判断力。
1.2.2 产品经理的核心职责边界
产品经理到底负责什么？这个问题看似简单，实际上很多人搞不清楚。
我把产品经理的职责分为三个层次：
第一层：必须做（核心职责）
| 职责 | 说明 | 产出物 |
|---|---|---|
| 需求分析 | 理解用户真正要什么 | 需求文档/用户故事 |
| 产品设计 | 把需求变成可落地方案 | 原型/PRD/架构图 |
| 项目推进 | 确保方案按时按质落地 | 排期/进度跟踪/风险应对 |
| 数据驱动 | 用数据验证假设、指导迭代 | 数据分析报告/A/B实验 |
| 竞品分析 | 理解市场格局和竞争态势 | 竞品分析报告 |
第二层：应该做（扩展职责）
| 职责 | 说明 |
|---|---|
| 用户调研 | 深入一线，获取一手用户反馈 |
| 商业分析 | 理解商业模式，参与收入规划 |
| 技术评估 | 理解技术方案，参与技术选型 |
| 团队建设 | 培养新人，建设产品文化 |
第三层：可以不做（边界外）
| 职责 | 说明 |
|---|---|
| 项目管理 | 有专业项目经理时，不必兼任 |
| UI设计 | 有设计师时，只提供设计方向 |
| 代码开发 | 理解但不亲自写 |
| 运营推广 | 提供策略但不执行 |
关键原则：产品经理对结果负责，但不负责所有过程。 你的核心价值是"做正确的决定"，而不是"做所有的事情"。
职责边界不是用岗位说明书划定的，而是用你的判断力划定的。该你做的你推不掉，不该你做的你抢不来。
1.2.3 产品经理与上下游角色的协作关系
产品经理不是一个人在战斗。理解上下游角色的诉求，是高效协作的前提。
产品经理 vs 研发
这是最常见的协作关系，也是最容易出现摩擦的。
研发的视角：产品经理的需求总是变来变去，写的PRD有逻辑漏洞，还总想加需求。
产品经理的视角：研发总说"做不了"，技术方案不够灵活，排期总是拖。
怎么办？三个原则：
- 需求评审前先技术预沟通。别在评审会上被技术一问三不知，提前和技术负责人对齐方案可行性。
- 写清楚"为什么做"，不只是"做什么"。研发理解了背景，才能给出更好的技术方案。
- 尊重技术评估，但不盲从。有时候"做不了"是真的做不了，有时候是"不想做"。区分这两者需要你有一定的技术理解力。
产品经理 vs 设计
设计的视角：产品经理给的空间太小，交互逻辑不清晰，总是改来改去。
产品经理的视角：设计太追求好看，忽略了效率和可用性。
协作要点：
- 先对齐交互逻辑，再开始视觉设计。避免设计稿出来后发现流程不对。
- 给设计目标，不给设计方案。"提升转化率"比"把按钮放大"更好。
- 评审时关注用户体验，不关注审美偏好。你可以说"这个操作路径太长"，但别说"这个颜色不好看"。
产品经理 vs 运营
运营的视角：产品功能不够灵活，运营工具不好用，数据不支持精细化运营。
产品经理的视角：运营的需求太碎片化，没有优先级，总想加功能。
协作要点：
- 定期对齐运营目标和产品节奏。运营追求短期效果，产品追求长期价值，需要找到平衡。
- 建设运营工具体系。好的运营工具可以减少80%的定制化需求。
- 数据共享。让运营看到产品数据，让产品看到运营数据，信息对称才能决策同步。
产品经理 vs 老板
老板的视角：我要这个功能，竞品有了我们也要有，这个月必须上线。
产品经理的视角：老板不懂产品，需求没逻辑，排期不合理。
协作要点：
- 向上管理是产品经理的必修课。不是所有老板的需求都要照做，但也不能硬顶。
- 用数据说话。"老板，上个月我们做了类似的功能，数据表明效果不好"比"我觉得不行"有说服力一百倍。
- 给出替代方案。拒绝的时候一定附带更好的方案，否则你只是个抱怨者。
| 协作对象 | 核心矛盾 | 解决原则 |
|---|---|---|
| 研发 | 需求变更vs技术实现 | 提前沟通、写清背景、尊重评估 |
| 设计 | 美观vs可用 | 目标驱动、先交互后视觉 |
| 运营 | 短期效果vs长期价值 | 对齐目标、工具赋能、数据共享 |
| 老板 | 拍脑袋vs数据驱动 | 数据说话、替代方案、向上管理 |
产品经理的核心能力不是"说服所有人"，而是"让所有人朝着同一个方向走"。方向对了，速度才有意义。
1.3 产品经理如何工作
1.3.1 产品从0到1的全流程概览
一个产品从想法到上线，经历哪些阶段？我用一个完整的流程图来说明：
第一阶段：发现（Discovery）
- 市场调研：行业规模、竞争格局、用户痛点
- 用户调研：访谈、问卷、数据观察
- 需求定义：核心用户是谁、核心问题是什么、核心场景在哪里
这个阶段的产出：产品定位文档。
第二阶段：定义（Definition）
- 产品规划：Roadmap、版本规划、优先级
- 产品设计：信息架构、功能架构、交互原型
- 需求文档：PRD、技术方案、设计规范
这个阶段的产出：完整的产品方案。
第三阶段：开发（Development）
- 需求评审：和研发、设计、测试对齐方案
- 开发跟进：解决开发中的疑问、调整方案
- 测试验收：确保实现符合设计
这个阶段的产出：可上线的代码。
第四阶段：发布（Launch）
- 发布计划：灰度策略、监控指标、回滚方案
- 上线执行：按计划发布、监控数据
- 紧急响应：处理上线后的紧急问题
这个阶段的产出：线上产品。
第五阶段：迭代（Iteration）
- 数据分析：核心指标、用户反馈、功能使用率
- 问题诊断：哪些功能好用、哪些不好用、为什么
- 下一版规划：新需求、优化点、技术债务
这个阶段的产出：下一版本的需求池。
产品不是"做完"的，是"迭代"出来的。从0到1只是起点，从1到N才是真正的考验。
产品从0到1全流程速查表
| 阶段 | 核心任务 | 关键产出 | 参与角色 |
|---|---|---|---|
| 发现 | 市场调研、用户调研 | 产品定位 | PM、用研 |
| 定义 | 产品规划、设计、PRD | 产品方案 | PM、设计 |
| 开发 | 需求评审、开发跟进、测试 | 可上线代码 | PM、研发、测试 |
| 发布 | 发布计划、上线、监控 | 线上产品 | PM、研发、运营 |
| 迭代 | 数据分析、问题诊断、规划 | 需求池 | PM、数据、运营 |
1.3.2 产品经理日常工作节奏与节奏感
产品经理的一天是什么样的？我用一个典型的工作日来说明：
上午（9:00-12:00）：思考与输出
- 9:00-9:30 邮件和消息处理，快速扫一眼昨晚的数据
- 9:30-10:30 专注时间：写PRD、画原型、做分析
- 10:30-11:00 站会：同步项目进度，暴露风险
- 11:00-12:00 需求评审或方案讨论
下午（13:00-18:00）：沟通与推进
- 13:00-14:00 午饭后和同事聊聊天（很多好想法来自非正式沟通）
- 14:00-15:30 设计评审或技术方案讨论
- 15:30-16:30 用户反馈整理、数据分析
- 16:30-17:30 跨部门对齐会
- 17:30-18:00 整理今天的工作成果，更新项目文档
晚上（可选）：深度思考
- 20:00-21:00 看行业动态、竞品更新
- 21:00-22:00 写周报、整理需求池、规划下周
这只是"典型"的一天。实际上产品经理的工作节奏有很大的波动性：
- 项目启动期：大量会议、频繁沟通
- 开发期：相对安静，偶尔处理疑问
- 上线期：高度紧张，随时待命
- 迭代期：数据分析为主，节奏较缓
产品经理的时间管理不是"把日程排满"，而是"把重要的事排对"。忙不等于有产出，想清楚比做出来更重要。
产品经理时间分配建议
| 活动 | 建议占比 | 说明 |
|---|---|---|
| 深度思考与输出 | 30% | 写PRD、画原型、做分析 |
| 沟通与协作 | 30% | 会议、评审、对齐 |
| 数据与调研 | 20% | 数据分析、用户反馈、竞品 |
| 学习与成长 | 10% | 行业动态、技术趋势 |
| 行政与事务 | 10% | 邮件、文档、流程 |
1.3.3 典型案例：产品经理的工作思考方式
讲了这么多理论，我用一个真实的场景来展示产品经理是如何思考的。
场景：老板说"我们也做个社区功能吧"
普通产品经理的反应：好，我马上去看竞品怎么做，然后画原型写PRD。
优秀产品经理的反应：先问三个问题——
问题一：为什么要做？
- 老板的判断依据是什么？是看到了竞品在做？是用户在提需求？还是数据表明社区能提升留存？
- 不同原因，社区的产品定位完全不同。竞品驱动意味着"防御性功能"，用户驱动意味着"核心功能"，数据驱动意味着"增长手段"。
问题二：为谁做？
- 我们的核心用户是谁？他们有社交需求吗？
- 如果核心用户没有社交需求，社区就是一个"伪需求"。工具型产品的社区和内容型产品的社区设计思路完全不同。
问题三：做成什么样？
- 不是先画原型，而是先定义成功指标。社区的北极星指标是什么？是日活跃用户数？是内容生产量？是互动率？
- 指标不同，功能设计的优先级就不同。追求内容生产要激励创作者，追求互动要设计推荐机制，追求活跃要营造社区氛围。
假设经过分析，确定了社区的目标是"提升用户留存"。接下来怎么设计？
第一步：定义MVP
社区的最小可用产品是什么？不是功能最全的版本，而是能验证"社区能否提升留存"的最小方案。
可能的MVP：一个简单的动态流，用户可以发布文字+图片，其他用户可以点赞和评论。仅对部分用户开放。
第二步：设计核心指标
| 指标类型 | 指标 | 目标 |
|---|---|---|
| 北极星 | 社区日活用户 | 占整体DAU的20% |
| 过程指标 | 发帖率 | 日活用户中5%发帖 |
| 过程指标 | 互动率 | 帖子平均互动数>3 |
| 留存指标 | 次日留存 | 社区用户比非社区用户高5% |
第三步：定义迭代路径
- V1：基础发帖+评论，验证核心假设
- V2：话题/标签体系，提升内容发现效率
- V3：推荐算法，提升内容匹配效率
- V4：创作者激励，提升内容供给
产品经理的思考方式不是"怎么做"，而是"为什么要做、为谁做、做到什么程度"。想清楚这三个问题，方案自然浮现。
产品经理思考框架3步法
| 步骤 | 核心问题 | 产出 |
|---|---|---|
| 为什么做 | 背景和目标是什么 | 需求定义 |
| 为谁做 | 目标用户和场景 | 用户画像 |
| 做成什么样 | 成功标准和迭代路径 | 产品方案 |
本章小结：产品经理不是画原型的，不是写文档的，不是开会的。产品经理是"问题的发现者、方案的发现者、结果的推动者"。理解互联网行业、理解产品类型、理解职责边界、理解协作关系，这些是基本功中的基本功。
| 本章核心知识点 | 一句话总结 |
|---|---|
| 互联网发展阶段 | 信息互联网→消费互联网→产业互联网 |
| 互联网产品定义 | 用技术为特定用户解决特定问题并创造价值 |
| 产品经理角色 | 翻译器：需求↔方案↔结果 |
| 职责三层模型 | 必须做/应该做/可以不做 |
| 协作核心原则 | 让所有人朝同一方向走 |
| 工作全流程 | 发现→定义→开发→发布→迭代 |
| 思考框架 | 为什么做→为谁做→做成什么样 |
觉得有用？收藏起来，下次直接照抄。
你刚入行产品经理时踩过什么坑？评论区说说，怕浪猫帮你复盘。
关注怕浪猫，下期我们讲"四大核心思维"——用户思维、逻辑思维、管理思维、商业思维，这四个能力决定了你能不能在产品这条路上走远。
系列进度 1/16
下章预告： 第2章，怕浪猫会带你拆解产品经理的四大核心思维。很多人做了三年产品，还在凭直觉做决策，为什么？因为缺的不是经验，是思维框架。下一章，我把这四个框架一次性讲透，让你从"凭感觉做产品"进化到"用思维做产品"。