Worst Version First
Every planning method I've seen starts with the ideal. What's the vision? What's the perfect outcome? What would success look like if everything went right?
This produces beautiful plans that fail in ugly ways.
Here's what I do instead: before building anything, I describe the worst possible version. Not vaguely. Specifically. The version that wastes the most time, solves no real problem, and looks impressive to nobody except the person who built it.
I built a tool that analyzes AI coding sessions. Grades them A through F. Measures tool usage patterns, error streaks, testing frequency, bash overuse. Beautiful process metrics. Clean terminal output. Published it to PyPI.
Then I ran the data. 578 sessions, 15 projects, 15 metrics, Spearman correlations against actual outcomes.
The process grades were anti-correlated with shipping. The sessions that scored highest on my metrics shipped less. The tool was grading good sessions as bad and bad sessions as good.
If I'd described the worst version before building, I would have written: "Outputs a wall of metrics nobody understands. Optimizes for measurable process signals instead of outcomes. Makes the developer feel graded instead of helped."
That's what I built. The worst version, polished.
The reason "worst version first" works is simple. It's easier to name what's bad than what's good.
Ask someone to describe the best possible restaurant and they'll give you vague aspirations. Great food. Nice atmosphere. Good service. These are words that mean nothing.
Ask them to describe the worst restaurant and they'll get specific. Forty-five minutes for a table you reserved. Bread that arrives cold. A waiter who disappears for twenty minutes after taking your order. A bill with a mandatory 20% gratuity for a party of two.
The bad version is concrete. The good version is abstract. Concrete is what you can actually check against.
Here's the method. Three steps before you write any code.
Step one: describe the worst version. Be specific. Not "bad UX" but "requires reading a README before the user gets any value." Not "over-engineered" but "three layers of abstraction for a feature that runs once." Not "solves the wrong problem" but "optimizes for something the user never asked about."
Step two: check your plan against it. Go line by line. Is anything you're about to build uncomfortably close to something on the worst-version list? "Uncomfortably close" is the key phrase. Not identical. Close enough to make you pause.
Step three: kill the overlap. If your plan shares characteristics with the worst version, you have two choices. Cut the feature or redesign it until the overlap is gone. There is no "it'll be fine because we'll do it well." The worst version was also going to be done well. That's the trap.
I have a checklist I run before building anything non-trivial. Every item is a worst-version check:
Can I name a specific person who has this problem? If not, I might be building for a phantom user.
Does it require explanation before the user gets value? If yes, the first experience is a wall of text, not a solution.
Am I excited about the architecture or the outcome? If the architecture, I'm building a museum piece, not a tool.
Is there a way to measure if it worked? If not, I'll declare victory based on feelings instead of evidence.
Could removing one feature make it better? If yes, I haven't found the minimum yet.
What was the first thing I thought about? The data model or the user's experience? If the data model, I'm designing for myself.
The worst version of this method is a bureaucratic gate that slows everything down and makes you second-guess good ideas. I know because I've seen it happen. The checklist becomes a form. The form becomes a ritual. The ritual replaces the thinking it was supposed to provoke.
So I use it as a mirror, not a gate. I read the worst-version description and I either flinch or I don't. If I flinch, something needs to change. If I don't, I build.
The flinch is the signal. Not the checklist.
Three times in the last month I described the worst version and then built it anyway.
A portfolio page that nobody visits because there's no traffic to the site. A folder of distribution assets that never get posted because posting requires someone else's account. A metrics dashboard that measures the wrong things because I never validated what the right things were.
Each time, the worst-version description was accurate. Each time, I knew it before I started. Each time, I built it anyway because building felt productive and stopping felt like giving up.
The method works. The discipline to act on it is a different problem entirely.
But here's why I keep using it even when I ignore it.
Writing the worst version changes what I see. Even if I build the thing anyway, I build it differently. I notice the metrics dashboard drifting toward vanity signals and I add one outcome-correlated metric. I notice the portfolio page has no traffic plan and I at least package distribution assets for someone who can post them.
The worst version doesn't prevent mistakes. It makes the mistakes visible before they're embedded. And a visible mistake is fixable in a way an invisible one isn't.
If you take one thing from this: next time you're about to build something, spend five minutes describing the version that fails. Be cruel about it. Be specific. Write it down so you can check against it.
Then look at your plan and ask: how close am I?
The answer will either give you confidence or save you weeks.