产品读书《人人都是产品经理 1.0》

版权声明:本文为博主原创文章,遵循 CC 4.0 by-sa 版权协议,转载请附上原文出处链接和本声明。
本文链接:https://blog.csdn.net/Julialove102123/article/details/81257444

这里写图片描述

核心技能: 沟通能力、无授权领导能力、学习能力、商业敏感度、热爱产品、注重细节,追求完美、日常产品管理能力
#1 写给-1到3岁的产品经理

为什么要做产品经理

  • 坏产品无处不在:垃圾桶、路标、盲道、洗手间的门、
  • 好产品能改变世界:马桶

我们到底是不是产品经理

  • 产品:用来解决某个问题的东西。可以是无形的服务,也可以是有形的实物。
  • 产品:同时解决用户的问题和公司的问题的东西。
    这里写图片描述

入行

  • 做产品的大前提是喜欢做产品(热爱产品)
  • 找准自己现在的位置:有没有激情,是否够机灵、好学,逻辑思维是不是清晰,沟通表达是否顺畅等
  • 入行切入点:现在本职工作上找到与产品有关的事情上做一些尝试,并考虑先从产品经理周边的职位做起。

一个产品经理的-1到3岁

  • 入行半年后,学习“怎么做”
  • 入行一年后,开始问“做多少,怎么做”
  • 入行两年后,项目与团队
  • 入行三年小结,战略与修养

2 一个需求的奋斗史

需求的奋斗史:从需求被发现到决定实现的过程。
这里写图片描述
需求采集的过程:明确目标、选择采集方法、制定采集计划、执行采集、资料整理。之后进入需求分析阶段。
需求分析:从用户提需求出发,找到用户内心真正的渴望,再转化为产品需求的过程。

2.1 从用户中来,到用户中去

2.1.1 “从用户中来,到用户中去”的含义:

  1. 需求或直接或间接都是“从用户中来”,所以要“到用户中去”
  2. 产品的设计过程是一个闭环,需求的源头是用户,产品发布之后,在整个产品的生命周期中,仍然要不断的“到用户中去”收集反馈,作为产品改进的依据。

正确地理解用户,是产品经理最重要的基本素质之一。
发现一个问题,然后设法将其转化为一个任务来解决。
###2.1.2 人类为什么有需求

因为生活中存在太多的问题,从而导致了不满意,而问题就是“理想和现实的差距”,于是,人类很自然地产生“减少甚至消除这个差距”的愿望,这就产生了需求。

2.1.3 用户vs客户

用户:user,有时也叫终端用户end user,是使用产品的人。
客户:customer,是购买产品的人,也是为产品付钱的人。

不同的用户有重要程度之分,我们必须、也只能有所偏重。
试图满足所有用户的需求是一个灾难,那会让产品变成一个臃肿不堪、谁都不满意的四不像。
我们无法满足所有用户的需求。
优先满足哪些用户需要和产品的商业目标结合起来考虑。
###2.1.4 描述用户-人物角色persona

人物角色

2.1.5 用户研究的方法

用户研究的方法.png

  • 横向:用户的说与做
    a. 怎么说表现了目标和观点,怎么做反映了行为,用户怎么说和怎么做经常是不一致的。
    b. 既要看用户怎么做,也要听用户怎么说,虽然他说的也不一定是真话。
  • 纵向:定性与定量
    a. 定性研究可以找出原因,偏向于了解;
    b. 定量研究可以发现现象,偏向于证实。

案例:
第一轮,听用户定性地说,确定产品的方向,做什么?随机抽样40个用户做访谈,据此写出需求列表。
第二轮,听用户定量地说,确定需求优先级,先做什么?投放了20万份调查问卷,确定了需求优先级的排序。
第三轮,看用户定性地做,要先做的那几个需求,应该怎么做?一边设计,一边陆续找了10个用户来验证,做可用性测试。
第四轮,看用户定量地做,根据产品的用户使用情况做数据分析,不断改进产品。
但是,一般公司是不会在用户研究上投入这么多时间与人力,更多会视情况采用简化方案。

