极客时间已完结课程限时免费阅读

29 | 产品分析的套路（中）：解决什么问题？

29 | 产品分析的套路（中）：解决什么问题？-极客时间

29 | 产品分析的套路（中）：解决什么问题？

2018-01-25 邱岳 来自北京
《邱岳的产品手记》
课程介绍

讲述：邱岳

时长10:16大小4.70M

“能帮助我们完成进步的，恰恰是人类的天性本身。”——弗朗斯·德瓦尔《共情时代》
上次我们提到产品分析时的套路就是反复思考：“用什么方法，解决谁的什么问题”，思考的路径应当是先考虑利益相关者，再考虑问题和方法。之前我们分享了如何对利益相关者进行列举和分析，今天我们来关注第二点：“解决什么问题？”
搞清楚相关人都是谁之后，我们要考虑的第二个点就是“解决什么问题”。所有的产品和平台的存在，一定都是解决了一个或多个问题。比如 Google 解决了搜索效率的问题、淘宝解决了买家购物效率的问题，还解决了卖家销售效率的问题。

重视解决的问题，而不是解决的方案

产品要做的任何事情，都应该围绕着某一个或某几个利益相关者的具体问题来展开。很多产品经理在这里投入的精力和时间是不够的，大家更喜欢花时间在解决方案上，也就是后面会提到的“用什么方法”上面。这样不妥，应该在理解谁的问题，什么问题之后，才去想解决方案。
这种错误也被称作 X-Y Problem，也就是，我们希望解决 X 问题，然后想到了 Y 方案，随后把所有的精力放在 Y 这个解决方案上，而忽略了对要解决问题本身的理解。 映射到我们的日常工作中，产品经理接到的需求通常不是真正意义上的“需求”，而是提出需求的人，基于某一个需求提出的“解决方案”。
我们举一个例子，比如用户提出所谓的需求——“希望增加收藏功能”，如果你只是拿到这个所谓的需求，画个原型，让开发做出来，那么你最多是一个需求翻译和分发的机器，而不是一个产品经理。
正确的做法应该是：把类似的所谓需求当做一个线索，抓住这个线索不断地向上追问背后的需求动机和需要被解决的问题。我们之前关于需求变更的分享中曾经提到利用“五问法”，来挖掘需求背后的需求，就是穿过解决方案抵达问题本质的好办法。
比如关于收藏，不同形态产品的收藏功能背后要解决的问题是不同的，浏览器的收藏可能是为了重复访问，所以演化为书签；阅读工具的收藏可能是为了日后检索，所以需要准备标签和检索功能；社区的收藏有索引和聚合功能，所以很多社区的收藏增加了发布和分享功能，成了另一种 UGC。

把自己放进场景，吃“自己的狗粮”

另外，在理解各种利益相关者的需求动机，尤其是用户的需求动机的过程中，有一个非常重要的概念叫做“场景”。我们常说场景是需求的灵魂。也就是我们在考虑需求时，不应该只是孤立地考虑功能逻辑，而应该把这些功能和流程放到具体的用户使用上下文里面去。
场景这个词来源于戏剧和电影，包含了时间、空间、角色等等许多因素。在考虑功能特性的时候，我们得把自己放到实际场景中去。
我之前经常给同事举过一个例子，就是现在很多 ATM 机是有免卡操作功能的，你可以不用带银行卡就能取款或者查询余额。结果有这样功能的 ATM 机很多时候是锁在一个必须刷卡才能打开的 24 小时银行房间里的。我们试着去模拟一下这个过程，到细节里面去，在脑子里演一遍，就会发现问题。
把需求放在场景中考虑最好的办法是在脑海中把所有的功能过程演一遍，充分地把自己带入，把每个细节都摸到。闭上眼一步步地演进，考虑具体利益相关人的情绪、关注点、好恶，以及所处的环境，所用的终端等等。
我们一般认为，为自己做一款产品是一件相对容易的事情，许多做产品的书也提到建议产品经理“吃自己的狗粮”，也就是成为自己产品的重度用户。
这是因为当你成为自己产品重度用户后，就压根不需要演的过程，不需要“带入”“模拟”或者“共情”之类的过程，便可以全然沉浸在产品的使用场景中从而发现和理解问题。
这里有一个有趣的概念叫“共情”，共情也叫“移情”或者“投情”，大概就是“设身处地”“感同身受”的意思。
一个很著名的研究动物和心理学的科学家弗朗斯·德瓦尔有一本书叫做《共情时代》，把共情这个事情做了很深的剖析和解释，他认为共情是人甚至动物的本能。这跟达尔文和道金斯的观点其实是有些相悖的，是一本很有意思的书，也是一本挺温暖的书，在这里顺手做一个推荐。

