前滴滴出行产品经理刘飞：写给产品经理的说明书（中）

最新推荐文章于 2024-09-15 19:46:31 发布

PMCAFF产品社区

最新推荐文章于 2024-09-15 19:46:31 发布

阅读量942

点赞数

文章标签：编程语言交互设计产品经理 android模拟器 java

本文链接：https://blog.csdn.net/pmcaff2008/article/details/111472181

版权

嘉宾介绍

刘飞，资深产品人，前滴滴出行司机方向前产品负责人，点我达前产品专家，嘟嘟美甲联合创始人，锤子科技产品经理。在知乎累计446579次赞同，224900人关注，“产品经理”话题下的优秀回答者。虎嗅网、36kr、雷锋网、人人都是产品经理、知乎等媒体专栏作者，通过“在行”平台线下帮助200余位产品学员进阶。开有公众号“刘言飞语”。

新书《产品思维》将产品经理工作中必须要面对的认知盲点和实践痛点掰开揉碎进行讲解，毫无保留地分享了产品新人迫切需要却很难在公开渠道获取的知识，现全网热卖中。

Q1. 产品经理的核心竞争力是什么？

细节层面的交互理解、体验创新，其实更像是 UX、UE、UI 的工作。而对一些工具的运用，也显然不能构成产品经理的竞争力。

我个人的体会是，对不同阶段的产品经理，都有一个核心的竞争力，就是「不仅能把事情做对，还同时能判断出对的事情」，换句话说，在执行力的基础上，还具备选择判断的能力。

这是我最近一个很深的体会。而这一点，是由于产品经理本身所需的能力、所涉及的工作决定的。

可以分几个方面说。

很好地满足需求，不仅是满足需求。

对于一件事，做到 60 分的方法很多，但做到 80 分的方法很少。比如一个注册登录，做到可以用，很简单，谁都能做，我身边不是产品经理的朋友也都能设计得出来。但是，注册需要邮箱、手机号还是账号？是不是提供第三方登录？找回密码的流程是怎么样的？要不要有冻结账号的途径？密码的复杂程度有要求吗？哪种交互页面更符合目标用户的习惯？... 这些都做得完全契合当前的产品，其实并不简单。

学习自己所需要的，不仅是学习。

产品经理的知识图谱十分复杂、五花八门，关键点不在于持续地获取新知识，因为知识是获取不完的。关键在于你明白：对于当前的产品来说，我最需要获得什么知识。大部分知识在你当下的工作中并不需要。

了解你所欠缺的，并快速学习，是比只会学习、在知乎上问「产品经理需要什么能力」更有意义的。对于这行，并没有「业内公认」的基本知识体系。

要谈笑风生，不仅是口齿伶俐。

过去我还比较初阶的时候，总是觉得有理就可以，惹得很多程序员哥哥们不开心。但回头想想，很多时候沟通的目的不是比个对错、吵个输赢，而是解决问题。所以要选择一种可以谈笑风生的方法，不要只强调本身的对错。哪怕有时候是说瞎话哄他开心呢？「咱们公司谁最帅？」「当然是程序员哥哥你最帅啦！」

做当下最重要的事，不仅是做事。

之前刚开始带团队时，我总是纠结在细节，跟大家打成一片。老板找我聊，说我做的的确没错，也确实起到了作用。但是，作为当前阶段在当下位置的 leader，是不是应该起到更重要的作用？

我后来意识到，的确要选择能产生更大价值的事情去做。亲自设计一个按钮一条文案，不如带出几个徒弟更好地配合你，你有精力时间去关注更高层面的问题；解决一个两个出现的问题，不如搞明白问题的原因，花时间建立一套完善的工作流程和考核机制。前者都是对的事，但很多情况下，我们需要做更对的事。

Q2. 作为一个产品经理或产品负责人会可能忽视哪些实际上很重要的事？

我在锤子科技做的是产品经理，在嘟嘟美甲做的是产品负责人，似乎恰好能回答这个问题。

