写在正文之前
试图只看一本书就了解一个领域的想法本身就是不成熟的,你能了解的只是作者在写书时的观点。我们应该养成一个习惯,当看到一个观点的时候,就有冲动去寻找与之矛盾的观点,然后通过对不同观点的分析找出背后的原因,从而更全面地理解某个事物。一个人成熟的标志之一就是心中可以容纳各种不同的思想而无碍行事。
想法:批判性思维,同时可以站在不同视角思考别人的观点,理解别人的立场。
第一章:-1到3岁的产品经理
越来越觉得对于一款产品,早期的决策无比重要,所以很想参与产品初期的战略规划,幸运的是公司也给了一线员工这样的机会。
想法:同感。早期的模型很大程度决定了后续。早期的规划很重要。
第二章:一个需求的奋斗史
资源总是有限的,所以我们只能做那些性价比高的事情,通过残酷的需求筛选,“活下来的永远是少数”。
想法:永远要考虑投入产出、考虑性价比
2.1
第2.1.1节,我们先了解需求的本质,再了解用户的本质,接下来谈到要有“以用户为中心的思想”,但也“不要试图满足所有的用户”。在第2.1.2节中,通过了解别人、认识自己,来“聊聊用户研究”的话题。
2.1.1
需求的本质就是“问题”,问题的本质就是“理想与现实的差距”。作为产品经理,我们每天都在设法满足用户的需求,其实就是在解决各种各样的问题,而解决这些问题的方法与思路,对任何人都有帮助。
想法:产品就是解决问题,思路相通
优先满足哪些用户需要和产品的商业目标要结合起来考虑。
想法:先做核心用户还是先做用户量多的用户,是需要根据产品目标确定效果的。所以需要清楚大目标、KPI是什么。
既然我们的产品目标是用户数、活跃用户数,而不是销售额,那么从一开始就注定了我们更要代表的是大多数用户的利益。这并不是说核心用户不重要,而是产品的不同阶段,目标自然不同。
想法:产品的不同阶段,目标是不一样的。侧重和满足的用户也是不一样的。
2.1.2你真的了解用户吗?
如果你做的东西确实是自己平时就会用的,那么可以试着装一下,不过要记住你装的用户只能代表一部分用户,而对于自己不怎么用的产品,千万别去臆测用户的情况。
想法:大部分人对自己的产品都不怎么熟悉,每个页面的使用数据、用户场景你了解吗?很多时候不了解,需要了解用。
用户研究不是附属内容,而是前提,必须在做产品的过程中随时纳入计划。也许,突然有一天,当你有了机会去接触用户,却很可能不知所措,我到底应该找谁?通过什么方式?聊些什么?如何指导产品发展。
想法:用户研究不是随便研究,必须基于明确的目的,提前做好预研等工作。
“用户研究”、“市场研究”、“需求采集”等,都是为确定产品应该有哪些功能服务的。
想法:都是为了知道用户要什么,产品最重要的是知道用户到底要什么,然后用户需要的东西抽象成产品功能。用户要什么,其实是从产品功能层面思考。
第一轮,听用户定性地说,确定产品方向,做什么?随机抽样40个用户做访谈,据此写出需求列表。
第二轮,听用户定量地说,确定需求优先级,先做什么?投放了20万份调查问卷,确定了需求优先级的排序。
第三轮,看用户定性地做,要先做的那几个需求,应该怎么做?一边设计,一边陆续找了10个用户来验证,做可用性测试。
第四轮,看用户定量地做,根据产品的用户使用情况做数据分析,不断改进产品。当然,这是一个比较重要的产品,所以在用户研究上投入了较多的时间与人力,更多的时候,我们会视情况采取简化的方案。
上述维度的划分可以帮助我们更好的理解用户研究各种方法的特点,以便在现实工作中更加灵活地应用。每类方法都有其优势和劣势,对应了不同的适用场景,使用之前要认真考虑清楚产品的目标,是新产品定位?老产品优化?预测某新功能的用户数?提高用户活跃程度?验证某个改动的效果
想法:说的很实际,关于用户研究的注意事项。
2.2 需求采集的大生产运动
用户访谈通常采用访谈者与被访者一对一聊天的形式,一批次用户访谈的样本比较少,一般是几个到几十个,但在每个用户身上花的时间比较多,通常为几十分钟到几个小时,围绕着几个特定的话题,我们问,用户答,用户说,我们听,这是一种典型的定性研究。用户访谈可以了解用户怎么说,即他们的目标和观点。根据我自己的经验,用户访谈经常用在新产品方向的预研工作中,或者通过数据分析发现现象以后,去探索现象背后的原因。
想法:定性访谈试用的情况,常见于发现预研、发现问题后探究原因
用户访谈的常见问题与对策
用户访谈经常出现如下问题:第一,“说”和“做”不一致的问题。
我们也可以注意区分用户说的事实与观点,一般来说,诸如“我做了什么,步骤如何,碰到了什么问题”这类事实的可信度更高一些,而“我觉得、我认为”这类的观点,则需要带着大大的问号去听。第二,样本少,以偏概全的问题。选择样本的时候需要多加注意,尽量做到随机,举几个常见的“不随机”的例子。
想法:多看用户怎么做,说的不一定对
2.2.3 定性地做:可用性测试
可用性测试是指通过让实际用户使用产品或原型方法来发现界面设计中的可用性问题,通常只能做少数几个用户的测试,看他们怎么做,属于典型的定性研究。
想法:产品原型做出来多问问用户。问问别人怎么觉得,别人的看法。
对于改版,对于升级,我们要把“暴力革命”变成温柔和谐的“和平演变”。
想法:迭代。发布前做好可用性测试。
2.2.5 需求采集人人有责
作为产品的主人,我们好意思还没有用户了解产品么?产品要用才能感觉出好坏,特别是自己做的产品。产品做多了,我们随便看看别人做的产品,总能一下子挑出很多问题,提出很多需求,反过来看自己的产品越看越完美,这一定有问题,所以必须用自己的产品,最好是发动认识的人都来用。
想法:为什么用自己的产品发现不出来问题?也许是自己不用、也许是产品做久了变得麻木了?
2.3.1明确我们存在的价值
需求分析:从用户提出的需求出发,找到用户内心真正的渴望,再转化为产品需求的过程
想法:了解用户的需求,但不一定按照用户说的去做了。用户需求到产品需求有一个转化的过程。用户需要马,而我们可以提供更快的汽车。
2.3.2给需求做一次DNA检测
我们先把用户需求转化为产品需求,然后一步步确定每个产品需求的基本属性、商业价值、实现难度、性价比等。
想法:知道这里面评估需求的角度
产品需求的列表
Feature List(功能列表)。一些Excel的简单技巧,建议大家还是学习一下,比如条件格式、筛选、单元格有效性、单元格锁定、隐藏等,可以让表格管理起来轻松一点,看起来也美观一点。
开发量是非评估不可的,我把它叫做“初评”
想法:知道这个流程,研发初评工作量
相对于“初评”,在项目启动之后,制定项目开发计划的时候还会有一次更精确的评估,那时候需求怎么做已经知道、由哪位开发工程师来做也知道,所以可以推算出相对准确的工期,工期和工作量是有很大区别的。
想法:精确评估时间点、人力,其实这些都是流程化的东西,只要走一遍就知道了。最重要的是找一个靠谱的导师。
“不要试图满足所有用户”,一切皆看性价比。
想法:性价比也是一个判断地标准。可以思考下产品经理怎么做判断?判断地标准有哪些?
2.4 活下来的永远是少数
需求筛选:需求打包——BRD制作——产品会议——立项
想法:知道这个过程,BRD。
本质上老板也在追求性价比。大家都希望花费最少的资源获得最大的商业价值。
想法:出方案要写清楚投入、产出。
魔方计划的粗略时间安排
想法:OKR拆解和进度管理图,知道这个管理节奏。
项目KickOff会议,我们简称KO,也许有的人会觉得很形式化,但我认为很重要。我们自己全程参与项目,所以对各种信息都已经了解,但是还有很多项目成员在KO之前很可能完全不知道这个项目是要做什么,而且KO的很大作用是在心理上的。
想法:团队成员的心理上的参与感很重要。
项目背景我们在哪里?说过去,做项目之前的“悲惨境地”,明确为什么要做这个项目,以让听众“痛下决心”为终极目标。项目意义、目的与目标我们去哪里?说将来,做项目之后的美好前景,解决什么问题就算成功了,以让听众“面带桃花”为终极目标。需求、功能点概述我们怎么去?说现在,具体用什么方法促使“过去”到“将来”的转变,以让听众“跃跃欲试”为终极目标。
想法:项目启动会议内容
感兴趣的朋友可以关注我的个人微信号:花生海语
在公众号后台回复你的微信号+人人思维导图哈,我加你。图片发这里不方便
不好意思,发现很多朋友都直接回复简书了。。不是回复简书哈