最近读到一本很不错的书: <产品的视角: 从热闹到门道>

产品的视角: 从热闹到门道

这是一本有关产品经理养成的书, 开头举了一个职业规划的例子也很有意思:

• 首先选择一个行业. 行业决定了发展空间. 一定要选择一个有发展的朝阳行业.
• 其次选择一个职业. 职业决定了资源. 同样是出海, 做水手干烧锅炉还是当厨子, 都是职业

• 最后选择一家公司. 公司决定了平台. 何时加入大公司见世面涨资历, 何时加入创业公司, 想清楚.
  作为程序员的我, 职业肯定不会变了, 如果要选择, 就是看行业找风口, 然后圈定公司找头猪骑上去等着飞? 哈哈

  
  职业规划思路

好吧, 读这本书不是为了职业规划, 跑题了.

---

读这本书的目的

作为程序员, 时不时会跟产品经理打交道. 突然想: 如何评价一个产品经理是否靠谱? 作为产品经理的下游, 如果不能评价上游产品经理是否靠谱, 如何避免在'不靠谱'的产品经理身上浪费时间? 毕竟那是随便动动嘴皮就能让程序员累死累活的上游.
本书给出了一个产品经理的能力框架:

• 用户体验
• 技术能力
• 商业思维

用户体验

如何培养: 三个维度: 场景, 需求, 动机.

技术能力

包含产品技能和懂技术.

为何产品经理要懂技术? 因为: 懂技术 = 沟通能力.

这个总结太到位, 程序员实在懒得跟狗屁不懂的产品经理费口舌. 懂技术不是让你们做, 是让你们听懂技术人员的话, 这里着重推荐一个公众号: 给产品经理讲技术

给产品经理讲技术

而针对产品经理的必备技能, 包含:

• 用户调研和需求分析
• PRD/MRD 撰写
• 原型绘制
• 流程图绘制和数据逻辑处理能力

说到 PRD 撰写, 后文中又定义了几个 PRD 的基本准则:

1. 动态数据的来源和去向交代清楚
   不懂技术的看你怎么写
2. 交互元素要定义.
   交互中涉及的元素要写清楚. 别等做出来你丫大喊'这不是我要的'.
3. 交互逻辑和上下文要交代清楚
   逻辑不严谨的, 基本上可以在这个环节吊打. 开发要天天追着产品经理后面问这个怎么办那个怎么办. SB 产品经理每天觉得自己很忙的样子. 不忍直视.
4. 静态文案的约束

本书将产品经理分成三个年级:

• 一年级产品经理: 执行力驱动, 产品感培养
• 二年级产品经理: 用户价值驱动, 沟通能力培养
• 三年级产品经理: 运营与规划

---

一年级产品经理: 执行力驱动, 产品感培养

把复杂问题简单化, 小步快跑地去做事, 也是一种执行力

想起了之前的读书笔记: 笔记: 从技术细节看美团的架构

方法论

一个需求点, 对应3个功能点, 对应至少9个开发点, 如果系统耦合度高, 这个比例还会放大.

因此你说加个需求'不加价'(不延长开发周期), 你是耍流氓

关于项目管理方面的知识, 我想本书中的三句话:

1. 版本要封闭
   不封闭的版本最后变成永远做不完
2. 版本 < 需求
   版本是需求的子集, 不是需求垃圾桶, 什么需求都可以往里面扔
3. 需求像流水, 版本是水闸
   需求永远做不完, 版本就是水闸, 控制一次放多少

---

总结

感觉是个写不完的话题, 恨不得把目录都作为读书笔记结构展开.

希望等过段时间, 我去评价一个产品经理时, 不需要凭感觉说这人'靠谱'/'不靠谱', 而是有客观的知识框架, 甚至可以出一套初级产品经理笔试题

-- EOF --