不为有趣之事,何遣有涯之生
不失其所者久,死而不亡者寿

读书笔记 启示录(第2版)

启示录2

前一阵子在设计新一代的项目协作平台时,在做一些关于新组织架构模式研究和产品开发过程优秀方法论研究,想起以前看过的启示录一书,里面针对互联网产品的开发有许多宝贵的经验之谈,然后发现该书已经与时俱进的出了第二版,于是买了刷了一遍,与第一版相比增加和调整了不少内容。

这本书的副标题是:如何创造用户喜欢的产品,打造伟大产品的灵感、方法与工具 ,非常值得产品从业者、项目管理、企业管理者去阅读。以下是我个人阅读后对文中的一些重点知识摘记,希望对你有用。

来自顶尖科技公司教训

在如何开发产品上,优秀公司与大多数公司有天壤之别。

每个优秀产品背后

不要以为国外没有996工作氛围,那么所有的产品开发都是朝九晚五进行的,那些耳熟能详的优秀产品背后其实的历程都是难度极大的,参与的团队也都是开足马力,贡献了超长的工作时间,只不过不是强行996加班,主要是自愿加班或在家中办公完成的。

技术驱动型产品

本书主要的讨论对象还是技术驱动型产品,而不是老板驱动或销售驱动的模式。
技术驱动的一个显著特征就是拥抱技术变革作用,团队保持始终如一创新精神。

初创型公司

对于初创型公司来说,最重要的事情是实现公司产品PMF工作,即完成产品和市场契合,从而生存下来,专注力重点应该放在产品上。

成长型公司

成长型公司的一个目标就是快速扩张,形成规模化,直至成功。这个阶段对于绝大多数公司来说都是极其困难的,不过令人欣慰的是,公司到了这个阶段,至少实现PMF,且发展的不错。值得注意的是,这个阶段初创期的领导力机制将失效,需要引入一些规范与制度。

成熟型公司

到了这个阶段的公司,基本也是行业内的独角兽了。这个时候公司要做的就是始终如一保持产品创新,公司发展到一定程度,原业务增长都会出现乏力,会有新的入行者或产品替代者出现,企业想要获取持续增长,必须不断尝试新的市场,不断寻找第二条曲线。这个阶段领导力机制将以企业文化和价值观为主。

导致产品失败根源

  • 瀑布流式产品开发:相信大家都在吹捧敏捷式开发,且不说我见过的大多数团队敏捷都是伪敏捷,及时是真敏捷的那些团队,也只有在需求到了产品团队才进行敏捷,而这之前和之后环节都还是传统的瀑布流模式,即敏捷只出现在研发环节,难道产品研发只和研发有关吗?
  • 创意来源自销售或利益驱动:导致偏离产品初心,最后变成四不像。
  • 详细优先级路线图:未来不可预估,这种路线图几乎很难执行到底。
  • 忽视很多创意是无效的:实践证明,至少一半以上创意是无效的,有效的创意也至少需要几轮迭代。
  • 产品管理主要工作是收集需求并文档化:这与真正的现代科技产品管理完全是南辕北辙,这种工作根本不需要团队最具才干的人去做。
  • 产品设计参与的太晚,只能把口红涂在猪嘴上:实在是太形象,我见过的大多数设计师都是对着原型画设计图,毫无灵魂而言。
  • 工程师只写代码的话,至多只发挥50%作用:能把这50%发挥好的公司已不多,如果能挖掘出另外50%才对得起薪资普遍较高的工程师们。
  • 把产品当作项目输出,忽视了结果:如果最终发布的某些东西,但它却与目标不符,那发布它的意义何在?
  • 把风险拖到最后:上线后才发现产品不是/用户客户想要的。
  • 浪费组织的机会成本:如此之多的公司花费了大量时间和金钱却鲜有回报。

精益与敏捷开发的本质

请牢记一句话:产品打造没有银弹。
精益与敏捷开发本质包含如下三大原则:

  • 及时解决风险,不要拖至最后。
  • 产品定义和设计是交叉进行。
  • 一切核心是解决实际问题,不是功能实现。

这三个原则,也是贯穿本书的三大原则,很多章节都有体现。

关键概念