转益多师，加深对场景的理解

另外，关于场景的理解，我还推荐大家可以去看一些编剧相关的书，看看编剧是如何构建和表述一个场景的。甚至是一些漫画书，我曾经在公众号中介绍过一本叫做《以图代言》的书，你在有空的时候，也可以去看看，总之所有叙事类的文字形式都会关注场景的描述和构建，可以借鉴。
之前在聊对利益相关者分析的时候，我们提到过用户角色分析、关键人物地图，这些都是来自于一个叫做“服务设计”领域的工具，这些工具可以给出很多解决体验问题的思考框架，在理解场景的时候，我们可能还会用到其中比如用户体验地图、服务路径、问题卡片之类的工具。
对于服务设计，专业做用户研究的人应该会有更深刻的理解，我也只是知道一点皮毛，你如果感兴趣的话，可以去网上搜“服务设计工具”，或者搜英文 Service Design Tools，找一些相关的东西来看，这里有个网站可以作为索引。
对于除了用户之外的其他利益相关者，比如投资人，供应商等等角色，最好的办法也是把自己放到他们的角色上，了解他们每天的工作、绩效考核标准、最关注的事情、最怕的事情等等。就像了解男女朋友那样了解这些利益相关者，最终才能做出全盘的平衡。
有时候我们因为习惯了某种流程，所以并不觉得流程中存在问题，比如我们在专栏开始时聊到关于验证码的分析，当我们都习以为常的时候，问题可能就会被掩盖。
有人说世界是不忿的懒人推进向前的，指的就是那些不断对现状表示不满，而且不断试图用新的方案简化问题解决路径的人。所以当我们希望发现问题的时候，不妨激活自己不忿和混蛋的那一面，做一个对现状找茬的人，会更容易发现问题。
好了，我们这次的分享就到这里，接着上一篇对利益相关者的分析，这一篇我聊到了如何针对不同利益相关者去发现问题的一些方法和方向，不妨在留言中说说你是如何发现问题，尤其是如何发现那些你并不了解的人面临的问题，我们下次再见。
分享给需要的人，Ta购买本课程，你将得18元
生成海报并分享

赞 10

提建议

© 版权归极客邦科技所有，未经许可不得传播售卖。 页面已增加防盗追踪，如有侵权极客邦将依法追究其法律责任。
上一篇
28 | 产品分析的套路（上）：谁是利益相关者？
下一篇
30 | 产品案例分析：Primer的扑克牌交互
unpreview
 写留言

