为什么「功能清单」不是产品路线图
很多团队把路线图写成「下个季度要上线的功能列表」。它看起来很清晰，但往往回答不了三个关键问题：
- 我们要验证什么假设？
- 不做成这样，用户会怎样？
- 为什么是现在，而不是三个月后？
一个更可用的写法
我更倾向把路线图写成三层：
- 主题（Theme）：这一阶段要推动的业务或用户结果，例如「降低新用户首次成功成本」。
- 赌注（Bet）：为了达成主题，我们愿意投入的方向，例如「用引导式配置替代空白工作台」。
- 交付（Delivery）：支撑赌注的具体改动，才是功能与项目。
功能仍会出现，但它是下注后的手段，而不是路线图的主角。
落地时怎么开会
周会里先对齐主题是否还成立，再看赌注有没有新证据，最后才排交付节奏。这样讨论会自然从「我们能不能做完」转向「我们是否还该继续赌这个方向」。
如果你也在用功能清单当路线图，可以先挑一个主题，试着把下周的条目重写成「主题 → 赌注 → 交付」三层，看看会议质量有没有变化。