书名：《人人都是产品经理》
作者： 苏杰

前言

最近开始系统地看一些产品经理相关的书。

其中也看了比较经典的《启示录》。

不过说实话，《启示录》并没有给我带来特别强烈的感觉。

里面很多观点是有道理的，比如用户价值、产品团队、产品发现等，但对于一个长期做研发、刚开始系统学习产品的人来说，我感觉它更多是在讲：

一个优秀的产品团队应该是什么样子。

而我现在更想知道的是：

产品经理到底每天在干什么？一个需求到底是怎么从想法变成产品的？

反而是苏杰的《人人都是产品经理》，让我第一次比较完整地理解了产品经理这个岗位。

它没有让我突然学会“怎么做出一个伟大的产品”。

但是它让我开始理解：

原来产品经理是这样工作的。

一、以前开发眼中的产品经理

做研发的时候，其实每天都会和产品经理打交道。

所以以前我一直觉得自己对产品经理这个岗位挺熟悉。

大概就是：

业务 / 老板
     ↓
   产品经理
     ↓
   需求文档
     ↓
   原型图
     ↓
   需求评审
     ↓
     开发

开发最关心的通常是：

• 需求有没有写清楚？
• 原型有没有画完整？
• 异常情况有没有考虑？
• 数据从哪里来？
• 接口怎么定义？
• 这个需求到底什么时候要？

所以站在研发的角度，很容易把产品经理理解成：

负责把需求整理清楚，然后交给研发的人。

但是看完《人人都是产品经理》以后，我发现自己以前看到的其实只是产品工作的一部分。

二、产品经理最重要的不是画原型

以前提到产品经理，我脑子里最容易出现的工具就是：

Axure。

甚至很容易形成一种印象：

会 Axure
   +
会写 PRD
   +
会画流程图
   =
产品经理

但真正开始学习以后，会发现这个逻辑其实反了。

Axure 只是表达解决方案的工具。

真正重要的是：

发现问题
   ↓
分析需求
   ↓
判断优先级
   ↓
设计解决方案
   ↓
原型表达
   ↓
推动研发
   ↓
上线
   ↓
持续优化

如果前面的判断是错的，那么后面的原型画得再漂亮也没有意义。

这对我来说是一个比较明显的思维变化。

因为作为开发，我们拿到的通常已经是一个相对确定的需求。

而产品经理面对的往往是：

一个非常模糊的问题。

三、用户说的“需求”，不一定是真正的需求

这是我比较喜欢这本书的一个地方。

它没有把需求分析讲得特别玄学。

很多时候用户会直接告诉产品经理：

我需要一个 XXX 功能。

以前作为开发，我听到这种话，第一反应通常就是：

那这个功能怎么实现？

但是站在产品角度，需要继续往下问：

他为什么需要这个功能？

举个交易产品里的例子。

假设用户提出：

我希望增加一个“一键全撤”的按钮。

表面需求是：

增加一键全撤

但真正的问题可能是：

行情快速波动
      ↓
用户存在大量挂单
      ↓
逐个撤单速度太慢
      ↓
无法及时控制交易风险

那么真正需要解决的问题其实是：

如何让用户快速处理大量未成交订单？

这样一来，解决方案就不一定只有一个。

可能包括：

• 一键全撤
• 按交易对批量撤单
• 按买卖方向撤单
• 批量选择订单
• 自动撤单策略

这让我开始意识到：

用户提出的是解决方案，不一定是需求本身。

产品经理需要继续找到解决方案背后的问题。

四、需求是有优先级的

开发过程中经常遇到一个很现实的问题：

所有需求都很急。

业务说：

这个必须这周上线。

运营说：

活动马上开始。

老板说：

这个优先级最高。

产品说：

这个也不能延期。

最后研发看到的是：

P0
P0
P0
P0
P0

如果所有需求都是最高优先级，那么实际上就不存在优先级。

产品经理一个非常重要的能力，就是做取舍。

可以从几个角度考虑：

             用户价值
                │
                │
开发成本 ──── 需求 ──── 商业价值
                │
                │
              风险

不能仅仅因为：

“有人提了这个需求。”

就认为一定要做。

而应该考虑：

解决多少用户的问题？

问题发生频率有多高？

不解决会造成什么影响？

对业务有什么价值？

需要投入多少研发资源？

这些因素综合以后，才能真正决定优先级。

五、产品经理其实一直在做“取舍”

这是我开始学习产品以后越来越明显的一个感受。

开发很多时候追求的是：

正确。

代码要正确。

数据要正确。

