邱岳的产品手记
邱岳
无码科技产品经理,公众号二爷鉴书作者
立即订阅
9950 人已学习
课程目录
已完结 48 讲
0/4登录后,你可以任选4讲全文学习。
开篇词 | 产品经理的世界没有对错
免费
01 | 验证码是个好设计吗?
02 | 产品经理工具指南
03 | 产品案例分析·Trigraphy的设计哲学
04 | 如何当好AI时代的产品经理?(学习篇)
05 | 如何当好AI时代的产品经理?(实践篇)
06 | 产品案例分析 · The Guardian的文本之美
07 | 关于需求变更(上):需求背后的需求
08 | 关于需求变更(下) : 化变更于无形
09 | 产品案例分析:Hopper的“人工智能”
10 | 产品被抄袭了,怎么办?
11 | 如何借鉴灵感?
12 | 产品案例分析:LabRdr的设计实验
13 | 无用却必要:产品规划(上)
14 | 留白与节奏:产品规划(下)
15 | 产品案例分析:Mimo与Learn Python的导学之趣
16 | 在内部产品中找到产品经理的价值
17 | 产品经理如何获得非权力性的影响力?
18 | 产品案例分析:WWF Together的情怀设计
19 | 产品经理如何与开发打交道(上):打破思维的边界
20 | 产品经理如何与开发打交道(下):合作与共赢
21 | 产品案例分析:Fabulous的精致养成
22 | 产品经理的图文基本功(上):产品文档
23 | 产品经理的图文基本功(下):产品图例
24 | 产品案例分析:PathSource的混乱与直观
25 | 产品世界的暗黑模式:操纵的诱惑
26 | 写好产品文档的诀窍
27 | 产品案例分析:Quartz&Hooked的对话式交互
28 | 产品分析的套路(上):谁是利益相关者?
29 | 产品分析的套路(中):解决什么问题?
30 | 产品案例分析:Primer的扑克牌交互
31 | 产品分析的套路(下):如何出解决方案?
32 | 从受众规模、需求频率和强度出发:排定需求优先级的方法(上)
33 | 产品案例分析:Arts & Culture 的架构之美
34 | 价值曲线分析:排定需求优先级的方法(下)
35 | 答疑时间:关于产品经理的12个问题
36 | 产品案例分析:解读知识星球
37 | 如何做好需求评审(上):需求评审不只是一次会议
38 | 如何做好需求评审(下):在评审中控住全场
39 | 产品案例分析:SeatGeek的订票设计
40 | 新年给产品经理的几碗鸡汤
41 | 产品经理的项目管理心得
42 | 产品案例分析:Unread的阅读体验
43 | “玩”的力量:从游戏设计中学习产品设计(上)
44 | “玩”的启示:从游戏设计中学习产品设计(下)
45 | 产品案例分析:Chartistic的“复杂”图表
尾声:你的快乐是哪一种
【第二季回归】二爷归来,再次扬帆起航
邱岳的产品手记
登录|注册

29 | 产品分析的套路(中):解决什么问题?

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

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

