叮嘟！这里是小啊呜的产品进阶读书笔记整理。好记性不如烂笔头，今天也是努力进步的一天。一起加油进阶吧！

一、今日阅读计划

第28讲 产品分析的套路（上）：谁是利益相关者？

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

二、泛读&知识摘录

1、第28讲 产品分析的套路（上）：谁是利益相关者？

（1）“自小秦楼望巧，吴机回锦，歌舞为谁。”——（宋末）刘辰翁

（2）在面对这些琳琅满目的需求时，我们需要一个套路，对需求进行快速地分析和决策。

我自己常用的套路，就是反复地思考一句话：
“用什么方法，解决谁的，什么问题”。

其中三个关键点分别是：“用什么方法” “谁的” 以及 “什么问题”。
这三个问题的思考顺序应该是：“谁的”、“什么问题”，最后才是“用什么方法”

（3）利益相关者，不只用户。

Stake Holder、涉众。

比如在电商领域中，我们要关注作为产品上游的供应商、仓储、物流等等。
比如，在医疗行业中，可能有患者、医生、医院、药企甚至一些学会和机构等等，都是我们需要关注的利益相关者。

（4）当评估整个产品的效率和盈利能力时，我们还要学会 站在投资者的角度 去看问题。

这是一个很大的话题，从投资者角度所关注的具体指标去看产品、服务，是一个产品经理有没有完成进阶的标志。

投资者关注的或许不仅仅是财务指标，还有整个产品的健康程度和存续指标。

比如一款工具的日启、日活、留存、传播，或者社区型产品的用户数量，用户之间的关系数量等。

（5）产品经理的 “共情能力”，其实指的是对 用户立场和偏好 的深刻理解，理解他们的关注点，并把它们变成指标。

这个过程有一些工具，比如做用户角色分析（persona）、关键人物地图等等，它们是做用户研究的一些基本功。

这些对角色的理解除了对单一功能点的分析很有价值之外，也对合理排定需求优先级有决定性的影响。

（6）不论是用户还是其他利益相关者，我们需要了解他们对哪些事情最为关心，不同的角色关心的指标或许会有关联，甚至有矛盾，产品经理要在其中做出 平衡和决策。

（7）To B 和 To C 的不同决策方式。

通常面向消费者的产品（To C 类的产品）
考虑利益相关者的套路跟面向企业用户（To B 类产品），是相差很大的。

对于 To B 类用户，做出购买决定的人、影响决定的人和使用最终产品的人、甚至是掏钱的人可能都是不同的，
他们在购买决策链上的角色和作用，以及发生作用的时机也是不同的。 

To C 类产品通常是一人一票，只要打动一个用户，就会投一票，一票就是一个实打实的 deal。

（8）上下游特点与平台价值。

对于市场容量比较大的 B 端客户，我们的思考方式和市场容量比较小的 B 端客户也是不同的。

这里的市场容量指的不是财务市场的大小，而是玩家数量的多寡。
通常 B2B 平台型的产品会偏向于认为市场容量越大、越散，玩家越多，平台越有价值。

2、第29讲产品分析的套路（中）：解决什么问题？

（1）“能帮助我们完成进步的，恰恰是人类的天性本身。”——弗朗斯·德瓦尔《共情时代》

所有的产品和平台的存在，一定都是解决了一个或多个问题。

比如 Google 解决了搜索效率的问题、淘宝解决了买家购物效率的问题，还解决了卖家销售效率的问题。

（2）重视解决的问题，而不是解决的方案。

X-Y Problem，就是我们希望解决 X 问题，然后想到了 Y 方案，随后把所有的精力放在 Y 这个解决方案上，而忽略了对要解决问题本身的理解。 

映射到我们的日常工作中，产品经理接到的需求通常不是真正意义上的“需求”，而是提出需求的人，基于某一个需求提出的“解决方案”。

我们举一个例子，比如用户提出所谓的需求——“希望增加收藏功能”，如果你只是拿到这个所谓的需求，画个原型，让开发做出来，那么你最多是一个需求翻译和分发的机器，而不是一个产品经理。