资金不能错。

系统不能出现并发问题。

但产品很多问题其实没有绝对正确答案。

比如一个交易页面：

功能更多
    ↓
专业用户更方便

但是：

功能更多
    ↓
页面更复杂
    ↓
新用户学习成本更高

那么到底应该：

增加功能？

还是：

保持简单？

这并不是技术问题。

产品经理需要根据：

目标用户
+
使用场景
+
业务目标
+
用户价值
+
数据
+
成本

做出判断。

所以我现在觉得：

产品设计很多时候并不是寻找完美答案，而是在各种限制条件下寻找当前最合适的答案。

六、为什么我觉得《人人都是产品经理》更适合入门

在看产品相关书籍的时候，我也看了《启示录》。

两本书给我的感觉差别挺大。

《启示录》更多让我思考：

优秀的产品团队应该怎么做产品。

而《人人都是产品经理》让我理解：

产品经理具体在做什么。

对于已经做产品几年的人来说，可能《启示录》会带来更多关于组织、团队和产品方法的思考。

但是对于我这种长期从事研发、刚开始往产品方向学习的人，我反而更喜欢《人人都是产品经理》。

因为它离实际工作更近。

从：

用户
 ↓
需求
 ↓
产品
 ↓
项目
 ↓
团队

把产品经理日常工作中的很多事情串了起来。

很多内容我甚至可以直接和过去研发工作中遇到的事情对应起来。

这也是为什么读起来会更有感觉。

七、技术转产品，我认为最大的难点不是工具

刚开始研究产品的时候，我其实也关注过：

• Axure
• 原型图
• PRD
• 流程图
• 思维导图

这些当然需要学。

但是现在我越来越觉得，这些东西并不是最难的。

对于开发来说，学习一个工具反而是比较简单的。

真正困难的是改变思考顺序。

以前是：

需求来了
   ↓
怎么实现？

现在需要尝试变成：

为什么会有这个需求？
        ↓
谁遇到了这个问题？
        ↓
问题发生在什么场景？
        ↓
现在怎么解决？
        ↓
为什么现有方案不够好？
        ↓
值不值得解决？
        ↓
有哪些解决方案？
        ↓
最后才是怎么实现

也就是从：

“How”

开始往前走到：

“Why → What → How”

我觉得这可能才是从研发转产品真正需要改变的东西。

八、技术背景可能也是一种优势

当然，我并不觉得转产品意味着过去的技术经验没有用了。

恰恰相反。

尤其是在交易、金融这种业务里面，产品和技术很多时候分不开。

比如一个合约产品需求背后可能涉及：

用户下单
   ↓
订单系统
   ↓
撮合
   ↓
成交
   ↓
持仓
   ↓
保证金
   ↓
风险率
   ↓
强平
   ↓
清算

如果只看到页面上的：

“开多 / 开空”

而不了解后面的业务逻辑，其实很难真正把产品设计好。

所以我现在比较希望形成的是：

        产品能力
       /       \
      /         \
用户需求         业务理解
      \         /
       \       /
        技术能力

不是完全从技术转到另外一个陌生领域。

而是在已有技术和业务经验上，再增加一层产品视角。

九、读完这本书，我最大的变化

如果一定要总结一个最大的变化，我觉得不是：

我学会了怎么当产品经理。

一本书显然做不到。

真正的变化是：

开始有意识地从需求的上游思考问题。

以前拿到需求：

“增加一个功能。”

首先考虑：

怎么做？

现在希望自己能够多问几个问题：

为什么做？
   ↓
给谁做？
   ↓
解决什么问题？
   ↓
为什么现在做？
   ↓
有没有更简单的方法？
   ↓
做完怎么判断有没有效果？

然后再进入：

怎么做。

写在最后

《人人都是产品经理》并不是一本读完以后就能让人变成产品经理的书。

但对于我来说，它确实起到了一个很重要的作用：

让我第一次站在产品经理的角度，重新看了一遍过去非常熟悉的软件研发流程。

过去这些年，我更多关注的是：

如何把一个需求实现好。

现在我开始对另外一个问题产生兴趣：

一个需求为什么会出现，以及它到底值不值得做。

接下来我准备继续学习需求分析、用户研究、竞品分析、原型设计和产品规划。

同时也想尝试把过去比较熟悉的交易所业务重新拿出来。

不再只从：

系统架构、撮合、清算、资产、性能

这些技术角度去分析。

而是尝试从：

用户、场景、需求、体验、商业价值

重新分析一次。

对我来说，这应该算是从研发思维走向产品思维的第一步。