我的理解，以下一些点是产品经理或者产品负责人会经常忽略的，我在新书《产品思维》中也有详细阐述。

1. 任何事情要考虑全面，逻辑链条清晰。

对产品经理来说，想出牛逼的点子只是副业，怎么把产品流程的设计顺利圆满没有遗漏地完成才是天职。

比如，作为电商产品经理，除了正常购买流程，每个环节的错误页面有补全吗？每种问题的处理情况想到了吗？遇到网络信号不好时界面会是如何的？用户没登录、没绑定支付、没支付成功的时候交互如何？用户登录失败、绑定失败、支付失败的交互又是如何？

所以，这可能是你初步想象到的正常页面逻辑：

这可能是实际的页面逻辑：

这其实是做产品时最常忽略的事。

2. 满足需求的功能 >> 优质用户体验

产品经理如果看到一些很炫的 APP，尤其一些很炫又相对比较成功的 APP，会误认为它们的成功完全归功于用户体验。

我可以负责任地告诉你，包含交互、视觉在内的用户体验，在用户需求尚未满足前，都是废物。满足用户需求是 1，而用户体验是可以在 1 后面添加的 0.

我见过 3D 效果做得简直像科幻片里的特效的 APP，同事用手机给大家演示，所有人都赶过来围观。这个 APP 有用吗？有用，但只有一个用途，就是拿出来让大家围观...

再举个例子，你看看淘宝的页面：

你如果是信奉极简主义，恨不能把主页改成这样：

当然，逼格高了，感觉用户视觉上舒服了。但你作为用户来用的时候，会发现特别难用，无从下手。作为大而全的电商网站，更多信息展示显然是比界面简洁更重要的。

所以永远记得，先满足需求，再考虑加特效，duang duang 什么的。

3. 理解需求背后的原理和原因

产品经理很多时候是需求承接方，有时需求来自老板，有时需求来自同事，有时需求来自用户。这时候，一定要分清一件事情，这件事情是非常非常容易被搞混的，就是：他们给你的是明确无误的需求还是只有实际的方案！

比如，老板的需求可能是这样的：

给我做个客户端实时记录美甲师 GPS 的功能来。

作为忠贞不二的员工你可能就落实去了。但实际上，你需要搞明白老板为什么这么做。在再三的追问下，老板可能就告诉你他的原因是：

因为美甲师经常会为了奖励刷单，也就是不出门让朋友来下单。GPS 用来帮助判断这个。

所以你理解了老板的需求，那么下一步做的时候就清楚了：要查美甲师是不是刷单，没有必要实时做记录，这样增加美甲师端的流量消耗，也增加了服务器的负担。正常的接单时间都会大于半小时，因此完全可以将功能改成：

每半小时记录一次美甲师的 GPS。

任何人（包括用户，严格说尤其是用户）给你提需求时，有时候只是根据自己的需求拍脑袋想了一个方案建议你做，但作为产品经理，要做的是理解其背后真正的原因或者原理，转化为更合适的产品方案。

4. 有写文档或者做记录的好习惯。

大公司会有详尽的文档撰写要求，但初创团队和小公司考虑到效率问题都很少有写文档的习惯。

许多人会觉得口头表述和口头确认是初创时期自然而然的工作方式，实则不然。即使最粗糙的产品功能说明文档、交互文档和需求文档，都要比任何事情全靠口头解决要好。文档和记录是规范产品研发的重要参考，是当大家有了争执可供确认的凭证，以及最后产品版本验收的查验标准。

半个月后，没人记得现在做的这个功能当初为什么决定要做，像这样尴尬的问题就不会出现。

我平时用的记录工具都很常见，供参考：

Evernote | 你的工作空间：会议/讨论的记录；零散想法/点子；脑图

Keynote (PowerPoint) ：交互；用户体验的想法

Sketch ：交互

Numbers (Excel) ：数据/信息的结构

5. 考虑将来可能的变化。

