The vision that gets built
What missing in most product teams that means the safe version always wins.
Most product teams ship things that no-one remembers.
The teams are always full of smart, capable people who do good work. But the products end up feeling indistinguishable from the next, and it’s unclear why.
Here’s what I think is going on. The safe version of any product decision wins by default. It’s easier to scope, easier to defend, easier to ship and saying yes to it doesn’t cost anyone as much.
The harder version, the one that would make the product actually distinct, requires someone who can hold the deep context of what’s going on across the org and within the specific context of the project whilst also zooming out of it, and then make an argument that’s core to what’s at stake and in a way that makes the team viscerally want to build it. Most teams don’t have anyone whose job it is to do that and that alone.
In a way, this is by design. A company is set up (even an early one) to dilute the creative spark that helped the company form in the first place. The competing demands inside and outside the organisation mean the familiar roles in any set up end up with a certain flavour: a designer who is rewarded for executing briefs cleanly, not for arguing the whole brief is wrong. PMs rewarded for managing scope, not expanding it. Engineers encouraged to ship quickly and reliably, not for taking on technical debt to enable something more ambitious. Each role has a perfectly good reason to nudge toward the safer answer. The cumulative effect is that nobody is individually wrong, but the product gets quietly less interesting with every retro and over-the-air update.
You can see this happening in real time if you sit in enough product meetings. Often the format itself fails to invite a contribution about what the more interesting version of the feature could be, especially in the half-day sessions that end up as partisan arguments about how something should be or have been coded. (This happened to me a lot early on, particularly when I was working as both PM and designer.)
And when someone does propose the better version of something, someone else, with good intentions, points out that it’s harder, takes longer, has no clear ROI, doesn’t fit the current sprint. Everyone nods. The simpler version gets built. And nobody fights for the harder, more interesting option.
Multiply that by a hundred decisions over a year and you have a product that does what it’s supposed to do but has nothing in it anyone would later describe as memorable.
This was roughly where we were with Kaizen’s onboarding by 2025. We’d gone from 0 to 10k downloads in 2023, then to over 30k, at which point we needed to dig deep into how to make things better. [Check it out:]
The thing that breaks this pattern is rare. It’s someone in the room who can present the harder version of the work in a way that makes the safe version feel obviously inadequate by comparison. Not by being charismatic or persuasive personally, the new direction has to rest on something substantive, not on enthusiasm alone. It’s a particular shift in approach, and I think it involves three things.
First, framing the problem in a way that surfaces what’s at stake. The safe version usually wins because the cost of building it is more visible than the cost of not building the better version. Most teams default to the simpler scope because the trade-off has been framed as “feature complete sooner” versus “feature complete later.”
Reframed properly, the trade-off is something else entirely. It’s why this company exists in the first place. It’s what the team actually cares about, beyond the sprint. It’s what customers (who already have a dozen options for solving the problem we think we’re solving) would notice and remember about ours. The trade-off isn’t time. It’s whether this product has a chance to stand out, or quietly joins the list of forgettable apps gathering 2.8 star ratings.
That’s a different conversation. And it changes what people are willing to spend energy on.
Second, presenting the harder version in enough detail that it moves you. Most attempts to argue for ambition fail at the imagination stage. The harder version exists as words or maybe a graphic in a slide; the team can’t picture it; but the easier version has some existing (internalised) wisdom for being there, heck it may already exist (bar a few tweaks in the Figma) or as a wireframe that can be polished up no problem. So arguing the case for something that’s almost invisible vs something we know how to do already. Of course the easier version wins.
The work, then, is to make the harder version real, or at least visible enough. There’s no single way to do this. Sometimes it means going back to the team, stakeholders, or customers to gather more context and structuring that process so their responses surface what’s actually important and what new direction or form this might take. Sometimes it means rough sketches, prototypes (AI is genuinely useful here, for moving across different media to make a point), references pulled together from inside and outside the team’s awareness. Anything that helps people actually imagine the product existing in a new way.
Once they can imagine it and feel that they’re part of contributing to that vision, the cost of not building it becomes concrete. Before that, it’s a hypothetical and blurry one at best.
Third, taking responsibility for the decision in a way that lets others commit. The harder version asks more of everyone, and people will only sign up if they feel someone is genuinely accountable for the call. If the person making the case waffles, hedges, or hands the responsibility back to the room, the room will revert to the safer answer. Nobody wants to be left holding a decision they didn’t fully make. Given the natural inertia around any big swing into the unknown, you have to be unambiguous: this is what we should do, this is why, and I’ll defend it. That clarity is what makes the team’s yes feel like a real commitment rather than a passive agreement.
I wrote about a specific time this happened, when our team at Kaizen agreed to build something operationally expensive, a full reimagining of the dashboard, designed to lay the foundation for how we built trust with users at every step of their training, and to give us real room to hang future innovation off it. It required real engineering effort. But the alternative had become unacceptable.
What changed the room was a specific way of presenting the work that made the cost of the safe version feel like the bigger risk. [Check it out ]
The reason I think this matters more now, not less, is AI. The safe version of any product decision is about to get dramatically cheaper to produce. Generic onboarding, generic dashboards, generic flows, generic copy, all of it is becoming nearly free. Which means the floor of “good enough” is rising quickly, and the gap between products that are merely competent and products that are actually distinct will be the thing that separates one app or thing from another. If you’re competing on competence, you’re competing against a tool that costs almost nothing.
Which makes the people who can do what I’m describing, frame the harder version, make it imaginable, take responsibility for the call, disproportionately valuable. Not because the rest of the team can’t do the work. They can. But the work won’t get chosen in the first place unless someone in the room makes the harder version feel inevitable.
Most teams don’t have that person. Some teams have them but don’t recognise it, which is its own problem. This type of work requires permission and a protected space to do well, and a lot of teams unintentionally crush it by defaulting back to scope discussions every time it surfaces. A few teams have the person and the conditions, and you can usually tell which products those are by using them. There’s something in the experience that makes you stop and notice. Something that wasn’t going to be there if the safe version had won.
Most products don’t have that something. The cost is invisible. There’s no obvious failure, no specific moment where the wrong call was made, but it accumulates. It’s the difference between a product that gets remembered and loved, and one that gets used and shelved until something only a little bit better comes along.
Thoughtful piece - the idea that what gets built is less about the purity of the vision and more about its ability to survive reality really resonates