作者 | 刘燕

杏仁产品汪、吃货，专业蹭吃蹭喝，羽生结弦是我的新晋男神；

欢迎小哥哥小姐姐们探讨产品、美食

在做产品经理之前，我是传说中第三种人类：程序媛。曾经，被产品经理虐过，吐槽过产品经理；现在，也虐过研发同学，也被研发同学吐槽过。因为做过研发也做过产品，可谓知己知彼，深刻的体会到双方沟通中的痛点，希望本文能够帮助研发同学更好的和产品经理沟（si）通（bi）。

什么是产品？

产品是指能够供给市场，被人们使用和消费，并能满足人们某种需求的任何东西，包括有形的物品、无形的服务、组织、观念或它们的组合。

比如，手机满足人们通讯需求，是有形的硬件产品；微信满足人们社交需求，是无形的软件产品；家政服务满足人们清洁需求，是无形的服务产品……

其实，简单来说，产品就是能满足人们某种需求的东西。

什么是好产品？

从以下三组图片中，选择你认为好的产品。

第一组，相信大家都会选择小米遥控器。因为相比传统的遥控器，小米遥控器设计简洁，按键功能一目了然，不用看说明书就知道如何使用。

第二组，每个人的选择都不一样。对于普通用户来说，美图秀秀是个好产品，好用、容易上手，而 PS 完全不知道从何下手。但对于专业设计师来说，美图秀秀就是个渣渣，根本满足不了工作需求。

第三组，大家可能没怎么接触过，通过这两款产品可以实时查询公交的位置，还有几分钟到达相应的站点。仅凭一个界面，有些人会觉得车来了是好产品，因为界面干净、整洁、交互也特别好，而上海公交查询体验特别差。但事实上，我把车来了这个 App 卸载了，却一直在使用上海公交查询，因为它提供的数据非常准确。对我来说，这两个产品都算不上是好产品。

所以，好的产品必须同时具有以下三点：

• 有用

• 能用

• 好用

人人都是产品经理？伪命题！

每次看到这句话我就特别想翻白眼，甚至想学罗胖来一句，我呸！

这是大家眼中的产品经理：

你是想卖一辈子糖水，还是跟着我们改变世界

在每个产品经理内心深处都有一个改变世界的梦想。

在父母眼中，产品经理就是公司的核心，不可或缺。

在研发眼中，产品经理就是一个打杂小妹，随叫随到。

在设计眼中，产品经理就是山顶洞人，完全没有审美眼光。

逻辑不如研发，文案不如运营，审美不如设计，视野不如老板。

为什么需要产品经理？

存在即是合理。

老板表示需要一个背锅的：遇到不好用的 App，大家第一反应都是什么 SB 功能，SB 产品经理，但是从来没有人骂 SB 老板；用户吐槽产品很难用，设计可以说这锅我不背，产品经理设计的流程就是这样的；项目进度延迟，研发可以说这锅我不背，产品经理需求变更频繁……

任何人都可以甩锅，唯独产品经理不可以，任何与产品相关的锅产品经理都要背，这些都是产品经理的责任，不可推卸。

研发、设计表示需要一个打杂的：缺文案，产品经理帮你写；缺数据，产品经理帮你整理；需求开发好了，产品经理还要帮忙验收测试……

市场、用户表示需要一个翻译：例如，如何向用户解释什么是 2G、3G、4G 网络。如果直接告诉用户 2G 是数字网络、3G 是高速 IP 数据网络、4G 是全 IP 数据网络，用户肯定一脸懵逼：什么鬼？但如果告诉用户 2G 可以看文字、3G 可以看图片、4G 可以看小电影，用户立马就明白了。

怎样才能成为产品经理？

在大部分人眼里，只要会吐槽就可以做产品经理。

吐槽吐的专业，可以成为评论家；吐槽吐的幽默，可以成为段子手；吐槽吐的群情激奋，可以成为意见领袖；但发现问题仅仅只是产品经理工作中的一小部分。一个优秀的产品经理，必须会分析并解决问题。

我们来看一下产品经理的关键词：

是不是有种产品经理从入门到放弃的感觉？其实，将这些关键词整理一下，可以分成以下几个维度：

1.人

实现一个产品功能，产品经理需要全程跟进，在这个过程中，就免不了在多个部门之间沟通协调。

例如，老板想要增加某个功能，那么产品经理首先需要和老板沟通，了解增加该功能的原因，然后简单评估一下需求的优先级，并给出一个合理的解决方案。找设计沟通UI设计及交互逻辑；拿着做好的设计稿找到研发，确定开发计划及上线时间；功能上线后，向市场、客服部门的同事做培训，推广产品功能；产品功能推向市场后，收集用户反馈，处理用户遇到的问题；功能稳定后，采集数据，分析数据，持续运营产品；最后，还需要向老板及相关部门汇报产品数据，复盘总结。