本书中罗列了一些新的概念和对一些常见概念重新解读,为了大家便于理解,统一罗列下。

  • 整体产品:产品是一个非常整体,全面的定义,而不应该仅仅关心需要实现的功能。
  • 持续发现和持续交付:不仅仅是研发流程敏捷化,产品整个流程都应该遵循敏捷化,充分发挥设计师、工程师作用。
  • 产品发现:主要包含4个方面,客户价值:用户会为我们的产品买单吗?;易用:用户知道怎么使用我们的产品吗?;可行性:我们工程师能够实现;干系人价值:利益相关者会支持这几款产品吗?。
  • 原型:原型类型有很多,每种原型都有不同的适用条件与风险。
  • 产品交付:最终可销售才是产品交付。
  • PMF:产品满足PMF验证,mvp应该是一个原型,而不是一个产品。
  • 产品愿景:产品长期目标。

合适的人

优秀产品团队遵循原则

  • 团队:传教士而非雇佣军。
  • 组成:1:10左右比例,1名产品经理,1名产品设计师,2-10名工程师。
  • 权力与责任:有权提出解决方案,对结果负责。
  • 规模:两个比萨原则。
  • 协作:一起制订方案。
  • 团队工期:稳定长期团队很重要。
  • 团队自主:足够自主权,减少依赖。

产品经理

应该是团队里最具才干的人:具备娴熟的技术;商业的敏锐;关键人员信任;深厚客户知识;产品激情;团队尊重。

  • 关键责任:让其他人相信你所构建产品是真正值得的。
  • 牢记:产品成功是每个人各司其职,产品失败就是产品经理过错。
  • 深厚客户知识。
  • 深厚数据知识。
  • 深厚业务知识。
  • 深厚市场和行业知识。
  • 智慧、创意、持之以恒:智慧:好奇心,快速学习能力,善于利用新技术;创意:创造力;持之以恒:产品热情,通过证据不断沟通。
  • 重要的两门课:计算机编程入门;商业会计和金融学入门。

产品设计师

这个岗位职责和国内大多数设计师职责差别最大了,可以发现一些产品经理职责划到了这个岗位,初看起来有点不合理,但是仔细一思考,还真是很合理,也很顺理成章的。最近我看到很多国外的设计师,他们利用processing编程语言,结合机器学习,创造出了很多有趣的产品,我想他们应该一直的重新定义设计师这个岗位角色,而我们设计师定位大多停留在美工层面。

  • 产品发现:传统的工作方式,设计师从产品经理哪里获取需求或产品说明书后再进行设计。产品设计师工作价值:由产品成功度衡量而不是工作产出。
  • 完整的用户体验设计:包含完整UX和UI。
  • 原型设计:不单只是传统意义上原型图。
  • 用户测试:找到现实用户测试。
  • 交互和可视化设计:这部分类似传统设计师相关工作,国内应该只停留在这一层。

工程师

对于一个成功的产品经理来说,最重要的关系莫过于与你团队中工程师关系。

  • 与他们直接交流讨论:充分挖掘和发挥他们作用,不仅可以为产品未来省下很多工作而且还能为你提供很多创意设计。
  • 向他们承诺真正的调研:不要欺骗和拍脑袋,不然到最后你会发现,小丑竟然是你自己。
  • 他们的士气取决于产品经理:产品经理工作要确保工程师们感觉自己是传教士而不是雇佣军。

产品营销经理

  • 一个营销经理通常服务与多个产品团队。
  • 如果公司有营销经理,产品经理要确保他和你一起工作,为了产品的常规,花时间去了解市场绝对很值。

辅助角色

  • 用户研究人员。
  • 数据分析师。
  • 自动化测试工程师。

领导角色

  • 产品管理领导CPO:定期审核各产品经理和产品团队的工作,找出问题并帮助解决。
  • 产品设计领导CDO:负责整体用户体验。
  • 技术组织领导CTO:从技术角度了解整个系统是如何整合的,负责系统的整体架构。

其它管理角色

  • 产品主管角色:最重要的职责就是培养出一个包含产品经理和设计师的优秀团队。

    强调团队发展,设定产品愿景和策略,强大执行力,技术驱动产品文化,一定行业经验,处理好部门关系。

  • 技术主管角色:即使是最伟大的产品创意,如何你不能付诸实践并发布,它就只是想法。

    该岗位也可能被称作CTO,其主要职责:建立优秀组织;帮助指导并购活动建立购买协作决策;快速交付产品;设计符合产品演化架构;确保团队活力。

  • 交付经理角色:消除协作障碍。

正确的产品

产品路线图