除了空间维度上要考虑更多情况，在产品方面，还要考虑时间维度上的状况。

包括但不限于：

版本的命名和意义（不要让用户困惑）
版本的更新周期（不要让用户觉得烦）
强制改版的情况（旧的功能无法使用。强制改版显然不宜太频繁）
将开发功能的预备（与技术沟通未来将开发的功能，提早在代码层面有所准备，以防经常做太多改版）
提前考虑埋点的情况（用来做用户行为分析）
要上 App Store 的应用，在做以上这些考虑时，一定要把审核时间算上

6. 正确地完成事情，是衡量产品经理称职与否的标准。

很多人问我怎么才算合格的产品经理或者产品负责人，我都会说关键词在于“完成”和“解决问题”，而不是“创造”、“创新”、“更美”和“更牛逼”。后者当然也重要，但应当只能算是锦上添花。

如前面所说，产品经理不是那种闷头想牛逼点子的人，而是把老板对产品的定位落实到方案上、把同事们的需求落实到功能的配合上，把用户对产品的反馈落实到迭代改版上的人。

举例来说，作为淘宝的产品负责人，你最重要的工作就是让用户很方便、很顺畅地买到想要的商品，其次是让商家很方便、很顺畅地售卖自己的商品，再次是让平台的营销活动很方便、很顺畅地进行。其它的都不重要。

而作为百度的产品负责人，你最重要的就是让用户很方便、很顺畅地搜到自己想要的东西。

我简单粗暴地总结了这样一个对比表格，你可以感受一下：

因此，对于产品经理或者产品负责人来说，“整体使用流畅、没有硬伤”比“这个功能真酷真炫真牛逼”是更令人值得骄傲的褒奖。

7. 让大家喜欢也是很重要的小事。

其实写着写着，感觉上面说的有的不算是小事了，但社交能力，或者说单纯地让别人喜欢你的能力，是我觉得最重要的小事。（...为什么不知不觉哼起五月天的歌来）

既然产品经理的工作有相当一部分是在协调、推进、跟踪和核对上，那沟通和交流就是产品经理日常工作最基本的元素。能让大家都喜欢你不是件易事，比如面对工程师，有的产品经理会跪舔（“哥，给你买了新鲜的荔枝尝一下。顺便看看这个问题呗。”），有的产品经理会利诱（“最近这么辛苦，今天版本上线后，晚上请你大保健吧。”），有的产品经理巧言令色（“你看这个功能我已经跟老板大吵三天三夜，帮你争取成这样了，你要知足常乐的。”），总之要会说话，都是为了让沟通更快捷，毕竟产品经理不是真正的“经理”。

这是两位产品经理在练习如何跪求工程师做需求的一幕（只是示意图，大家不要紧张。没有产品经理在本次拍摄中受到伤害）：

这是我最崇拜的老同事大帝坐在工位上面不改色舌战群狮的壮丽一幕（冒着生命危险拍下宝贵镜头，还被恶狠狠地瞪视了）：

他们都是我的榜样。

Q3. 产品经理没做过成功产品，应该何去何从？

前几天公司有个面试的小伙子。

小伙子很精神，思路很清晰，也很努力。对事情有主见，大部分的判断也都正确；沟通无障碍，聊得也不错。

就是有个大问题：他几乎没做过上线运营的项目。

他很坦诚，就说自己运气不好，每次上马一个项目，设计都做完了，结果老板拍板说撤掉。来回换了几家公司，换了几个项目，都是「探索型」的新产品，都不了了之。

后来我们婉拒了他。

到这里你可能会觉得，哦，果然还是得烧烧香啊。

其实不是。我们婉拒的理由不是「没有做过成功产品」，而是我们觉得他心态有些问题。

在他的视角里，对这段经历的描述是这样的：

我的产品设计很完善了，可惜没上线
我的老板不靠谱
我所在的环境不好
我的出身（学历）不好

