PMF
产品市场契合
市场以你来不及构建的速度把产品从你手里「拉」出去的那个点。在你感受到这股拉力之前，你还没有 PMF。
PMF 出了名地难定义又出了名地好识别。Marc Andreessen 的启发式仍然成立：当产品被用户、媒体与股权表同时拉动，而你的问题不再是怎么找到客户、而是怎么跟上他们时，你就知道你有了它。
PMF 之前，你做的几乎所有事都是一个赌。正确的组织架构图、正确的技术栈、正确的招聘计划，全都取决于哪一段客户真的在拉。PMF 之后，问题变成运营的：扩团队、加固技术栈、控制烧钱。
最昂贵的 PMF 之前错误，举个实际例子：一支团队融了一轮种子，招了四名工程师，花九个月构建一个由 Kubernetes 支撑、多区域、微服务的平台「好让我们能扩展」。他们扩展到了四十个用户、烧完了 Runway，而那个为数百万构建的架构从没被数百个用户测试过。相反的失败更少见但真实：一支团队找到了拉力、被报道了，而那台过载的单一服务器在整个市场都在看的那一周里崩了。这个工程决定完全是「你在 PMF 线哪一侧」的函数，所以诚实地命名这条线，比任何技术栈决定都更重要。
创始人回避的诚实取舍：承认你在 PMF 之前感觉像承认失败，于是 BP 把一场一次一个客户的苦战描述成「早期牵引」。如果获取仍是一场苦磨、且流失高到口碑无法承载增长，那么不管 BP 怎么说，你都在 PMF 之前，而正确的动作是继续发布那个能解决下一个不确定性的最便宜 MVP，而不是为一个你还没挣得的规模去构建。一段发现阶段帮你命名最有风险的假设；一位 fractional 运营者能在搜索期间防止昂贵的技术错误，但无法替代真正产生拉力的那种创始人对客户的执着。过了 PMF，你通常需要的是一位 CTO，而不是一位联合创始人。参见 Fractional CTO 奥地利。