正确的做法应该是：
把类似的所谓需求当做一个线索，抓住这个线索不断地向上追问背后的需求动机和需要被解决的问题。

比如关于收藏，不同形态产品的收藏功能背后要解决的问题是不同的。
浏览器的收藏可能是为了重复访问，所以演化为书签；
阅读工具的收藏可能是为了日后检索，所以需要准备标签和检索功能；
社区的收藏有索引和聚合功能，所以很多社区的收藏增加了发布和分享功能，成了另一种 UGC。

（3）把自己放进场景，吃“自己的狗粮”。

场景是需求的灵魂。

也就是我们在考虑需求时，不应该只是孤立地考虑功能逻辑，
而应该把这些功能和流程放到具体的用户使用上下文里面去。

把需求放在场景中考虑最好的办法是在脑海中把所有的功能过程演一遍，充分地把自己带入，把每个细节都摸到。
闭上眼一步步地演进，考虑具体利益相关人的情绪、关注点、好恶，以及所处的环境，所用的终端等等。

建议产品经理“吃自己的狗粮”，也就是成为自己产品的重度用户。

当你成为自己产品重度用户后，就压根不需要演的过程，不需要“带入”“模拟”或者“共情”之类的过程，
便可以全然沉浸在产品的使用场景中从而发现和理解问题。

（4）转益多师，加深对场景的理解。

图书推荐：《以图代言》

所有叙事类的文字形式都会关注场景的描述和构建，可以借鉴。

工具推荐：“服务设计” Service Design Tools

可以给出很多解决体验问题的思考框架。

Service Design Tools
设计 | Service Design 服务设计 读物推荐&资源分享

（5）有人说世界是不忿的懒人推进向前的，指的就是那些不断对现状表示不满，而且 不断试图用新的方案简化问题解决路径 的人。

所以当我们希望发现问题的时候，不妨激活自己不忿和混蛋的那一面，
做一个对现状找茬的人，会更容易发现问题。

三、头脑风暴

1、产品分析的套路（上）：谁是利益相关者？

他人启发1：品类扩展

针对桔子交易平台商家垄断的情况，平台完全可以顺势而为，平台可以借此机会向多品类平台发展。
依然给这家优质桔商造势，通过这个桔商作为入口，给其他品类的产品做导流。
平台可以卖其他水果，也可以卖水果相关产品，例如卖果盆，卖榨汁机等等。
就像一个商场，用户买完了桔子，看到有苹果也会带一些回家的。

借势发展比逆势压制来的好。

他人启发2：

“谁”的问题，也可以翻译成是“从更高的角度看待自己接到的需求”。

如果从更高的角度来靠自己的需求，那需求的优先级甚至产品方案都可能会有不同。

拿我自己做内容监控产品来说，我的需求方是监控团队，我只接他们的需求。
但是在接到需求和将需求转化为产品方案的这两个阶段中间，还需要考虑运营侧的情况，运营侧的同学也需要评估监控需求的影响情况。

原因是在公司内部，监控和运营在很多情况下会存在矛盾，监控一定是希望管的越严越好，
但是运营却希望不用太管用户，让用户有更好的自由度也是为了促进平台氛围的活跃度。

所以在规划监控需求的时候，我们需要和运营一起讨论产品的生效尺度如何才能最小程度的影响用户体验。
这是在日常情况下通常进行的步骤。

但是在一些特殊日子里，一切都以监控为优先，甚至愿意为此牺牲很大的用户体验。

所以做一个产品或者功能，既要考虑直接需求方，同事也要考虑相关利益方，再高一点，还得考虑国家政策和市场情况。

“总体来说，不管是基金经理还是研究员，或是刚入行的年轻人，都要形成思考大问题的习惯。”
产品经理也是类似。

他人启发3：

应该是用平台的规则和制度来限制垄断，维护上下游的分散，保持平台价值存续。
如果一个平台中的一个商户一家独大，其实是违背了作为平台多样化的本质，
将会产生很多垄断本身带来的负面影响。

他人启发4：