问题在哪？他认为这一切都是外在条件的错。只要项目上线，或者老板靠谱一些，或者环境好一些，或者背景再好些...... 就会没问题了。

这对于做产品经理来说，是个硬伤。

我所熟悉的朋友，对产品经理的定义都惊人地一致——解决问题的人。这个问题包括用户的问题，包括团队的问题，包括协作的问题。问题可能很杂很多，或大或小，但产品经理就是为了让产品顺利上线迭代，来填各种坑、铺平道路的。

如果是产品设计师，那只关心自己的产品设计没毛病。可产品经理就不能这样。

比如，如果意识到老板并不关心这个产品，有没有劝说老板认可你的能力？

比如，如果觉得产品没有得到其他人支持，有没有说服其他同事配合你的能力？

所谓沟通能力不是指巧舌如簧、能说会道，最重要的是能够影响别人。

再比如，如果产品上了没有人用，有没有尝试去学着做点运营的事情？

拿到自己的产品，有没有亲自去拉几个种子用户来用？

如果说很多时候我们的确影响不到别人，或者说运气就真的太差，公司砍掉了项目、资源急剧缩减，那么有没有主动换个环境、做点别的事情？或者说，有没有及时止损？

对于刚毕业的 5 年内，都是很关键的时期。在这段时间内，觉得没有得到成长，有没有想改变？觉得项目不靠谱，有没有想走？觉得没有人带，是不是还硬着头皮上？

这个小伙子没有让我们看到他曾经「试图改变」的努力，而是「既然如此，我就尽量吧」这样的心态。

我见过许多在创业公司中间来回折腾、反复跳槽的产品经理都是这样的情况。很多刚毕业的朋友没有意识到眼下最重要的问题（没有导师带、项目风险大、资源缺失），而是关注着很多细节问题（这个按钮摆在哪、那个版本什么时候上、技术今天又不开心了），同时还享受着创业公司相对比较光鲜的环境（现在创业公司的办公室越来越高级了）和相对比较光鲜的 title（初创团队随便写），缺乏思考的结果就是，没有趋利避害，没有在职场上掌握主动性，最后就大概率地成为题主所说的情况。

那么回到问题，该何去何从呢？

不要跟最顺利的人比。那些毕业就含着金钥匙，去了 BAT 快速成长几年，混得风生水起，或者成了高 P，或者创业拿了大钱成了副总的，不要羡慕他们——已经来不及了。

对于现在的情况，做一个自我剖析，再做一些行业判断，最后再决定该走哪条路。

自我剖析说的是，你到底做了什么、擅长什么。这时候不要太关心自己学历如何、背景怎样，也别在意产品是不是成功，就看自己真正跟几年前比，哪些地方不一样。产品经理和产品经理差别巨大，你不做剖析，只一个「3 年经验产品经理」和「5 年经验产品经理」，没有人会对你有认知的。

得到的不一样的这些点，梳理一下，便是你在职场里的优势。跟市场里其他的应聘者去竞争的时候，拿出这些来，而不是拿自己的软肋（产品经历）去比。

最尴尬的情况是，你跟刚毕业时没什么两样，那就真的毫无办法了，你可能需要花比应届生都要多的成本才能找到一份好工作，这时候认真反思，从头再来吧。

行业判断说的是，不要只看薪资、环境和个人工作的成长，也要对公司所在的行业有一些感知，对公司的业务有一些感知。

以当前的状况，你很可能还是要去中小型的公司，那这点就至关重要了。像游戏分发、O2O、众筹和互金，都是一夜春风来千树万树开的潮流行业，每次都进这样的行业，说明并没有很好地吸取之前的教训。这种潮起潮落节奏快、潜在泡沫很多的行业，未必不能去，只是反复吃亏还反复去，就不太值得同情了。

最后，结合自己的情况，做出相对最好的选择。注意我说的是相对摆在自己桌面上的所有选择，里面相对最好的。有时候我们在起跑线上已经落后了，就只能先保证目前一直在进步，而不要再顾此失彼了。要是真的找不到什么靠谱的产品岗位，利用过往的优势做别的事情也未尝不可，总之，不要太在意沉没成本。

