邱岳的产品手记
邱岳
无码科技产品经理,公众号二爷鉴书作者
33999 人已学习
新⼈⾸单¥59
登录后,你可以任选4讲全文学习
课程目录
已完结/共 49 讲
邱岳的产品手记
15
15
1.0x
00:00/00:00
登录|注册

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

激活自己不忿和混蛋的那一面
了解其他利益相关者的角色
理解用户角色
建议产品经理“吃自己的狗粮”
共情/移情/投情
场景是需求的灵魂
利用“五问法”挖掘需求背后的需求
理解需求背后的需求
X-Y Problem
转益多师,加深对场景的理解
把自己放进场景,吃“自己的狗粮”
重视解决的问题,而不是解决的方案
再考虑问题和方法
先考虑利益相关者
解决什么问题
反复思考:“用什么方法,解决谁的什么问题”
产品分析的套路

该思维导图由 AI 生成,仅供参考

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

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

产品要做的任何事情,都应该围绕着某一个或某几个利益相关者的具体问题来展开。很多产品经理在这里投入的精力和时间是不够的,大家更喜欢花时间在解决方案上,也就是后面会提到的“用什么方法”上面。这样不妥,应该在理解谁的问题,什么问题之后,才去想解决方案。
这种错误也被称作 X-Y Problem,也就是,我们希望解决 X 问题,然后想到了 Y 方案,随后把所有的精力放在 Y 这个解决方案上,而忽略了对要解决问题本身的理解。 映射到我们的日常工作中,产品经理接到的需求通常不是真正意义上的“需求”,而是提出需求的人,基于某一个需求提出的“解决方案”。
我们举一个例子,比如用户提出所谓的需求——“希望增加收藏功能”,如果你只是拿到这个所谓的需求,画个原型,让开发做出来,那么你最多是一个需求翻译和分发的机器,而不是一个产品经理。
正确的做法应该是:把类似的所谓需求当做一个线索,抓住这个线索不断地向上追问背后的需求动机和需要被解决的问题。我们之前关于需求变更的分享中曾经提到利用“五问法”,来挖掘需求背后的需求,就是穿过解决方案抵达问题本质的好办法。
比如关于收藏,不同形态产品的收藏功能背后要解决的问题是不同的,浏览器的收藏可能是为了重复访问,所以演化为书签;阅读工具的收藏可能是为了日后检索,所以需要准备标签和检索功能;社区的收藏有索引和聚合功能,所以很多社区的收藏增加了发布和分享功能,成了另一种 UGC。
确认放弃笔记?
放弃后所记笔记将不保留。
新功能上线,你的历史笔记已初始化为私密笔记,是否一键批量公开?
批量公开的笔记不会为你同步至部落
公开
同步至部落
取消
完成
0/2000
荧光笔
直线
曲线
笔记
复制
AI
  • 深入了解
  • 翻译
    • 英语
    • 中文简体
    • 中文繁体
    • 法语
    • 德语
    • 日语
    • 韩语
    • 俄语
    • 西班牙语
    • 阿拉伯语
  • 解释
  • 总结

产品分析的套路是一个重要的技术,本文通过弗朗斯·德瓦尔的《共情时代》引言,引出了产品分析的核心思路:“用什么方法,解决谁的什么问题”。文章强调了在产品分析中要重视解决的问题,而不是解决的方案,避免陷入X-Y Problem的误区。此外,文章还强调了将自己放入场景中,吃“自己的狗粮”,以及通过共情和移情的方式深入理解用户需求动机和场景。作者还建议读者多师转益,加深对场景的理解,推荐了一些相关的书籍和工具。整体而言,本文强调了在产品分析中要注重问题本身,深入理解用户需求和场景,以及不断寻找问题并提出新的解决方案的重要性。

仅可试看部分内容,如需阅读全部内容,请付费购买文章所属专栏
《邱岳的产品手记》
新⼈⾸单¥59
立即购买
登录 后留言