其实这个情况和最近的淘宝限流爆款的思路是一致的。
先从平台的角度想，小池柑橘能做到10%的用户的话，实际上已经是非常严重的影响了平台流量的流向了，可以和小池签约，从平台导流，向多样化发展。

但是这里分为两种情况。
第一种：
小池知道自己已经成为平台的主导，用户的意愿是直接来买小池柑橘，这时候对于平台来说就很可怕了。
如果它走了，那么势必带走大量的用户，这时候平台需要考量以及签约合同。
绑定小池，然后发展多样性。
（这就很尴尬了，主动权不在自己手里，但是唯一的好处是他现在在这个平台建立起的信用体系。
如果直接搬走去其他平台，也会给它带来损失，所以它也必然不会贸然的更换平台，除非它的利益受到了极大的伤害。）


第二种：
小池不确定自己是否成为平台主导，这时候可行的方式是限流。
（但也不宜过多，因为如果多了，必然会转移其他平台，甚至自己建立平台，多一个竞争对手，而且这个竞争对手口碑还非常好。）
并且扶持另外一个甚至两个供应商，并且进行签约导流和宣传扶持，让第一名误以为自己不是主导地位，从而进行橘子的多样性发展，以及竞争优势。
然后再和小池签约，让对方觉得我们也有意扶持他，从而拖近关系，又能保持着多样性的情况下，还能把小池继续留在平台里，既定平台的主导地位。
（这个方法虽然不厚道，但是站在利益方，恐怕也都愿意这么做吧）

2、你是如何发现问题，尤其是如何发现那些你并不了解的人面临的问题？

他人启发1：

总的来说，就是需求方知道自己要干嘛，但是他们不知道自己要什么。

还是拿我自己在工作中的经历来说，有一次需求方跑来跟我说他要一个白名单功能，这个时候他要的就是一个字面上理解的白名单功能.

但是在后续的沟通中，他渐渐说明白了他的最终目的是能够更灵活的监控某些用户，
对某些用户或者选择相信而无需审核，或者重点审核。

所以总结起来，他是要一个对用户打标签的标签管理系统，用过标签的不同，既可以支持白名单功能，也可以支持灰名单功能，还可以支持黑名单功能，当然后续还可以支持其他的特殊要求。

需求方说能不能在后台的这个页面上显示更多的用户信息，能够通过用户信息来辅助内容的审核，沟通之后就会发现，其实他要的是一个CRM系统。

通过更多的沟通和分析，可以将需求方提出的各种看似割接的需求通过系统化的方式去解决。
通过实现单个功能背后的系统化目标来做方案，也是能大大提高产品的持续适应性和拓展性。

当然这个时候还需要考虑公司内部的技术资源的支持能力。
不过总归大方向确定了，再规划单个方案，行动起来也会更有连贯性。

他人启发2：

这就是腾讯提倡的每周拜访1000个用户，抖音提倡的“离用户近一点、再近一点” 。

他人启发3：

前端时间就遇到客户说想要一个点赞功能，后来聊了发现，他想要的是内容社交。
但是做项目跟做自己产品不一样，项目根据时间/人力成本来。

后来领导也说：需求已经确认了，就不要调整了，有点无力感。

想要知道更多关于项目产品与做自己产品的区别，
发现做项目一开始没规划好，项目后期很难做好了，任何改动都会被视为成本。

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

他人启发4：

问题，归根到底就是产品的真实需求，而不是使用者直接提供的解决方案，这就需要产品经理一步步刨根问底了。

想起刚工作时，老板给我们的一个要求就是没事多使用自己开发的产品。

但多数同事对这种要求很排斥，理由是白天一天都在搞这个，下班了还搞，太无聊了。
工作这么多年才明白老板的初衷，他可能希望员工深入产品，作为产品的直接使用者，发现产品中不合理的地方，也就是"共情"能力。

很多领域的知识其实都是相通的，相互间都有可以借鉴的地方。

Ending！
更多阅读笔记记录随后再来吧！

就酱，嘎啦！

注：
人生在勤，不索何获。