PMF 前与 PMF 后的领导力：连接者 vs 探索者

[ashammi244]

了解 PMF 前后的哲学和态度的差异可以帮助您作为领导者做出更好的决策。

现在，这些已经解决了，让我们深入了解 PMF 之前的注意事项！


1）不要制定路线图，而要写问题陈述
对于早期公司来说，路线图纯粹是浪费时间。

当事情不断发生变化时，你越是推迟做决定，你就能做出更好的选择。

相反，要识别问题 - 并且不要停止处理最重要的问题，直到问 台湾赌博数据 题得到解决。您可以使用周期（例如 2、4 或 6 周）来找到挑战优先事项和进入执行模式之间的正确节奏。

但是，如果没有路线图，你如何有效地规划你的工作呢？通过写问题陈述。

撰写详细的问题陈述，以确定用户和市场面临的重要问题并确定其优先级。这份按优先级排列的问题列表将成为贵公司的重点，让您有最大的机会实现产品与市场的契合。

诸如待完成的工作或第一原则思维之类的方法有助于确保您的重点与您的策略和专业知识保持一致。

通过将重点从构建路线图转移到编写问题陈述，并采用上述原则，您可以创建一种动态方法，使您的组织能够快速适应、有效地确定优先级并增加成功的机会。


2）不要写故事和史诗，要实事求是，制作原型
PMF 之前的产品管理中的另一个陷阱是编写用户故事、史诗和票证。

这些抽象的任务会减慢实际交付过程并限制团队的创造力。

虽然用户故事对于后期公司管理开销和加速交付很有用，但在早期公司，它们可能会阻碍交付团队的进度。

抽象总会减慢你的速度，而速度是实现产品与市场契合的关键。

那么你能做什么呢？认清现实吧。

这一概念的灵感来自 Basecamp 的《 Getting Real 》一书，它涉及做的事情与实际交付给客户的事情非常相似。这包括原型设计、执行快速质量保证 (QA) 和其他可提高交付速度的活动。

例如，您可以使用 Figma 等原型设计工具直观地表达您的想法，而不必编写冗长的文档。或者，您可以在功能进入准备阶段后进行简短的 QA 会话以识别任何关键问题。

另一种有效的方法是实时原型设计。您无需在纸上进行传统的原型设计，而是可以编写代码，将其推送到暂存环境，并赋予其原始原型般的外观。

通过优先考虑实际实施、原型设计、质量保证和实时原型设计，您可以提高团队的生产力，并最大限度地减少花在不必要的翻译和抽象上的时间。最终，您将加快实现产品与市场的契合。

Basecamp 的 Ryan Singer 在六月播客中讨论了实时原型设计和更好的产品构建流程（从创意到发布）：
3）无需进行深入的用户研究，直接发布即可
这通常会激起人们的兴趣。

这并不意味着快速发布有缺陷的功能或无用的东西。这样做没有任何价值。这意味着你不应该 做过多的用户研究。

是的，用户研究对于预先的产品市场契合至关重要。

是的，进行深入的初始用户研究很重要，这样才能了解你的目标和世界上缺少什么。但过度研究也有风险，因为这种做法没有限制。

解释和包装问题的方法数不胜数。早期公司经常会发现一个问题，然后就将注意力转移到另一个无关紧要的问题上，而不确定要解决哪一个问题。

最好的方法不是进行过多的研究，而是“将其付诸实践”。

Y Combinator 创始人之一保罗·格雷厄姆 (Paul Graham) 在推特上谈到了产品交付速度与实现产品市场契合的机会之间的相关性。


尽管这可能违反直觉，但这是事实。

通过快速发布产品，您可以增加找到合适产品的可能性。频繁发布产品还可以帮助您增强收集反馈、迭代和调整方向的能力。

随着时间的推移，这种能力会逐渐增强，让您更好地了解理想客户及其需求。

因此，我的建议是尽快发货。即使是最好的用户研究也无法经受住市场现实和人们对产品的实际使用。

4）不要影响你的团队，而要赋予他们权力
在后期公司，产品经理通常会被教导如何影响和领导他人做出集体决策。他们充当设计、工程和营销团队之间的枢纽，收集意见以做出明智的选择。


虽然这对于具有层级和部门的成熟组织来说很有价值，但对于早期、 PMF 之前的公司来说却没有必要。

在早期阶段，如果你有意见，就清楚地表达出来并采取行动。

当然，要倾听他人的意见并考虑他们的观点，但要避免陷入复杂的决策过程。目标是快速做出正确的决定，发布这些决定，然后从用户反馈中吸取教训。根据反馈进行迭代并继续前进。

相反，在 PMF 之前的创业公司中，要赋予人们权力。

授权决策权，分散决策流程。赋予个人的决策权越多越好。

我见过的一些有效流程涉及在规划练习中收集工程师的意见。在更激进的情况下，工程师甚至可以提出要构建的新项目，而无需进行广泛的优先级排序练习。如果反馈相关且令人信服，他们可以向 PM 解释他们为什么要研究它并继续构建和发布它。

这种程度的授权可能看起来很极端，但事实证明它对很多公司都是成功的。

日历应用 Cron 采用了这种方法，让工程师能够在最后一刻做出改变游戏规则的决定。实时访问控制系统 Nira 也在做同样的事情。我坚信这种方法——我称之为“极端工程所有权”——将在未来几年得到发展。

对于 PMF 之前的产品经理来说，这可能会让人感到不安，因为它背离了传统的路线图，甚至挑战了每周的计划。但值得考虑，因为一些伟大的公司已经通过这种方法取得了成功。


5）不要设置然后忘记，获取发布时的反馈！
打造一款出色的产品需要不断迭代和改进。这就是为什么要避免“先发货再继续”的思维模式。

在 PMF 之前阶段，您的初始版本不可能完美地达到标准。

不要设置然后忘记，而是收集有关发布的反馈并在产品仍然新鲜时进行迭代。

建立跟进每次发布的流程。

例如，您可以在 Slack 或任何其他通信平台中创建专用的反馈渠道，以集中收集来自用户的反馈。

Stripe 使用 Slack 频道接收用户采用新功能的通知。这样，工程团队就可以跟踪功能的使用情况，设计师和产品营销人员也可以直接与用户互动。

如果您有收购或采用目标，请让相关团队成员参与反馈循环。

根据收到的反馈，决定是否应该迭代该功能或确定是否该继续前进。请记住，持续的反馈和迭代是开发成功产品的关键。

最后的想法
上面的注意事项列表只是产品管理在产品市场契合前阶段的一些常见陷阱。

上述许多事项可能会让您感到不舒服。

没有路线图？

没有广泛的用户研究？

这违背了我们所学到的一切！

但根据我打造产品（大型、小型、PMF 前和 PMF 后）以及与数百名产品负责人交谈的经验，如果您希望自己的产品取得成功，就必须打破许多常见的陈词滥调。

PMF 前后的环境截然不同，因此以不同的思维方式和策略来应对它们至关重要。事实上，我正在考虑就这个主题写一整本书。