对产品经理的认识

先前找工作时给自己定的目标是产品岗，为此看了一些书籍，看归看了，大脑依旧有些混乱。

这周看完了Marty Cagan的《启示录》，趁着新鲜，用自己的语言整理一下对产品部门的认识，顺带分享一些觉得有价值的观点，不当之处，还望斧正。

01 对「产品」的认识

很多公司都招聘产品岗，但实际交谈时又会发现他们对这个岗位工作内容的描述相距甚远，依我之见，其原因在于产品部门位于领导层、开发团队、用户与市场之间，所以职责复杂多样。

按书中的理想状态讲：

1. 首先，产品部门从用户和领导处获取产品需求，听他们说「我需要一个产品来解决我xxx的需求」，分析市场情况，如市场上是否有解决这些需求的产品，他们有什么不足，做一份报告找领导要资源。

2. 接着，产品部门综合各方的声音和数据，给产品做个定义，比如「我们应该做一个射击游戏、应该添加“已读”功能……」，着手撰写说明文档，设计最简化产品模型。

3. 有了最简化模型，就可以去邀请用户做测试，不断完善产品；请开发人员过来，研究这个产品能不能开发出来，困难有多大……做完这些事情，高保真模型也差不多出来了。

4. 拿着高保真模型，产品部门就跑过去对开发团队说，你们照着这个模型做，实现功能A、B、C……

5. 产品上市后，可能还需要跟进营销，产品生命周期管理之类的

我看书的时候就觉得，产品好像真的啥都干，要和几乎所有部门协作，但主要面对的还是领导、开发团队、用户/市场三个方向，如我下面画的气泡关系图。

偏向用户和市场——需求挖掘、数据分析、用户体验

偏向开发团队——与开发协调、任务管理

偏向领导——产品策划和立项

偏向产品自身——产品设计，画Axure，扣细节

……

不同公司的产品部门偏向不同，都叫产品经理，招的岗位也不尽相同，我只能根据自己的了解做这么个简单的框架。

02 有趣的观点

会前沟通：

确保会议召开前你们已经达成一致意见，正式会议的作用只是让与会人员认识到大家取得了一致意见。

在会议前和重要的与会人员先私下交流，达成一致意见，而不是试图通过开会告诉来达成一致。

这个观点解决了我多年的困扰。以前无论是当班长、会长还是组长，我都喜欢搞民主那套，但经常是开起会来一片沉默，或者七嘴八舌，大方向还没确定就开始扣各种细节，不得不花很大的功夫去掌控会议。

先在会前沟通，交换想法，达成一致，再在会上补充观点，营造一种目标一致的氛围，这或许是个好方法吧。

永远不要告诉别人怎么做。告诉他们做什么，他们自然会发挥天赋，给你惊喜。

我特别讨厌我们大学教仿真软件的老师，她的教学方法是：我点一下鼠标，你们跟着我点，而不解释其原因。

有一段时间我特别困扰，我不知道点这个按钮是为了做什么，想做优化应该去研究哪个步骤。

我觉得如果只告诉别人怎么做，而不告诉他做什么，那只能培养出一个鼠标精灵，而不是工程师。

如果能告诉他为什么，那就更好了，因为可能他会有比你更棒的解决方法。

高保真模型是最好的产品文档

当你想向别人解释什么东西，高保真模型显然比文字有力得多……

©许安平SpermWhale 2021/03/22