要坚决杜绝“经组织研究决定,用户需要一个xx功能”这些事件的发生,要实实在在把用户当作需求之源。

2.2 需求采集

这里写图片描述

2.2.1 定性地说:用户访谈(开放式问题较多)

常见的问题和决策:
(1)“说”和“做”不一致的问题----->说+做
(2)样本少,以偏概全的问题---->增量的方式
(3)用户过于强势—>引导到主题或尽快结束对话
(4)我们过于强势—>牢记访谈的目的,管好自己的嘴

2.2.2 定量地说:调查问卷(封闭式问题较多)

时间<5min;(简单题、较为敏感的放中间、个人信息放最后)
常见问题和决策:
(1)样本偏差(样本与目标用户)
(2)样本过少
(3)问卷内容的细节(无引导性、)

2.2.3 定性地做:可用性测试

步骤:
(1)招募测试用户(尽可能代表用户群体)
(2)准备测试任务
(3)测试过程(观察用户操作过程)
(4)询问测试者的主观看法和感觉;
(5)研究和分析
常见问题和对策:
(1)可用性测试做的太晚—>(各个阶段都要做)
(2)一定要做可用性测试
(3)测试产品而不是用户
(4)用户“发声思维”,我们不做引导,只做观察和记录,

2.2.4 定量地做:数据分析

常用用户使用产品日志分析、客户管理系统里的信息、网页访问情况的统计信息等;
常见问题和对策:
(1)科研和实际生产的区别
(2)不要误读数据
(3)时刻准备做数据分析
需求:一手需求 > 二手需求
单项需求卡片:
一张单项需求卡片描述了一个用户的需求到底包含哪些内容,重点是描述用户场景,谁在什么时间,地点产生了何种需求。
这里写图片描述

需求采集

  • 现场调查
  • AB测试
  • 日记研究
  • 卡片分类法
  • 自己提需求(需求驱动学习)

2.3 需求分析

用户需求 vs 产品需求(转化即需求分析)
Y理论
攀梯术
满足需求的三种方式

  • 提高现实。常用的方法是开发某种产品,也是最笨的方法。
  • 降低理想。不要忽视精神的力量。“打预防针”、“丑话说在前头”等。
  • 转移需求。因为人的注意力是有限的,所以引导用户去关注其它事物
    这里写图片描述
    1、需求转化(用户需求转化为产品需求–头脑风暴)
    产品需求列表(feature lists功能列表)
    这里写图片描述
    每行是一个产品需求,每列是产品需求的一种属性
    用户需求和产品需求(多对多)
    2、确定需求基本属性
    这里写图片描述
    需求种类:
    产品需求=产品功能需求+产品 非功能需求
  • 分类:新增功能、功能改进、体验提升、Bug修复、内部需求等;
  • 层次:基础、扩展(期望需求)、增值(兴奋需求)–KANO模型
    3、分析需求的商业价值:方法
    加权平均
  • 重要性:
  • 紧急度:
  • 持续时间:
  • 商业价值(上也有相机)
    4、初评实现难度
    工作量、开发量(人天)
  • 绝不能因为某个需求的商业价值很大就马上去做,也不能因为另一个需求的商业价值不大就不做。
  • 绝不能因为某个需求的实现难度很小就马上去做,也不能因为另一个需求的实现难度很大就不做。
  • 一切皆看性价比(商业价值/实现难度(开发量))。
    备注:
    信息架构IA-为信息和用户认知之间搭建一座桥梁,实习直观表达的载体,是研究信息的表达和传递
    “5±2模块”二级模块

2.4 需求筛选

这里写图片描述
做项目,终极目标时多快好省。即范围大、时间短、品质高、资源省
2.4.1 需求打包

  • 最好打包类似的功能点。
  • 需求依赖,功能相互之间有依赖关系。
  • 需求的粒度大小问题。
    2.4.2 BRD文档

