百事可乐。

V1

2022/10/18阅读:42主题:灵动蓝

《人人都是产品经理》读书笔记

人人都是产品经理

Date: October 11, 2022 Status: PM

读后感:

花费了大概一周时间读完了《人人都是产品经理》这本书,收获颇丰,作为大多数产品经理的第一本启蒙书,文笔轻松,读起来很舒服,也让人沉浸。

谈谈收获吧:大概对产品经理这个职业,或者说这一类人有了一定的认识,也希望能够通过对这本书的学习,在后续的生活中,运用一些产品的思想,如作者所说,一切形式都是为了实现目的手段,我认为手段多一些,总比遇事感到捉襟见肘要强,希望自己能够成为这一类优秀的人,共勉!

名词解释:

PM Product Manager(产品经理)Project Manage(项目经理)
PD Product Designer(产品设计师)
PE Product Engineering(产品工程师)
PR Public Relations(公共关系)
项目TRQ Time(项目时间)Resource(项目资源)Quality/Quantity(品质+数量)
WBS Work Breakdown Structure(工作分解结构)
BRD Business Requirements Document(商业需求文档)
MRD Market Requirements Document(市场需求文档)
PRD Product Requirements Document(产品需求文档)
FSD Functional Specifications Document(功能详细说明)
UML Unified Modeling Language(统一建模语言)
UC 用例文档
QA Quality Assurance(质量保证人员):负责产品品质保证的相关工作,比如流程控制,不同于测试人员
PV Page View

书籍推荐:

  1. 《敏捷迭代开发——管理者指南》
  2. 《敏捷估计与规划》
  3. 《用户体验的要素》
  4. 《赢在用户》
  5. 《一目了然》
  6. 《点石成金》
  7. 《胜于言传》
  8. 《设计心理学》
  9. 《情感化设计》
  10. 《交互设计之路》
  11. 《软件观念革命:交互设计精髓》
  12. 《GUI设计禁忌》
  13. 《走出软件作坊》
  14. 《Web信息架构》
  15. 《产品经理实战手册》
  16. 《美第奇效应》
  17. 《别做正常的傻瓜》

培训推荐

  1. 《需求工程》《需求管理》
  2. 《项目管理》
  3. 《流程管理》

Kick Off 会议主题

  1. 项目背景
    • 回忆过去,为什么要做
  2. 项目意义、目的与目标
    • 畅想未来,做成之后有什么好处,解决什么问题即表示成功
  3. 需求、功能点概述
    • 表述现状,具体使用什么方法从“过去”过渡到“未来”
  4. 项目组织架构
    • 让项目组成员互相认识,明确什么问题应该找谁
    • 关键人物、非关键人物都尽量到位
  5. 项目计划
    • 项目时间点与里程碑
    • 各个时段每个人需要做什么事情
  6. 沟通计划
    • 设立规矩及渠道,逼迫团队主动沟通

WBS 模板

PD 要写的文档们

文档名称 文档内容 文档用途 文档面向 文档形式
BRD 市场分析 销售策略 盈利预测 获得认可 争取资源 领导 PPT
MRD 市场/竞品分析 产品功能 优先级 商业目标—>技术实现 领导 Feature List 业务逻辑图
PRD 整体说明 用例文档 产品Demo 技术人员
FSD 产品界面 业务逻辑 技术人员

