人人都是产品经理 2.0 思维导图
2018-01-29 18:03:27 9 举报
AI智能生成
人人都是产品经理2.0 书籍内容思维导图
作者其他创作
大纲/内容
00 开始:写在正文之前
0.1 为什么会有这本书
第一,非产品岗位的同学,因为工作或者兴趣,需要了解产品的方法论
第二,对初创公司来说,如何让非专职产品人员短时间内胜任产品工作
第三,非互联网圈的从业者,需要更通俗的了解互联人是怎么做产品的、有哪些异同、如何选择性的借鉴他们的经验
第四,学习资料太多,不利于圈外人找到真正适合自己的图书、网站、社群、公众号
0.2 本书的产品定位
目标用户:-1~3岁的产品经理
需求场景
对于“泛产品经理”,可以通过阅读此书,理解一套方法论体系
对于产品经理,这本书像一本知识图谱,可以粗读一边,后续有困惑再针对性的查阅
产品概念
通过社群组织与用户保持沟通,加上相应的培训咨询服务、工具包,以及积累多年的社交媒体与此书构成有机整体
竞争优势
1.此书的底层逻辑方法论提取与作者相关的实体书籍,并非凭空搭建,这样的内容源头使得此书具备了第一无二的沉淀
2.基于作者的个人经历,出身于阿里,不仅做过一线陈皮,也关注了很多关于“产品经理岗位”、“创新”的事情
3.写书的过程中,通过读书会与国内产品经理圈内的作者沟通,把一些建议融入此书框架中,共同构建了更加经得起推敲的内容
0.3 本书内容与阅读方法
把书对应章节的视觉引导图与内容互相对应,建立自己的知识地图
0.4 我与本书的局限性
1.没有从无到有操盘过一款真正出色的产品
2.广义的运营非读者的强项
3.产品形态、公司类型太多,无法一一亲历
4.创业的过程,最大的收获是体会到自己“做不了什么”
01 初始:大话产品经理
1.1 从一个小故事谈起(通过小故事分析产品设计的流程)
产品定位阶段
需求采集阶段
需求转化阶段
产品概念验证
新功能上线时
1.2 产品经理的前世今生
1.2.1 从人类社会出现分工说起
1.2.2 岗位诞生,宝洁的故事
1.2.3 从项目经理到产品经理
核心区别:一个靠想,一个靠做
项目经理是执行人,工作重点是把任务完成,并不充当任务的提出者,需要的是执行、计划和控制能力
产品经理是任务的提出者,更需要创造力
创造力、洞察力和对客户的感知力是产品经理需要掌握的核心技能
1.2.4 与“传统”产品经理的区别
传统行业的产品已经相对稳定,能为公司创造更大价值的事是偏营销的。所以,作为要对最终产品扶着的人,产品经理需要把主要经理放在营销上
泛互联网行业的产品经理,由于很多产品不成熟,甚至有些产品尚未有准确定义,且每时每刻都可能出现新的东西,工作重点更侧重与产品上市前的产品定义,以及需求的采集与细化等
1.2.5 十年,产品经理逐渐成熟(常见细分角度)
1.明确的层级定义
2.按照产品生命周期不同阶段的主要任务,细分为四个发展方向:产品架构、产品设计、产品管理、产品运营
3.产品类型不同,背后需要产品经理具备的能力也不同,据此的细分可视为产品的细分
1.3 思维方式与性格特点
1.3.1 从“学生”到“职场”
一看到问题,马上就想答案,这就是典型的“学生”思维
产品经理式的思维
第一步,需要采集需求,分析需求
只做一次的事情找可行解,反复做的事情求最优解
先搞清问题,后选择方法
转变思维后的好处
1.有了更多选择
2.可做价值判断
1.3.2 从“用户”到“产品经理”
每个人每天都会已用户的角色接触成百上千件产品,所以习惯以用户的视角来看待这个世界,因为这是一种简单、直接、更舒适、以自我为中心的方式
要做好产品经理,就必须摆脱以自我为中心,转向以用户为中心,换句话说,即具备“同理心”
需时刻提醒自己,用户和我们是不一样的,我们并不懂用户,但必须有能力切换成用户视角来发现产品问题
1.3.3 从“现象”到“本质'
产品碰到的实际问题,往往没有完美的方案,只有用心去研究,才能找到相对合理的方案
1.3.4 还有什么性格特质是加分项
热爱生活,好奇心
理想主义,完美主义
善于沟通,团队精神
抗压,自我激励,情绪调节
1.4 产品经理的日常
1.4.1 入行,社招与校招
1.4.2 一天里的典型任务
产品的细分
产品架构
定义、规划产品,确定产品定位,规划、把我产品的节奏,对产品进行宏观把控,对经验要求较高
产品设计
负责产品细节设计
2C的产品,需要和交互设计紧密结合,注重用户体验
2B的产品,主要是业务逻辑、流程、规则的设计
产品管理
狭义的管理,偏资源协调、跟进实施和团队建设,有点像项目管理,负责把产品做出来
产品运营
负责产品大运营,解决产品”有人用“的问题,建立产品与用户的通路,负责营销推广
1.4.3 周边团队从小到大
主要讲初创团队从零发展,团队角色的变化
02 产品:关键词与分类
2.1 产品:解决某个问题的东西
2.1.1 某个:明确定位
定位用来限定”有所为有所不为“
2.1.2 问题:用户、需求、场景
用户:这个问题是谁的问题
第一,本书里提到的用户,除非特殊说明,都是指广义用户,即产品干系人,指与产品有关的所有人,也包括公司内部人员
第二,任何产品的用户都是多种多样的,但又的确有主次之分,因此,不要为了次要用户的需求干扰核心用户
第三,这里说的用户,更多指”角色",而不是自然人
客户与终端用户
客户,指付钱买产品的人
终端用户,指最终使用产品的人
需求:问题的核心是什么
第一,需求即“问题”的核心,它是分深浅的
第二,每一个需求,挖到最后,都可以归结到人性层面
第三,满足需求其实有三种方法:提高现实、降低期望、转移需求
场景:用户在什么情况,以及何时何地碰到这个问题
为何移动时代更看重场景
用户:用户多样化、触达用户的渠道复杂化
需求:更加丰富多样,也更加碎片化
场景:随时随地,在各种环境下
解决方案:移动特有的领域知识
要掌握移动领域的基础知识
要熟悉各种可利用的硬件
要理解互动方式的变化
要明白产业链的结构
要懂得用简单逻辑完成任务
要采用更灵活的实施过程
2.1.3 东西:解决方案
产品、功能、特性、流程、服务等都可以算作东西
东西可以是一个有形的实物,也可以是一个无形的服务
2.2 常见的产品分类维度
2.2.1 用户关系角度
单点:启动最简单
单边:可能有网络效应
多边:平台相,壁垒最高
2.2.2 用户需求角度
工具,解决单点问题
解决特定的单点问题,用户可以“用完即走”
内容,价值观过滤器
必须提供有价值的信息,如果用户想打发时间,那么“可打发时间”也算一种价值
基本的产品逻辑是:主动(搜索、订阅等)或被动(推送、推荐等)接触内容→消费内容→消费后行为(评论、点赞、打赏等互动,以及分享、传播等扩散行为)
社交,彼此相互吸引
用户与用户互相玩,彼此吸引并建立关系,最终因此而留下来
社交产品最大的优势就是用户黏性相对高,最大的劣势是离钱比较远
交易,做生意卖东西
线上的交易,就是电商和O2O概念下的各种收费服务
有的是真正做“交易”,即自己卖货,属于B2C模式
有的其实是“交易平台”,自己不卖东西,通过服务卖家、买家让双方在平台上成交
平台,复杂的综合体
这是一种同时满足多种角色的产品形态,也可以说是“生态"
游戏,打造平行世界
可大可小,一切皆可包容,是真实世界的副本
2.2.3 用户类型角度
第一个角度:企业 VS 个人
2B产品至少要同时面对企业代表(要不要买、要不要用的决策)和终端用户两种角色
典型的2C产品相对简单,自己买自己用。但也有特例,比如各种礼品就是买给别人用的
第二个角度:群体 VS 个体
典型的OA系统,需要多个角色一起使用
2C的产品,经常是自己一个人用就可以了
第三个角度:工作 VS 生活
2B的产品是生产资料
2C的产品是生活资料
2B重商业价值,2C重用户体验
第四个角度:男人 VS 女人
2B像男人,2C像女人,男人在乎目的与结果,女人在乎过程与感受
2B、2C没有完美的分类方法和清晰的分类界限,我们应该综合两者的优势来做产品,它不是非此即彼的概念,而是一条线的两端
2.2.4 产品形态角度
BS结构:Browser-Server
对研发团队来说,大部分工作在服务端,或者说是云端,客户端借助一个浏览器来做展示
研发过程简单,最大的优势就是“快”
相比客户端,Browser模式还有个跨平台的优势
CS结构:Client-Server结构
它有一个需要安装的客户端,还会有一个服务端,手机里的App、电脑里安装的软件就是这种
软硬结合
除了软件部分,还有硬件实体
大实体:有软硬件更有服务
前面的轻,做起来快,迭代周期短,试错成本低,对质量的要求没那么搞,有问题容易改正。当然,相应的进入壁垒也就比较低
模式的取舍
偏交互的用Native(Client模式),偏浏览的用Web(Browser 模式)
交互指复杂操作,包括输入、选择等,Web往往支持得不好
已稳定的用Native,试错中的用Web
访问硬件的用Native,信息展示的用Web
硬件包括手机里的各种传感器等,Native的访问权限更高,安全性也更高
核心功能用Native,周边辅助用Web
变化少的用Native,经常变的用Web
2.2.5 各种其他角度
行业分类角度
关于行业的具体细分
盈利模式角度
基本可以分为两大类:俗称卖货的行当与卖人的行当
卖货采用前向收费,直接像用户要钱
卖人采用后行收费,即2B的抽水模式,主要像对企业单位或信息提供者收取费用,包括广告发布,竞价排名,冠名赞助,企业会员等费用
关键资源角度
资本驱动
对应着需要大笔资金做准入门槛的产品
技术驱动
意味着拥有核心技术能力,成为别人无法模仿的壁垒
产品体验
产品本身要好,对互联网行业来说,就是用户体验很爽
运营服务
对应着需要很多“人肉”参与的产品,强调运营效率、服务体验等
垄断资源
取决于获取资源的能力
行业成熟度角度
从0到1和从1到N的区别
03 概念:提出与筛选
3.1 产品概念的提出
核心用户
产品目标用户中最重要的用户是谁,表达为一个抽象的人群
产品目标用户中最重要的用户是谁,表达为一个抽象的人群
刚性需求
用户需求中最重要的那些,叫作刚性需求
刚性需求要满足三个条件:真实、刚需、高频
真实:需求是真的存在,还是幻想出来的
刚需:特指需求是否强烈,不满足能否忍受
高频:需求发生的频次是高是低
典型场景
到底什么场景更典型?可以通过有没有“唤起点”来判断。
在某种情境下、某时某刻,用户能想到,最好是能第一个想到你的产品。这个时刻就是产品的唤起点
产品概念
简单的一句话,说出你的解决方案是什么,一个App,一个网站,一个服务体系,还是一个企业协同的工具?
竞争优势
人无我有;人有我优,无非就是多快好省,具体的说,包括更多功能、更快解决问题、更好的质量、更省钱等
竞品分析
竞品的范畴:相似的产品→能满足同样需求的不同产品(从表层到深层需求)→所有消耗用户时间的产品
互联网/手机上的所有产品都是竞品,竞争的是用户仅有的那点时间
3.2 概念提出的综合案例
3.2.1 案例1:智能长命锁
3.2.2 案例2:淘宝首页
首先,我们要确定这个产品的核心用户
第一步,做用户细分,列出可能与淘宝首页发生关系的各种用户:买家、卖家、合作伙伴(即服务买卖方的服务商)、淘宝员工、竞争对手、机器爬虫等等
第二步:判断每种用户的价值,排个优先级
第三步:判断“买家”这个用户群体的粒度是否足够细。如果够细,到此为止,如果不够,回到第一步再细分,并循环这三步
接着,要确定这批核心用户的刚性需求和典型场景
第一步,类似地列出新手买家的各种需求:逛、购物、学习如何使用淘宝等
第二步,对这些需求做价值判断
第三步,判断“购物”这个需求场景的粒度是否足够细。如果够细,到此为止,如果不够,回到第一步再细分,并循环这三步
问题和解决方案,不一定先有哪个,最重要的是要找到它们的匹配
聊聊用户分类的方法
分类逻辑:把全集分为子集后,不同子集的个体之间差异尽量大,每个子集内的个体差异尽量小
在进行分类务求遵守的原则就是:不同细分用户的“需求场景”差异要尽量大
第一,如果产品的用户是多边的,先根据不同角色分类
多边型的产品,对应单点(如小工具)和单边(某种同好社交应用)的产品,要至少两种明显差的用户群体,通常这种产品都具有平台属性
第二,新人、中间用户和专家
这是按照用户对“产品所在领域的熟悉程度”来分类的结果,也是一种非常常用的用户分类方法。对于单边的用户角色,如果找不到更好的分法,建议用这个方法保底,毕竟新人和专家的需求场景差异已经足够大,前者希望“简单易用易上手”,后者期待“稳定可靠性能高”
第三,根据人口统计信息(包括年龄、性别、职业、所在地、消费水平等)
这个方法要慎用,要避免人口统计信息和产品关系不大的情况(比如按照不同职业来区分打车用户,就没什么逻辑),这样划分成的几类用户,需求场景差异往往不是很明显
第四,根据产品的业务场景
总结:多边先分边,新人与专家,人口统计学,业务场景化
3.3 产品概念的筛选
3.3.1 内部因素:能力
人:团队是否与要做的事情匹配
财:各种资本、资金的支持是不是到位
物:行业资源与业务能力
行业资源:任何产品都需要,往往靠的是长时间在行业、产业的积淀
业务能力:是通过反复做某些事逐渐总结出的套路,如复杂的IT支持系统、运营活动的方法论,公司内部的流程等
3.3.2 内部因素:意愿
意愿就是使命、愿景、价值观
使命就是我们要解决一个什么问题,要做一个什么事情
愿景是说我们希望成为什么
价值观就是我们认为什么是对的什么是错的
3.3.3 外部因素:价值
宏观:天花板
具体点说,就是我们想做的事情,扩大到一个行业,整体有多大?增速怎样?现在是高速增长期还是成熟期,甚至已经是衰退期?
潜在用户³×单用户可挖掘价值=行业天花板
微观:身边人
从身边起步的优势
一是为身边人,甚至为自己做产品,能减小“误以为自己懂用户”的错误概率
二是找第一批精准用户更加容易
找到你的种子用户
种子用户是受你要解决的那个问题困扰最深的一小群人
对产品的帮助
愿意配合
可以提供很多有价值的信息
可以忍受缺陷
可以成为义务推销员
初次接触用户,验证概念
创意——验证——调整
预筛选用户
“开放式”、“非引导”的问题
从种子用户到潜在用户
3.3.4 外部因素:成本
宏观:大环境
政治因素
是指对组织经营活动具有实际与潜在影响的政治力量和有关的政策、规定等因素
经济因素
是指组织外部的经济结构、产业布局、资源状况、经济发展水平以及未来的经济走势等
社会因素
是指组织所在社会中成员的历史发展、文化传统、价值观念、教育水平以及风俗习惯等因素
技术因素
不仅仅包括那些引起革命性变化的发明,也包括与企业生产有关的新技术、新工艺、新材料的出现,以及发展趋势、应用前景
环境因素
一个组织的活动、产品或服务中能与环境发生相互作用的要素
法律因素
组织外部的法律、法规、司法状况和公民法律意识所组成的综合系统
微观:行业环境
对于同行业内现有竞争者的能力,其主要指标为市场成熟度和竞争激烈程度
潜在竞争者进入的能力,代表行业门槛高低
替代品的替代能力
供应商的讨价还价能力
购买者的讨价还价能力
3.4 概念筛选的综合案例
3.4.1 案例1:阿里巴巴的成与败
做产品要顺势而为。这个势,说大点事行业的浪潮、公司和产品的基因,说小店事用户群体的特质、需求的特性、场景的特点
对一类用户、需求、场景的深入定制,一方面可以成就一个产品,成为对手进入的壁垒,另一方面,这堵墙也有可能成为这个产品的牢笼
3.4.2 案例2:B12在方向上的思考
04 需求:采集与用户研究
4.1 需求采集方法的分类
4.1.1 直接采集与间接采集
直接采集与间接采集,获取到的需求分别是一手需求和二手需求,可以从以下两个角度来理解它们的差异
第一个角度:需求的提出者是不是有需求的人。如果用户是为自己提需求,采集到的就是一手需求;如果这个需求是转述的,就是二手需求。
第二个角度:需求是原始的还是加工过的。
对于这两种采集方式的优劣,可以从准确与效率两方面加以对比
直接采集的一首需求更准确,所以产品经理一定要确保手里有足够比例的需求是来自直接采集的,这样才能让产品本身和自己对产品的判断更接地气
而间接采集的二手需求,就需要带着问号来看,思考其需求者和提出者分别是谁,以及有没有被曲解过。但二手需求是经过梳理的,所以获取结论的效率会更高
实践层面,“全员参与采集,产品经理处理”是比较可行的模式
4.1.2 说和做,定性和定量
说和做
定性与定量
完整需求采集过程(Z字采集法)
产品规划阶段:听用户“定性地说”,确定产品方向(做什么)
项目早期:听用户“定量地说”,确定需求优先级(先做什么)
项目实施过程:看用户“定性地做”,确定要先实现的那几个需求应该怎么做;设计的同时完成可用性测试
上线后的优化阶段:看用户“定量地做”,根据产品的用户使用情况做数据分析,不断地改进产品
4.1.3 是否在真实场景里
临场感
需求与场景结合
4.1.4 是否和产品发生交互
用户以为自己要,但又了并不用的产品功能
用户以为自己不需要,但用过就离不开的产品功能
低成本验证:先不上复杂的系统,设法简化实现,或者干脆用人肉跑流程来验证
4.2 一些实用的采集方法
腾讯的10/100/1000
阿里:直接去当销售或客服,加深对用户的理解
请用户到公司里开批斗会
利用网络搜索引擎
看各种报告和公开数据
4.3 用户、需求的再理解
4.3.1 需求的三种深度
第一种深度——观点和行为
表面能听到、能看到的东西,一般是通过用户怎么说、怎么做直接表现出来的
第二种深度——目标和动机
用户为什么这么说、这么做?
第三种深度——人性和价值观
最底层的,最稳定的需求,人类社会诞生的千万年来,基本上没怎么变
4.3.2 如何理解战略需要这类内部需求
首先,因为提出者都是广义用户,所以这些需求都需要考虑,但要判断主次
然后,要分清楚手段和目的。公司成立后,通过服务外部用户、满足外部用户价值来实现商业价值才是最终目的,而搭建团队只是达成目的的手段
4.3.3 用户:抽象到具象再到抽象
第一阶段:用户是抽象群体:在产品概念阶段,用户是假想的某一类人——目标用户、核心用户
第二阶段,用户是具象个体:需求采集时,我们要去接触一个个真实的用户,见过人,听故事,找感觉,发现“用户故事”
第三阶段:用户又是抽象群体:整理采集到的需求时,把真实用户再合并特征,定义出“人物角色”,并反向修正产品概念
工具:用户故事
去见真正的用户,能听到一个个具体、鲜活的需求场景,这就叫做“用户故事”
工具:人物角色
“人物角色”是一个对整个产品生命周期都很重要的工具,也叫“用户画像”,是指根据一些具体的用户故事,对某类目标用户的汇总描述。它可以用来帮助团队内部达成共识
两种典型用户:新手与专家
每个产品都会面向多种多样的用户,只不过有主次之分
新手:简单易用,快速上手
专家:稳定可靠、性能高
核心用户是新手的典型产品,是那种用户量很大的大众产品,比如公众设施或者普通家用电器
核心用户是专家的典型产品,往往用户量很少,比如专业仪器、乐器、专业级数码设备等
总体来看,2C的产品新手用户更多,2B的产品专家用户更多;前台产品的新手用户更多,后台系统的专家用户更多
随着时间推移,一个产品的核心用户也会发生变化
4.4 产品原则与初心
产品原则是整个产品团队必须达成共识的准则,依赖于团队的价值观或者是产品的初心,相当于一个产品的宪法
目标用户分为哪几类,以及他们的优先级排序,整个团队必须达成共识
产品的市场切入点,最关键的用户需求场景是哪几个,一开始的最小可行产品MVP必须满足那些
对一个社区而言,人和内容都很重要,到你哪个更重要?回答这个问题的共识是这个社区的产品原则。而且,往往对错都没有共识重要。
4.4.1 案例:“小得”的产品原则
4.4.2 美好初心:知乎与豆瓣
4.4.3 跨界参考对象:美国宪法
05 转化:需求分析与Y模型
5.1 从问题到解决方案
先以问题为中心,尽快找到“用户需求”,回答Why和What;然后以方法为中心,最终设计出“产品功能”来回答How
5.2 Y模型的基本概念
解读Y型图
1是用户需求场景,经常简单说成用户需求。这是起点,是表象,是需求的第一种深度——观点和行为
这个阶段主要问题是Who(用户)、What(需求)和Where/When(场景)
2是用户需求背后的目标和动机,是需求的第二种深度,产品经理再思考用户目标时也要综合考虑公司、产品的目标
Why
3是产品功能,是解决方案,是实施人员能看得懂的描述
Which/How many。Which是指选哪一个方案,这背后其实是对价值的判断,比如怎么评估性价比和优先级。How many是指这一次做多少个功能,考验的是对迭代周期、MVP的把控
4是人性,或者说是价值观,是需求的第三种深度,是需求的本质
Why
5.2.1 最经典的例子
5.2.2 用心听,但不要照着做
5.2.3 不照着做的好处
不被伪需求欺骗
解决需求冲突
发现更多用户目标
抓住恒定的人性
在成熟市场中找到机会
5.3 实战中如何深入浅出
5.3.1 深入:如何深挖人性
“定性的说”(攀梯术)
通过一系列直接的探询式问句来洞察人性
典型的提问句式是“为什么那个东西对你来说很重要”和“那个东西对你来说意味着什么”
遇到的困难
用户想不出“为什么”,开始胡编乱造
越接近个人价值的答案越抽象,离原本的讨论主题月圆,离用户的个人生活越近,可能会遇到隐私或者用户防御的问题
由于老是要绕着弯追问为什么,用户可能会觉得你很傻,须考虑如何让对方不至于讨厌你
解决方案
做准备时让访谈环境尽可能舒适放松,比如准备好饮料零食
提前向用户说明
回答没有对错,只需要表达自己的观点
如果过程中觉得有一些问题无法回答,可以直接说出来
情景唤醒
通过让用户假想、会议(使用产品的)情境,引起Ta的思考
假设某物或某状态的缺失
让用户思考,某物/状态如果缺失了会怎样
反向攀梯
用户无法说出做某事或想要某种感觉的原因时,可询问Ta不做某些事情或不想产生某种感觉的原因
时间倒流对比
让用户反思过去,并与现状对比
重定向——沉默或重述确认
用沉默或通过再次询问确认的方式来鼓励用户继续讲
5.3.2 浅出:如何设计功能
浅出的意思是解决方案要尽量简单
向“糗事百科”学借力用户
充分利用UGC(User Generated Content,用户产生内容)的理念和优势
设计出“提交→审核→最新→推荐”的内容审核机制
向“知乎”与“知乎日报”学冷启动
早期控制用户注册
员工早期亲自上阵生产、筛选内容
向各种游戏学“引人入胜”
Badge:勋章和等级,表示玩家过往的成就
Point:积分和经验值,代表你现在的状态
Leaderboard:排行榜,指引你未来努力的方向
5.4 一些综合案例
5.4.1 淘宝首页
5.4.2 健身应用
5.4.3 直播应用
5.4.4 企业内训
5.5 Y模型的更多理解
5.5.1 用户视角与公司视角
用户需求就是产品机会
用户目标就是产品目标
用户任务就是产品功能
5.5.2 新手思维与专家思维
拥有“新手”心态
保持好奇心,思维不固化,拒绝“存在即合理”,才可以不断发现新的问题和可改进之处
拥有“专家”能力
5.5.3 普通青年与文艺青年
5.5.4 复习、预习一些概念
06 功能:细化与打包
6.1 一个功能的DNA
6.1.1 功能的价值判断
对某个功能进行价值判断的流程
参考“产品原则”里“目标”部分的定义,明确当前产品最看重的指标是什么,可以数字化的KPI,比如注册用户数达到10万,也可以是某些关键结果,比如“建立起线上自动化的专家入驻全流程”。如果有多个指标,则需要对这些指标加权合并。
考察每个功能点是先后,对上述指标的帮助打不打。如果大,则这个功能的价值就大。因为每个产品的不同时期的指标不同,所以评判各个功能价值的标准也有差异。通常用半定量的方式来衡量,比如最简单的大、中、小,或者5、4、3、2、1等评分标准
广度:潜在用户数×单用户价值
简单来说,广度对应着潜在用户数,即一个产品将来可能覆盖的用户群体有多大
频度:需求频次×单次复杂度
频度是指需求频次的高低,不同的需求,频次差异会非常大
强度:不可替代、紧急、持久
强度背后说的就是真实刚需
可替代性
可替代性用来说明一个功能是不是很容易被其他功能替代
紧急程度
需求紧急程度也可以作为衡量需求强度的判断原则
持续时间
持续时间是指一个功能做好之后,用户有效使用的周期是多久
不同阶段的产品看重什么
在产品的不同阶段,对上面提到的广度、频度、强度,会有不同的侧重点
产品早期的验证阶段,更重视“强度”
验证完毕,产品进入大面积拉新(指获取新用户)的阶段,这时更重视“广度”
当用户增长出现瓶颈,就需要开始对产品的用户进行激活,这时更重视“频度”
真实情况是各个环节相互渗透,交替出现
6.1.2 几个价值判断的案例
实用工具,如何突破
智能硬件,怎样“送礼”
上门服务,哪种靠谱
1.客单价要高
2.订单密度要高
6.1.3 成本评估与性价比
成本评估
互联网常常把“开发量”的高低视为成本的高低
确定性价比
性价比=价值/成本
6.1.4 功能分类:KANO模型
第一类,基础功能
第二类,亮点功能
第三类,期望功能
前三类功能的与时俱进
第四类,无差别功能
第五类,反向功能
6.2 功能打包,确定MVP
6.2.1 尽可能多地放弃
这一步要确定“最小可行产品”,即MVP(Minimum Viable Product)
MVP指的是满足“用户愿意用、最好愿意付费“、”用户易于使用“、”团队有能力实现“的最小功能集合,有些可以直接作为最终产品使用,有些甚至只能用来演示。它的重点就是制作的成本要极低,但是却能展示最终产品的主要特色
MVP的公用就是让你拿着它接触客户,尽早根据客户的回馈来改进你的产品
和需求采集阶段”尽可能多地采集“不同,这一步要”尽可能多地放弃“
6.2.2 案例:QQ的MVP
6.2.3 MVP的限制因素
不同功能不同对策
基础功能必做,要留足资源
在产品初创期,先实现个别低成本的亮点
对期望功能,先做性价比高的
无差别功能必须做,低成本验证出来即可
对反向功能,权衡各方利益后再决定
考虑功能依赖关系
功能的内外部依赖关系,如合作伙伴和各种前置条件等,都需要事先考察
考虑功能相似性
考虑非功能需求
6.2.4 MVP的表达,产品架构图
6.2.5 功能分分合合的本质
不同的功能,到底应该做在一起,还是分开
看不同用户角色背后的自然人重合度高不高。如果高,则倾向于同一个端搞定,如果不高,则倾向于分离
6.3 把需求和功能管起来
6.3.1 空间维度:功能列表
6.3.2 时间维度:需求流程
07 执行:立项组队与研发生产
7.1 从“想清楚”到“做出来”
7.1.1 原型验证与NPS
确保有的放矢,不要努力地做错误的事
NPS(Net Promoter Score)指净推荐值,是一种计量用户将会向其他人推荐某产品可能性的指数。作为一种流行的用户忠诚度分析指标,它专注于用户口碑,在产品早期验证用户价值时,尤为重要
计算公式:NPS=(推荐者数-批评者书)÷ 总样本数 × 100%
确定净推荐值时,可以直接了当地询问用户一个问题:您是否会愿意将某某产品推荐给您的朋友或者同时?然后让用户根据愿意推荐的程度,在0到10分之间来打分,最后分解打分情况把用户分为推荐者、被动者和批评者
推荐者:9~10分之间
被动者:7~8分之间
批评者:0~6分之间
然后再根据推荐至与批评者的人数来计算NPS的数值
NPS的得分值再50%以上就已经比较理想,如果达到70%~80%,则说明产品拥有一批忠实拥趸
7.1.2 产品委员会与关键节点
概念筛选
立项组队
上线发布
营销推广
7.2 立项:搞定各种资源
7.2.1 关于人:团队、组织
7.2.2 关于物:政策、资金等
MRD:Market Requirements Document,市场需求文档,除了描述问题,解释为什么要做这个产品,还要给出解决方案。这个文档比较像产品规划和商业计划书,时写给资源拥有方看的
Why:为什么要做这个产品
What:产品MVP包含哪些功能及要做什么
How:项目计划及风险对策等
PRD:Product Requirements Document,产品需求文档,是在项目过程中写给开发、测试、设计师看的,仔细描述产品功能要怎么做
7.3 组队:聊聊初创团队
7.3.1 如何快速知己知彼
非工作时间、非工作地点
为什么要来这个团队
对一年后收获的底线预期
个人对团队的帮助
自己能做什么
自己想做什么
项目失败最可能的原因是什么
7.3.2小团队的沟通协作
7.3.3 小团队与大公司的区别
对于初创公司,组织架构应该以目标为中心,按需设置部门,而不是像大公司一样以流程为中心。而组建公司之前,应该以机会为中心
7.3.4 借助第三方力量做产品
缺钱?众筹
缺人?众包
分享
座谈
咨询
外包
7.4 研发生产时,我们做什么
7.4.1 产品经理要不要懂技术
第一,底线时可以和技术人员无障碍沟通,并不要求你会写代码
第二,多向技术伙伴请教,自学一些技术知识
第三,根据所负责的产品,决定要懂哪些技术,懂到什么程度
第四,要特别关注技术方案与业务场景的练习
开发的Secret Toolbox
测试是个专业活
设计与运维环节
设计
交互设计
视觉设计
工业设计
服务设计
7.4.2 如何做一个让Ta们讨厌的人
开始实施之前
不说请需求价值
不去想功能细节
帮技术评估工作量
逼着技术团队承诺
实施过程之中
做了一半改需求
开发过程中消失
过度关注实现细节
产品发布之后
发布后没有反馈
任务无节奏感
全程适用
优柔寡断无决断
报喜不报忧
不要把他们当人
08 成长:规划与迭代
8.1 好产品步步为营
8.2 规划:只看最短和最长
8.2.1 从规划上看战略
长期的规划即战略,它是一种从全局考虑、谋划实现全局目标的规划。一个战略就是设计用来发展核心竞争力、获取竞争优势的一些里的综合的约定和行动。
战略上接企业的使命、愿景、价值观,下接具体的战术实施步骤,包括产品规划
8.2.2 通过提问把别人干翻
8.2.3 提升规划能力的实践
让产品团队每个人做一份自己产品的规划,规划周期可以限定为3个月。重点是每个月需要拿出一天时间,每个人轮流宣讲,团队其他人来点评
8.3 迭代:再理解敏捷
8.3.1 价值观、宣言与原则
敏捷的价值观
沟通
约定好明确的“沟通计划”和“沟通原则”
简单
Less is More
反馈
及时获取反馈,用反馈来拥抱变化
勇气
不怕犯错,勇于尝试
谦逊
承认自己的无知,也是互联网行业很重要的一个特点,它来自于“求援”思维
敏捷宣言
一、人与人的交互。重于过程和工具
二、可用的软件,重于详细的文档
三、与客户写作,重于合同谈判
四、随时应对变化,重于循规蹈矩
敏捷的十二条原则
一、对于我们而言,最重要的是通过尽早和不断交付有价值的软件满足客户需要
二、拥抱变化,欢迎需求的变化,即使在开发的后期
三、敏捷过程能够驾驭变化,保持客户的竞争优势
四、经常交付可以工作的软件,从几个星期到几个月,时间尺度越短越好
无、业务人员和剋发着应该在整个项目过程中始终朝夕在一起工作
六、围绕斗志高昂的人进行软件开发,给开发者提供适宜的环境,满足他们的需要,并相信他们能够完成任务
七、在开发小组中最有效率也最有效果的信息传达方式是面对面的交谈
八、可以工作的软件是进度的主要度量标准
九、敏捷过程提倡可持续开发
十、对卓越技术与良好设计的不断追求将有助于提高敏捷性
十一、简单——尽可能减少工作量的艺术至关重要,最好的架构、需求和设计都源于自我组织的团队
十二、每隔一段时间,团队都要总结如何更有效率,然后相应地调整自己的行为
8.3.2 敏捷项目管理的实践
Scrum
团队角色
PO(Product Owner)通常是产品经理,要对各种利益相关方负责
SM(Scrum Master)充当教练的角色,一般由对流程、方法论比较熟悉的人来当人,不建议这个角色和PO重叠
关键产出物
Product Backlog指比较长期的产品任务表
Sprint Backlog在Scrum里指当前这个迭代里面的任务点
Burndown Chart是燃尽图,用来监控任务是不是在按期推进
重要的会议
每个迭代的计划会,经常和需求评审会合并,主要目的是明确任务,以及评审这个爹代理需要做的功能
每天的站立会议,是重要的信息同步手段
功能评审会用来评估做出来的东西是不是想要的
回顾会的目的是为了过程改进
日常管理工具:看板
项目流程简化
角色的简化
产品
设计
前端
开发
流程的简化
立项会议
确定项目目的——为什么、做什么(时间控制在半小时内)
需求评审
确定项目怎么做(对相对较小的项目,可以和立项会议合并,总体时间控制在2小时内
功能评审
就是在测试环境下演示一下产品,以确定做出来的是不是团队要的(1小时左右)
发布上线
确定产品是不是用户想要的,以及用户还要什么。通过获取用户反馈来让产品的优化形成一个螺旋上升的闭环
需求变更
在项目过程中不可避免,一开始可以简化成某个人拍板,决定是否接受变更
日常需求
即零散 、随机出现的小需求
文档的简化
在项目开始阶段,文档只保留PRD、设计稿、代码三件套,其他文档都用看板、白纸加上拍照留存来解决
8.4 天下武功,唯快不破
8.4.1 互联网速度到底有多快
8.4.2 烧钱是为了抢时间
计算一款产品的“单用户成本”时,要纳入整个公司的运营成本(含人员等成本),而不是只计算该产品的推广费用
8.4.3 省时间的低成本验证
在一个快速变化的环境下,不断地用最少的时间、成本去获取市场反馈,不断修正前进方向
8.5 与用户一起成长
09 运营:先验证再扩张
9.1 产品与运营的关系
9.1.1 需求、功能到卖点
实质性区别:一个真正以用户为中心,另一个总是在说我
9.1.2 多相爱,少相杀
9.1.3 给运营提需求的模板
9.2 运营工作的分类
9.2.1 不同阶段的运营目标
验证期
产品发布前的筹备阶段,加上发布后到推广前的预备阶段
这个阶段的主要目标是验证产品是否达到了与试产的匹配,即PMF(Product Market Fit)
产品在这个期间要不断修正主打功能,运营主要关注的指标是用户留存,典型的良性表现就是用户用了还想用,成为回头客
爆发期
产品验证完成后的开始大面积推广,即进入爆发期
此阶段产品依然在围绕核心功能进行强化,但用户数会迅速增加,运营工作的主要目标是拉新
运营的主要目标是拉新
平台期
拉新一段时间后,产品进入平台期
产品功能开始扩展,升级2.0版逐渐提上日程
运营工作的主要目标是激活用户,也常常说成“促活”,让用户使用产品的时间尽可能增减
衰退期
进入衰退期以后,产品仅需要维护
运营能做的事情就是想方设法榨取产品的剩余价值
9.2.2 综合案例:星巴克
9.3 大运营的其他职责
9.3.1 产品与销售的关系
产品与销售在创造价值的模式上颇具互补性
9.3.2 服务是广义的用户运营
9.3.3 市场的几种分类维度
旧有市场,也叫存量市场
要有突出的产品优势,比如更便宜、质量更好、获取更便捷等
细分市场,也叫小众市场
介于现有与全新之间,要突出小众特色,找到差异化定位
全新市场,也叫增量市场
要突出产品能解决的问题,此时做品牌推广意义不大,而是要有一个较长的客户培养其
9.3.4 品牌到底是什么
9.3.5 公关是企业的戾气与利器
9.4 产品的生命周期
从验证期到衰退期
产品在“验证期→爆发期→平台期→衰退期”这个完整生命周期的每个阶段,都需要面对和实现不同的运营目标
从定位、需求到品牌
从企业发展层面来看,依次要经历定位、需求、产品、流量、用户、收入、盈利、品牌这些阶段
对应要做的事有:给产品定位→采集需求回来分析→做产品功能剪头产品上市以后要获取流量→把流量转化成有价值的用户→从用户身上获取收入→盈利→沉淀为品牌
想清楚、做出来、推出去
创意设计
问题正确,解决方案靠谱——用户还没用上产品
研发生产
做得出来,不断优化——极少量种子用户用上了内测版本
运营销售
卖得出去,赚得到钱——尝鲜者、早期采纳者使用产品
市场品牌
铺得开,叫得响——主流用户使用产品
10 案例:商业模式、创新与行业
10.1 聊聊商业模式
10.1.1 对比:商业、业务、盈利模式
商业模式:完整讲述了我们创造了什么价值
业务模式:在解决方案层面做得事什么事
盈利模式:怎么赚钱,怎么养活自己的团队
10.1.2 分析100块去哪儿了
10.2 创新那点事儿
10.2.1”活着“就是为了创新
用户只能提出渐进式创新,而颠覆性的创新则要靠产品经理
10.2.2 创业公司的创新坑
这个IDEA不能对人说
我们就差个程序员了
别急,我们要憋个大招
我觉得用户一定喜欢
给我盯着XXX,先抄后超
不怕,我们有资源
找到风口,找对赛道
10.2.3 大型公司的创新坑
高层管理者与基层管理者的矛盾
主流业务与非主流业务的纠结
我们高估了”内部创业“的成功率
赛马选手和团队自身水平的问题
一是承载”新型组织形态探索“的任务
二是”创新文化“的宣导
10.2.4 传统企业的创新坑
设立的新部门成为众矢之的
成立子母公司控股的子公司
内部投资后不知怎么导入资源
不强求公司转型而只须让钱转型
10.2.5 再谈创新者的窘境
10.3 行业案例分析
10.3.1 各种上门与O2O
坐商适合买方市场,行商适合卖方市场
从”行商“到”坐商“再到市场出现细分,变为”混合模式“
10.3.2 知识类共享经济
10.3.3 老年人的广场舞江湖
11 蜕变:从产品助理到CEO
11.1 在人力资源部做产品经理
11.2 产品经理的七层修炼
11.2.1 第一层,需求细化与研发跟进
11.2.2 第二层,主动挖掘与项目管理
11.2.3 第三层,完整产品与大局观
11.2.4 第四层,产品线与带团队
11.2.5 第五层,成功案例与影响力
11.2.6 第六层,商业闭环与全智能管理
11.2.7 第七层,自己成功到助人成功
11.2.8 七层里的三个阶段
11.3 十年后再无产品经理
11.4 归宿:无非广义创业
11.4.1 从产品经理到创业者
11.4.2 体验创业的三种选择
11.4.3 互联网船业的5个启动步骤
11.4.4 互联网船业的地域鄙视链
11.4.5 下一个硅谷在哪里
11.5 从生活态度到社会推动力
11.5.1 先说生活态度
11.5.2 再说社会推动力
12 结束:写在正文之后
12.1 国产产品图书盘点
12.2 重新定义“读书会”
12.3 七印部落翻译的书
0 条评论
下一页