2.能力

在图中列出的产品经理相关能力中，最核心的能力是学习能力、独立思考、沟通协调能力。这里的沟通能力，并不是指性格开朗、热情大方、幽默风趣这些一般人理解的沟通能力，而是把细节说清楚，专业。把细节描述清楚，没有歧义，双方能达成共识；工作态度专业认真，不过于情绪化。而协调指的是协调所有可用资源，让事情朝着你想要的方向前进。

3.工具&方法&输出

工具、方法、输出都是手段，不是目的。学以致用才是学习的目的，学了不会用等于白学。

而在实际工作中，光会这些还不够，必须把所有这些都揉碎、重组、融入到工作的每个细节中。

左边是大家看到的路径，右边是产品经理考虑的路径。

左边是大家看到的需求，右边是产品经理面对的需求。

左边是大家的工作流程，右边是产品经理的工作流程。

以杏仁医生App药品登记需求为例，下图是用户和研发看到的。

而实际上，下图是我考虑的内容。

看到这里，你还认为产品经理门槛很低吗？人人都是产品经理吗？

产品经理不生产需求，只是需求的搬运工

介绍完产品经理，我们要介绍产品的另一个关键词：需求。产品经理不生产需求，只是需求的搬运工。有人可能要说反对意见，乔布斯不就生产了需求吗？其实乔布斯也没有生产需求。

需求就像煤矿一样，有的随意散落在地表，大家都能看见；可绝大部分有价值的需求就像埋在地底下的煤矿一样，需要专业的人员去挖掘，去采集，去清洗。而产品经理就是这个挖煤的矿工，优秀的产品经理能挖掘到人性最深层的需求。

按照马斯洛需求层次理论，饿了么满足了用户的生理需求，在家也能吃上全国各地的饭菜；支付宝满足了用户的安全需求，给用户提供了资金安全保障；微信满足了用户的社交需求，让用户低成本的与朋友、亲人、同事交流；知乎满足了用户的尊重需求，让用户展示自己出众的知识技能，得到大家的赞赏；得到满足了用户自我实现需求，营造一种充实感，让用户感觉自己每天都在进步……

需求需要符合这四个条件：

• 特定的人

• 特定的情况下

• 特定的问题

• 可以被解决

概括下来就两个字：场景

之前有同事提出，杏仁医生 App 中的药品登记模块需要增加一个批量登记的功能。咋一看是不是很合理？但仔细一想，什么场景下医生会需要批量登记呢？

事实上，并没有这样的场景。医生开药的场景大部分都是先搜索药品，如果没有搜索到合适的药品，就顺手登记一下。医生并不会用小本本记下缺哪些药品，然后批量登记。因此，批量登记功能是一个伪需求。

把问题放到一个具体的场景中可以过滤掉非常多的伪需求、不合理的需求。

需求从哪里来？

1.公司外部

公司外部的需求主要来自用户、合作伙伴、竞争对手。用户经常抱怨某个功能不好用，用户反馈其实就是需求；合作伙伴在和我们合作的过程中，肯定会产生一些新的想法，这些也是需求；竞争对手推出了一些好用的功能抢走了很多用户，为了抢夺市场，也会产生需求。

2.公司内部

公司内部的需求主要来自公司战略、产品规划、内部人员。每年公司都会制定公司一整年的战略计划，产品总监会根据这些战略制定每个季度的产品规划，产品经理再将这些产品规划分解成多个产品功能。在产品迭代的过程中，老板、市场、运营会提各种各样的需求，研发、产品经理也会从技术、产品层面提出需求。

怎么定优先级？

1.刚性

指这个需求是否迫切，实现了这个需求，是不是能立马解决困扰用户很久的问题。

2.广度&频率

广度指这个需求会影响多少用户，多少核心用户。频率指用户使用这个功能的频率。

3.替代方案

指解决这个需求，是否有替代方案。

按照以上原则，规划电商模块功能。第一个版本必须要实现商品展示、商品详情、购物车、下单结算、支付功能，因为这是用户购买过程中最核心的功能。而售后退款相关流程可以放到后续版本，因为在初期售后退款功能并不是很迫切，只影响部分用户，且存在替代方案——人工处理的方式。当用户规模达到一定程度后，再做相关功能的开发。

满足需求的方法？

相信大家都去海底捞吃过火锅，每次去总是人满为患，假设你是海底捞的店长，你怎么解决海底捞排队的问题？满足用户快速吃饭的需求。

1.改变现状