Q4. 从产品经理怎样过渡到产品总监？

最近在思考产品经理的个人发展，看到这个问题，就稍微歪个楼，不讲有哪些大牛，先说说为什么产品经理可以成为，以及怎样成为业务负责人甚至公司老板，成为互联网大佬。

1.产品经理是知识工作者，输出的是决策。

知识工作者是大师彼得·德鲁克思想的精髓，在过去的年代，大部分员工的价值在于体力劳动，或者说能够输出稳定的熟练劳动能力。在框架和规则下，尽量提高效率、保证实际产出，是那时候工作者的目标。

而后来的企业管理，都普遍认识到知识输出也是极为重要的一环。在大家的认知里，也能区分谁是白领谁是蓝领，谁在做机械式劳动、谁在做重要决策。在互联网时代，产品经理就是最典型的知识工作者，几乎没有多少机械式劳动的输出。

那产品经理在输出的决策是什么呢？这才是说不清楚的点，也是大家争议最大的点。

若要说说不清楚，也未必，只是在特定场景下、对于不同时期的产品、对于不同的产品角色，甚至看不同的老板性格、不同的团队文化，产品经理要输出的决策差别还都是很大的。

我随手做了一个输出决策的全集，供参考：

这个金字塔里，往上看的决策愈发重要，而且对决策人的要求愈高，同样的越往上走能做好这个决策的人也就越少。虽然简陋，但用这张图能够说明几个道理，我们一个个来看。

2.产品经理的影响范围有很多层次。

从图里可以看出，产品经理决策的类型实在太多种多样了。我在创业期间实际上要做从整个平台模式、产品定义，一直到每个按钮的颜色、位置，这全部有关产品的所有决策，所以那段时间会思考得很多，也有了产品经理输出不同层次决策的亲身感知。

就像下面这些事情都是在做决策，但显然是不同层次的决策：

“刘飞，你做个注册页面的原型出来。”（原型交互）
“刘飞，你判断下要做哪种样式的注册页面。”（产品体验）
“刘飞，你考虑下我们的这类用户要不要做注册流程。”（用户需求感知）
“刘飞，你想想看我们平台需不需要这类用户。”（市场分析）
“刘飞，你定义下我们平台的模式。”（产品定位）
......

正因为许多产品经理实则是在不同的层次做决策的，才会产生“咦我做的事情怎么跟他不一样”这样的问题。

早期最知名的一些产品经理，实际上都是在这个决策金字塔的顶端做事情，比如马化腾、周鸿祎。他们关注的几乎都是战略层面的事情，以及更基础、更重要的决策，这些决策会影响到整个公司、整个产品团队的实际规划和操作。

他们的确也关注用户体验，但关注的方式还是“老板式”的，就是发现了就治理，不发现的还是会交给下面的人去做。

3.产品经理要做出优质决策需要不同的技能和经验。

延伸出的第二个结论就是：产品经理到底需要具备什么样的技能和经验。这显然也是跟具体在做什么有关的。

有很多想转行为产品经理的同学，被媒体和一些不靠谱的产品经理的书误导，认为产品经理就是做公司战略、做商业分析的，所以动辄就去聊支付宝微信的线下场景大战、聊摩拜和ofo到底哪天合并......我当然很支持每个互联网从业者都关注天下大势、行业现状，不过把这些过于宏观的判断、过于想当然的很多媒体分析，当作是产品经理的技能点，就是不合适的了。

那好的产品经理到底能不能做金字塔顶端的决策呢？当然能。但前提不是你的title是产品经理，前提是你足够有商业头脑、有大量的行业信息输入、有充分的行业判断经验、有长期的互联网行业工作履历等等。

