今天这篇文章，是 PostHog 的 CEO James Hawkins 根据他们 6 次产品的经验写了一篇 PMF 通关指南，里面也结合了他们为超过 50 家 YC 初创做咨询时的洞察。找到了 PMF 之前，

　　PostHog 是个开源的产品分析工具，开源和自托管是他们找到 PMF 的两个解法，同时满足了 SaaS、B2B 客户的两个共性需求：他们希望深入分析用户行为，同时不愿依赖外部第三方平台的企业的需求。

　　这份闯关方法论值得一读，PMF 的具体难题各不相同，但万变不离其宗。找到 PMF 的过程充满了陷阱、需要一点运气，而且肯定不会是直线通关。

　　要赢得这个游戏，需要完成所有五个等级。除第一级外，每一级都有多种失败的可能性。我已经列出这些可能性——按顺序依次进行。如果你发现没办法完成某一级，意味着你可能需要对整个公司来个大转型。关于转型的注意事项，我会在最后提到。

　　记住，在每个阶段与客户或潜在客户的对话中，详细地记下来所有信息。你可能会需要回头看看某个细节，这些记录也可能对之后的其他想法有帮助。在 PostHog，我们在最初的几周里就写满了一个超过 100 页的 Google 文档。

　　从解决你自己遇到的问题开始。这个问题不仅需要你亲身经历过，还要你曾尝试过去解决，否则它就不算是一个重要的问题。

　　你的想法和你选择服务的用户群体，会深刻影响你的职业生涯和个人生活。我建议多尝试一些想法，然后找出你喜欢的是什么，以及为什么喜欢。

　　选择那些你愿意花时间去合作的用户群体。比如在 PostHog 早期，我们尝试过开发一款面向销售主管的工具。但很快我们就发现，那些电话里说得天花乱坠，但实际行动却跟不上承诺的人，让我们心累。于是我们转向了客服或工程师，因为我们觉得他们更可靠。

　　解决已知的问题相对容易验证，但你的解决方案必须有显著的不同。如果你想建一个可以做大的公司，你的产品或服务必须比现有的好 10 倍，或者便宜 10 倍。

　　对于那些看似没人关注的问题，要谨慎验证。可能是你真的发现了别人没注意到的点，但更可能的是，这个问题并不重要。

　　对热门趋势保持警惕。跟那些不够吸引人、管理不善、缺乏创新的公司竞争，通常比与那些已经拿到风投、用上最新技术的公司竞争要容易得多。不要被那些创业公司的大额融资和媒体曝光所迷惑，它们并不等同于 PMF。事实上，一个领域越热门，公司成功的可能性可能越低。

　　保守型买家要求差异化。你可能很容易让别人尝试一个新的社交应用，但要让企业去用一个未经验证的 CRM 系统就难多了。取代现有产品的策略比开发全新领域的策略要难得多。卖给那些没有现有解决方案的客户要容易得多。

　　很多人在前期花费数月甚至数年去验证自己的想法，结果却毫无进展。实际构建一些东西并让用户使用，总能让你更清楚地看清方向，所以在这个阶段，不要犹豫，尽快行动起来。

　　现在你认为存在某个问题，你需要弄清楚其他人是否也有同样的感受。为此，你需要和他们聊聊。这很难，因为你是在要求别人花时间，去帮你验证一个他们自己可能都不在意的问题，而你又有可能到最后也解决不了。

　　无论在联系时还是在会面时，都要明确表达你的需求。如果想要反馈，就说清楚。如果你想要推销产品，也要说明。这次可以只验证问题，等验证成功后再回来推销。

　　不要过度依赖自动化外联，这样是在浪费精力。可以多发些消息，但没必要用专门的软件群发上千封邮件。如果走到这种极端，那说明你离失败不远了——因为这意味着没人真正关心你说什么。

　　有些群体的回复率本来就很低。像那些竞争激烈的群体或者高管，给完全不认识的人发的冷邮件可能完全没用。如果你的产品只针对财富 500 强企业，那在没有足够人脉之前，还是多考虑一下吧。

　　速度很关键。有人回你消息的线 秒内回复——对，就得这么快。我以前做过呼叫中心的生意，如果我们能在 5 分钟内回电，客户预约的概率会提高 90%。创业公司就是要拼速度，所以要时刻盯紧你的消息。

　　尽量找出一个具体的问题。问题越清晰，你就越容易验证并解决它。具体性不仅来自于产品功能，也来自于目标用户。比如，PayPal 意识到 eBay 上的大卖家在支付上有问题。

　　最好的反馈就是看用户是否真的使用、回购并为你的产品付费——这也是我说要尽快进入下一个阶段的原因。别在验证阶段拖太久，这应该是个短平快的过程——按周算，而不是按月算。

　　用户不了解你的解决方案是什么，所以觉得是浪费时间。可能产品是免费的，但用户的时间可不是。用户职位越高，这种影响越明显。你能和他们的下属一起合作试用产品吗？如果一直没有回应，那可能有其他问题——即使是高管，只要问题足够严重，他们也会花时间去解决的。

　　你没有把产品讲清楚。 怎么描述产品很重要，太复杂了别人就听不懂。用跟朋友聊天的方式去解释产品，并直接问用户对你的解释有什么意见。