我们能想到最直接的办法，就是扩大门店，增加更多的桌子和服务员。但性价比很低，一是扩张需要成本，需要额外负担装修成本、服务员工资；二是在非吃饭高峰期造成资源浪费，大面积的区域没有使用，部分服务员无事可做。

2.降低期望

在海底捞排队取号时，通常服务员都会告诉你前面还有多少桌，并告诉你大概的排队时间。但这个预估的排队时间通常都比实际等待时间要长一倍到两倍，虽然会吓跑一部分顾客，但留下来排队的顾客体验会好很多。本来以为要排 1 个小时，实际上只排了半个小时，内心会有小小的惊喜：海底捞效率还挺高的。

3.转移需求

现在海底捞的做法就是在排队区域准备一些小零食、水果和小游戏，让顾客一边吃东西玩游戏，一边排队。一方面通过零食和小游戏分散顾客的注意力，缓解顾客排队等候的暴躁情绪；另一方面通过零食和小游戏将大部分顾客牢牢的锁在海底捞，提高订单转化率。

研发与产品的爱恨情仇，本是同根生相煎何太急

经常会在网上看到程序员吐槽产品经理的各种段子、漫画和文章，平时工作中也遇到不少。分析下来，矛盾的根源在于：

• 频繁变更需求

• 低估研发成本

• 需求变更没有通知到位

产品经理防“群殴”指南

需求频繁变更，其实说明产品经理在分析需求时缺乏思考，没有多想几个为什么。

不要用战术上的勤奋掩饰战略上的懒惰。

经常有朋友问我：做产品经理和做研发有什么区别？

最大的区别在于研发 80% 的时间用于执行，而产品 80% 的时间用于思考和沟通。

1.考虑未来三个月内的扩展性

在做一些比较大的功能模块时，不能只考虑第一个版本的规划，还需要考虑未来两到三个版本的功能。可以将版本规划提前告知研发团队，让他们了解未来产品要做成什么样子，哪些功能必须要做，哪些功能可能要优化。这样研发同学就可以提前做相关技术调研，规划技术架构，提高代码的可扩展性。

2.考虑常见的特殊情况

最常见的情况，调后台接口，展示列表数据。此时就要考虑很多种特殊情况：

1. 没有网络

2. 网络条件不好

3. WiFi网络环境和非WiFi网络环境

4. 没有数据

5. 少量数据

6. 大量数据

再比如，电商业务中最常见的订单，需要梳理整个过程中的状态，并画出各个状态之间的转化示意图。只有把所有状态都列清楚，才能确认逻辑是否完善，让研发能更好的实现订单流程。

3.不要想满足所有人的需求

相信大家也知道夫妻骑驴的故事，在这个故事中，无论这对夫妻采用何种方案，总会有批评的声音。

做产品也是同样的道理。比如，针对患教资料是否显示原创医生的个人信息。部分医生认为应该显示，理由一：这是医生花费大量时间和精力编写的文章，要尊重医生的知识产权；理由二：通过分享患教资料扩大知名度，让更多的陌生患者添加自己；另一部分医生却强烈要求隐藏原创医生的个人信息，这部分医生认为自己分享了其他医生写的患教资料，相当于向自己的患者介绍其他医生，为其他医生做推广。

无论是否显示原创医生的个人信息，总会有部分医生不满。你不可能满足所有用户的需求，在这种情况，坚持做自己认为对的事情就好。

4.MVP（ Minimal Viable Product 最小可行性产品）

产品迭代路径应该按照 MVP 原则，先向用户提供能用的产品，再根据用户需求，逐步提供更好用的产品。而不是一上来，就规划一个非常完美的方案，然后花上好几个月甚至一两年来实现，说不定等你实现所谓“完美”的产品，用户需求早已发生翻天覆地的变化。

5.适当了解一些技术，适当看一些技术文档

在做患者端小程序前，先查看小程序接口文档，了解以下问题：

1. 小程序能实现是否支持语音、视频、扫一扫功能

2. 小程序和公众号如何相互跳转

3. 小程序通知下发机制

4. 如何配置 webview 业务域名

5. webview 组件如何实现微信支付

这样才能规划小程序做哪些功能；如何实现小程序和公众号之间相互引流；如何通知用户；遇到非业务域名如何处理；如何在 webview 中调用小程序微信支付。

之前听过一句玩笑话。

产品经理懂技术等于流氓会武功？

流氓会武功的话，对付一般的小警察还是很有优势的；但如果流氓因为自己会武功，而无法无天，自以为是；等遇到狙击手的时候，直接一枪就被放到了好吗。

同样的道理，产品经理不能仗着自己懂一点技术，就对研发同学指手画脚。懂技术是为了排除需求中的隐患，更好的和研发沟通，提升工作效率。了解一些基础技术架构即可，不要沉迷于技术实现，否则，就是本末倒置。