这个结论还能解释为什么我一直强调会用Axure、会写调研报告，甚至会看《人人都是产品经理》《从点子到产品》都不是产品经理的主要技能，都没必要写进简历里充字数。产品经理的主要技能不是会用工具会看书，而是输出优质决策。具体你用Axure输出也好，用PPT输出也好，用纸笔输出也好，并不重要，重要的是内容本身。

4.产品经理的决策价值=工作内容影响范围×工作中决策的优质程度。

结合前两个结论，对于一个产品经理真正的价值，就可以有这样一个公式了。影响范围（决策层次）和做出决策的优质程度（本身在此层次的水平）要综合考虑，才能确定一个产品经理的价值。

可以做以下的对比：

一个能够画特别完美原型的产品经理，未必就价值非常大，因为他的影响范围实在有限。一个能够推动新业务从0到1的开创型产品经理，即使经常做出不靠谱的推断、即使不怎么会画原型，也能输出给产品或者公司更具价值的一些决策。

一个已经有产品总监title、要负责许多重要判断的产品经理，在用户体验上、在交互层面上的经验，并不能帮助他产出更多在他的工作职责中应当产出的有价值决策。一个目前在负责基础体验的初阶产品经理，即使在商业策略上有诸多想法、能够指点江山，也同样无法帮助他工作上做更好的产出。

5.产品经理的薪资和成长空间∝产品经理的决策价值。

最终，我们就可以有这样的结论了：产品经理的薪资和成长的空间，都是依赖于产品经理决策的价值的。既不依赖于产品经理的工作年限，也不依赖于产品经理工作的平台。重要的是，作为产品经理，你在做哪个层次的事情，以及你在这个层次做到能有多好。

对于初阶产品经理，更重要的就是把分配好的需求跟好、跟完，都是比较基础的决策，能够实现公司对于产品的要求，也能够创造用户价值。当能够完全掌握这个层次的工作后，就可以逐步往更高的层次去尝试，是不是可以不做细节的决策，而做功能层面、模块层面比较宏观的决策了？

长此以往，反复确认，做的决策越来越接近产品的本质、商业的本质，也就越来越有价值、越来越不可替代了。

很多人会疑虑做产品经理五年后会怎么样，可以加个定语，就是一直在同样的层次输出机械式的决策，并没有任何变化的产品经理，他们五年后可能的确会面临被替代的风险。而一直在金字塔中向上转移的，决策分量变重、决策质量变高的这些产品经理，肯定不存在同样的风险。

所以我们回到题目来看，许多产品负责人，逐步都在往投资人、创始人、CEO的方向去转型。像李明远，目前在实地集团做总裁，负责整体业务。QQ空间当年的产品经理郑志昊，如今也是猫眼的CEO。有赞CEO白鸦原本也是产品设计师。UC原来的产品负责人何小鹏，在UC并入阿里后，开始转战汽车领域，成立了小鹏汽车。还有黄海均、马力老师他们，也都在自己创业，做得有声有色。

这都源于他们在后期团队中的角色并非是简单在输出产品设计的决策了，他还在做行业的判断、战略的把控，能够更清楚行业分析、团队运作、产品规划等等一系列的工作（可以看出都是金字塔顶端的重要决策）。

我觉得这个通路比起很多人想象的“我画五年原型是不是就是CEO接班人”会更具象一些——你需要先让自己做更多更重要的决策，并让决策的质量变高，才能更接近所谓的权力中心、成为最不可替代的大佬。

Q5. 高级产品经理和普通产品经理有哪些区别？

普通产品经理的一天可能是这样的。

早上到公司想一想，这几天有哪些事情要处理。打开记事本，按照上面要求的任务一条一条开始做。

这里有个需求，是要给产品的聊天模块增加历史记录。嗯，看一下常见的几款社交工具 APP，他们的做法，心里大概有数。打开空白的 Sketch 文档，开始作图。

这时工程师同事来找，说有个之前的需求文档表述不清。于是带上相关的大伙紧急开会核对一下。哦，原来是有个逻辑没描述好，讨论清楚就行了。大家心满意足地散会。

