第一章：写给-1到3岁的产品经理
确定自己真的想做产品。这一点非常关键!
做产品的大前提是要喜欢做产品，不然将来你痛苦，团队痛苦，用户也痛苦。
你说自己喜欢产品，到底是喜欢做用户，还是喜欢 做产品经理?
产品经理需要绕过表象，从背后看问题的本质，思考怎么设计这个产品才能更好地平衡用户目标与商业目标。
找到自己的位置：
想入行，就要首先明确自己现在的位置。先在本职工作上找到与产品有关的事情做一些尝试，并且考虑先从产品经理周边的 职位做起。比如你是做开发的，那就经常要参与需求评审，不妨比别人多用点功，每次都预先了解需求，多多思考，然后在评审会上对需求提出自己的合理建议，时间长了大家都会觉得你很有想法，做产品也许不错。关于职位，可以从“需求分析师”切入，这有些像系统分析的工作，比如业务逻辑、流程图，都是你已经很熟悉的，你可以在这
个过程中慢慢培养商业的感觉，重点体会某个产品功能是为了满足商业上的什么需求而做的。
最后给大家介绍一个很 简单的办法——研究几十家公司的产品经理招聘广告。我一直觉得把研究结果做成一 份漂亮的调研报告，而后去应聘产品经理是个很靠谱的事，而且我相信大家多半都很 想读这样的一份报告，可惜还没见过有人这么做。
第2章 一个需求的奋斗史
首先说说“从用户中来到用户中去”，做任何产品都是一个端到端的过程，端即用 户，所以“用户是需求之源”，我们要拥有“以用户为中心的思想”，不断“体会真正 的用户”，于是，本章开始就会和大家“聊聊用户研究”。
然后我带着大家发起“需求采集的大生产运动”，与用户接触的过程就是需求采集 的过程，我们来看看几种常用的需求采集方法，如“数据分析”、“调查问卷”、“用户 访谈”等。并且希望大家意识到“需求采集人人有责”，从而“尽可能多地采集”。
用户说了很多需求，产品经理要“听用户的但不要照着做”，必须“明确我们存在 的价值”是“把用户需求转化为产品需求”，这一过程即需求分析过程。产品经理要通 过“给需求做一次 DNA 检测”，来“确定需求的基本属性”、“分析需求的商业价值”、 “初评需求的实现难度”，从而计算出需求的“性价比”。
资源总是有限的，所以我们只能做那些性价比高的事情，通过残酷的需求筛选，“活 下来的永远是少数”。看看“永远忘不掉的那场战争”，给自己打打气，“别灰心，少做 就是多做”，我们要有意识的“尽可能多地放弃”。
最后，是需求管理的话题。任何东西多了都需要管理，做产品更是“心急吃不了热豆腐”。
发现一个问题，然后设法将其转化为一个任务来解决
2.1 从用户中来到用户中去
2.2 需求采集的大生产运动
明确目标、选择采 集方法、制定采集计划、执行采集、资料整理，然后进入下一步的需求分析阶段。
用户研究方法：
用户访谈经常用在新产品方向的预研工作中，或者通过数据分析发现现象以后， 去探索现象背后的原因。
2.2.1 定性地说:用户访谈
用户访谈的常见问题与对策：
第一，“说”和“做”不一致的问题。
索尼找了一些用户来，问他们喜欢黄色的还是黑色的游戏机，结果发现说喜欢黄 色的用户比较多。之后，索尼告知用户为了感谢他们的配合，将送他们一台游戏机， 颜色可以任意挑选，而同样一批用户选择黑色的游戏机带回家的更多。很明显，有部 分用户说喜欢黄色却带走了黑色的游戏机。
第二，样本少，以偏概全的问题。
比如为了成本考虑，我们上门访谈的时候只找了本市的用户，这样很可能得出一 些与地域有关的错误推论;又如电话访谈时，为了提高联系成功率，我们优先拨打留 了手机的用户，而留手机很可能代表这批用户忠诚度已经比较高;再如邀约用户来公 司访谈，“愿意来的用户”，就已经和全体用户有差异了……
第三，用户过于强势，把我们往沟里带。
第四，我们过于强势，把用户往沟里带。
牢记访谈的目的，并且管好自己的嘴。
《软件观念革命:交互设计精髓》讲了不少关于用户 访谈的注意点：
►避免一组固定的问题:固定的问题会让被访者产生被审问的感觉，我们应该准 备好问题清单，但清单只起一个引导作用，并不用照着读。
► 首先关注目标，任务其次:比用户行为更重要的是行为背后的原因，多问问用 户为什么这么做。
► 避免让用户成为设计师:听用户说，但不要照着做，用户的解决方案通常短浅、 片面。
► 避免讨论技术:特别是碰到一些略懂技术的用户，不要与其纠缠产品的实现方式。
► 鼓励讲故事:故事是最好的帮助设计师理解用户的方法。
► 避免诱导性的问题:典型的诱导问题是“如果有××功能，你会使用么?”一般来说用户会给出毫无意义的肯定答复。
2.2.2 定量地说:调查问卷
调查问卷的常见问题与对策
第一，样本的偏差，即样本与想了解的目标用户群体出现偏差。
第二，样本过少的问题。
第三，问卷内容的细节问题。
2.2.3 定性地做:可用性测试
可用性测试是指通过让实际用户使用产品或原型方法来发现界面设计中的可用性 问题，通常只能做少数几个用户的测试，看他们怎么做，属于典型的定性研究。
可用性测试的常见问题与对策：
第一，如果可用性测试做得太晚(往往在产品将要上线的时候)，这时发现问题 也于事无补了。
第二，总觉得可用性测试很专业，所以干脆不做。
第三，明确是测试产品，而不是测试用户。
第四，测试过程中，组织者该做的和不该做的。
产品改版的一次冒险：改版的初衷都是为了产品升级， 更好地服务用户，但改版在客观上会挑战用户现有的习惯，所以必须慎之又慎。
2.2.4 定量地做:数据分析
有时候用 户的行为比语言更能反映出他的真实需求
介绍一种简单的二手需求采集工具——单项需求卡片。
单项需求卡片的理念就是:产品的需求工作不只是需求分析人员的事，而是涉及 产品的每个干系人的义务，至少得参与“采集”的过程，理想的状态是产品的所有干 系人都参加过“需求采集”的培训，然后在日常工作中养成主动提交需求给产品人员 的习惯，但实际很难做到，所以作为专业的需求分析人员，就应该尽量降低同事们， 比如销售、服务、技术人员提交需求的成本，也是节省我们自己的时间。
用户需求 VS.产品需求
用户需求: 用户自以为的需求，并且经常表达为用户的解决方案。
产品需求: 经过我们的分析，找到的真实需求，并且表达为产品的解决方案。
需求分析: 从用户提出的需求出发，找到用户内心真正的渴望，再转化为产品需 求的过程。
伟大的需求分析师，可以无视用户想要的东西，去探究他内心真正的渴望，再给 出更好的解决方案，或者说是用户真正需要的东西，这就是本节标题的意思——我们 存在的价值。
需求来源于理想与现实的差距，那么减小这个差距就有三种方式:
改变现状。是我们最常用的，去开发某种产品，但也是最笨的办法。
降低理想。不要忽视精神的力量，什么“打预防针”、“丑话说在前头”这类句子 想必大家都经常听到。
转移需求。因为人类的注意力是有限的，所以引导用户去关注其他事物，他就会 觉得这个差距没那么可憎了。我们也可以说，人的行为是需求驱动的，想改变人的行 为，可以寻找更强烈的需求展现给他，而让他不再纠结于原来的需求。
需求可以分为“新增功能、功能改进、体验提升、Bug 修复、内部需求”等
分析需求的商业价值
绝对不能因为某个需求的商业价值很大就马上去做，也不能因为另一个需求的商 业价值不大就不做。
开发量是非评估不可的，我把它叫做“初评”，允许误差，并且会要经验丰富的 人来评估，通常是技术经理，或者系统分析师、架构师。
绝对不能因为某个需求的实现难度很小就马上去做，也不能因为另一个需求的实现难度大就不做。
“不要试图满足所有用户”，一切皆看性价比。
性价比 = 商业价值÷实现难度(简化为开发量)
扫一扫
1万+
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
