在客户同理心的基础上进行构建

“必要性是发明之母。这句话捕捉到了人类精神的不可磨灭和我们发明的自然动力。 正如牛津英语词典中所述，“当需要的东西变得势在必行时，你被迫找到获得或实现它的方法。很少有人会否认这些关于发明的普遍真理。 然而，正如 数字经济创新 文章所解释的那样，云创新需要发明与采用之间的平衡。

如果我们继续类比，创新来自一个更扩展的家庭。 对客户的同理心，是孕育创新的源头。 若要创建推动创新的客户同理心解决方案，需要一个合法的客户需求，让他们回来解决关键挑战。 这些解决方案是基于客户的实际需求，而不是他们的想要或异想天开的东西。 若要查找客户的真实需求，请从同情和深入了解客户体验开始。 同情是许多工程师、产品经理甚至商业领袖的欠发达技能。 幸运的是，云架构师角色的多样化交互和快速速度促进了这种技能。

如何建立同理心，为什么客户同情如此重要？ 客户同理心可帮助你了解和分享客户的体验。 从最低可行产品（MVP）的第一个版本到市场级解决方案的正式发布，客户同情有助于构建更好的解决方案。 更重要的是，同情更好地定位团队，以发明鼓励采用的解决方案。 在数字经济中，最容易同情客户需求的产品团队可以使用更好的工具构建更光明的未来，以重新定义和引领市场。

定义使用客户同理心构建的假设

定义假设是规划的基本部分。 你计划得越多，就越能清楚地看到你的假设如何渗透到一项伟大想法的基础当中。 假设通常是自我同情的产物。 换句话说， 如果我处于这个位置，我该怎么办？ 从生成阶段开始时，它会最大程度地减少假设可能会入侵解决方案的时间段。 此方法还加速了与真实客户的反馈循环，从而激发了早期学习和锐化同理心的机会。

谨慎

正确地定义要构建的内容可能很棘手，需要一些练习。 如果你构建得太快，可能不会反映客户需求。 如果你花太多时间试图了解初始客户的需求和解决方案的要求，市场可能会在你有机会构建任何东西之前就已经满足了这些需求。 在任一方案中，学习机会可能会显著延迟或减少。 有时数据甚至可能已损坏。

历史上最具创新的解决方案始于一种直观的信念。 这种直觉感觉既来自现有的专业知识，也来自第一手观察。 从生成阶段开始，因为它允许快速测试直觉。 从那里，你可以培养更深入的理解和更清晰的同理心程度。 每次迭代或发布解决方案时，平衡都来自生成可证明客户同情的 MVP。

为了稳定这种平衡行为，以下两个部分介绍了如何用同理心构建和定义 MVP 的概念。

定义以客户为中心的假设

使用同理心进行构建时，这意味着你根据定义的假设创建解决方案，这些假设说明了特定的客户需求。 以下步骤提出了一个鼓励同理心建设的假设。

1. 使用同理心构建时，客户始终是焦点。 这种意图可以采用许多形状。 可以在要解决的问题中引用客户原型、特定角色，甚至引用客户的照片。 请记住，客户可以是内部（员工或合作伙伴）或外部（消费者或业务客户）。 此定义是你测试的第一个假设：我们能否帮助此特定客户？
2. 了解客户体验。 使用同理心进行构建意味着你可以与客户体验相关并了解其挑战。 这种思维模式表明要测试的下一个假设：我们能否帮助此特定客户应对此可管理的挑战？
3. 定义单个挑战的明确解决方案。 如果你依赖于跨人员、流程和主题专家的专业知识，则可能会导致潜在的解决方案。 然后，要测试的完整假设是：我们能否通过建议的解决方案帮助此特定客户应对此可管理的挑战？
4. 达成价值陈述。 你希望为这些客户提供哪些长期价值？ 这个问题的回答创造了你的完整假设：如何使用建议的解决方案来解决这一可管理的挑战，如何改善这些客户的生活？

最后一步是客户同理心驱动假设的最终体现。 它定义受众、问题、解决方案和要改进的指标，所有这些都以客户为中心。 在度量和学习阶段，你应测试每个假设。 预期客户、问题陈述或解决方案的变化，因为团队在理解目标客户群时会发展出更大的共鸣。

谨慎

目标是以客户同理心构建，而不是以客户同理心进行规划。 我们很容易陷入无休止的计划和调整循环中，目的是找到完美的客户同理心声明。 在尝试开发此类语句之前，请查看以下部分，了解如何定义和生成 MVP。

在证明核心假设后，以后的迭代将重点关注于增长测试以及同理心测试。 在建立、测试和验证同理心之后，你开始大规模地了解目标市场。 通过扩展前面所述的标准假设公式，可以更深入地了解可寻址市场。 然后，根据可用数据估计总市场的大小（潜在客户数量）。

从那里，估计遇到类似挑战的总市场的百分比，因此可能对解决方案感兴趣。 然后，你有你的可寻址市场。 下一个要测试的假设是：使用建议的解决方案来应对这一可管理的挑战将如何改善客户的 x% 生活？ 一小部分客户将揭示领先指标，这些指标表明对所参与客户群的影响百分比。

定义用于测试假设的解决方案

在构建-度量-学习反馈循环的每次迭代中，你对构建具有同理心的尝试都是由 MVP 定义的。

MVP 是创建足够的解决方案来 与客户学习所需的最小工作量单位（发明、工程、应用程序开发或数据体系结构）。 每个 MVP 的目标是测试先前的一些或全部假设，并直接从客户接收反馈。 虽然输出并不是一个漂亮的应用程序，但却具有改变你的行业所需的所有功能。 每次迭代的所需输出都是一个学习机会，有机会更深入地测试假设。

