导语：知道Marty Cagan这位产品大神，是他去年11月在台湾的演讲视频。看完中文翻译后，其中产品理念与我导师传授、以及在另一本书《持续交付2.0》相似。因此找来了《Inspired: How To Create Products Customers Love》（启示录：打造用户喜爱的产品）细细品读，以下便是几条感悟最深、也正在不断实践的总结。

产品经理经常会面对来自四面八方的需求，例如来自公司高层、业务方、用户调研反馈等等。如何评判哪些创意点子值得投入开发资源，通常PM会借助MRD来完成这个工作，也就是评估产品机会。其实很像我工作中遇到的「需求来源分析」。

在评估并确定好产品机会后，还要探索产品的解决方案，包括不仅限于产品设计重点、产品流程、交互体验等，也就是「定义要开发的产品」。

通过我会采用敏捷开发的方式，也就是小步快跑，快速迭代，先寻找MVP方案即明确产品的核心价值，一个版本迭代一个核心价值的内容。这需要PM在基于公司业务的基础上，了解用户想要什么，再去对需求进行本质的思考（目的、价值、行动、验证）。

这里对于产品新人，我总结出来的一个经验是：时刻保持对需求的思考而非项目管理。也就是不要花过多时间在和开发一起奔东奔西解决问题，而是多花去思考需求本身。我刚做产品经理的那个月，经常会把自己当成「项目经理」。

很典型的就是自己的需求小，但总是推这个推那个，对需求的思考不够。

因为人总是会沉溺于「能够解决问题的兴奋感」里，例如一起和开发找到了用户的问题所在，一起和开发把问题解决了，很开心的那种感觉。我记得当时在梳理转介绍口径，一起和测试花了整个下午找到口径不对的问题点并解决，当时觉得「好开心啊解决了一个问题」。

但是当导师问我整个下午做了什么，我回答这个时，她问我「你是不是觉得挺开心和兴奋的？但是你学到了什么呢？」似乎并没有。

因此不要沉浸在这种兴奋感里面，初当PM，就应该踏实地、一步一步地去把每个需求思考透：思考场景、用户的需求怎么来、怎么满足、哪种方式更合适、如何自洽…尽管和「跟开发一起解决问题」相比真的很难，但是也要让自己跳出舒适圈，逐步克服，3-5个月之后，就会发现一个不一样的自己！

在我看来，这些问题不涉及具体的解决方案，只是帮助我更好地明确待解决的问题是什么以及问什么，类似于黄金圈法则的「why/how」。

在接业务方的需求时，难免会听到他们一上来就和PM讨论解决方案，这时PM就需要帮助业务方思考清楚产品要解决什么问题，为什么要解决这个问题，目标是什么。

尽量避免将评估产品机会留到和解决方案一起考虑，因为当解决方案遇到困难时，这样的做法会让自己把产品机会也一并放弃，这可能就是典型的「没有思考好为什么做」的现象。

在上述10条「如何评估的问题」里，私以为最难回答的就是第一个问题——产品要解决什么问题（产品价值）。

解决什么问题，背后就是在问：这个需求，解决了什么用户在什么时候的什么场景下，遇到的什么问题，并且能够获得什么结果，也就是自己一直反复练习的「用户场景」。这个问题，不光是PM需要思考清楚，产品运营也同样很重要。

上个月接到运营侧一个需求，是希望让产品侧支持一个活动玩法，让刚购买体验课的用户分享邀请海报，然后给予金币奖励，以下对话（非原话，大概意思）：

• 我：这个活动的目的是什么？
• 运营同学：促进转介绍，提升转介绍例子数。
• 我：具体目标是多少？
• 运营同学：因为之前没有做过这个，所以只要是做了就肯定会有效果。
• 我：那是否可以根据已有的数据，来预估目标呢？另外为什么是选择这个群体来做？
• 运营同学：因为我们的体验课用户体量很大，每个月有xxxx这么多，加上这只是随手转发，还能获得奖励，不好么？
• 我：试想一下，一个刚购买体验课的用户，他连我们品牌的课程是怎么样的都不知道，他为什么要帮我们去推广宣传？这部分用户最想做的就是赶紧有人来联系他、告知怎么上课然后赶紧体验体验课程内容。所以反而是应该促进这部分用户赶紧去上课，提升CC的服务效率和质量。

因此可见，我们去梳理刚购买体验课的用户的场景，根据自己体验来说，会是「我刚购买了体验课，怎么上课啊？有没有老师来服务我？几点上课啊？上课前要准备好什么吗？上完课作业遇到问题该找谁？」这类的场景问题。

对于这批用户，最早让他们做转介绍的时机，可能是出现在「上完体验课」那一刻。比起和他人谈论解决方案，一开始就需要明确目的和场景。

Marty Cagan 对产品原则的定义是：是对团队信仰和价值舰的总结，用来指导产品团队做出正确的决策和取舍。它体现了产品团队的目标和愿景，是产品战略的重要组成部分。

在团队内，产品原则是整个产品团队的战略指南，一般是产品负责人带头制定。所以通过观察和学习，也可以了解公司的企业文化和团队的价值观，让团队在认知上保持一致。

或许在某些时候，会因为方向不一致导致冲突，产品原则所制定的优先级和目标就可以帮助团队成员达成一致。

