Vision isn't magic

Ideas are cheap. Every designer I’ve managed has had three ideas by mid-morning. If your org’s problem is “we don’t have enough ideas,” that’s easy to fix: creativity is a muscle, and a muscle needs reps. Generate a lot, including bad ones, and the good ones show up more often. That part is trainable.

The hard parts are choosing which idea to build, and then faithfully building it.

Choosing well requires something most orgs are worse at than they think: staying clear on what success means, and holding that clarity during the twists and turns of the project. I call it goal maintenance. It’s not glamorous. It’s also where I’ve watched more visions die than in the idea stage – not because the idea was wrong, but because a few months in the team had lost their grip on why the idea was chosen in the first place. Every debate about the product turned into a fight about what was easy for engineering or design, and not about what the customer actually needed.

Nobody kills a well-chosen idea with one bad call. They kill it with a hundred small, locally reasonable ones – a scope cut here, a shortcut there – that each look harmless and, together, push the built thing away from what it was supposed to be.

This isn’t only a product problem. Most of what gets labeled “bad engineering” is that same drift, one layer down. A quick band-aid that quietly becomes a pattern, a migration that never gets finished, a shortcut that was fine under this week’s load and isn’t fine under next month’s. No single decision was wrong on its own. Nobody was adding them up. This is the same failure as before, just harder to see at the code level than the roadmap level.

Here’s where I think “vision” gets misunderstood. Executives often want it sharp: a specific target, fully defined, implications worked out in advance. That instinct makes sense. Fuzziness feels like risk. But a vision defined that tightly is fragile and expensive. Pin down every implication before you’ve built anything, and the first real customer conversation or technical constraint breaks it, because you’ve left no room for the plan to be wrong about details you never had a way to check. All that pinning down takes patience that the org probably doesn’t have.

The alternative is a vision fuzzy enough to survive contact with reality, but attractive enough that people will fund exploring it before it’s detailed out. Creating something malleable enough to adapt, but attractive enough to invest in, is a design skill.

Coding agents change the pressures here, but the fundamentals remain. When code is cheap to generate, “we’ll figure it out as we build” starts to look like a real alternative to developing and committing to a vision at all. It’s tempting for the same reason that just pursuing your first idea is tempting: you skip the hard part. You get to start building without defending a claim about where you’re going.

But when “figuring it out as you build” works, it works because there’s implicit direction behind it. It only works if someone is doing the same goal maintenance quietly – holding a stable sense of what success looks like, near-term and long-term, and testing the current direction against it as new information comes in. Take that away, and “we’ll figure it out” is an aimless accumulation of a lot of shipped code that’s unlikely to converge on anything.

It turns out that a vision-led approach and a feel-your-way-through-the-dark approach need the same underlying discipline. Not a plan or a spec, but goal maintenance: a clear sense of what success means, near and far, and an explicit list of the assumptions the current idea depends on. Without both it doesn’t matter whether you started with a bold vision or an empty backlog.

That’s the actual differentiator – not who has the better idea, but who can tell, at any point, whether the idea they’re building is still the right one, and who wrote down, in advance, what would prove them wrong.