6.重视文档更新

这个不解释。

研发防“入坑”指南

每次版本总结，总是会有研发表示被产品经理“坑”惨了：需求变更太频繁，需求不靠谱，需求解读错误，需求不明确……除去市场、产品本身存在的问题，大部分问题其实是沟通问题。

1.正确看待需求变更

一提到需求变更，一些研发会皱着眉头改代码，心里 mmp ，怎么又 TM 改需求啊；一些研发会让产品经理签字画押，作为日后打脸的呈堂证供；还有一些研发会直接拒绝，要改你来改啊，老子就不改……但事实上，业务稍微复杂一点的产品都会有需求变更，要求产品没有需求变更，相当于要求研发写的代码没有 bug 。我相信没有一个研发敢摸着良心保证自己的代码没有一个 bug 。

从另一个角度思考，需求变更其实是一件好事。正因为有需求变更，才能体现研发的价值：如果没有需求变更，80% 的程序员都要失业了。正因为有需求变更，研发的工作更具有挑战：如何设计更合理的架构，覆盖更多的业务场景，支持更复杂的业务流程。

2.先考虑需求是不是合理，是不是有更好的解决方案

看到这里，有部分研发同学认为，我为什么要考虑这些，这是产品经理的工作，不是研发的工作。这的确不是研发的工作，但实现这些需求却是研发的工作。为了避免自己被“坑”，如果有更好的解决方案，完全可以提出来，和产品经理一起讨论。

也许你们会讨论出一套性价比更高的方案：一方面满足产品需求，一方面减少自身的开发工作量。也许你们讨论过程中发现遗漏了某个分支的处理流程：一方面发现了产品设计的漏洞，一方面减少了 bug 数量提高代码质量。

3.有疑问，有困难一定要尽早提出，不要自己一个人默默的解决

例如，某个功能实现起来有技术难度，此时，研发和产品经理可以沟通讨论出更好的方案；某个模块功能太多研发时间太长，此时，产品经理可以根据实际项目情况，砍掉部分优先级低的需求，或者申请适当延长研发周期。千万不要自己一个人死扛，默默的处理遇到的所有问题，最终产品验收时，发现偏离了产品需求，吃力不讨好。

在每个版本开发前，产品经理都会先和各组研发 leader 进行小范围的需求评审，之后和后台研发同事进行第二轮需求评审，最后和所有相关研发同事进行最终需求评审。在这个过程中，产品经理逐步完善产品设计。前期沟通的越清楚，后期沟通的成本就越小，产品需求变更的情况也越少。

4.产品经理做的不好的地方，可以当面指出

在产品研发的过程中，产品经理接触最多的就是研发，听到最多的就是研发同事对产品经理的吐槽与抱怨。吐槽需求不靠谱，吐槽产品原型有漏洞，吐槽产品经理低估研发成本……吐槽产品经理也成为研发日常工作的一部分，我也相信这些槽点三天三夜也吐不完。

面对这些吐槽与抱怨，任何一个有职业素养的产品经理都会认真的听取意见。毕竟产品经理的部分工作就是收集用户建议、跟踪用户反馈、持续提高用户体验，而研发其实是产品经理最重要的用户。

没有什么事情，是一顿火锅解决不了的。如果有，那就两顿！

相信大家都知道瞎子和跛子的故事：一个瞎子和一个跛子，被困在火场中，眼看着要被烧死了，瞎子背起跛子，跛子指路，终于从大火中死里逃生。

如果说创业就像在火场中逃生，九死一生。那么产品经理就是一个跛子，能看见前进的方向，但没有行动能力；研发是一个瞎子，有行动能力，但看不见前进的方向；如果研发和产品经理之间相互猜忌，埋怨，最终可能是死路一条。只有两者相互信任，才有可能活着走出火场。

最后，希望研发同学和产品经理能够相互信任、和谐沟通，一起愉快的玩耍。

全文完

---

以下文章您可能也会感兴趣：

• 四维阅读法 - 我的高效学习“秘技”

• 工程师成长的必备技能

• iOS 屏幕适配浅谈

• Web 与 App 数据交互原理和实现

• 苹果在医疗健康领域的三个 Kit

• 聊聊移动端跨平台数据库 Realm

• 复杂业务状态的处理：从状态模式到 FSM

• 如何成为一名数据分析师：数据的初步认知

• 从 React 到 Preact 迁移指南

• 后端的缓存系统浅谈

• Objective-C 中的语法糖

• Android 图片编辑的原理与实现——涂鸦与马赛克

• 捋一捋 App 性能测试中的几个重要概念

杏仁技术站

长按左侧二维码关注我们，这里有一群热血青年期待着与您相会。