产品要做的任何事情,都应该围绕着某一个或某几个利益相关者的具体问题来展开。很多产品经理在这里投入的精力和时间是不够的,大家更喜欢花时间在解决方案上,也就是后面会提到的“用什么方法”上面。这样不妥,应该在理解谁的问题,什么问题之后,才去想解决方案。
这种错误也被称作 X-Y Problem,也就是,我们希望解决 X 问题,然后想到了 Y 方案,随后把所有的精力放在 Y 这个解决方案上,而忽略了对要解决问题本身的理解。 映射到我们的日常工作中,产品经理接到的需求通常不是真正意义上的“需求”,而是提出需求的人,基于某一个需求提出的“解决方案”。
我们举一个例子,比如用户提出所谓的需求——“希望增加收藏功能”,如果你只是拿到这个所谓的需求,画个原型,让开发做出来,那么你最多是一个需求翻译和分发的机器,而不是一个产品经理。
正确的做法应该是:把类似的所谓需求当做一个线索,抓住这个线索不断地向上追问背后的需求动机和需要被解决的问题。我们之前关于需求变更的分享中曾经提到利用“五问法”,来挖掘需求背后的需求,就是穿过解决方案抵达问题本质的好办法。
比如关于收藏,不同形态产品的收藏功能背后要解决的问题是不同的,浏览器的收藏可能是为了重复访问,所以演化为书签;阅读工具的收藏可能是为了日后检索,所以需要准备标签和检索功能;社区的收藏有索引和聚合功能,所以很多社区的收藏增加了发布和分享功能,成了另一种 UGC。
取消
完成
0/1000字
划线
笔记
复制
© 版权归极客邦科技所有,未经许可不得传播售卖。 页面已增加防盗追踪,如有侵权极客邦将依法追究其法律责任。
该试读文章来自付费专栏《邱岳的产品手记》,如需阅读全部文章,
请订阅文章所属专栏。
立即订阅
登录 后留言

精选留言(10)

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

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

    2018-02-02
    4
  • 刘祯
    今天在讨论直播新需求时,我突然发现之前的想法都过于关注解决方案本身,思维就容易陷入其中,只盯着问题,想要让更多订场用户了解智能服务,可是要加上创建直播功能就不符合我们最初要解决的问题。

    静下心来去思考这个需求背后的逻辑,其实可以通过更多运营或是页面表现优先级上的区分来强调新功能,并且辐射更广。转念焕然开朗。

    这些天也在同样进行用户和产品分析,解决方案可以无穷无尽,然而最为关键的还是问题以及对应的场景。
    2018-01-25
    4
  • GeekAmI
    这就是腾讯提倡的每周拜访1000个用户,抖音提倡的“离用户近一点、再近一点”
    2018-01-25
    4
  • 罗帅
    产品经理接到的需求通常不是真正意义上的“需求”,而是提出需求的人,基于某一个需求提出的“解决方案
    2018-05-11
    3
  • 拾叔
    二爷说的对,每一个用户需求其实都应该按照这个思路去处理,先问清楚需求的本质是啥,很多时候也许你觉得是这个原因,但是实际上,用户深层次的原因很有可能不一样,甚至都有可能会相反,不理清问题就出方案,可能南辕北辙。

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

    2018-02-01
    3
  • yaxin
    问题,归根到底就是产品的真实需求,而不是使用者直接提供的解决方案,这就需要产品经理一步步刨根问底了。
    想起刚工作时,老板给我们的一个要求就是没事多使用自己开发的产品。但多数同事对这种要求很排斥,理由是白天一天都在搞这个,下班了还搞,太无聊了。工作这么多年才明白老板的初衷,他可能希望员工深入产品,作为产品的直接使用者,发现产品中不合理的地方,也就是邱哥说的"共情"能力。
    邱哥最后一段我也深有感触,很多领域的知识其实都是相通的,相互间都有可以借鉴的地方。
    2018-11-12
    1
  • 雪甫
    说下刚刚经历的一个事。后台系统,有个B功能是A的后续。A功能会展示一个页面,用户点击确认后进入B功能,B功能也是展示一份一样的信息的页面,上传一些附件后,再次确认。A和B有较大可能是一个人进行操作。A有可能被系统自动确认。这样的场景下,我觉得设计成一个功能2个操作是很自然的事。我们的PM设计成2个功能就算了,把B功能的上传附件嵌入A的列表页,却又不提供从A到B的直接跳转;B功能的上传也放在B的列表也,却需要点到B的详情页去确认! 完全没用脑子在做交互的感觉。关键还是个级别不低的PM。我就吐槽一下,我怕憋不住打人!
    2018-01-29
    1
  • Dylan
    对需求方和需求有一个把握,感谢老师提了个醒
    2018-07-09
  • 罗帅
    产品经理接到的需求通常不是真正意义上的“需求”,而是提出需求的人,基于某一个需求提出的“解决方案
    2018-05-11
收起评论
10
返回
顶部