　　你缺乏可信度。如果你的网站乱七八糟，或者看起来不够专业，企业是不会冒险试用的。最好的情况是他们觉得浪费时间，最差的是他们认为你的产品有安全隐患，或者会带来问题。所以，在第一级选择这个想法的的原因最好是你自己遇到过类似的问题，这意味着你有资格帮别人解决。和他们互动时，说明你的相关资历，特别是那些让人信服的部分。人们通常不会直接说出他们的顾虑，他们可能会沉默，甚至给出误导性的反馈，说问题在别的地方。

　　用户怀疑，你的方案不一定真的能解决问题，所以觉得没必要尝试。如果潜在客户不认可你的解决方式，他们可能不会试用你的产品。常见的说法是：「软件解决不了人的问题」或者「AI 看起来不错whatsapp 变更手机号，但在实际应用中不够准确」。

　　用户无法访问你的解决方案。这就是 PostHog 最初用户遇到的问题之一。要做三重检查，确保用户能顺利开始使用你的产品。

　　用户对你的解决方案有顾虑。你的产品是否需要访问个人或公司隐私数据？可以直接问：「我看到你还没用这个产品——能不能直接告诉我有什么让你不舒服的吗？」你能减少对数据的访问需求吗？能不能让产品、网站看起来更专业，给人更靠谱的感觉？如果感知的安全风险比不上解决问题的好处，那可能说明问题本身不够大。

　　用户并不想解决这个问题。很多问题的优先级并不高，而你的解决方案对他们来说显得很麻烦。你能让产品用起来简单 10 倍，或者更吸引人 10 倍吗？如果做不到……那就换个问题吧，回到第 0 级。

　　用户反馈是个良性循环。就像滚雪球一样，你越多听取用户意见并采取行动，他们就会给你更多有价值的反馈。

　　收到的反馈相互矛盾，不知道该开发什么。进入第五级，这会帮你区分哪些是你的理想客户画像（ICP），哪些不是，从而找到更明确的方向。

　　产品没解决用户的问题，用户没理由回来。针对同一个问题做新产品，或者修复现有产品。重新进入第三级。

　　用户不需要反复使用。也许问题已经自动化解决，不需要用户再做什么。进入第五级，验证他们是否愿意付费。如果问题解决后不再需要互动，不要强求用户使用。

　　用户用了产品，但很少遇到你解决的问题。进入第五级。不常发生的问题可能很难带来可观收入，但需求量不大。如果市场潜力足够大，低客单价也可以接受。但如果招募用户非常困难，定价也有限，那可能说明问题不够大，需要回到第一级重新开始。

　　复制这个模式，把收入做到大约 100 万美元的年经常性收入（ARR）。如果你对自己的销售有信心，感觉很顺利且可以重复，那么做到至少 50 万美元；如果每次销售都觉得很难，或者流程不同，那就冲刺 100 万美元吧。

　　别把销售外包给别人。找到 PMF 本来就是个复杂的问题，别再增加「是产品的问题还是销售的问题」这个额外变量。无论外面的销售员多有经验，创始人永远是销售自己产品的最佳人选。创始人可能会因为害怕失败、缺乏信心、懒惰或者过于自信，把这一步交给别人，但你一定要避免这种冲动。确保有一个可行的商业模式至关重要，而这通常需要多次调整产品、定价和定位。创始人比员工更能快速、高效地做出这些调整。

　　拿不下第一个客户。如果用户愿意试用你的产品，但就是不付钱，可能是因为：(i) 他们遇到了问题，希望你的产品能解决，但实际上没有解决；或者 (ii) 问题存在，但价值不够大。如果是前者，你需要找出如何让产品更好地解决问题。是不是缺少关键功能？有太多 bug 让用户不愿为此付费？如果是后者，那你可能需要回到起点，寻找一个更有价值的想法。

　　用户付了钱但不满意。这可能是因为你收费很低，但实际上没有解决问题——用户可能只是出于礼貌付了点钱，或者希望你未来能解决他们的问题。如果他们付了很多钱却不满意，那可能是他们的问题非常严重，只是期待你能解决。在任何一种情况下，你需要回到前一步，确保问题真的得到解决。

　　你的客户之间差异太大。能成功卖出去是好事，但你不能对每个客户卖不同的产品然后说这就是产品市场契合点。你能把一次销售的经验重复四次吗？如果能，说明你做对了。如果不能，那还是回到上一阶段，继续优化。

　　在这一步卡住了。如果你总是有一些小进展，但没法转化为实质性的收入，可能是因为你没有能力彻底解决当前面对的问题，即便这个问题确实存在。如果你还想继续尝试，可以再坚持一下。但如果这样的情况已经反复发生，那也许选择一个更简单的目标会更明智。

　　按月收费而不是按年收费，除非客户更偏好年度合同。如果客户倾向于年度合同，可以提供解约条款，让他们在一定条件下退出，从而降低他们的决策风险。

　　动机很重要。如果你对正在做的事情不感兴趣，那就转型。就这么简单。做你感兴趣的事会让你走得更远。

　　果断决定。 在我们那一届 YC 项目中，我们看到有些公司让一个创始人做 X，而另一个做 Y。找到 PMF 已经够复杂了，不要再因为分散精力让事情变得更难。选一个点全力以赴。如果失败了，迅速转到另一个想法。

　　不要拿着解决方案去找问题。这样很容易对现有的代码或问题产生依赖。特别要小心那些非常小幅度的转型。我们最初的一个想法是开发一个监控技术债务的工具——通过 GitHub 插入，问工程师在哪里遇到问题，浪费了多少时间。因为卖不出去，我们不得不转型，然后用相同的方法来监测工程师的幸福感，重新用了一遍用我们的代码。结果是浪费了一周时间开会，最后还是放弃了。