2021-3-1 资深UI设计者
产品经理经常会面对来自四面八方的需求，例如来自公司高层、业务方、用户调研反馈等等。如何评判哪些创意点子值得投入开发资源，通常PM会借助MRD来完成这个工作，也就是评估产品机会。其实很像我工作中遇到的「需求来源分析」。
在评估并确定好产品机会后，还要探索产品的解决方案，包括不仅限于产品设计重点、产品流程、交互体验等，也就是「定义要开发的产品」。
通过我会采用敏捷开发的方式，也就是小步快跑，快速迭代，先寻找MVP方案即明确产品的核心价值，一个版本迭代一个核心价值的内容。这需要PM在基于公司业务的基础上，了解用户想要什么，再去对需求进行本质的思考（目的、价值、行动、验证）。
这里对于产品新人，我总结出来的一个经验是：时刻保持对需求的思考而非项目管理。也就是不要花过多时间在和开发一起奔东奔西解决问题，而是多花去思考需求本身。我刚做产品经理的那个月，经常会把自己当成「项目经理」。
很典型的就是自己的需求小，但总是推这个推那个，对需求的思考不够。
因为人总是会沉溺于「能够解决问题的兴奋感」里，例如一起和开发找到了用户的问题所在，一起和开发把问题解决了，很开心的那种感觉。我记得当时在梳理转介绍口径，一起和测试花了整个下午找到口径不对的问题点并解决，当时觉得「好开心啊解决了一个问题」。
但是当导师问我整个下午做了什么，我回答这个时，她问我「你是不是觉得挺开心和兴奋的？但是你学到了什么呢？」似乎并没有。
因此不要沉浸在这种兴奋感里面，初当PM，就应该踏实地、一步一步地去把每个需求思考透：思考场景、用户的需求怎么来、怎么满足、哪种方式更合适、如何自洽…尽管和「跟开发一起解决问题」相比真的很难，但是也要让自己跳出舒适圈，逐步克服，3-5个月之后，就会发现一个不一样的自己！
在我看来，这些问题不涉及具体的解决方案，只是帮助我更好地明确待解决的问题是什么以及问什么，类似于黄金圈法则的「why/how」。
在接业务方的需求时，难免会听到他们一上来就和PM讨论解决方案，这时PM就需要帮助业务方思考清楚产品要解决什么问题，为什么要解决这个问题，目标是什么。
尽量避免将评估产品机会留到和解决方案一起考虑，因为当解决方案遇到困难时，这样的做法会让自己把产品机会也一并放弃，这可能就是典型的「没有思考好为什么做」的现象。
在上述10条「如何评估的问题」里，私以为最难回答的就是第一个问题——产品要解决什么问题（产品价值）。
解决什么问题，背后就是在问：这个需求，解决了什么用户在什么时候的什么场景下，遇到的什么问题，并且能够获得什么结果，也就是自己一直反复练习的「用户场景」。这个问题，不光是PM需要思考清楚，产品运营也同样很重要。
上个月接到运营侧一个需求，是希望让产品侧支持一个活动玩法，让刚购买体验课的用户分享邀请海报，然后给予金币奖励，以下对话（非原话，大概意思）：
因此可见，我们去梳理刚购买体验课的用户的场景，根据自己体验来说，会是「我刚购买了体验课，怎么上课啊？有没有老师来服务我？几点上课啊？上课前要准备好什么吗？上完课作业遇到问题该找谁？」这类的场景问题。
对于这批用户，最早让他们做转介绍的时机，可能是出现在「上完体验课」那一刻。比起和他人谈论解决方案，一开始就需要明确目的和场景。
Marty Cagan 对产品原则的定义是：是对团队信仰和价值舰的总结，用来指导产品团队做出正确的决策和取舍。它体现了产品团队的目标和愿景，是产品战略的重要组成部分。
在团队内，产品原则是整个产品团队的战略指南，一般是产品负责人带头制定。所以通过观察和学习，也可以了解公司的企业文化和团队的价值观，让团队在认知上保持一致。
或许在某些时候，会因为方向不一致导致冲突，产品原则所制定的优先级和目标就可以帮助团队成员达成一致。
例如，团队首先应该确定哪个目标对用户最重要，是易用性、响应速度、功能、成本、安全性，还是用户隐私？只有先统一对产品目标和目标优先级的认识，大家才能在此共识上进一步讨论各种方案的合理性与可行性。
一些产品团队对自己的产品往往过于自信，只顾埋头开发，总想等到公开测试的时候再收集反馈意见，但总是亡羊补牢为时已晚。这样的做法可能会导致产品在上线时与达成目标相差较远。
作者提出的三方面测试，第一点是可行性测试。这点完全可以在产品方案ing（产品逻辑输出过程中）时去和开发讨论。
对于小需求，直接询问即可；对于大需求，开发需要提前进行技术预研，讨论哪种技术方案对需求的实现更合适，兼容性和后续需求的拓展性更包容，有何技术障碍，是否需要跨部门的开发联动等等。
对于产品新人，切忌因「不好意思、这样问会不会很蠢等胡思乱想」而不去询问。因为等到需求文档写完、需求评审过程中发现技术障碍的代价远比起初大得多。
或者是在产品设计过程中，可以自己去百度一下某些问题的技术方案，拿捏不准再去问开发，这样做一来会让开发觉得你比较有「诚意」（因为你是已经带着自己的思考和解决方案去和开发沟通了）；二来自己也能掌握基本的技术知识，能比较理解开发在说什么。
第二点是可用性测试。对于作者提到的「真实的用户、目标的用户」，或许不是在每家公司都能频繁地直接地接触用户，但是也可以这么解决：如果我的需求是forB端，那拿着原型去问班主任、业务主管（目标用户）的意见，了解他们的使用习惯即可。
但如果我的需求是forC端（可能是学员、家长），一种方案是在电话调研时顺便询问；一种方案还是去问班主任，因为他们是离家长最近的人；还有一种方案是加一位家长作为微信好友，长期保持电话联系，向朋友一样询问意见。
虽然作为产品需要向张小龙学习，10s内变成产品白痴地去体验一款产品，但产品经理终究不能代替真实用户的反馈意见，如果实在无法接触用户，或许身边的开发、测试都是值得一试的「真实用户」呢~
导师在我刚成为产品的时候，反复和我强调「向上管理」。
或许上司对产品新人来说，像是一种权威、严肃、面无表情的「怪兽」哈哈，比较幸运是能遇到像朋友一样的导师，但是我们更应该去思考，如何做好「向上管理，积极反馈」。
我的做法是：
在这本书的最后，Marty Cagan给出了一份产品经理的反省清单。从产品价值、产品设计、到产品管理、团队管理，都是我们每个人都需要去思考的问题。所以其实虽然人人都是产品经理，但做出好产品真的是难于登天呀！
最后我认为作者在「寻找出色的产品经理」中说的很对的一点，也是给自己今后从初级到高级产品的掌握能力，如下所述：最宝贵的经验不是行业知识或技术(这些都可能过时)，而是打造优秀产品的流程、领导产品团队的能力、应对产品扩张的经验、个人对自己的认知，以及自我激励的能力。
文章来源：人人都是产品经理 作者：莫琳
蓝蓝设计( www.lanlanwork.com )是一家专注而深入的界面设计公司，为期望卓越的国内外企业提供卓越的UI界面设计、BS界面设计 、 cs界面设计 、 ipad界面设计 、 包装设计 、 图标定制 、 用户体验 、交互设计、 网站建设 、平面设计服务