精选留言(12)

  • Charles tong
    2018-01-26
    感谢邱哥的分享。总的来说，就是需求方知道自己要干嘛，但是他们不知道自己要什么。还是拿我自己在工作中的经历来说，有一次需求方跑来跟我说他要一个白名单功能，这个时候他要的就是一个字面上理解的白名单功能，但是在后续的沟通中，他渐渐说明白了他的最终目的是能够更灵活的监控某些用户，对某些用户或者选择相信而无需审核，或者重点审核。所以总结起来，他是要一个对用户打标签的标签管理系统，用过标签的不同，既可以支持白名单功能，也可以支持灰名单功能，还可以支持黑名单功能，当然后续还可以支持其他的特殊要求。 需求方说能不能在后台的这个页面上显示更多的用户信息，能够通过用户信息来辅助内容的审核，沟通之后就会发现，其实他要的是一个CRM系统。 通过更多的沟通和分析，可以将需求方提出的各种看似割接的需求通过系统化的方式去解决，通过实现单个功能背后的系统化目标来做方案，也是能大大提高产品的持续适应性和拓展性。 当然这个时候还需要考虑公司内部的技术资源的支持能力。不过总归大方向确定了，再规划单个方案，行动起来也会更有连贯性。
    展开
    20
  • 罗帅
    2018-05-11
    产品经理接到的需求通常不是真正意义上的“需求”，而是提出需求的人，基于某一个需求提出的“解决方案
    13
  • Bonnie Mei
    2018-02-02
    前端时间就遇到客户说想要一个点赞功能，后来聊了发现，他想要的是内容社交，但是做项目跟做自己产品不一样，项目根据时间/人力成本来，后来领导也说：需求已经确认了，就不要调整了，😭😭，有点无力感。 二爷，能否抽时间，说说做项目产品与做自己产品的区别，发现做项目一开始没规划好，项目后期很难做好了，任何改动都会被视为成本

    作者回复: 项目型产品更像生意，关键是成本控制，不是真的在「做产品」

    10
  • 拾叔
    2018-02-01
    二爷说的对，每一个用户需求其实都应该按照这个思路去处理，先问清楚需求的本质是啥，很多时候也许你觉得是这个原因，但是实际上，用户深层次的原因很有可能不一样，甚至都有可能会相反，不理清问题就出方案，可能南辕北辙。

    作者回复: 👍 我也做得不够好，还是要不断提醒自己

    6
  • 听天由己
    2018-01-25
    今天在讨论直播新需求时，我突然发现之前的想法都过于关注解决方案本身，思维就容易陷入其中，只盯着问题，想要让更多订场用户了解智能服务，可是要加上创建直播功能就不符合我们最初要解决的问题。 静下心来去思考这个需求背后的逻辑，其实可以通过更多运营或是页面表现优先级上的区分来强调新功能，并且辐射更广。转念焕然开朗。 这些天也在同样进行用户和产品分析，解决方案可以无穷无尽，然而最为关键的还是问题以及对应的场景。
    展开
    共 1 条评论
    6
  • GeekAmI
    2018-01-25
    这就是腾讯提倡的每周拜访1000个用户，抖音提倡的“离用户近一点、再近一点”
    5
  • 罗帅
    2018-05-11
    产品经理接到的需求通常不是真正意义上的“需求”，而是提出需求的人，基于某一个需求提出的“解决方案
    3
  • 雪甫
    2018-01-29
    说下刚刚经历的一个事。后台系统，有个B功能是A的后续。A功能会展示一个页面，用户点击确认后进入B功能，B功能也是展示一份一样的信息的页面，上传一些附件后，再次确认。A和B有较大可能是一个人进行操作。A有可能被系统自动确认。这样的场景下，我觉得设计成一个功能2个操作是很自然的事。我们的PM设计成2个功能就算了，把B功能的上传附件嵌入A的列表页，却又不提供从A到B的直接跳转；B功能的上传也放在B的列表也，却需要点到B的详情页去确认！ 完全没用脑子在做交互的感觉。关键还是个级别不低的PM。我就吐槽一下，我怕憋不住打人！
    展开
    3
  • Marnie
    2018-11-12
    问题，归根到底就是产品的真实需求，而不是使用者直接提供的解决方案，这就需要产品经理一步步刨根问底了。 想起刚工作时，老板给我们的一个要求就是没事多使用自己开发的产品。但多数同事对这种要求很排斥，理由是白天一天都在搞这个，下班了还搞，太无聊了。工作这么多年才明白老板的初衷，他可能希望员工深入产品，作为产品的直接使用者，发现产品中不合理的地方，也就是邱哥说的"共情"能力。 邱哥最后一段我也深有感触，很多领域的知识其实都是相通的，相互间都有可以借鉴的地方。
    展开
    1
  • 罗伟
    2021-01-27
    从二爷的文章可以看出二爷做的产品肯定是很具人情味的
  • JianXu
    2020-12-07
    1. 深入了解需求本质，把大部分时间花在想清楚本质上这一点跟5个Why 是一致的，往往一开始的需求并不是真正的需求。2. 产品经理需要成为自己产品的重度用户，这样才能帮助自己更有代入感。我从来没有想过学习编剧和做产品经理有相通的地方，这一点值得学习。3. 很多固有思维如何打破的问题，习以为常的流程不一定就是对的，思维方法是相信任何东西都有改进的空间。这一点我觉得很锻炼思考力。因为意识不到，突破自己很难的，希望老师能给一些建议。
    展开
  • Dylan
    2018-07-09
    对需求方和需求有一个把握，感谢老师提了个醒