BRD:business requirement document,商业需求文档
PRD:product requirement document 产品需求文档
MRD:market requirement document 市场需求文档

项目背景:我们在哪里为什么要做这个项目,解决什么问题,主要列出一些数据说明项目的必要性。
商业价值:我们去哪里?重点!老板最感兴趣的。做这个项目以后有什么价值,还可以预测一下相关数字的变化,提出这个项目的商业目标。
功能需求描述:我们怎么去?通过做哪些事情来达到目标,把打包好的需求描述一下,可以用功能列表来表达,最好能画出业务逻辑关系。
非功能需求描述:如果有,提一下重要的非功能需求。
资源评估:第二大重点!说清楚达成项目的目标需要多大的花费。
风险和对策:提出潜在风险,老板会给出对策。
老板关注性价比:商业价值&资源评估
马云:少做就是多做

2.5 产品迭代

需求的周期
这里写图片描述
2.5.2 需求管理的附加值
统计每个“提交人的”需求数量
统计“提交时间”、“发布时间”等信息
统计每个“模块”的需求数量
统计每个“分类”的需求数量
统计需求的“商业价值”、“性价比”变化
这里写图片描述


3 项目的坎坷一生

这里写图片描述

3.1 从产品到项目(维度1)

项目:只会进行一次,包含多项相互关联的任务,并且有绩效、时间、成本和范围限制的一项工作。

做项目 VS 做产品

  • 从生命周期的角度看
    产品(长)-项目(短)
  • 从具体要做的事情看
    产品(不断修正自己的判断,给出适宜的创新)
    项目(有明确的目标,更注重计划与控制)
  • 从产出物的角度看
    项目的产出物经过改造会成为通用的产品,有的产品经历个性化定制实际也是一个项目。
    产品经理VS 项目经理
  • 产品经理product manager:内部驱动。做正确的事,靠想。
    项目经理project manager:外部驱动。把事情做正确,靠做。
    产品经理管项目

一个事物必然有它的两面。如果你只看到了一面,说明你只看到了一部分,这时你一定要跳出去,寻找另一面,之后再努力寻找“对立”背后的“统一”。
##立项
做项目的本质是在保证品质的前提下,在时间要求、人财物花费、项目范围三点上做平衡。
1 团队组建

  • 项目督导委员会(买单背锅-获批准进行任务执行)
    • 项目经理
      • PD
      • 开发经理
      • 测试经理
      • UE
      • 服务团队

2 计划确定

  • 评估“工作量”–“三点估算法”(最乐观、最悲观、最可能的工作量)
  • 推出“工期”
    注:关键路径、里程碑(监控点)

3 沟通

  • 周期:日、周(Eg:晨会、日报、评审会、项目变更申请、发布预告及公告)
  • 渠道(考虑成本效益):会议、邮件
  • 发起者
  • 参与者

项目启动大会

  • 时间:<15min;
  • 内容:
    - 项目背景
    - 项目意义、目的与目标
    - 需求、功能点概述
    - 项目组织架构
    - 项目计划(项目时间点、里程碑、资源【每个人每个阶段干什么事】)
    - 沟通计划

4 WBS(Work Breakdown Structure):工作分解结构

需求

1 需求文档写作:

