在黑暗中规划

当你尚未实现产品与市场契合（PMF）时，规划产品开发，持续的迭代和适应不确定性可以帮助照亮前路。

如果你是一家初创公司或开发团队，希望拓展新的产品领域，那么找到产品与市场的契合点至关重要。这关系到你公司的存续，或者你为客户创造价值的能力。工程和技术负责人可能会感到，在明确产品市场契合度之前进行开发规划，就像在没有前灯的深夜开车。“产品市场契合”对不同的人来说可能有不同的含义。在本文中，我们认为它指的是你的产品满足潜在客户需求的程度。

你或许进行了一些基本的竞争分析，对用户的痛点有高层次的了解，或者掌握了目标客户的人口统计信息，但这些都不足以给你清晰的方向感。你正处于Kent Beck的3X框架中的“探索”阶段，需要通过持续、增量的实验来完善你的想法。

处于这个阶段可能会让人望而生畏；我深知这一点，因为我曾亲身经历。2020年，我带领团队在Gusto推出了项目跟踪功能，这套功能允许企业主监控跨项目的劳动力成本。这是一项雄心勃勃的任务，涉及诸多不确定性，尤其是在早期规划阶段，我们不确定要构建什么功能以及如何发布它们。

我们的经验告诉我们，你必须适应这种不适感。对于不习惯的团队来说，开发一个没有明确产品市场契合度的产品所伴随的未知因素可能会让人沮丧，但模糊性是这一过程的正常组成部分。好消息是，你有可能在黑暗中找到出路。

重新设定期望

作家Anne Lamott在她的书《Bird by Bird: Some Instructions on Writing and Life》中反思道，我们在夜晚开车时只能看到前方几百英尺，这很奇怪，但我们仍然设法到达目的地。在明确产品市场契合度之前规划产品时，你同样必须接受视野有限的事实。你最实际能知道的就是未来几周、下个月或其他压缩时间框架内需要完成的工作。除此之外的道路笼罩在迷雾中，当你到达那里时，你需要重新评估、审视和修订。

考虑到这一点，请抵制从头到尾规划整个项目的冲动。你的计划可能很快就会变得不准确，因此最好将精力投入到流程的其他部分，比如确定你的假设、调整指标和测试假设。

你的团队也必须习惯于采取慢热、增量的开发方法。工程负责人常常认为他们需要事先了解一切；相反，应考虑哪些是必须预先知道的，哪些可以等到以后。收集利益相关者的意见来确定第一次迭代的方向。是否有关于客户所经历痛点的现有用户体验研究？销售团队是否有可以查看的通话记录数据？也要盘点未知因素——这些可能涵盖从功能优先级排序到用户更喜欢在什么浏览器中使用你的产品等方方面面——但要认识到，在过程中会有时间找到这些答案。

当我的团队构建项目跟踪功能时，我们还没有所需的用户研究、实验结果或调查反馈来理解产品市场契合度是什么样子。很多目光都盯着我们团队，这让我们觉得必须从一开始就完美地规划和估算一切。但我们真正需要做的是，抛开在初始规划会议上设想的理想功能集，一次发布一个快速的“切片”，并评估用户反馈，在过程中调整下一次迭代。我们必须适应发布v0版本，即使它不是我们想象中的功能完备的版本。

概述你的假设

实现产品市场契合度的第一步是提出一个假设。你相信什么软件解决方案能满足用户未满足的需求？这给你一个目标，即使你在过程中必须修改它。构建一个范围小且集中的东西来测试它，然后获取反馈、迭代并重复——这是经过验证的MVP方法。

接下来，你将建立一些初步指标。这些指标可以让你评估是否正在朝着目标前进，以及何时达到了产品市场契合度的水平，这意味着是时候投资进一步开发了。为一个未发布的功能预测最合适的指标可能很困难，但请将你的指标——可能包括功能采用率、客户反馈、调查结果或净推荐值——视为积累信息和意见的起点。你还会选择一个（或多个）“北极星”指标来帮助你确定何时实现了产品市场契合度——例如，产品参与度提高30%或客户流失率降低25%。

