Product Evolution Blueprint
Draw the next few versions on one chart, so each version has an answer to give.
Draw the next few versions on one chart, so each version has an answer to give. 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:
- After the first version you don't know what to do next, so you just follow whoever's asking for features
- The schedule is full, but nobody can say why it's in this order
- Six months in, you can't tell how the product improved since the start
A schedule and a blueprint are two different ways to order work. A schedule orders by features: March does records and categories, April does stats and charts, May does export and sharing—done is done, with no standard telling you whether to keep going. A blueprint orders by hypotheses: v1 validates "someone is willing to record," watching week-two retention; v2 validates "they'll come back after recording," watching return frequency; v3 validates "they'll pay," watching conversion. Every version gets a clear verdict. This is the build-measure-learn loop from lean startup, applied to versions: write the hypothesis first, pick a metric, and let the data decide the next step instead of pushing forward on feel.lean-startup
A schedule isn't useless—it fits the phase where the product is already validated and you're executing a plan. Before that, scheduling features means betting a definite plan on an uncertain assumption. If the bet loses, a full schedule still says nothing about right or wrong.
How to write it
Four lines per version. If you can't fill them, that version is not yet thought through:
| Line | What to write | Example |
|---|---|---|
| The hypothesis | A statement that can be falsified | He'll spend ten seconds a day recording one entry |
| What you'll build | The smallest scope that tests the hypothesis | Only the complete flow of recording one entry |
| Which number to watch | One metric, not a pile | Week-two retention |
| What counts as success | A line set in advance | Week-two retention above 25% |
The fourth line must be written in advance. Set the standard after the fact, and you'll always find a way to convince yourself the number is fine.
The four lines are themselves a chain of reasoning: the hypothesis answers "what am I betting on," the build answers "what am I betting with," the metric answers "how will I know it won," and the success line answers "what counts as winning." If you can't write the fourth line, one of the first two is usually empty anyway.
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.
A blueprint pairs with a not-doing list: the blueprint says what this version validates, the list says what it explicitly won't do. Without both, AI and your team will roll the scope up with "just add it while you're at it."
When you build solo, this chart can be a markdown file—three sections, four lines each. What matters is not the form; it's that before starting each version you can say, "this is what I'm betting on."
The chart also forces a bet statement before every version starts: when you can name the bet, the scope naturally tightens; when you can't, go back and fill in the four lines instead of scheduling.