Product evolution blueprint
Draw the next three versions on one chart, and write down what each one is meant to validate. The feature list is an outcome, not a starting point.
What you'll run into
- 做完第一版，不知道下一步该做什么，只能看谁在提需求
- 排期表列得很满，但说不清为什么是这个顺序
- 做了半年，回头看不出产品比当初进步在哪
3 月：记录、分类
4 月：统计、图表
5 月：导出、分享
按功能排。上线之后无法判断对错
v1 验证有人愿意记 → 次周留存
v2 验证记了会回来看 → 回访频率
v3 验证愿意付钱 → 付费转化
按假设排。每一版都有明确结论
How to write it
Four lines per version. If you cannot fill them, that version is not yet thought through.
| 这一行 | 写什么 | 例子 |
|---|---|---|
| 要验证的假设 | 一句能被证伪的话 | 他愿意每天花十秒记一笔 |
| 为此要做的 | 能验证这条假设的最小范围 | 只做记一笔的完整流程 |
| 看哪个数 | 一个指标，不是一堆 | 次周留存 |
| 什么算成立 | 提前定一条线 | 次周留存高于 25% |
When to revise it
- Re-read the blueprint after every release. If the hypothesis held, follow the plan into the next version; if not, the next version should test the same hypothesis a different way — not march forward blindly.
- Only draw three versions out. Anything further is a guess. The further out you draw, the more it looks like a promise, and the heavier the psychological cost of changing it.
- When a hypothesis changes, write down why. Half the value of a blueprint is that it records how you were thinking at the time — looking back tells you where the judgment went wrong.
- Don't send it out as a promise. Externally you can talk direction; specific version contents stay internal. Once it's out, every change reads as a broken promise.
When you build solo, this chart can be a markdown file — three sections, four lines each. What matters is not the form; it is that before starting each version you can say "this is what I am betting on."