前往小程序,Get更优阅读体验!
立即前往
首页
学习
活动
专区
工具
TVP
发布
社区首页 >专栏 >价值探索环

价值探索环

作者头像
新亮
发布2022-12-05 21:18:25
2410
发布2022-12-05 21:18:25
举报
文章被收录于专栏:新亮笔记新亮笔记

《持续交付 2.0》读书笔记

探索环的意义

如何发现和识别用户的真实需求是目前所有企业面临的难题。

现在的市场变化很快,当花大量时间将产品功能全部开发完成后,产品常会因为潜在用户对原型的理解偏差,或者用户需求发生了变化,导致当初的设计不再适应市场需求。事实上,这反映了产品或服务开发过程中常见的风险假设。

  1. 用户假设,即我们提供的产品服务是针对某类潜在用户人群的需求的假设。
  2. 问题假设,即目标用户群之所以有这种需求,是因为他们的确存在某些痛点(或问题)需要解的假设。
  3. 解决方案假设,即我们提供的解决方案可以解决这些痛点或问题,而且比其他现存的解决方案都有效且高效。

这 3 类假设中,任何一个假设不成立,都会导致我们事倍功半,甚至前功尽弃。因此,探索环的目标就是要持续识别和定义这些有价值的假设,选择并验证其中风险最高或最易验证的价值假设,并借助价值验证环得到数据反馈,以便深入理解用户需求,把握业务前进方向。

在探索环中,我们是要从业务问题出发,与团队一起,共同找出这 3 类假设,通过分析评估,确认最大的风险点,并制订相关的衡量指标,找出相应的最小可行的验证方案。然后再借助验证环的高速运转,尽早获得反馈,并根据衡量指标来验证这些风险点。

探索环的 4 个关键环节

探索环是指团队通过一系列工作环节,能够识别和定义业务问题,制订相应的衡量指标,并找出低成本且可快速验证的最小可行解决方案。这是一个理解真实需求、判断优先级、再评估需求的过程,具体包括以下 4 个环节。

  1. 提问,通过有针对性的提问与讨论,找出团队期望达成的业务目标或者希望解决的业务本质问题。
  2. 锚定,针对该问题进行信息收集,经过分析,去除干扰信息,得到适当的指标项,并用其描述现在的状况,以及我们希望的结果或状态。
  3. 共创,通过深入讨论,找到所有可能的解决方案。它是一个深入理解和验证问题的环节。
  4. 精炼,结合实际情况,进行评估,筛选出最小可行性解决方案或方案的集合,以作为验证环的输入。等待它的真实反馈,再做价值判断。

提问

目的在于通过不断地提问,澄清客户需求背后要实现的真正目标,以便找寻更多解决问题的方法,同时也有助于团队成员从业务问题出发,充分理解业务问题。

探索环中的提问环节要求不仅仅是找到“实现什么”以及“如何实现”,更是要了解客户需求背后要解决的真正问题“为什么要实现”,以便规划更加方便快捷的验证方案或解决方案。

由于角色惯性,从开始讨论的那一刻起,我们就很容易跳过最重要的问题,也就是说,如何更好地为客户解决真正的问题,而这恰恰是我们应该做的。因此,要通过持续提问,对问题进行深入探究。

当我们接到一个工作任务时,我们应该更多地深入理解所要解决的问题,了解其背后的真正原因,不要过早地进入解决方案环节的讨论,而忽视了对问题的讨论。这样才能更好地解决问题,而不仅仅是完成软件功能的开发工作。

在“提问”这一环节中,组织者需要注意以下 4 点:

  1. 问题域的提出方及解决方案的提供方代表尽量到场,参与讨论。
  2. 多问几个“为什么”。尽量避免因为感觉自己熟悉这个问题域,而过早地放弃探索。
  3. 在条件允许的情况下,尽可能收集数据信息,以便作为问题理解和分析的佐证。
  4. 移情,使用同理心。设身处地站在客户或问题提出方的角度思考问题,还原客户问题的场景。

锚定

当我们已经选定要解决的问题领域时,接下来就要确定我们要达成的具体目标与结果。“锚定”是设定目标以及目标分解的讨论过程,其目的是确定要达成的目标以及可以衡量它的指标,并能够指导后续的共创与精炼活动。

我们应该尽量避免模糊不清的目标,它会影响团队成员之间的交流。清晰地描述目标让我们自己知道当前所在的位置,离目标还有多远。清晰的目标通常是具体且可衡量的,并有时间限定。

最好的方式是让目标可客观衡量。有时,我们很难立即拿出一个可衡量的标准。但是,我们可以通过描述目标状态,并根据这一目标状态可能产生的结果来寻找可客观衡量的目标结果。如何发现可衡量的指标呢?我们可以这样来思考:如果某个产品满足了用户的需求,那么用户会非常满意,而用户的满意会带来复购,同时会有更好的品牌知名度,从而带来更多的用户。那么,我们可以设定用户数量和营业收入作为产品的指标维度。

