Easy Builds, Uneasy Values
There's a box on a form that asks whether you've considered the end user. Checking it takes about four seconds.
I've watched plenty of teams check it. They aren't careless or cynical. They're funded, staffed and moving, and the form sits between them and the work. So it gets filled in, submitted and forgotten, the way most gates are.
For a long time, that mattered less than it should have. Not because the gates worked, but because something else did: building was expensive. Standing up a product took months of engineering effort, and that cost quietly forced a question nobody had to write down. Is this worth building? The expense was a crude form of discovery. Teams argued, hedged, and occasionally talked to customers, mostly because being wrong was costly enough to be frightening.
That protection is gone. With tools like Lovable and Google AI Studio, a team can go from approved funding to a working prototype in days. Feasibility, once the hardest question, is now the easiest. And that's the trap, because feasibility feels like progress. It demos well. It gives everyone something to point at. Meanwhile, the questions of whether anyone wants this and whether it works for the business haven't moved an inch.
The build got easy. Knowing what's worth building got no easier, and it's now the only hard part.
The checkbox problem
Large organizations saw a version of this coming. They added stage gates: an early checkpoint where a team confirms it has thought about the user. It's a reasonable idea with a predictable flaw. A gate that can be passed by clicking submit measures compliance, not understanding. Nobody is accountable for the answer, and often nobody reads it.
The form isn't the villain. The structure is. Asking the question and acting on the answer are owned by different people, or by no one. And AI makes it worse, because when a team can have a working version before the review happens, the gate stops being a gate. It becomes paperwork on something already built.
You can't fix that with a better form. You fix it by giving discovery a permanent place in how work gets done.
A different model
At a previous company, I was trained in what's called the Product Operating Model, along with dual-track agile. Two ideas from that training stuck with me.
The first is that experience strategy sits on equal footing with technology strategy and product strategy. Three disciplines share responsibility for decisions that have to work for users and for the business, so no single voice can skip the user.
The second is dual-track: two sprints running side by side. One delivers against the roadmap. The other, the background track, runs discovery on signals that might change what the roadmap should be. Discovery stops being a hurdle you clear once and becomes a standing part of the schedule, with its own time and people.
Here's what that looked like in practice. I owned a scheduling product built around one-off appointments: book a 90-minute massage. Over time, customers started using it for something different, like signing up for a six-week yoga series. The product had never been designed class-first, and nothing was broken enough to trigger an alarm. It was just a slow, quiet mismatch.
Our background track went looking, with three kinds of evidence:
What people do. A data analyst helped us understand who the class users were, where they came from, and how they used the product.
Where they struggle. We worked with support and read through tickets to see where people stumbled and reached out.
What they say. We contacted class customers directly and asked whether the product was working for them, and why or why not.
All three pointed the same direction. Some customers were frustrated enough to weigh alternatives. Others, the evidence suggested, never signed up because the product didn't fit how they worked. One investment could protect the customers we had and open up a market we weren't serving. That's not a conclusion you reach from a checkbox. It's one you reach by listening in three different ways at once.
Speed with aim
None of this means slowing down. AI can accelerate the learning side too: synthesizing interviews, clustering support tickets, surfacing patterns in usage data. The goal isn't to make building slower. It's to make sure discovery speeds up alongside it, with its own capacity, so it doesn't get squeezed out the moment someone can ship in a weekend.
So back to the box. Checking it takes four seconds, and that's the problem. Speed only helps if you're pointed at the right thing, and when building is nearly free, pointing is the scarce skill. No form can do it for you. Give it a seat at the table and a place on the calendar, and the rest gets a lot easier.