例如，团队首先应该确定哪个目标对用户最重要，是易用性、响应速度、功能、成本、安全性，还是用户隐私？只有先统一对产品目标和目标优先级的认识，大家才能在此共识上进一步讨论各种方案的合理性与可行性。

一些产品团队对自己的产品往往过于自信，只顾埋头开发，总想等到公开测试的时候再收集反馈意见，但总是亡羊补牢为时已晚。这样的做法可能会导致产品在上线时与达成目标相差较远。

作者提出的三方面测试，第一点是可行性测试。这点完全可以在产品方案ing（产品逻辑输出过程中）时去和开发讨论。

对于小需求，直接询问即可；对于大需求，开发需要提前进行技术预研，讨论哪种技术方案对需求的实现更合适，兼容性和后续需求的拓展性更包容，有何技术障碍，是否需要跨部门的开发联动等等。

对于产品新人，切忌因「不好意思、这样问会不会很蠢等胡思乱想」而不去询问。因为等到需求文档写完、需求评审过程中发现技术障碍的代价远比起初大得多。

或者是在产品设计过程中，可以自己去百度一下某些问题的技术方案，拿捏不准再去问开发，这样做一来会让开发觉得你比较有「诚意」（因为你是已经带着自己的思考和解决方案去和开发沟通了）；二来自己也能掌握基本的技术知识，能比较理解开发在说什么。

第二点是可用性测试。对于作者提到的「真实的用户、目标的用户」，或许不是在每家公司都能频繁地直接地接触用户，但是也可以这么解决：如果我的需求是forB端，那拿着原型去问班主任、业务主管（目标用户）的意见，了解他们的使用习惯即可。

但如果我的需求是forC端（可能是学员、家长），一种方案是在电话调研时顺便询问；一种方案还是去问班主任，因为他们是离家长最近的人；还有一种方案是加一位家长作为微信好友，长期保持电话联系，向朋友一样询问意见。

虽然作为产品需要向张小龙学习，10s内变成产品白痴地去体验一款产品，但产品经理终究不能代替真实用户的反馈意见，如果实在无法接触用户，或许身边的开发、测试都是值得一试的「真实用户」呢~

导师在我刚成为产品的时候，反复和我强调「向上管理」。

或许上司对产品新人来说，像是一种权威、严肃、面无表情的「怪兽」哈哈，比较幸运是能遇到像朋友一样的导师，但是我们更应该去思考，如何做好「向上管理，积极反馈」。

我的做法是：

1. 前三个月每天写日报，总结当日工作，更重要是写下自己对工作、成长的思考（进步与不足）；三个月之后每周写周报。
2. 日常不管遇到什么问题，都必须带着自己的解决方案去和老大沟通。因为老大比我有经验，我能想到的问题她都能想到，但是她更希望听到我对这个问题的思考程度如何。不要让上司成为作答者，而是选择者。
3. 及时反馈。当老大主动问你一个项目的进度或某个问题的答案时，就已经说明你的反馈慢了，老大没有在他需要得到答案的时候得到，所以才来问你。因此需要摸清老大的喜好，比如什么时候有空听你的反馈，在她忙的时候尽量不要一长串钉钉轰炸….之类的。及时反馈的内容包括不仅限：交代给你的任务的进度；某个问题的处理结果和时间；项目遇到的风险及当前解决方案；事情进展不顺利的困难障碍。
4. 学会向上司借力。这一点是很难去体会和做，但也是很重要的。借力，是指向他人借其力，借到力，借好力。为什么是很难去体会和做，因为我刚开始工作，总会担心去麻烦别人，习惯自己去解决问题。但正是因为这样的思考，我很难去迈上更高台阶。原因在于一个真正优秀的产品经理，是懂得团队每个人的长处，提供机会去发挥队友的长处，比自己埋头苦干，更容易做成事。老大也是一样的，有一些事情，你不会不要硬撑，就需要及时向老大借力。在她的帮助下，你更明白下次怎么做，如果你不说，老大怎么会知道你需要借力呢？
5. 寻找对标对象。对标对象即为你可以学习、你想具备像ta一样有某种能力的人。这个人可以是你的导师，也可以是你的产品总监。导师很大的一个好处是在于，你可以从他身上找到自己不足的地方，然后模仿并刻意练习，久而久之掌握你想得到的能力。例如我的导师，我会经常观察她是怎么和别人沟通的，怎么说服别人，怎么做需求评审…，这是职场上成长的最大帮助技巧了！

（之前也有写过一篇关于对标对象的文章，戳：初级产品的2020年终复盘与成长）

在这本书的最后，Marty Cagan给出了一份产品经理的反省清单。从产品价值、产品设计、到产品管理、团队管理，都是我们每个人都需要去思考的问题。所以其实虽然人人都是产品经理，但做出好产品真的是难于登天呀！

最后我认为作者在「寻找出色的产品经理」中说的很对的一点，也是给自己今后从初级到高级产品的掌握能力，如下所述：最宝贵的经验不是行业知识或技术(这些都可能过时)，而是打造优秀产品的流程、领导产品团队的能力、应对产品扩张的经验、个人对自己的认知，以及自我激励的能力。

本文由 @莫琳 原创发布于人人都是产品经理。未经许可，禁止转载

题图来自Unsplash，基于CC0协议