另外,目标需要针对不同的组织层级而设定。一个企业的总目标应该是整个企业范围内的目标,而不应该只是企业中某个团队的目标。一旦制订了企业总目标,企业中的每个团队都要以它为方向,根据自身团队的职责与性质,制订各自相应的目标,并为实现它而集思广益,群策群力。

共创

共创就是指,当我们制订了想要达到的目标后,团队为设法验证或达成目标而找出多种可行性解决方案的过程。

共创要在理解问题和制订目标之后进行,否则会因为缺少目标约束,使得解决方案容易过于发散。这一环节的产出应该是很多带有量化指示器的解决方案。事实上,每一个解决方案都是基于一定的假设条件或猜想得出的,而每一个假设都等同于一个风险项。因此,每个解决方案都只是“试验方案”,试图解决问题域中的某个具体问题。

在“共创”这一环节中,需要注意两个陷阱,它们分别是:分析瘫痪(paralysis by analysis)和直觉决策(extinct by instinct)。分析瘫痪是指因为过度分析(或过度思考)而无法决策或采取行动,最终影响结果产出的一种状态。通常是由于有太多的细节选项,或者过于寻求最佳或“完美”的解决方案,并担心做出任何可能导致错误结果的决定。而直觉决策是指不做分析,基于匆忙的判断或直觉反应而做出致命的决定。它是与分析瘫痪相反的另一个极端。

同时,值得注意的是,很多解决方案产生的结果是相互影响和关联的。一个解决方案可能会影响多个结果指示器。

精炼

精炼环节就是对共创环节中得出的众多方案进行评估,从中筛选出团队认为最小可行性解决方案的过程。评估因素包括备选方案的实施成本、时间与人力、效果反馈周期,以及该方案对业务目标的影响程度。

精炼的目标并不是为了删除在共创阶段得出的解决方案,而是将它们按优先级排列,并让团队将解决方案进一步分解,顺序选出共同认可的最重要改进项,并确保它能够尽早被验证。

通过精炼之后,被选择的方案就可以进入验证环了。那么,如何判断我们已经准备好,可以进入验证环了呢?一个简单的方式就是你能够将探索的成果以下述形式表述出来,并且达成团队共识:

我们相信,通过实现(XXXXX 这样的最小功能组合),我们的指标可以达到(YYYYY 程度)的话,说明我们关于(ZZZZZ)的假设是成立的。

工作原则

为了能够加快探索环的速度,缩短整个 “8” 字环的运行周期,避免陷入“分析瘫痪”的境地,在探索环的工作中应该遵循“分解并快速试错”、“一次只验证一点”、“允许失败” 原则。

分解并快速试错

“一次到位式”解决方案通常需要较高的实施成本,而其带来的实际效果具有较高的不确定性。由于前期投入的成本较高(即沉没成本),一旦这个解决方案未能带来预期效果,团队不愿意放弃这一方案,决策者通常选择保留它,或者仍会持续优化,使其慢慢“死去”,而这会带来不必要的产品复杂度和维护成本。

如果我们能够换一种思路,更多地使用低成本快速试验方式,那么在相同的成本下,可以尝试更多的方法,能够尝试更多的次数,意味着可能会有更多的收益。

一次只验证一点

一次只验证一个需求假设。在执行整个试验方案过程中,我们仍旧要保持开放心态,不断优化这些试验方案。时刻提醒自己,我们的目标是验证我们的假设,试验方案只是我们验证假设的手段,而不是我们的目标。

允许失败

尽管每个产品经理都希望所有方案都获得成功,但是我们却无法保证每个方案都会获得成功。但是,只要具有开放的心态,我们就可以从所有方案中都学到很多新的知识,而这些收获无论是对产品今后的成功,还是团队人员的能力提升,都具有非常重要的作用。

共创与精炼的常用方法

价值探索环的使用前提是团队拥抱“先假设后开发”的思考方式,能够识别前面提到的 3 类假设,即问题假设、人群假设和解决方案假设。当然,有了这些假设以后,我们还需要一些方法能够快速设计与实现。只有这样,我们才能以最快的速度完成价值验证闭环。

装饰窗方法

所谓装饰窗方法(DecorativeWindow),就是指为新功能预留一个“入口”,让用户能够看到,但实际上并没有真正实现其功能。就像一个装饰性的窗户,这是一种了解用户喜好的方法,其目的是利用最小成本,来验证用户是否喜欢某个功能,以及其紧迫程度,为是否研发后续更全面的解决方案提供数据支持。

最小可行特性法

最小可行特性法(Minimum Viable Feature)是指在产品从 1 到 n 的过程中,寻找用户可直接感知到的需求假设作为产品的最小可行特性优先开发的方法,以尽可能少的成本快速增加或修改某个产品特性,让用户使用,收集真实反馈,专注于验证功能改进,同时也可提升用户使用体验。

特区法

特区法(Special Zone)是指在特定用户范围内进行试验,以验证某个新功能的有效性。这样,即使新功能无效或者效果不好,也不会影响特区外的用户。这种方法对于资源有限、成本敏感,但仍希望为用户提供良好服务的业务来说,是非常有效的方法。

定向探索法