不要使用传统的产品路线图。

  • 产品路线图问题:我们至少有一半的创意是行不通的,所以指定产品路线图很多情况下是无用功;有价值可行的创意,也需要根据市场反馈进行多次迭代,产品路线图无法预测规划好这一切。

  • 路线图替代方案:故事地图技术。此替代方案满足产品路线图提供的两个需求:1 管理层想确定业务上最有价值的事情;2 管理层需要时间承诺。故事地图是一种二维地图,纵轴是用户活动,横轴是时间;管理层提供需要解决的特定业务目标,团队工作方式关注结果而不是产出,建立高信用承诺的文化。按照我个人的理解,用户活动类似史诗级故事。

产品愿景

搞清楚产品愿景与产品战略,它们都起到赋予团队工作意义感重大作用。
产品愿景具体作用:

  • 传达愿景,激励团队(利益相关者、投资人、合作伙伴、潜在客户)。
  • 有效招聘工具。
  • 类似于优秀的领导力

产品战略具体作用:

  • 不要试图取悦任何人,不然会导致取悦不了任何人。
  • 它是计划交付的产品或版本顺序。
  • 类似于优秀的管理力
产品愿景原则
  • 从为什么开始。
  • 相比解决方案更热爱提出问题。
  • 不要害怕远见卓识。
  • 不要害怕打乱自己。
  • 产品愿景需要激励。
  • 拥抱那些有意义的趋势。
  • 关注事物变化的方向。
  • 大方向坚持,小细节灵活。
  • 实现任何产品愿景都是一种信仰的飞跃。
  • 坚持不懈的布道。
产品战略原则
  • 一次只专注于一个目标市场或一类角色。
  • 产品战略于业务战略保持一致。
  • 产品战略与销售战略、上市战略保持一致。
  • 关注客户,而非竞争对手。
  • 组织全体成员参与沟通战略。
产品原则
  • 产品愿景描述了你想打造出什么东西
  • 产品战略描述了你实现产品愿景的路径
  • 产品原则描述了你想打造的产品实质

产品目标

OKR技术

采用OKR技术来管理产品目标:

  • 每年设定一次公司OKR。
  • 每季度设定一次部门的OKR。
  • 团队目标和组织目标保持一致。
  • 每次设置1-3个目标。
  • 每个OKR设置1-3个关键结果。
  • 打分阶段推荐:0 毫无进展,0.3 完成基本工资, 0.7 满足期望, 1.0 超出预期。
  • 高级管理层对组织OKR负责。
  • 产品和技术主管对团队目标负责。
产品团队目标
  • OKR的关键点就是集中在产品团队级别上。
  • 不要和职能团队的OKR混到一起。

产品与规模

产品规模上分为小组织和大组织。

  • 小组织:每个人都有必要知道别人在做什么和为什么做这个。
  • 大组织:对组织目标有非常清晰的理解,确保产品团队适应多层级OKR。

此外产品需要做好布道的工作,这是CEO和产品负责人最重要工作之一。推销梦想的工具和方法:展示原型,分享愿景,分享痛点,毫无保留分享经验,毫无保留信任,学会精彩的演示,发自内心的兴奋,表现出狂热,花时间多和团队相处。

正确的过程

产品发现

产品发现确保工作不是一种浪费

产品发现原则
  • 不能依赖客户、高管、利益相关者。
  • 最重要事情是创造有目共睹的价值。
  • 功能、设计、技术本质上是相互关联的。
  • 很多创意会行不通,行得通的也需要多次迭代。
  • 产品发现目标是以最低的成本来验证我们的创意。
  • 基于真实用户/客户来验证创意。
  • 在产品发现中迭代,比在交付中迭代起码节省一个数量级时间和精力。
产品发现风险管理
  • 价值风险:客户会购买或选择使用我们的产品吗?
  • 可用性风险:客户知道如何使用我们的产品吗?
  • 可行性风险:我们能打造出优秀的产品吗?
  • 业务可行性风险:这个解决方案对我们的业务有用吗?

产品发现技术包含:发现框架技术,发现规划技术,发现构思技术,发现原型技术,发现测试技术,测试可行性,测试可用性,测试价值,测试业务可行性,转换技术。

发现框架技术

确保团队在整理目标刻画上保持一致,发现和解决重大风险(财务、业务、营销、销售、法律、道德)

  • 1 机会评估技术:主要回答4个关键问题,1 业务目标:这项工作解决什么业务目标?2 关键结果:如何度量成功?3 客户问题:这项工作解决了客户什么问题?4 目标市场:我们关注哪些客户?
    适用:小规模、典型项目

  • 2 客户函件技术:站在客户的角度,介绍产品成功发布后,能够带来的价值和变化
    适用:大规模项目

  • 3 初始画布技术:一种业务模型验证法
    适用:新业务和新产品

