《从点子到产品：产品经理的价值观与方法论》读后感

从点子到产品：产品经理的价值观与方法论

刘飞
36个想法

第1章 点子与方案

创意是否能变成产品图

收费的思考

根据产品模型的特征可以匹配对应的赚钱模式。

流量可观的，一般都尝试用广告的方式；youtube

有高质量用户的，可以考虑发掘他们的付费意愿； 得到

有数据或者渠道价值的，看能否进一步向第三方提供服务。

商业模式

构件（Building Blocks），

它们可以描述公司创造收入的逻辑。这九个部分分别是客户细分、价值主张、渠道通路、客户关系、收入来源、核心资源、关键业务、重要合作，以及成本结构。

产品模型和商业模式的区别

有些内容可能在产品模型里也有探讨，但在考虑商业模式时，分析的角度会有所不同，

一个主要强调用户和市场上的逻辑合理性，另一个主要强调在经济和商业上的逻辑合理性。

对商业模式来说，还存在一个重要的问题：商业模式不只意味着怎么赚钱，还要考虑清楚怎么花钱。也就是说，盈利能够覆盖成本的模式才是合理的模式，仅仅有盈利不能算有效模式。

商业化合理程度

大部分的互联网产品都要考虑到用户获取成本（CPA）和用户活跃成本。也就是说，能够让用户愿意用自己的产品，这里要花费多少成本？能够让用户愿意留在自己的平台上并且愿意付费，需要花多少成本？这两个成本跟预期的收入之间的关系，就代表着商业模式的合理程度。

第2章 找到产品核心价值

用户体验设计模型

找出核心价值的原因：

第一，发现核心价值，能够选择综合考量下来最优的功能。

能够创造价值的功能很多，但核心价值意味着对产品来说，这样的功能性价比最高，或者是最受用户认可、最有商业价值、对公司最有利。

单一核心价值，吃喝玩乐尽在美团，搬家就找货拉拉，衣食住行。淘宝美团安居客飞猪

第二，基于相同的核心价值设计的功能，逻辑统一。

逻辑一致的功能可以互为补充，用户群体相似、需求也相似，能让价值产生增益。而零散的功能，成本高，往往吃力不讨好。

第三，有单一的核心价值能够让用户对产品产生认知。

想要依靠多种价值打动用户在初创阶段往往特别困难。产品起初强调核心价值和核心功能，可以让用户更理解这个产品能解决什么问题。很多产品是大杂烩，用户可能都发现不了自己想要的功能，因此很快就流失了。

运营目标和核心价值区别

产品经理关注的是真正解决用户的问题，而用户不够活跃，可能有多方面的原因，不能牺牲产品逻辑的一致性来完成运营目标。

就好像你卖家具并不是因为品质好，而是因为送礼品、玩花样、搞噱头，这样看起来数据好看、

第三章 MVP与痛点

MVP（Minimum Viable Product，最小可用产品）

它的目的是验证两件事：

一是产品满足了用户需求；二是产品能够创造商业价值。这恰好跟前文我们提到的，初创团队的产品经理应该探讨产品模型和商业模式对应。

MVP就是验证它们的手段。

产品从小做大，实现核心价值就可以上线，比如嘟嘟美甲。一开始支付模块和售后模块都是线下支付+客服人工处理。

第4章 深挖需求

关注真正诉求

产品经理不应只关心浮于表面的需要，而是要关心需求背后的真正诉求。

阿尔伯塔大学的一门关于软件设计的课程中，用Want（需要）和Needs （需求）来区分这两者，前者是“希望在产品中看到的功能”而后者是“确定的具体问题，留待产品解决的问题”。

福特汽车：你会说你想要更快的马，但我告诉你你需要一辆车。

人性需求，共情

大家在看这样的直播的时候，往往不是想获得很具体的知识、价值，也不是要得到什么快感和刺激，更多的就是想在别人的直播里体验另一种生活。

第5章 用户研究

用户研究分类。不要用主观好恶和假象自己是用户，投资行为也是不要自己是某一个行业就对某行业有信心，只要有投资价值就去追。哪怕它本身一文不值，比特币郁金香等

图5-1 常见的用户研究方法分类
在尝试接触用户、了解用户后，先不要着急去做用户研究。