定向探索法(Directional Explorer)是指针对具有某种特定行为的特定用户群体,依据该用户的具体行为模式,设计调查提纲,有针对性地探索其行为背后的动机。这种定向探索法与一般用户访谈的不同点在于:团队已经掌握了被访谈对象的具体行为(包括行为细节与发生时间等),以事实为依据,进行定向式的探索发现,而非宽泛的通用提问。

稻草人法

稻草人法(Corn Dolly)就是指:不开发任何真实的功能,只假装这个功能已经完成了,并向用户展示该功能的真实效果,从而得到用户的真实反馈。这种方法与装饰窗方法的区别在于它让用户真实地感受到了功能提供的结果,而事实上并没有开发这个功能。

最小可行产品法

最小可行产品法(Minimum Viable Product)通常是在产品从 0 到 1 的过程中使用。它是以尽可能少的成本快速开发产品的核心功能,并找到用户,收集真实反馈,验证真实的用户需求,以确定新产品方向和形态的方法,其目标是找到合适的产品形态。

实施注意事项

为了更好地执行价值探索,在整个过程中有以下 6 点值得注意:

  1. 多角色参与探索 - 探索环涉及业务领域的很多方面,包括问题的发现与定义、目标与衡量的制订等多种产物,而不仅仅是产出一个功能需求列表。因此,建议与业务领域问题及产品解决方案相关的各类角色都能够参与其中。而且,参与其中的每个人均应该对上述内容有所贡献。
  2. 探索过程中存在很多的不确定性 - 因此 4 个环节中也必然存在一定的反复与循环。这是正常现象,尤其是当业务领域比较复杂、涉及环节比较多,业务流程中所涉及的角色也比较多时,更容易发生。很可能在讨论某个问题的可行解决方案时,会发现另一个隐藏的重要业务问题。
  3. 风险不是等价的 - 我们会从每个业务问题中分析出很多风险或假设,假如我们为每个假设都设计出多种试验方案,并且坚持实施所有试验方案的话,很可能会消耗太多的成本,并错过市场时机。因此,我们仅需对那些被评估为风险较大的假设进行验证方案设计,并尽量以较低成本进行验证。而对于那些低风险项,团队要在设计解决方案时,提出一些衡量指标器,并在方案执行后,一同收集相关的数据结果。
  4. 上帝视角 - 由于在某个领域工作时间较长,有些人认为自己非常了解用户,常常“闭门造车”,并美其名曰“注重用户体验”。然而,当产品上线后却发现,用户对产品功能有很大的意见。
  5. 唯数字论 - 当我们建立起数据指标体系,搭建好我们的试验机制,并且能够收集到大量指标数据以后,有一点需要格外注意,那就是:所有收集到的数据只能告诉你当前的状态是什么,并不能直接告诉你背后的原因是什么,也无法完全预测未来,尤其当业务市场发生改变,而数据又无法展示时。
  6. 蛇行效应 - 还有一种情况,比较常见。团队针对问题制订了一系列的试验方案 A,并开始执行验证。但在还没有执行完成或得到结果之前,团队又有了新的想法和方案 B,并且对新的想法兴奋不已,马上开始执行方案 B。没有多久,可能又想到了一个新的方向,如此循环。

小结

本章讨论了持续交付 “8” 字形环之探索环中的 4 个关键环节,包括提问、锚定、共创和精炼。希望顺利实施这 4 个环节,需要遵守 3 个基本实施原则,分别是分解并快速试错、一次只验证一点和允许失败。

本章还花了大量篇幅介绍了共创与精炼环节中经常用到的 6 种方法,也就是装饰窗方法、最小可行特性法、特区法、定向探索法、稻草人法和最小可行产品法。这 6 种方法可以帮助团队用最少的时间、最小的成本来找出用户的真实需求,避免最终的产品与用户需求的偏差,达到事半功倍的效果。

探索环中的最小可行方案,对价值验证的速度有极大的影响。希望大家在日常工作中能够使用这些方法,以最小的成本来实现更多的价值交付。

本文参与 腾讯云自媒体分享计划,分享自微信公众号。
原始发表:2022-08-28,如有侵权请联系 cloudcommunity@tencent.com 删除

本文分享自 新亮笔记 微信公众号,前往查看

如有侵权,请联系 cloudcommunity@tencent.com 删除。

本文参与 腾讯云自媒体分享计划  ,欢迎热爱写作的你一起参与!

评论
登录后参与评论
0 条评论
热度
最新
推荐阅读
目录
  • 探索环的意义
  • 探索环的 4 个关键环节
    • 提问
      • 锚定
        • 共创
          • 精炼
          • 工作原则
            • 分解并快速试错
              • 一次只验证一点
                • 允许失败
                • 共创与精炼的常用方法
                  • 装饰窗方法
                    • 最小可行特性法
                      • 特区法
                        • 定向探索法
                          • 稻草人法
                            • 最小可行产品法
                            • 实施注意事项
                            • 小结
                            领券
                            问题归档专栏文章快讯文章归档关键词归档开发者手册归档开发者手册 Section 归档