全部留言(12)

  • 最新
  • 精选
  • Bonnie Mei
    前端时间就遇到客户说想要一个点赞功能,后来聊了发现,他想要的是内容社交,但是做项目跟做自己产品不一样,项目根据时间/人力成本来,后来领导也说:需求已经确认了,就不要调整了,😭😭,有点无力感。 二爷,能否抽时间,说说做项目产品与做自己产品的区别,发现做项目一开始没规划好,项目后期很难做好了,任何改动都会被视为成本

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

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

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

    2018-02-01
    6
  • Charles tong
    感谢邱哥的分享。总的来说,就是需求方知道自己要干嘛,但是他们不知道自己要什么。还是拿我自己在工作中的经历来说,有一次需求方跑来跟我说他要一个白名单功能,这个时候他要的就是一个字面上理解的白名单功能,但是在后续的沟通中,他渐渐说明白了他的最终目的是能够更灵活的监控某些用户,对某些用户或者选择相信而无需审核,或者重点审核。所以总结起来,他是要一个对用户打标签的标签管理系统,用过标签的不同,既可以支持白名单功能,也可以支持灰名单功能,还可以支持黑名单功能,当然后续还可以支持其他的特殊要求。 需求方说能不能在后台的这个页面上显示更多的用户信息,能够通过用户信息来辅助内容的审核,沟通之后就会发现,其实他要的是一个CRM系统。 通过更多的沟通和分析,可以将需求方提出的各种看似割接的需求通过系统化的方式去解决,通过实现单个功能背后的系统化目标来做方案,也是能大大提高产品的持续适应性和拓展性。 当然这个时候还需要考虑公司内部的技术资源的支持能力。不过总归大方向确定了,再规划单个方案,行动起来也会更有连贯性。
    2018-01-26
    20
  • 罗帅
    产品经理接到的需求通常不是真正意义上的“需求”,而是提出需求的人,基于某一个需求提出的“解决方案
    2018-05-11
    13
  • 听天由己
    今天在讨论直播新需求时,我突然发现之前的想法都过于关注解决方案本身,思维就容易陷入其中,只盯着问题,想要让更多订场用户了解智能服务,可是要加上创建直播功能就不符合我们最初要解决的问题。 静下心来去思考这个需求背后的逻辑,其实可以通过更多运营或是页面表现优先级上的区分来强调新功能,并且辐射更广。转念焕然开朗。 这些天也在同样进行用户和产品分析,解决方案可以无穷无尽,然而最为关键的还是问题以及对应的场景。
    2018-01-25
    1
    7
  • GeekAmI
    这就是腾讯提倡的每周拜访1000个用户,抖音提倡的“离用户近一点、再近一点”
    2018-01-25
    5
  • 罗帅
    产品经理接到的需求通常不是真正意义上的“需求”,而是提出需求的人,基于某一个需求提出的“解决方案
    2018-05-11
    3
  • 雪甫
    说下刚刚经历的一个事。后台系统,有个B功能是A的后续。A功能会展示一个页面,用户点击确认后进入B功能,B功能也是展示一份一样的信息的页面,上传一些附件后,再次确认。A和B有较大可能是一个人进行操作。A有可能被系统自动确认。这样的场景下,我觉得设计成一个功能2个操作是很自然的事。我们的PM设计成2个功能就算了,把B功能的上传附件嵌入A的列表页,却又不提供从A到B的直接跳转;B功能的上传也放在B的列表也,却需要点到B的详情页去确认! 完全没用脑子在做交互的感觉。关键还是个级别不低的PM。我就吐槽一下,我怕憋不住打人!
    2018-01-29
    3
  • Marnie
    问题,归根到底就是产品的真实需求,而不是使用者直接提供的解决方案,这就需要产品经理一步步刨根问底了。 想起刚工作时,老板给我们的一个要求就是没事多使用自己开发的产品。但多数同事对这种要求很排斥,理由是白天一天都在搞这个,下班了还搞,太无聊了。工作这么多年才明白老板的初衷,他可能希望员工深入产品,作为产品的直接使用者,发现产品中不合理的地方,也就是邱哥说的"共情"能力。 邱哥最后一段我也深有感触,很多领域的知识其实都是相通的,相互间都有可以借鉴的地方。
    2018-11-12
    1
  • 罗伟
    从二爷的文章可以看出二爷做的产品肯定是很具人情味的
    2021-01-27
收起评论
显示
设置
留言
12
收藏
沉浸
阅读
分享
手机端
快捷键
回顶部