事件漏斗

针对一项包含多步操作的功能，比如注册、登录或者下单，可以定义为事件并观察事件的完成情况，包括完成率及在每一步的跳出率。
定义事件漏斗是常见的分析功能优劣程度的方法，通过查看事件在大规模用户量上的完成情况，可以知道这个功能的问题主要出在哪里。对关键步骤的优化，效果就最明显。图5-4就是一个常见的电商平台下单的事件漏斗。

第6章 用户体验

产品内部逻辑的一致性

户的学习成本急剧增加。另外，也会让已经使用某个功能养成习惯的用户，在别的功能上突然不知所措。
比如，在社交产品中，关注你的人会被称为“粉丝”，在另一个页面又变成了“关注者”；在一些提醒对话框中，确定按钮有的时候在左侧，有的时候又在右侧；在工具类操作中，红色有时候表示正确，有时候又表示警告和提醒，等等。
之前我看到过一个例子是某打车软件的支付宝绑定提醒。在App界面上，文案写的是“回复验证码，即可绑定账号。”然而确认绑定时发来的短信里却是“您的验证码是0235，将此输入应用程序，确认账号。”估计所有用户都会疑惑：那么我到底是要输到哪里呢？

可恢复

而在新浪微博App中看某个人微博时，如果跳出再回去，又回到了微博列表的顶部。在这种情况下用户可能每次都会有想摔手机的冲动。
未来产品会越来越多，大家对信息接收的方式也不会满足于整块儿的形式，而是会变成以信息流、碎片化的方式为主。所以保护现场将是每个产品都要考虑的原则。

第7章 文档管理

三种逻辑关系
在功能设计中，需要有三种逻辑关系是特别清晰的。它们分别是功能框架的逻辑、业务流程的逻辑，以及功能描述的逻辑。

软件设计种。框架图，导图，流程图，顺序图可以帮开发者迅速了解软件体系。

第8章 需求管理

记录别人提出的需求

职级越高代表着身边人提需求的可能性越大。

初入行的产品专员或助理，主要是得到被安排的任务；

初级产品经理，需求来源主要是用户和上级；

产品负责人，需求来源还会有老板和其他相关部门；

而作为老板，谁都可能提产品需求。
所以在获取到需求这一刻，就必须做一个判断并且记录。如果不做判断，等做的时候根本没办法梳理出头绪，可能大部分时间都在疲于折腾需求清单。记录当然是为了方便回溯，获取到的再小的需求也记下来，不要指望你随时能想起来每天听过的每个需求。
判断需求的方法如下：
第一，判断需求本身的重要性。
同样是页面写错了一个字，把“登录”写成“登陆”和把“奖励15元”写成“奖励50元”，对不同问题的严重性要有一个大致的预估。

方案评审，不要出问题再讨论，

对于这种情况，各个流程中的环节都要做一些调整，才能确保最终产品方案的完整。
分析需求时，先梳理逻辑再出方案。能画流程图的画流程图，能画逻辑图的画逻辑图，能画脑图的画脑图，穷举整体的逻辑。
讨论方案时，所有产品经理参与小组讨论，一起提出疑惑，发现问题。
在做可行性评审时，技术人员要尽可能从逻辑角度提出质疑，多发现问题。

需求同步流程规范

图8-8 一种需求同步

第9章 工作流中的管理

与技术人员常规协作

与技术人员的常规协作
在第8章里，我们已经从需求管理的角度描述了跟技术人员之间需要协作的事项。其中可行性评审，以及后续的很多评审都是协作中的关键。
评审最重要的目的就是正式场合下的沟通，其意义在于：第一，确保产品经理对产品的要求传递给了技术人员；第二，确保技术部门的意见得到了表达；第三，双方对共同认可的内容予以确认。
缺了第一项，技术人员可能做错功能；缺了第二项，技术人员可能中途才发现问题，不得已返工；缺了第三项，最后出了事大家扯皮的时候可能发现不了问题，找不到源头。反思一下之前跟技术部门协作中出现的状况，是不是大多是这三种里面的一种呢？

开会的学问