时间盒是确保产品保持精益的标准方法。 例如，确认开发团队认为解决方案可以在单个迭代中创建，以便进行快速测试。 若要更好地了解如何使用速度、迭代和发布来定义最小含义，请参阅 规划速度、迭代、发布和迭代路径。

降低复杂性并延迟技术高峰

创新方法中描述的发明层面介绍了交付成熟的创新或可扩展的 MVP 解决方案通常需要的功能。 使用这些学科作为特征包含的长期指南。 同样，在解决方案中早期测试客户价值和同理心时，请将它们作为警示指南使用。

特征广度和发明的不同学科不能全部在一次迭代中创建。 MVP 解决方案可能需要多个版本才能包含多个学科的复杂性。 根据开发方面的投资，可能有多个并行团队在不同的学科内工作，以测试多个假设。 尽管保持这些团队之间的架构一致性是明智的，但在验证价值假设之前，尝试构建复杂的集成解决方案是不明智的。

你可以在技术峰值的频率或数量中最佳地检测到复杂性。 技术峰值指的是创造无法轻松通过客户来测试的技术解决方案。 当客户价值和客户同情未经测试时，技术高峰表示创新风险，应最小化。 对于在迁移过程中发现的成熟测试解决方案的类型，技术高峰在整个采用过程中可能很常见。 但他们推迟了创新努力中的假设测试，你应该尽可能推迟这些假设。

不懈地简化方法有助于任何 MVP 定义。 此方法意味着删除任何无助于验证假设的内容。 若要最大程度地降低复杂性，请减少测试假设不需要的集成和特征的数量。

生成 MVP

每次迭代时，MVP 解决方案都可以采用许多不同的形状。 常见的要求只是输出允许测量和测试假设。 这个简单的要求启动了科学过程，并允许团队生成具有同理心。 为了实现这种客户优先的定位，初始 MVP 可能只依赖于 发明领域之一。

在某些情况下，创新最快的途径意味着暂时避免这些规则，直到云采用团队确信假设得到准确验证。 对于像“Microsoft”这样一家科技公司来说，这样的建议听起来可能适得其反。 但它强调，客户的需求，而不是特定的技术决策，是 MVP 解决方案中的首要任务。

通常，MVP 解决方案由应用程序或数据解决方案组成，具有最少的功能和有限的优化。 对于具备专业发展专业知识的组织来说，这条路径通常是通往学习和迭代最快的途径。 以下列表包括团队构建 MVP 可能需要采用的几种其他方法：

• 预测算法，该算法在 99% 的时间内出错，但演示了特定的所需结果。
• 一种物联网设备，无法生产规模安全地通信，但展示了流程中近乎实时数据的价值。
• 由公民开发人员构建的应用程序，用于测试假设或满足较小的需求。
• 一个手动过程，可重新创建要遵循的应用程序的优势。
• 详细到足以让客户交互的线框或视频。

开发 MVP 不应需要大量的开发投资。 最好是尽可能限制投资，以尽量减少一次测试的假设数。 然后，在每次迭代和每个版本中，你会有意地改进解决方案，朝着一个可以扩展、代表多种发明学科的最终解决方案发展。

加速 MVP 开发

上市时间对于任何创新的成功至关重要。 更快的版本可加快学习速度。 更快的学习能带来更快扩展的产品。 有时，传统的应用程序开发周期可能会减缓此过程。 更频繁地，创新受到可用专业知识的限制的约束。 预算、人数和员工可用性都可以为团队可以处理的新创新数量创造限制。

人员配备限制和对生成具有同理心的愿望催生了公民开发人员的快速增长趋势。 这些开发人员可降低风险，并在组织的专业开发社区内提供规模。 公民开发人员是客户体验的主题专家，但他们没有接受工程师培训。 这些人使用原型制作工具或较轻量级开发工具，这些工具可能不被专业开发人员接受。 这些业务一致的开发人员创建 MVP 解决方案并测试理论。 在对齐良好时，此过程会创建提供价值但未能通过足够有效的规模假设的生产解决方案。 在规模工作开始之前，Teams 还可以使用解决方案来验证原型。

在任何创新计划中，云采用团队应将其项目组合多样化，以包括公民开发人员的努力。 通过扩展开发工作，您可以形成和测试更多假设，并减少投资。 验证假设并确定可寻址的市场时，专业开发人员可以使用新式开发工具强化和缩放解决方案。

最终生成门：客户痛点

当客户同情力很强时，显然存在的问题应该很容易识别。 客户的痛苦应该是显而易见的。 在构建过程中，云采纳团队正致力于根据客户痛点测试假设的解决方案。 如果假设定义良好，但痛点不是，解决方案并不真正基于客户同理心。 在这种情况下，不适合开始构建。 相反，请首先投资构建同情心，并从真正的客户中学习。 构建同理心和验证痛苦的最佳方法非常简单：倾听你的客户。 投资时间与他们会面并观察它们，直到你可以确定经常发生的痛点。 了解客户痛点后，即可测试一个假设的解决方案，以解决这种痛苦。

何时不应用此方法

有许多法律、合规性和行业要求可能需要备用方法。 如果正在开发中的解决方案正处于公开发布阶段，此方法可能不适用。

• 可能会对专利申请时机、知识产权保护或客户数据泄露造成风险
• 违反既定的合规性要求

当这些感知到的风险存在时，请在采用任何引导式发布管理方法之前咨询法律顾问。

参考

本文中的一些概念基于 Eric Ries 在 The Lean Startup 中讨论的主题。

后续步骤

生成 MVP 解决方案后，可以度量同理值和扩展值。 了解如何 衡量客户的影响。

衡量客户影响