继续做文档，已到中午吃饭时间。刚要去吃饭，老板突然喊住，说哎昨天安排的那个整理产品简介的 PPT，有没有做好。才突然想到这事儿，记事本里倒是记了，还没来得及做。

于是叫了外卖，赶快先做 PPT。花了一小时终于搞定，赶快发邮件给老板，然后继续做聊天模块的方案。

方案做完，发给 UED 部门。再看还没做的任务。哦，之前有个邮件，运营部门提到，现在的转账功能使用非常不方便，用户反馈很差。于是翻出转账功能的需求文档来，细细端详。

花了一个多小时，做了 5 个优化方案，喊几个产品同事一起讨论了半小时，定好细节，准备第二天完成文档提交给开发。

傍晚原本还有个项目迭代会，但这次人不齐没有开成。昨天也是因为人没齐。想了想他们真不靠谱，又得晚一天开，可能还要延期，自己又要背锅啦。

晚饭在楼下随便吃了点，回来看任务还有调研社交软件的商业化这项工作，于是在知乎、微博、微信公众号上把各种文章都搜出来，一篇一篇读。

读到 9 点半，很充实。下班，回家。刚到家老板打电话问 PPT 怎么样了，回答说早就发邮件了啊，可能是漏掉了。老板检查了下，果然如此。

高级产品经理的一天可能是这样的。

早上到公司，打开 to do list，按照优先级给自己排一个序。老板说过有个产品简介的 PPT 很重要，所以先做这个。

PPT 花 20 分钟先做个初稿，拿给老板看，问是不是这个意思。老板说有几处不太合适。于是改掉，再继续补充完整、调整排版，最后再拉个设计师同事来帮忙点评下，调下配色和布局。

整理后发给老板。考虑到老板比较着急怕他漏掉，特地到他办公室提醒他一句东西已做好。

这时大概是中午吃饭时间，想到最近跟开发的哥哥们接触比较少，就喊了几个工程师一起吃饭。吃饭的时候聊了聊近期产品的策略和开发上遇到的几个问题，顺便沟通沟通感情，扯扯淡。

吃完饭，开始按 list 里的安排，做聊天模块的历史记录功能。

先写出这个功能的需求逻辑来，比如给谁用的、什么时候用、在什么情况下用、怎么用，这几点也都罗列清楚，然后把场景和需求结合来看，推导出应有的功能。

这时，根据功能画了 A、B、C 三个方案，然后查看常见的几款社交工具 APP，取长补短放在自己的方案里。再观察三个方案的优劣，写清楚。

跟产品同事们聊了聊不同的几个方案，一致认为 B 方案最优，因此暂定是 B 方案，发给 UED 部分，顺便发给相关开发，请他们过目看可行性。

这时开发的一个同事来说，有个之前的说有个之前的需求文档表述不清。于是带上相关的大伙紧急开会核对一下。哦，原来是有个逻辑没描述好，讨论清楚。然后，再跟大家复盘下出现的问题，何时出现的、为什么会出现、谁发现的、之前为什么没发现等等。这些搞明白后，一起拟定了一套新的协作流程，以规避会出现的问题。大家散会。

看还没做的任务。哦，之前有个邮件，运营部门提到，现在的转账功能使用非常不方便，用户反馈很差。于是找到运营部门的同事，问他们是谁提的问题。运营的同事说是有几个用户，于是要到用户的联系方式，直接打电话回访。记录下来 3 个问题，然后思考了对应的 3 个优化方案，给运营的同事过目，然后准备第二天完成文档提交给开发。并且提醒运营部门的同事，未来这样的问题，要连同用户的联系方式一并提供。

傍晚原本还有个项目迭代会，但这次人不齐没有开成。昨天也是因为人没齐。不能再拖，找到今天临时有事的几个同事，严辞跟他们说清，如果再不一起开成会，这次迭代可能就会延期，后果要他们承担。回到工位再发送一封邮件，抄送给所有参会者和他们的 leader，说明情况。大家纷纷表示，第二天上午就一定把会开完。

