“能帮助我们完成进步的，恰恰是人类的天性本身。”——弗朗斯·德瓦尔《共情时代》
重视解决的问题，而不是解决的方案
很多产品经理在这里投入的精力和时间是不够的，大家更喜欢花时间在解决方案上，也就是后面会提到的“用什么方法”上面。这样不妥，应该在理解谁的问题，什么问题之后，才去想解决方案。
映射到我们的日常工作中，产品经理接到的需求通常不是真正意义上的“需求”，而是提出需求的人，基于某一个需求提出的“解决方案”。
比如
用户提出所谓的需求——“希望增加收藏功能”，
如果你只是拿到这个所谓的需求，画个原型，让开发做出来，
那么你最多是一个需求翻译和分发的机器，
而不是一个产品经理。
正确的做法应该是：把类似的所谓需求当做一个线索，抓住这个线索不断地向上追问背后的需求动机和需要被解决的问题。我们之前关于需求变更的分享中曾经提到利用“五问法”，来挖掘需求背后的需求，就是穿过解决方案抵达问题本质的好办法。
比如
关于收藏，不同形态产品的收藏功能背后要解决的问题是不同的，
浏览器的收藏可能是为了重复访问，所以演化为书签；
阅读工具的收藏可能是为了日后检索，所以需要准备标签和检索功能；
社区的收藏有索引和聚合功能，所以很多社区的收藏增加了发布和分享功能，成了另一种 UGC。
把自己放进场景，吃“自己的狗粮”
在理解各种利益相关者的需求动机，尤其是用户的需求动机的过程中，有一个非常重要的概念叫做“场景”。
我们常说场景是需求的灵魂。
也就是我们在考虑需求时，不应该只是孤立地考虑功能逻辑，而应该把这些功能和流程放到具体的用户使用上下文里面去。
我之前经常给同事举过一个例子，
就是现在很多 ATM 机是有免卡操作功能的，你可以不用带银行卡就能取款或者查询余额。结果有这样功能的 ATM 机很多时候是锁在一个必须刷卡才能打开的 24 小时银行房间里的。我们试着去模拟一下这个过程，到细节里面去，在脑子里演一遍，就会发现问题。
把需求放在场景中考虑最好的办法是在脑海中把所有的功能过程演一遍，充分地把自己带入，把每个细节都摸到。闭上眼一步步地演进，考虑具体利益相关人的情绪、关注点、好恶，以及所处的环境，所用的终端等等。
转益多师，加深对场景的理解
另外，关于场景的理解，我还推荐大家可以去看一些编剧相关的书，看看编剧是如何构建和表述一个场景的。
甚至是一些漫画书，我曾经在公众号中介绍过一本叫做《以图代言》的书，你在有空的时候，也可以去看看，
总之所有叙事类的文字形式都会关注场景的描述和构建，可以借鉴。
之前在聊对利益相关者分析的时候，我们提到过用户角色分析、关键人物地图，这些都是来自于一个叫做“服务设计”领域的工具，
这些工具可以给出很多解决体验问题的思考框架，在理解场景的时候，我们可能还会用到其中比如用户体验地图、服务路径、问题卡片之类的工具。
对于除了用户之外的其他利益相关者，比如投资人，供应商等等角色，最好的办法也是把自己放到他们的角色上，
了解他们每天的工作、绩效考核标准、最关注的事情、最怕的事情等等。
就像了解男女朋友那样了解这些利益相关者，最终才能做出全盘的平衡。
网友评论