PRD

  1. 总体说明:
    • 修订历史:修订日期、版本号、说明和作者
    • 项目概述:项目背景、意义、目的、目标;如此PRD不包含全部需求,说明该部分需求是什么,其他需求位置
    • 功能范围:业务逻辑图,描述系统中角色职责,与周边系统关系、全局商业规则
    • 用户范围:涉及角色、系统
    • 词汇表:专有词汇、术语、缩写
    • 非功能需求:性能需求、数据监控需求等
    • 其他说明
  2. UC 部分(用例文档):
    1. UC 概述:
      • 用例的唯一标识
      • 用例名称
      • 业务描述:商业目标、用户目的(为什么做)
      • 需求描述:需要实现的功能点(要做什么)
      • 行为者:使用人
      • 前置条件:使用该用例的前提
      • 后置条件:用例完成的后续动作
      • 其他说明
    2. UC 主体:
      • 界面描述:给出截图、洁面各种元素说明,与Demo关联
      • 业务规则:通用规则,限制条件
      • 流程描述:分为主干、分支和异常。描述用例发生过程中,由什么事件触发,系统与用户之间产生何种交互步骤。尽量以时序图、活动图形式呈现。
    3. 要求:无歧义、完整、一致、可测试
    4. UC 模板:

评审:

  • 需求评审:包括PRD评审,UC评审,Demo评审
  • 设计评审:概要设计与详细设计完成后,由开发描述需求理解,展示设计文档,PD,测试进行评审
  • 测试评审:测试TC编写完成后,PD,开发进行评审

Bug 级别定义

建立文档规范

  • 需求规范类:
    • PD 做什么:对产品和团队 PD 工作内容的总结,让新人快速了解工作职责
    • 用户体验规范:
      • 交互规范:控件规范;判断规则
      • 视觉规范:页面大小、字体字号、颜色编码
      • 文案规范:语言风格,语法模板,常用操作标准说法
    • 通用原则
  • 需求管理类:
    • 用户调研
    • 产品需求列表:产品需求列表模板、需求管理文档模板,需求状态变化流程图等
    • 产品信息架构:产品的页面或功能之间的关系,如网站地图,导航结构等
  • 流程管理类:
    • 日常发布流程
    • 变更事件流程:紧急发布流程、需求变更流程,需求打车流程等
  • 项目管理类:
    • 项目管理制度:产品会议制度,各岗位权责利
    • 项目任务书
    • Kick Off 的 PPT
    • 项目组织结构
    • 项目 WBS:作者推荐软件“WBS Chart Pro”
    • 项目日报周报:今日/本周要闻,明日/下周看点,当前问题,所需支持,项目进展
    • 项目发布预告与公关
  • 日常工作类:
    • 会议记录:会议决议、遗留问题、行动方案
    • 个人日报周报:分享工作情况

各类会议重要性:

  • 产品会议:必须,决定产品方向,参会人员越齐越好
  • Kick Off会议:最好有,鼓舞士气
  • 需求评审:重要
  • 设计评审:取决于开发人员水平,开发较强可省略,开发较弱可采取由开发进行需求描述,PD进行细节提问的形式,既能使开发了解需求,又能降低不进行设计评审的风险
  • TC评审:仅次于需求评审,若测试能力不够会增加PD工作量
  • 功能评审:必须,可采取线下方式,若是重要项目,开产品演示会
  • 发布评审:可由开发经理决定

敏捷方法(作者推荐书籍:《敏捷迭代开发——管理者指南》和《敏捷估计与规划》)

  • 有计划,更要“拥抱变化”:项目计划不断修正,在一开始的计划中留有弹性
  • 迭代周期内尽量不加任务:当前迭代不变,下次迭代待定
  • 集中工作,小步快跑:集中办公,站立晨会等形式
  • 持续细化需求,强调测试:更早的测试,重度的测试,不断细化和补充需求,发现业务逻辑中的限制条件,异常流程等
  • 不断发布,尽早交付:让需求方不断的、尽早的看到结果,并给予反馈
  • 一句温暖的话:“无论最终发现了什么,我们必须理解并完全相信:每个人在其当时所处情况下,在其能力范围中,做了最大的努力”

四、大产品,大设计,大团队