BRD 商业需求文档 最早期 PPT;老板、获得认可,争取资源;
MRD 市场需求文档(Feature Lists、业务逻辑图) ;老板、商业目标到技术实现
[PRD 产品需求文档,技术人员](原型+各种图)(https://blog.csdn.net/Julialove102123/article/details/82597574)
FSD 功能详细说明,技术人员

2 评审

  • 需求评审:PRD评审、UC评审、 Demo评审的统称。于需求的相应部分完成以后进行,评审会上pm把PRD和UC说给开发和测试听, Demo评审则由UE主讲。
  • 设计评审:在概要设计与详细设计完成之后进行,由开发工程师把对需求的理解以设计文档的形式说给pm、测试听。
  • 测试评审:俗称TC评审,是在TC编写完成、测试开始执行之前进行,由测试工程师把对需求的理解以TC的形式说给PM、开发听。

需求评审会需要:一个能做决定的人;一个与此项目有关的产品接口人。
需求评审通过:里程碑

开发

测试

这里写图片描述
TC
TC的内容:测试目标、测试环境、输入数据、测试步骤、预期结果、测试脚本等。

bug
1、bug级别的定义标准
2、bug状态流转图
这里写图片描述

发布

SVN管理员:代码版本管理员、负责项目的每日代码更新。
发布标准
发布过程
发布手续和各种表签字画押
项目发布公告!!!安慰一下众战士!!!
项目总结!!!

3.1 项目管理(维度2)-文档管理、流程管理、敏捷方法

计划与控制,就是项目管理。

PART1:文档管理

  • 建立自己的文档规范
    这里写图片描述

  • 文档模版的作用
    1 让经常看同类文章的人提高效率
    2 让写文档的新手快速上手
    3 让写作者不会漏考虑某些内容

  • 产生文档版本管理的本质需求是多人合作,协同办公。(SVN)

PART2:流程管理

流程的本质:
当年的英雄把自己的个人经验转变成显性知识表达出来,而对于经常做的事情,就可以用流程这种形式固化、传承,后人在做这些事情的时候起码不会太无助。在这点上,规范、模版的作用也类似,这也是团队核心竞争力的一种。
注:
UED:used.taobao.com
DCP (Decision Check Points)商业评审点
LMT(Life-Circle Mangement Team)生命周期管理团队
评审:
商业评审:产品会议、功能评审
技术评审:需求评审、设计评审、测试评审、发布评审

PART3:敏捷方法

  • 有计划,更要“拥抱变化”
  • 迭代周期内尽量不加任务
  • 集中工作,小步快跑
  • 持续细化需求,强调测试
  • 不断发布,尽早交付

敏捷沟通:在任何情况下,我们都要做好手头的事情,确保“这事就算对公司来说黄了,我们也要通过这件事情有所收获。”

**注:**瀑布模型vs敏捷方法

物竞天择适者生存

1 老板项目(TRQ)

  • 时间T是给死的。我们最常犯的错误就是把老板的偏好当成规则。老板只是一时说最好怎样,结果我们理解成必须怎样,那就亏大了。
  • 数量Q(项目范围)是可变的。列出需要的功能、优先级、所需的资源,让老板选。
  • 资源R是丰富的。项目优先级较高。

4 我的产品,我的团队

这里写图片描述

4.1 大产品,大设计,大团队

4.1.1 产品之大

  • 时间之大:产品生命周期

    • 创新者innovators:新鲜感强,消费能力强,忠诚度不高,需要新鲜的东西不断刺激。
    • 早期追随者early adopters:观念比较新,需求目的性强,需要迅速能够解决问题的产品。信息达人,不盲目试用,忠诚度高。
    • 早期主流用户early majority:实用主义者,是产品大规模产生商业价值的用户群。
    • 晚期主流用户late majority:对新产品存在抵触。
    • 落伍者laggards:附加值较低的最后一批用户。
      这里写图片描述
  • 空间之大:商业、产品、技术

    • 商业:在公司里主要由市场、销售、服务等部门来考虑,他们决定产品的销售渠道、价格策略、促销策略、服务方式等。
    • 产品:包括产品设计、用户体验、产品运营部门等部门来考虑,他们决定了产品的功能范围、交互流程、视觉表现、运营手段等。
    • 技术:主要由开发、测试、运维等部门考虑,他们决定了产品的稳定性、性能、bug数量等特性。

4.1.2 设计之大

产品设计的五个层次

  • 战略层:明确商业目标和用户需求,找准方向,重点是解决两者之间的冲突,找到平衡点。
  • 范围层:明确“做多少”。对于软件类产品,确定功能范围。对于网站类产品,确定内容范围。
  • 结构层:考虑产品的各个部分相互之间是什么关系。
  • 框架层:用户可见的东西。对于软件类产品主要是界面设计,对于网站类产品主要是导航设计,两者都有的是信息设计。
  • 表现层:视觉设计和内容的优化,比如页面配色、字体字号等。

设计的三个层次

  • 第一个层次,本能水平的设计是基础,产品要有用。
  • 第二个层次,行为水平的设计是保证,产品要能用。
  • 第三个层次,反思水平的设计是升华,是难以捉摸的“用得爽”。

4.1.3 团队之大

这里写图片描述

  • 如何设计各种职位,让各种人(职员)与各种事(职责)相互匹配。
  • 接口人存在的价值
  • 矩阵型组织

4.2 产品团队

这里写图片描述
规划师VS 设计师

  • 规划师更多的是“结构化思维”,保证产品有用,能满足用户的某些需求,让产品“从无到有”。
  • 设计师更多的是“形象化表达”,保证产品好用,能让用户用起来舒服,让产品“从有到优”。

用户体验部门

  • 用户研究员user researcher:利用各种方法进行用户研究,给产品决策提供建议。
  • 交互设计师interaction designer:负责人机交互页面、用户操作流程的设计,典型的工作有导航设计、信息设计,必须了解很多商业的内容,理解功能的商业价值。
  • 视觉设计师visual designer:主要做视觉设计,即用户第一眼看到的效果,比如页面结构、配色方案、字体字号、按钮的形状、颜色、大小、质感等。
  • 前端工程师web developer:运用前端技术进行web开发,实现产品体验的良好传达。

运营师

4.3 商业团队

团队组成:市场、服务、营销

4.3.1 好产品需要市场化

  • 定价与促销

当自己对某个领域不熟悉的时候,做起事来总会把问题想象得很复杂,把自己知道的所有知识都用上,而真正的高手,是可以一下子就找出问题的关键,然后用最简单的办法搞定。

  • 销售与渠道

销售:直销vs分销(通过渠道(代理or经销))
注:代理:赚佣金;经销:赚差价

  • 产品的版本细分
  • 做功能区分,打细分市场。
  • 为了促进销售,利用消费者心理,纯策略性地作出“炮灰版”。
  • 水平营销

纵向营销是进化,水平营销是革命;

  • 需求维度
  • 目标维度
  • 地点与情景维度
  • 时间维度
  • 体验维度
  • 有形的产品与服务
  • 品牌特征
  • 使用或购买
    ###4.3.2 我们还能做什么
    数据分析
    提供支持,提供核心功能与卖点
    部门视角
  • 服务部门是为昨天的利润工作,给已经购买产品的客户提供承诺的价值。
  • 销售部门是为今天的利润工作,把产品变成利润,争取更多的客户。
  • 开发部门是为明天的利润工作,确保明天我们有优秀的产品可以卖。
  • 研究部门是为后天的利润工作,了解趋势、发展科技,保证永远处于领先的位置。

4.4 技术团队

  • 开发团队:负有架构、编码等职责
  • 测试团队:做功能、性能等各种测试等工作
  • 运维团队:管理产品的数据库、服务器、软件配置

合作:超级理性的人很明白“没有规矩,不成方圆”的道理,他们喜欢被规则管而不是被人管。
##4.5 支撑团队
老板、财务、法务、行政

让老板做问答题➡️让老板做选择题➡️让老板做判断题。

5 产品的灵魂:战略

5.1 说战略

产品和产品经理(产品帮PM,互相帮助,PM帮产品)

战略如何炼出来

  • 价值观Value为根基
  • 思考公司或产品的使命Mission愿景Vision

培养大局观:站得高看得远

  • 帕累托改进

5.2 制定战略:可行性分析

产品战略的具体制定,在项目管理里叫“可行性分析”,在产品设计层次的角度叫“战略层”,在公司层面可能叫“战略规划”。
完成“可行性分析”,也只是决定“做不做”,还完全没到“做多少”、“怎么做”的阶段。
###(1)我们在哪儿

  • 价值观

  • 使命

  • 愿景

  • 行业(市场扫描)

    PEST分析

  • 竞争对手(竞品分析)

a $APPEALS分析法:太过冗杂
b 上网搜相似产品+看行业分析报告+咨询公司

  • 自身情况(自我分析):行业积累、技术积累、缺点

SWOT分析法

(2)我们去哪儿

  • 细分市场是什么(需求场景)?

需求层次
战略管理和市场细分方法:安索夫矩阵、BCG矩阵、波特五力模型、GE矩阵、战略地图、SPAN战略定位分析、价值链分析法等
电子商务三流:信息流、资金流、物流

  • 目标用户是谁?

  • 解决他们的什么问题(需求)?

    注释:

    CRM 用户关系管理软件
    OA 办公自动化软件
    SCM 供应链管理软件
    HRM 人力资源管理软件
    ERP 企业资源计划

(3)我们怎么去(策略)

  • 用什么产品满足需求?
  • 产品的核心竞争力?

5.3 执行战略

1 产品路标规划Roadmap(指明方向)
这里写图片描述
2 靠谱的会议(修正方向)

  • 开会和做产品是一样的,不要试图在一个会议中解决很多问题。
  • 大会决定小事,小会决定大事。大小只参会人数。
  • 要想让会议不流于形式,就要把会议本身变成形式。
  • 所有人提供意见,少数人讨论,一个人拍板。《罗伯特议事规则》
  • 会议记录
    这里写图片描述

5.4 绩效考核

SMART原则

  • 具体specific:绩效考核要切中特定的工作指标,不能笼统。
  • 可度量measurable:绩效指标是数量化或者行为化的,验证这些绩效指标的数据或信息是可以获得的。
  • 可实现attainable:绩效指标在付出努力的情况下可以实现,避免设立过高或过低的目标。
  • 现实性realistic:绩效指标是实实在在的,可以证明和观察。
  • 时限time bound:注重完成绩效指标的特定期限。
    产品设计的好坏是假的,用户体验的好坏也是假的,只有商业利益的多少才是真的!

多个目标间权衡:产品设计、用户体验都是假的,只有商业利益是真的!

6 产品经理的自我修养

就业保障会降低一个人的竞争力,职业保障可以提高竞争力。假设有一天,公司突然不需要你了,这时候你不用去找工作,而是有一堆公司马上排着队请你去,这才是真正的保障。

  • 个人品牌建设
  • 只有方法,没有答案。
  • 会思考,活到老学到老
  • 沟通不是为了说服,而是更好地认识世界。

提需求用户的分析思路

骂得人是不是典型用户?他的观点能代表多少人?他的影响力有多大?他是不是只是“嗓门大”的用户?他说的是不是解决方案?他的本质需求是什么?把他的需求加入需求列表里应该标什么级别?什么属性?…

解决问题的通用思路

为了什么?做什么事,解决什么人的什么问题?何时做?谁来做?效果如何?

  • 为了什么?
    做某件事情“为了什么”,是大前提。
  • 做什么事,解决什么人的什么问题?
    事前需要考虑的,其中“什么问题”和“什么人”是指用户需求和目标用户,“做什么事”是从用户需求转化而来的产品需求。
  • 何时做?谁来做?
    事中关注的重点。项目和团队,重点是计划、控制和执行。
  • 效果如何?
    事后需要讨论的。主要是总结、反馈一类的观点,都是对这个问题的回答,想清楚了才能持续改进,不断提高。
展开阅读全文

没有更多推荐了,返回首页