如何看待亚马逊产品管理和软件开发周期？创建可重复流程需要什么机制？每个步骤谁负责？谁应该参与？如何发散想法？如何确定优先顺序？如何让流程保持在正轨上？思考之后，我写出了整个流程，并认为这对其他人有帮助，因此想在这里与您分享。
本概述的目标受众主要是新产品经理，因为这些是基础概念。经验丰富的产品经理会非常熟悉这些步骤，但我希望他们也能从中得到一些启发。我还想澄清的是，我并不认为这是“唯一”的产品开发流程——根据行业或情况，毫无疑问需要替代方案和特定修改。因此，我不认为这是一次详尽的审查，而是一个高层次的蓝图。该“蓝图”适用于单个程序或功能，因此在此周期之上存在一些机制，以实现长期战略投资目的。有些组织还会有不同的活动顺序或分组，这当然完全没问题。重要的是为每项活动建立强有力的机制：建立明确的所有权，制定目标和产出期望，并定期检查和改进你的机制。我将这 10 个步骤总结为下面的图 1：
01. 产品和功能创意
那么，我们应该为客户打造什么？您可以使用许多潜在的重复机制来开发想法：为客户开发全新产品、为多个内部或外部客户提供服务的平台级产品、现有产品的功能扩展、重构现有产品，或者只是为了修复错误。然后，这些想法可以用作年度/季度投资和规划周期的一部分，或者用于提出需要额外人员的新想法。我们建立了多种机制来促进这一周期：年度战略和投资规划、季度优先级规划、每两周一次的状态审查和冲刺规划。我们还与利益相关者分享这些机会，包括客户（特别是在企业对企业领域）、内部和外部合作伙伴团队、供应商/供应商、和领导班子。
对于新产品机会，我们试图回答的真正问题是：我们可以为客户提供的最有价值的体验是什么？而且，我们可以为供应商提供的最有价值的经验是什么（或在此处插入其他关键利益相关者）。价值由组织定义，并且对于不同行业或组织处于成长成熟度的情况可能会有所不同。
一般来说，我推荐您最好的增量长期自由现金流代理。长期自由现金流包括短期交易价值（包括广告）和订阅形式的长期价值、长期参与/转化或“释放”组织其他地方的价值（即跨领域的价值）。销售/追加销售机会或发现新产品和服务）。长期自由现金流是增长的引擎，与投资者保持一致，不会为了短期改善而牺牲长期收益。增量是一个至关重要但很难预测的概念。我们进行了无数次实验，了解到新产品会产生价值，但可能会抵消其他地方的价值，甚至从根本上改变客户的行为。因此，这种新体验可能并不完全具有增值性。随着组织的产品和服务变得越来越复杂，必须始终将其纳入您的价值方程式中。同样，如果不是更重要的话，将其纳入您的营销活动也很重要。
在为客户和利益相关者开发新想法时，您可以考虑以下一些机制：
1.1 直接客户反馈
我将直接客户反馈定义为旨在提供产品反馈的明确信号。
1. 可用性研究：通常在产品开发早期使用，您可以与大约 10 名客户进行一次会议，以获得有关特定流程和设计选择的反馈。您可以利用整个流程的产品原型，如果创建原型的投资很大，您甚至可以利用模拟。客户会给出无数的建议和进一步调查的机会。我的建议是采取五种思维方式：客户很少会给你答案，甚至不会清楚地表达他们想要什么。继续挖掘以找到他们的真正动机。
2. 客户焦点小组/日记：这种机制有助于更深入地了解客户为什么做他们所做的（或不做的）。您可能想知道为什么客户喜欢竞争功能，为什么他们不使用某些功能，为什么他们停止使用产品等。此步骤不是为了获得统计显着性和最重要问题的排序，而是为了建立一个带有排序假设的首要问题列表。这里的日记也非常有帮助，你可以要求客户写下他们每次做 X 的事情，为什么这样做，他们想要完成什么，以及他们希望有什么不同。这有助于发现自动或潜意识的行为。
3. 客户调查：一旦您从焦点小组/日记中掌握了最重要的问题，就可以使用客户调查来更接近统计显着性，从而排序最重要的机会。
4. 客户评论/应用程序商店评论：通常撰写应用程序商店评论或客户评论的客户真的非常非常恼火。提供反馈通常并不容易，因此他们愿意不辞辛苦地这样做。虽然我不一定建议这样做来创建“最”的问题，但它们是新想法以及现有体验中的错误或破坏的“未加工的钻石”的重要来源。
5.面板/测试版应用程序：尽早获得产品反馈很有帮助，特别是在构建需要数月才能完成的更复杂的功能或服务时。要获得此反馈，您可以创建一个客户面板（特别是如果您拥有大量重要客户）或测试版应用程序，其中客户对您的产品充满热情并愿意尝试新功能。鉴于来源有偏差，您显然需要对这些数据持保留态度，但它会给您提供有价值的早期指标。
6. 明确的客户信号或反馈：这些可以内置到产品本身中，以获得客户对体验的反应。这可以通过多种不同的方式来实现，从简单的“赞成/反对”到让客户填写反馈表。对于客户反馈来说，当客户立即遇到问题时，这是最有用的，因为那时他们可以最好地阐明问题，并且他们有动力提供反馈。为了实现这一点，您可以构建一种机制，使客户能够在流程中的任何位置提供反馈（例如，启用操作系统的宏观功能之一，例如“摇动”）。
1.2 间接客户反馈
我将间接反馈定义为表明客户对产品产生共鸣的隐含信号。
除了直接向客户征求反馈之外，您还可以回答“客户与组织外部的哪些内容产生共鸣？”的问题。收集与内部体验相同的数据（即保留数据、财务信息，甚至简单的点击率）显然具有挑战性，但有一些方法可以收集数据来定向了解您是否应该考虑这些体验。我还强烈建议您不要进行直接基准测试 – 根据我的经验，在绝大多数情况下，您会花费不成比例的时间来收集数据，将其与您自己的数据进行比较，并试图弥合或理解差异，这几乎总是导致死胡同和浪费精力。尝试理解“为什么我们在 X 表现不佳？”是很诱人的（尤其是对于高级领导层或投资者而言）。但细节决定成败，而这些细节通常是无法获得的。比较我们自己的内部数据，我们已经遇到了足够多的挑战！
7. 客户行为数据：这是了解客户对现有产品体验的最明显的方法之一。我们可以专门写一篇文章来讨论如何思考这个主题。一些示例包括点击率、一段时间内的保留率、转化率、流失率等指标。了解这些数据的最有效方法之一是通过一段时间内的群组来了解客户行为如何以及为何发生变化。
8. 客户服务：这是识别现有产品中的错误和损坏的绝佳来源。客户服务人员也是极好的知识来源，可以帮助他们了解最困扰客户的问题，并获得诸如“为什么我不能只做某事？”之类的有用信息。
9. 数据聚合器：我们发现寻找以一致方式收集数据的数据聚合器很有用。这也不是“纯粹的”，并且可能无法与您的内部数据进行比较，但它是相对的，因此差异和趋势可以具有洞察力。因此，绝对数据没有用，但增量和随时间的变化才是有用的。数据聚合器的一些示例包括 data.ai（以前称为 App Annie）、Sensor Tower、Appfigures、Quantum Metric。这些组织跟踪 iOS 和 Android 应用程序的客户行为，并可以提供有关客户下载最多的应用程序、不同应用程序的保留情况、相对大小以及这些应用程序如何随时间变化的信息。除了应用程序跟踪网站之外，Similarweb 和 Statista 还提供有关可用于市场规模评估的各种主题的信息。
来自团队或利益相关者的想法
10. 团队：我们使团队成员能够创建一页“推介文档”，并在两年一次的“鲨鱼池”式流程中评估这些想法，看看是否有任何想法将包含在路线图中——或者——是否提交给高级领导以获得额外资金。目的是让我们的团队成员能够以相对轻量级的方式参与创意生成过程。这个想法可以来自他们收集的数据、他们在其他应用程序中经历过的事情，或者来自朋友的推荐。我们的一个标准是这个想法有一定的数据基础——一篇表明这个想法优点的文章，鼓励所有团队成员参与，包括刚从学校毕业的工程师。如果这个想法被选中，我们将让作者与产品经理合作，在完整开发的 PRFAQ 中充实这个想法（更多信息请参见下面的步骤 2）。我们采用的其他三种机制（与许多其他组织一样）是 1) 黑客马拉松：使团队成员能够合作创建他们感兴趣的任何想法的原型，以及 2) 创作者日：每年两次，我们专门用一个冲刺来实现团队成员可以从事他们想做的任何事情 – 从清理代码到研究新想法，3）巡视商店：每月一次，PM 将带领团队逐步了解现有的客户体验，就像客户一样。这应该在现场完成（尽可能），由 PM 参与并允许团队成员提出问题。大多数时候，这将突出显示改进现有体验的多种机会，
11. 合作伙伴团队吸纳：如果您组织周围的其他团队使用您的服务或受到您的产品的影响，您可以征求他们自己的想法。我们通常创建一个简单的模板（即想法、为什么客户会喜欢它以及任何表明为什么这对客户有帮助的数据、高水平的长期自由现金流影响）。
02. 工作反馈文件
一旦您决定了您的顶级产品或功能创意，您需要详细说明最低限度的客户体验（短期和长期）、业务计划、日志记录、数据和指标策略，以及您将面临的风险遭遇以及您将如何解决它们。这一切都可以记录在我们所说的工作反馈文档中。例如，一份阐明我们将向客户提供的完整端到端体验的文档，为什么客户会喜欢该产品，他们如何使用该产品，以及他们可以在哪里找到它。您阅读本文档的深度会有所不同，但大致与投资金额相关。如果投资很高，例如一个或多个两个比萨饼团队持续六个月以上（我们围绕两个比萨饼团队组织，这是一个具有明确和具体目标的团队，由大约 6-8 名工程师、一名产品经理和一名软件开发经理组成。两个披萨加在一起就足够喂饱他们了），然后我们将发布一份完整的新闻稿并附上常见问题解答 (PRFAQ)。
关于亚马逊的 PRFAQ 已经写了很多，所以我不会在这里详细介绍，但从较高的层面来看，新闻稿通常不超过一页，旨在描述发布时的体验以及为什么客户会喜欢它、他们如何使用它，以及客户如何找到这种体验。常见问题解答通常为三到五页，整个文档不超过六页，尽管可以添加带有用户界面模拟的附录（即，客户体验的分步屏幕截图）或其他相关信息。在软件开发过程开始之前，预先记录客户体验和关键业务决策的重要性怎么强调都不为过。 创建此文档使人们能够向利益相关者（包括您自己的团队成员）传达该策略。它使您能够预先阐明客户流程和辩论（如有必要）的关键决策。亚马逊的一位高级管理人员曾经告诉我们：“在编写一行代码之前，我们总是从 PRFAQ 开始。这使我们能够在将经验呈现给客户之前就经验进行调整并讨论关键问题。”
如上所述，您可以使用“推介文档”或其版本来开始该流程，而不要求团队成员在进行对话之前写六页纸。如果这个想法是现有产品的一个功能，您还可以跳到步骤 5 详细说明用例并将其转化为技术规范。
03. 确定优先级
我将优先级划分作为第三步，但是，优先级划分是在整个产品开发周期中进行的。我将其包含在这里是因为一旦您有了顶级产品创意（其中大部分都会有向后工作文档），您将获得做出年度或季度（或月份或冲刺）投资决策所需的信息。随着您收集更多信息，功能或子功能决策可能会在整个过程中发生变化。
为了促进优先级确定过程，拥有与整个组织的团队保持一致的一个或一组指标非常有用。优先级指标有很多种，但通常至少包括以下三个：
1) 客户或业务影响：这可以被视为财务指标（例如，收入、利润的增加），也可以被视为参与度的增加（例如，访问或重复访问、停留时间），或客户对体验的评分/满意度提高，或投诉减少。您需要权衡衡量客户价值的准确性与覆盖整个公司的单一指标的简单性。我个人主张后者，因为随着时间的推移，团队会越来越好地估计单个指标的影响。
2) 实施时间：价值更高、上市时间更短显然是首选。在考虑上市时间时，问问自己是否可以将体验版本放在客户面前，以便更快地估计产品价值。这将取决于创建产品的总成本；成本越高，您在全力投资构建产品之前就越应该寻找这些机会。
3) 风险：是否有内部或外部因素可能阻碍您的努力？这些情况发生的可能性有多大？团队是否在某些方面经验较少，例如机器学习？
04. 用户故事细分
使用逆向工作文档，您可以捕获客户和/或利益相关者希望通过该产品实现的所有预期功能。这通常是从产品价值接收者的角度来写的。例如，我们构建了一个产品，为搜索产品评论信息（超出客户评论）的客户提供有关产品的专家文章（例如，来自 Wirecutter 等出版商）。我们在亚马逊的搜索结果中构建了一个版本，例如，如果客户搜索“最佳电视”，我们将在搜索中显示一个小部件（或更准确地说，我们将向亚马逊搜索提供显示文章的机会）。
一个客户故事是：“作为客户，我希望在搜索产品时看到有关我感兴趣的产品的专家文章。我想查看该产品、星级、哪个出版商对该产品进行了评论，以及文章中的“简短”信息，以确定我是否愿意参与。这也使我们能够为客户提供不同的产品界面。另一个用例是“作为客户，我希望看到与我搜索的产品相关的前三篇文章。” 您应该考虑与该产品相关的所有利益相关者。
在上述案例中，出版商是明确的利益相关者。因此，一个用例是“作为发布商，我希望向客户清楚地展示我的品牌。” 合作伙伴团队的一个示例可能是，“作为搜索团队，我们需要在 X 毫秒内通过我们的 API 发送一组排名的文章小部件”。您还可以将其他合作伙伴团队（例如法律、财务、公关、运营和其他团队）视为利益相关者，您可以从中创建用例。
然后，您可以对所有用例进行优先级排序，以形成最小可爱产品 (MLP)。一些组织使用术语“最小可行产品（MVP）”作为产品的第一次迭代。这在亚马逊内部引起了激烈的争论，并确定最低标准是顾客会喜欢的产品。因此，我们争论哪些特征应该成为 MLP 的一部分，然后 MLP 将成为 P0 特征的集合。为了促进功能的优先级排序，您可以利用可用性测试来提供有关客户认为哪些是关键的哪些是最好拥有的数据。
05. 业务需求文档
业务需求文档的目标是比工作反馈文档更深入，并成为技术设计的关键输入。该需求将更深入地概述为：
1）为什么我们要构建这个产品 – 为什么客户会喜欢这个产品以及业务案例是什么？
2）更深入地了解客户体验。您应该拥有完整的客户流程和客户旅程中每个步骤的模拟 – 这将基于上一步中确定的 P0 功能。然后可以用它来阐明客户的预期功能和结果是什么，以及产品不打算做什么。通常在此过程中，您将在团队内部以及与利益相关者就设计和功能进行多次辩论。
3）了解如何解决异常和错误。
4) 详细说明实验策略、设计以及需要解决的任何关键要素（例如，如何处理实验触发以确保处理和对照之间的平等分配？）。该文档将是技术团队用于开发技术设计的主要工件。
06. 技术设计和技术分解
让技术团队参与整个产品开发周期非常重要。如果您在第 6 步让技术团队参与进来，那么 MLP 很可能会根据他们的意见而有所不同（并且对客户来说更好）。他们将拥有洞察力、问题和经验，帮助确定为客户构建什么是容易的、什么是困难的、什么是有风险的，并提出关于为什么客户会喜欢该产品的难题。虽然产品管理负责完成步骤 1-5（随后共同负责步骤 8-10），但技术团队将负责步骤 6 和 7。
在此阶段，产品经理获得最终技术设计的向后工作时间表非常重要。为了实现这一目标，团队将编写设计草案，与首席工程师和高级工程师一起审查，并在必要时与合作伙伴团队合作。他们还将包括及时测试和构建的计划，以修复任何阻塞错误。团队还应该就卓越运营/工程以及实验设计和设置进行讨论。为了实现卓越的运营/工程，技术团队需要时间进行文档记录、延迟测试、安全、隐私、弹性工作（即可用性杠杆、负载和混沌测试），并记录运营指标以了解客户体验及其状况失败以及达到什么程度。
团队的问题是：团队在实验之前预先完成了多少工作？我们认为，有几个关键组成部分是不能推迟的：安全性、隐私性、可用性和运营指标。弹性工作对于高流量场景尤其重要，但如果产品不会发布（因为它没有通过实验），那么这些投资可能会被丢弃。因此，我建议区分什么对客户实验至关重要，什么对高流量至关重要。
产品经理的主要职责是：
1) 准备实验计划。需要测试什么——而不仅仅是面向客户的指标，例如点击次数、收入、广告、长期价值等。这些当然很重要，但您还应该衡量所有运营指标，包括点击和体验绘制之间的延迟以及其他参与点的准备情况、客户遇到的错误数量以及程度。
2) 负责用户验收测试 (UAT)，您可以通过点击进行逐步检查，以确保体验在每个区域和每种语言中都按预期进行。我们建议编写一份概述测试方法的文档，并从每个地区招募团队成员来帮助进行测试。在每个区域和每种语言中。
07. 技术实施和测试
正如前面提到的，这一步是由技术团队负责的。PM 应与软件开发经理和相关工程师密切合作，以确保他们在所有数据流、测试方法和实验方法上保持一致。就本产品开发周期框架而言，此步骤包括所有技术测试，例如，确保服务以正确的数据进行响应、体验按预期呈现、服务以预期的可用性和延迟运行。
08. 客户流和用户验收测试 (UAT)
与第 7 步并行，PM 将主导客户流和 UAT。我们通常会进行一次“bug bash”，团队成员会浏览整个体验，点击他们能点击的所有内容来 1) 确保体验按预期发生——不仅流程正确，而且延迟和任何回退体验也是正确的，2）尝试打破体验并像客户一样在整个流程中来回走动。确定所有问题后，您可以根据每个问题的频率和严重程度确定优先级。您还可以确定在实验之前需要修复的关键内容以及在体验之后但在生产启动之前可以修复的内容。
09. 最终修复和实验设置
到目前为止，PM 应该拥有优先修复错误的完整列表和详细的实验计划。此步骤旨在在开始实验之前花时间完成所有最终修改。讨论是否以及如何进行实验非常重要。一般来说，只要有可能就进行实验是有帮助的，因为它们
1) 产生代表“客户意愿”的输出。我非常支持让客户决定产品是什么以及它是否会为他们的体验增加价值，
2）产生增量归因，这意味着您向客户展示的任何内容都将超越他们今天所体验的 – 可衡量的以分配真实归属的方式。归因是一个复杂的主题，可以单独撰写专门的论文。
然而，实验自动准确地分配归因。它们是确定增量客户行为的黄金标准。然而，我确实想澄清的是，实验是有代价的，在某些情况下，成本非常高。
此外，获得真正具有统计意义且正确的结果并非易事。您的实验可能会通过多种方式产生偏差，从而产生不正确的结果，例如实验触发问题、客户偏差、体验偏差（例如，如果治疗或对照存在延迟问题）。咨询统计学家以确保结果准确非常重要。在某些情况下，尝试可能没有意义。也许您已经在 15 个国家/地区中的 10 个国家/地区推出了产品。或者也许您正在提高产品的性能（例如延迟）。
10. 实验、客户反馈和分析
除了运行实验之外，您还需要考虑收集其他客户反馈。理论上，实验结果应该告诉您客户是否更喜欢这种新体验而不是控制 – 假设您拥有所有正确的指标来准确衡量客户的偏好。然而，在实验中记录和分析每一个指标是具有挑战性和昂贵的。我们在亚马逊应用程序中进行了一项实验，根据客户是否登录该应用程序来硬控制客户体验。登录应用程序可显着改善客户的体验 – 我们可以根据客户过去的参与行为提供个性化体验，我们可以向客户展示他们购买的商品以及订单跟踪历史记录等。实验中的所有指标都非常积极——我们看到的每一个指标都告诉我们要推出这种新体验。然而，我们联系了参与实验的客户，以了解他们的反应。他们的答案再清楚不过了——他们鄙视这种新体验。但他们必须这样做才能购物，所以他们愿意不辞辛苦地购买他们需要的东西。尽管有实验结果，我们还是决定不推出新体验。
我还建议记录实验结果和客户反馈。我总是告诉我的团队，我们唯一的失败就是不学习。我们可能不会根据实验结果和客户反馈推出新体验，但如果我们更多地了解客户想要什么以及我们可以采取哪些不同的做法，我认为实验是成功的。这些知识可以作为未来产品功能和新程序的输入返回到步骤 1。