产品之大

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

    用户分类:

    1. 创新者:新鲜感强,在产品初期,可帮助产品快速成长,但如果不能够持续的输出新鲜感,可能会很快的离开
    2. 早期追随者:观念新颖,需求目的较强,需要迅速能够解决其问题的产品,如果产品能够达到要求,有一定的忠诚度,并且会从需求出发为产品提出意见,对产品发展价值较大。产品上市后的早早期,可偏向“专家用户”
    3. 早期主流用户:大规模产生商业价值的用户群。产品进入该阶段,应逐步面向“中间用户”和“新手”,偏向简单易用
    4. 晚期主流用户:对于新产品有抵触心理,产品进入定型阶段,需要市场营销发力,该阶段投入人力也较小,产出快速、可预期,收割商业回报的大好时期
    5. 落伍者:最后一批用户,产品逐渐退出市场,可以更加注重利益,发挥产品最终的余热
  • 空间之大:商业、产品、技术

    1. 商业:市场、销售、服务;销售渠道、价格策略、促销策略、服务方式等
    2. 产品:产品设计、交互体验、产品运营;功能范围、交互流程、视觉表现、运营手段
    3. 技术:开发、测试、运维;稳定性、性能、Bug数量

设计之大

  • 产品设计的五个层次:

    1. 战略层:明确商业目标和用户需求,找准商业上价值切入点,平衡两者之间的冲突
    2. 范围层:软件类产品确定功能范围,网站类产品确定内容范围
    3. 结构层:规划产品各部分之间的关系。软件类产品明确交互设计,网站类产品明确信息架构,常见产出物为软件业务逻辑图、网站站点地图
    4. 框架层:用户能看到的东西,软件界面设计,网站导航设计,以及两者都有的信息设计
    5. 表现层:视觉设计和内容优化
  • 设计的“现实与浪漫”

    Donald Norman,设计目标的三个层次:本能水平设计、行为水平设计、反思水平设计

    一些基础原则:

    1. 反馈:动作前的可预测、动作中的积极响应、动作后的可评估
    2. 容错:一些貌似多余的强制性设计,不可逆操作可以后悔
    3. 简化:充分利用用户已有的知识,利用心智模型,利用标准化,利用一切

团队之大

做的事情较小,不太重要,一个人可以负责多项工作;做的工作越来越多,越来越大,分工明确可以提高效率,也可以提高质量,专业的人来做专业的事。

从概念设计到信息架构

概念设计的产出物是产品概念图,节点通常为需求采集之后,需求筛选之前,常用一下两种方式产出:

  1. 思维导图改画:需求采集后,画出思维导图,整理分类需求
  2. 会议讨论

产品概念图主要描述内外关系:

  1. 外界关系:上下级系统、并列系统关系;勾勒产品所处产业链结构
  2. 内部关系:产品模块关系;不同角色的身份

文案设计

文案问题的三个阶段:

  1. 低级阶段:错别字,病句,标点符号错误
  2. 中级阶段:用词不统一,不准确
  3. 高级阶段:语言风格,产品气质不统一

好产品还需市场化

包装、定价、促销、销售、渠道

  1. 渠道:直销和分销;通过渠道销售的产品,改动产品时,需要考虑公司内部渠道管理人员、及渠道商的培训成本;渠道销售代表终端用户对互联网应用能力不足,需要改变设计思路;渠道的终端用户一般是企业,需要考虑企业与个体用户的差异;渠道介入代表流程繁琐,需要相应的系统支撑;保证渠道服务质量,进而控制合作公司保障产品的整体体验
  2. 版本细分
    1. 做功能区分,打细分市场:手机型号、电脑硬件级别等
    2. 促进销售,利用消费者心理,策略性的做出“炮灰版”
  3. 水平营销:
    1. 需求纬度
    2. 目标维度
    3. 地点与情景维度
    4. 时间维度
    5. 有型的产品或服务
    6. 品牌特征
    7. 使用或购买