晚饭在楼下随便吃了点，回来看任务还有调研社交软件的商业化这项工作，于是在知乎、微博、微信公众号上把各种文章都搜出来，一篇一篇读。读的时候把有价值的观点都整理到 Evernote 里，并做好索引，方便查阅。

读到 9 点半，很充实。下班，回家。

要抽象出来几条解释很难，从我的故事里应该能体会到区别。非要说用一句话来描述的话，就是「高级产品经理会关注和参与更多」。

对于普通的产品经理，他只负责份内的事情，诸如产品设计、项目推进、需求分析。所以跟其他部门一样，是独立的职能人员。

对于高级产品经理，一方面是视野和感知，一方面是负责的事务和工作内容，都要触及其他部门，成为他们的中枢。

嗯大概就是这样。希望能帮到你。

Q6. B端产品经理与C端产品经理有什么区别吗？如何做好B端产品经理？

我目前在做的产品是物流（配送）领域的产品，介于 to C 和 to B 之间。可以说下我的理解。

先说 to C 产品。大家都比较熟悉用户产品，分析的思路都是看市场组成、看竞争对手、看用户群体，可以说，得用户者得天下。不管是用户体验至上、打价格战补贴战，还是讲情怀说故事、买广告做公关，这样的产品就是想方设法要让用户用上、而且让用户喜欢上。

对于这样的 to C 产品，产品经理要做的事情是我们平时都会聊到的：需求分析、功能设计、用户体验、迭代推进等等。用这些工作保障产品一直在向让产品更有价值、用户更愿意埋单的方向进步。

因此，对 to C 产品的产品经理来说，主要能力大概是：

对市场和用户敏感，懂得做调研、访谈和分析
对需求和场景敏感，可以做好功能设计
熟悉用户体验，懂审美
沟通、团队协作和管理能力
熟悉运营、营销方面的知识

再说 to B 的产品。to B 的产品有两种，一是内部产品，比如后台产品、CRM 系统或者 ERP 系统，这是针对公司的需求让很多工作结构化、信息化以及流程化，而公司未必是做 to B 的产品的；二是公司的商业产品原本就 to B，比如一些外包团队、提供语音技术解决方案的公司，以及像菜鸟这样试图填充某几项物流环节的公司。

对前者来说，产品经理要关注的是公司的产品，以及公司团队的整体协作方式。产品的所有价值就是让团队的工作更加高效、快捷和方便。比如原本客服团队都用最笨拙的手工记录方式处理问题，客服系统可以让效率提升十倍，这就是价值。比如，原本发布各种版本（正式、灰度、强更、A/B）都要让工程师去手动完成，后来做一套可视化的后台发布系统，发布由产品或者运营就能完成，这也是价值。

对后者来说，产品经理要关注的则是整个产业链的情况、整个 to B 市场的状况。自己公司的产品在行业内是处于什么位置？价值产生在什么地方？威胁最大的会是什么？说白了也就是 SWOT 的分析。

关注点并不一定只在要让甲方满意，他们说什么就做什么。还要关注，甲方对自己的态度是如何的。这也是一种潜在的用户诉求，只不过对方不会明白告诉你。举个简单例子，如果有一个专门做 to B 算法技术的公司，给很多公司提供大数据算法解决方案，技术好也来钱快。不过，核心的算法对某些公司来说很敏感，可能甲方用你的产品只是前期人员不足的折中方案，早晚都要自己亲自做。这样就不能高枕无忧，万一现在对接的甲方都是这种心态呢？就要想其他的出路了。

总之，这样的产品经理要对付的不是成千上万、并不那么具体的用户群，而是一个个形象具体的甲方。他们的问题都明摆着，需求也明摆着，你不需要做什么麻烦的用研，也很少要做需求分析。最重要的就是用最好最快的方法把他们的问题解决。

to B 的产品经理，更需要：