除了验证你的假设外，你的指标还应帮助你更好地理解客户的需求。例如，当我们构建项目跟踪功能时，我们专注于快速发布第一个版本，因此只构建了跟踪全职员工薪资的功能。但我们的漏斗指标显示，雇用小时工的企业主选择退出，因为他们的整体劳动力成本数字不准确。一旦意识到这一点，我们优先考虑在下个功能切片中添加小时工，这提高了采用率。

测试风险最大的假设

风险假设测试是一种用于在开始构建之前测试对你的产品影响最大的假设的框架。它是对MVP方法的有力补充，可用于验证与你的产品、客户、商业模式和软件设计相关的假设。

想象一下，你应用的财务可行性取决于一个假设：它将实现特定的客户获取成本。为了验证这个假设，你可以发布一个应用广告并跟踪它产生了多少安装。如果没有足够的人与广告互动或转化为应用安装，你就需要设计另一个广告，并继续调整价值主张——以及你的产品计划——直到达到必要的CAC。

在项目跟踪开发的早期，我们对其中一个用户角色偏好的项目时间跟踪方式只有模糊的了解。基于一组早期的设计，我们制定了一个测试计划，用六名客户来验证提议的用户体验流程。我们收到的反馈促使我们改变方向，为该特定角色创建了一个不同的时间跟踪流程。利用RAT使我们能够了解什么能引起用户的共鸣；如果我们没有花时间获取他们的意见，我们可能不得不在后期进行大规模且昂贵的调整——或者更糟的是，我们可能根本无法找到产品市场契合度。

精简范围，再精简范围

当你考虑构建新东西时，很容易想象出功能齐全的版本。问题是，还有太多你不知道的东西。如果你构建了“泰坦尼克号”般的功能集，想要快速行动几乎是不可能的。相反，如果你雕琢一艘“独木舟”，你可以快速启动，看看客户是否感兴趣。你可能会为自己节省数月建造“泰坦尼克号”的时间。

在开发项目跟踪功能时，我的团队不得不进行一些关于削减范围的艰难对话。我们意识到，鉴于我们愿景的宏大——项目跟踪将触及现有产品的许多部分——以及项目的模糊性，以切片形式发布功能将是向客户学习并根据需要改变方向的最快方式。每当我们接近发布下一个切片时，我们的工程、产品和设计团队都会聚在一起评估先前发布的反馈，并就下一个最高优先级的功能达成一致。

这种快节奏、迭代式的方法意味着我们必须深入思考功能排序，并抵制在每个切片中添加“额外一点东西”的冲动。起初这很困难，因为我们习惯于创建更完整的产品集。但在几周内，随着我们发布第一个切片并收集反馈，我们开始享受这个过程。我们找到了灵活构建的新方法，尝试试点和测试群组，安排技术债务，以及通过手动变通方法削减功能。例如，对于早期的项目跟踪切片，我们团队的技术负责人——我们称她为Jamie——手动从一个试点列表中为新客户进行入职操作，使我们得以推迟构建入职流程。我们戏称这个新功能为“Jamie即服务”。

一旦我们的团队接受了优先级排序、增量开发和范围精简的原则，就不再需要为每个功能估算精确的故事点数，因为每个特定的功能切片已经具有严格的范围。我们的利益相关者认同这种方法，因为他们从一开始就参与了团队的这些讨论，所以我们不需要再进行“这什么时候能完成”的对话。而且，我们稳步开始朝着指标取得进展。

大约六个月后，我们达到了我们对产品市场契合度的定义——在三个月内达到一定比例的回头客——是时候考虑下一步了。对我们的团队来说，这意味着暂停进一步的产品增强，以便解决我们在早期专注于速度时所积累的一些技术债务。

与模糊性做朋友

适应不适感并不容易，但这对找到产品市场契合度至关重要。产品开发的这个探索阶段要求你进行盘点，并不断重新评估需要完成的任务。

作为工程领导者，重要的是要提醒你的团队，快速行动并不意味着更努力、更长时间地工作，或在周末工作。它也绝对不意味着从第一天起就发布一个完美的产品。这需要削减范围、随着时间迭代，并且更自在地发布一个尚未完全成熟的功能，以了解客户想要什么。

你不可能从一开始就把所有事情都做对，这没关系。目标是在过程中学习：制定假设、建立指标、降低风险、收集反馈、迭代、重复。一旦你接受了不确定性，致力于寻找产品市场契合度不仅是一项挑战，更是一种刺激。