如何与工程师合作

  1. 流程:喜欢被规则管理而非被人管理
  2. 沟通:避免情绪化。每个人都希望自己被认同,可能导致思路变形,不再考虑产品的优劣,而是为了说服对方;有些人会将对人的反感转移到对此人观点的反对上;沟通的主动性会决定互动的氛围,也会决定信息是否顺畅
  3. 提高自我修养:文档质量要足够高,准确,全面,简洁,及时更新,保持最新;对不同的工程师可以讨论不同的内容;让业务人员冷静下来,让技术人员兴奋起来。

最好的资源:老板

事情我做,黑锅你背

  1. 问答题:问老板怎么做
  2. 选择题:收集资料,给出几种方案让老板选择
  3. 判断题:给出解决方案的同时,加上自己的建议,学习老板的判断方法;老板给出授权后,可以帮忙承担责任

默默奉献的团队

  1. 法务:政策法规相关问题、知识产权问题
  2. 财务:财务流向(用户、经销商、厂商),预付款尾款处理、发票开具、退款流程等
  3. 行政与IT:后勤团队

产品经理应该是管理者吗

  • 优势:

    1. 话语权
    2. 获取信息
    3. 争取资源
  • 劣势:

    1. 行政工作
    2. 脱离群众
  • 解决方法:

    在专业路线上拥有高级别,对产品、业务的决策有充分的话语权;参与管理会议的业务讨论;拥有临时的资源支配权,并给管理层提供同事的考核建议,但不负责行政工作,与同事打成一片,以产品证明自己

    如何让团队更开心

    项目经费使用:

    1. 大中之小不如小中之大:高级的小玩意儿
    2. 有用的不如无用的:吃不掉、用不掉、送不掉、扔不掉
    3. 需要的不如想要的:想买却舍不得买
    4. 有选择不如无选择:会有“放弃了另一种选择的患得患失”
    5. 小奖不如没奖:人做事的内在动力与奖励挂钩,就变成了经济交易,就会有性价比的衡量,所以小奖不如不奖;与之相反,小惩罚会让人觉得心安理得,还不如不惩罚
    6. 晚说不如早说:在期待的过程中,让员工的快乐最大化
    7. 一次送不如两次送:好消息要分开说,坏消息要一次说
    8. 公开不如不公开:薪资会互相比较,导致心理不平衡
    9. 涨工资不如发奖金:有较大的回旋余地,且涨工资的激励效果不大

别让灵魂跟不上脚步

触及产品的灵魂

  • PD的三个境界:
    1. 产品帮助我们
    2. 产品与我们互相帮助
    3. 我们帮助产品

可行性分析三部曲

我们在哪;我们去哪;我们怎么去

  • 我们在哪

    1. 市场扫描:PEST分析

    2. 竞品分析:

      1. 上网搜
      2. 行业分析报告
      3. 咨询公司
    3. 自我剖析:SWOT分析

  • 我们去哪:根绝客户需求进行方向确认

  • 我们怎么去:简单来讲就是“策略”

我们急需靠谱的会议

  1. 不要试图在一个会议中解决很多问题(目标明确)
  2. 确认参会人员,不漏人,不多人;会议开始前再次确认是否能够到场
  3. 会议邀约提前进行,并且附上会议文档初稿,对于重要人物可重点确认,必要时可提前面谈,节约会议时间
  4. 明确的主持人:掌握整体时间进度、控制每人的发言时间、均衡发言机会,保证议题不走偏;记录人:如实做好记录,尤其是“会议决议”和“遗留问题”
  5. 所有人提供意见,少数人讨论,一个人拍板决定

产品经理的自我修养

爱生活,有理想,会思考,能沟通。

  1. “充分沟通”是不存在的
  2. 沟通不是为了说服,而是为了更好地认识世界:每个人都无法保证自己的观点是更好的,观点不同很正常,关键是要充分表达,在表达的过程中磨合,找出最优解;推销自己的想法,最好的方式是引导对方主动说出来

产品经理主义

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

分类:

设计

标签:

产品设计

作者介绍

百事可乐。
V1