发现规划技术

  • 故事地图技术(简单):一种二维地图,纵轴是用户活动,横轴是时间,将主要用户活动分布在二维图中(个人觉得有点类似史诗级的故事)。

  • 客户发现技术(复杂):寻找自己产品的铁杆粉丝,铁粉是产品的参照客户,产品经理需要投入大量的精力。根据客户类型,参照客户的含义也不尽相同。

    toB:为企业量身定制产品,参照客户数至少6个。
    to应用程序:打造平台类产品。
    to内部员工:打造公司内部员工使用的客户支持工具。
    toC:为消费者量身定制产品。

理念探索技术

  • 客户访谈:最强大且最重要的技能之一,主要问题有:你的客户是你认为的那种人吗?他们真的存在你认为的问题吗?现在,客户是如何解决这个问题的?他们需要什么才能改变?
  • 礼宾测试技术:快速生成高质量的产品创意,走到实际用户和客户身边,让他们教你他们是如何工作的。
  • 客户不当行为力量:鼓励客户使用产品解决计划/规定之外的问题。
  • 黑客日:是一种内部产品创意(定向和非定向),可以使用这种方法来打造传教士般的组织。

原型探索技术

  • 原型原则:使得成本更低,强迫我们在更深层次思考问题,强大协作工具,有不同程度的保真度,解决一个或多个产品风险(价值、可用性、可行性)。
  • 可行性原型技术:通常工程师使用代码来创建可行性原型,工程师给出大概的时间成本,团队是否花费这个成本由产品经理决定。
  • 用户原型技术:用户的原型不只是原型图,根据不同的目的选择不同的原型技术,低保真原型传递:信息和工作流,高保真原型传递:交互、布局,模拟业务场景。
  • 实时数据原型技术:是一个非常有限的工具,主要目的是解决重大风险,所以收集一些实际的使用数据,实际数据原型只是产品的一小部分,不过是最核心部分。
  • 混合原型技术:原型+人工双重配合。

发现测试技术

  • 测试可用性:产品经理和设计师必须参加每一项和每一次测试,目的是更深入了解用户和客户,找出并解决原型中摩擦点。
  • 价值测试:定性价值测试:用户会不会花钱?定量价值测试:用户会花多少钱?
  • 需求测试技术
  • 定性价值测试技术:从金钱、时间、信誉、其它方面对用户进行测试。
  • 定量价值测试技术:收集具体的证据。
  • 技术可行性测试:由工程师进行,产品经理要注意控制成本。
  • 业务可行性测试:业务的可行性涉及各个部门:营销,销售,财务,合法,安全,客户,业务发展。

转型技术

  • 发现sprint技术:敏捷化产品开发,不只是研发流程,是整个产品周期。
  • 试点团队技术:从小范围开始实施、改变,然后逐渐扩大。
  • 让组织摆脱路线图:采用故事地图或用户故事来进行迭代

过程与规模

在过程中要管理好利益相关者,做好产品知识的沟通,最好每1-2周分享产品近况。

利益相关者包括但不仅限于:管理层,商业伙伴,财务部门,法务部门,合规部门,业务发展部门。关键技巧有:和利益相关者进行一对一的交流;不要构建好方案才展示,学会预展示;产品经理和利益相关者意见一定要统一。

正确的文化

优秀和糟糕团队对比

【优秀】

  • 振奋人心产品愿景,像一群传教士
  • 观察客户分析痛点,结合新技术挖掘灵感
  • 从关键干系人收集需求
  • 专注于客户
  • 庆祝成果
  • 不断主动创新

【糟糕】

  • 没有清晰的目标,像一群雇佣军
  • 从销售和客户那获得需求
  • 从所有干系人收集需求
  • 专注于竞品
  • 庆祝上线
  • 等待授权

失去创新缺少东西

  • 以客户中心文化
  • 振奋人心愿景
  • 目标明确的战略:最容易导致产品失败的原因就是试图取悦每个人
  • 优秀产品经理
  • 稳定产品团队
  • 工程师参与产品发现
  • 被授权的团队
  • 产品思维与工程思维结合
  • 企业勇气

失去速度的首要原因

  • 技术债务
  • 缺乏优秀产品经理
  • 缺乏产品愿景和战略
  • 没有统一文化
  • 没有稳定的团队

构建一种强大产品文化

  • 持续创新
  • 执行
未经允许不得转载:菡萏如佳人 » 读书笔记

评论 抢沙发

  • 昵称 (必填)
  • 邮箱 (必填)
  • 网址

欢迎加入极客江湖

进入江湖关于作者