会议通知邮件不要写成“各位，下午2点在会议室2开会，请大家按时出席”，这样是极糟糕的写法，完全可以做得更好，说清楚会议的主题和内容，以及大家需要提前准备的阅读材料。比如“各位，下午2点在会议室2召开‘校园群体用户需求讨论会’，希望大家提前做好准备，调研相关的信息。附件中有部分背景材料，推荐阅读。”
除了通知的内容翔实之外，还可以尽可能地与重要的参与者事先做一下沟通。尤其是比较重要的讨论会，预计会有很多矛盾和冲突要解决，如果提前能私底下达成基本共识，会上就能少费很多力气，因为毕竟在非正式的环境下氛围会轻松很多。
开会时最重要的是讲规则。规则有很多种，越多人参加的议题，越复杂的会议越需要规则。
最基本的规则有：
• 针对拟定的主题讨论，其他无关议题禁止讨论或者加会再讨论。
• 讲求发言顺序，不能争抢和吵闹，最好有主持人。
• 禁止人身攻击，避免太情绪化的讨论。
• 会议要对原定的主题输出结论，如果没有结论，要制定解决方案（比如由于信息不全面无法决定，要设立日期再议）。

需求流程化

我就遇到过一个印象深刻的例子，事情发生在跟业务部门协作时。起初我们提需求、安排需求的流程是空白的，也就是大家经常口头去提，甚至在哪天坐电梯碰上了，就随口一说，产品经理答应下来就着手去做。在刚开始需求不多、功能简单的情况下，倒没出什么大问题，但随着提的需求越来越复杂，参与协作的人越来越多，这么做就不合适了。经常出现我们做的功能他们不满意的情况，从他们的角度看，是我们产品部门不积极配合完成他们的需求，而从我们的角度看也很无辜，我们是按照他们的意思在按部就班地做。
后来针对跟业务部门的协作，我们制定了以下规范：
所有需求必须通过邮件提出。否则，不予理会。（目的：为了记录需求内容和明确责任人。）
业务方的需求提出者是固定的接口人，不接受其他人的需求。（目的：业务方过去经常在未达成内部一致的情况下提需求，造成麻烦。）
产品这边接收方也设立固定的接口人。（目的：防止需求重复设计、由一个人统筹外来的需求。）
需求的状态每周固定时间发布。（目的：让需求来源方放心，了解需求正在推进的状态。）
有延期的需求，发送邮件给相关需求方，告知原委。（目的：让需求方了解延期的原因。）
此后，虽然偶尔还是会发生少量的扯皮，但整体协作顺畅了很多，看似是多做了一些工作，但总的来说从实际上减轻了大家的负担。

自我管理。设定截止日期审视结果才能进步

不设截止日期

无论多么不紧急的事情，一定要设定截止日期。不然任何紧急的任务都可以插到前面，所有不紧急的任务都无限期地延后了。
对一个不紧急的任务设定了截止日期后，肯定不是马上开始动手做的。但快到它的截止日期时，这个任务就变成了紧急的、必须要完成的任务。我们都遇到过那种想学一个技能却拖来拖去发现最终干脆放弃了的经历，这就是因为我们根本没有规划、没有给截止日期造成的。

不检视效果

除了把充实感当成任务完成的标志之外，还要不断反思、复盘每件任务完成的效果是不是达到了目的，或者以怎样的程度完成了设想。跟前文提到的工作流程中的复盘一样，对自己处理事务的方式、方法也要有把控，把任务拆解开来找出做得不够好的地方，然后判断如何做得更好。
知识管理
知识管理指的是要把很多知识、信息记录在案，方便以后查阅。这是基于一个假设：我们不能记住全部所学、所见的知识。这个假设在我接触到的产品经理中是广泛存在的，大家都很少有天才般的过目不忘的能力，那么把接触到的有价值的信息记录下来就是必要的。

管理技能

技能足以服众。一定管理能力

在《领导梯队》里，作者提到了作为领导应具备的三个管理能力为：领导技能、时间管理和工作理念。
领导技能是指一些要修习的专业技能，包括制定团队规划、对团队成员的工作进行评估、营造好的工作氛围、为团队获取必要的资源，等等。
时间管理在上一节就提到了，对领导来说在关注个人事务的