.png)
Every major product team right now is solving the wrong problem.
The industry has spent the last two years racing to make building faster, faster prototyping, faster iteration, faster shipping. And by that measure, it’s working. AI has genuinely compressed timelines that used to take months into days. That’s real progress.
But speed isn’t the same as direction. And right now, a lot of teams are moving very fast toward the wrong thing.
The trap is forgetting what building a product is actually supposed to do. It’s not just about shipping features. It’s about shipping features that users actually want, understand, and come back for. When teams get seduced by how fast they can build, how quickly a prototype appears, how polished the output looks, they skip the step where everything falls apart: finding out if real people can actually use what they made.
Building fast and understanding users are not the same thing
AI has flipped the product development lifecycle upside down. Five years ago, the logic was simple: protect engineering time by validating before you build. Understand the customer, design the solution, test it, then invest in building it out.
That model assumed engineering was the scarce resource. It isn’t anymore.
“AI has sped up development by like 10x, 20x, depending on what you’re building. We fail much faster now and then go even faster.”
— Arbind Duhan, Senior Product Leader
When you can go from idea to working prototype in an afternoon, the calculus changes. Teams ship to early adopters, watch usage, and iterate. The feedback loop that used to take a year now takes days. This feels like progress, and in many ways it is.
But there’s a critical assumption buried in this model: that the feedback you’re getting is actually telling you something meaningful. Most of the time, it isn’t.
Usage data has a blind spot. And it’s a big one
Here’s what product analytics can tell you: where users drop off, which features get clicked, how long someone stays on a page, and which flows get abandoned.
Here’s what product analytics cannot tell you: what the user was thinking when they gave up, why they clicked the wrong button, and whether “I love this feature” in a survey actually means they found it easy to use.
That gap between what users do and why they do it is where products quietly fail. Not in a dramatic way. Just slowly, steadily, with churn that never quite makes sense and adoption that never quite takes off.
“I’ve watched usability testing where a user tells me the feature is really easy, and I’m watching them do it wrong right in front of me. They’re not lying. They just don’t know they’re struggling. No amount of product analytics catches that.”
— Lihong Hicken, Host • UX Stories
"The why only comes from watching real people use your product. Not from dashboards. Not from surveys. Not from sales call notes or support tickets, though all of those help. From actually observing behavior."
Teams are solving the symptom, not the problem
There’s a deeper issue that emerges when teams build without watching users: they end up solving the wrong problem entirely.
Customers are good at describing their pain. They are rarely good at diagnosing the root cause or identifying the right solution. That’s not a criticism, it’s just how humans work. We describe what hurts. We don’t always know why.
“Customers know what their problem is — but they may not know what the right solution is for them.”
— Arbind Duhan
A customer asks for a conversational AI agent to reduce support calls. The team builds it. But when a prototype goes in front of real users, it becomes clear that the real opportunity is somewhere else entirely, a different workflow, a different use case, a different ROI story. The customer didn’t know that. They couldn’t have known that without seeing something real to react to.
This is the cost of skipping observation. You build what the customer asked for. You ship it. And six months later, you’re wondering why adoption is flat because you solved the symptom, not the disease.
A generation of builders never learned to test. Here’s why.
If so many product teams know user research matters and most do, at least in theory, why does an entire generation of builders skip it?
The answer isn’t laziness or arrogance. It’s access.
There was a time when running a usability test cost $19. Any founder, any PM, anyone with a hypothesis and a prototype could get real feedback from real users the same day. The cost of curiosity was essentially zero. Testing became a habit because it was easy to do.
Then the major platforms got acquired by private equity, consolidated, and repriced for enterprise. That $19 test became a $30,000 annual contract. Overnight, user testing stopped being something a startup could just do and became something you budgeted for once a year, if at all.
“The new generation of vibe coders and founders — they didn’t grow up in an era where the cost of curiosity was affordable. They’re just used to building fast based on whatever information they have available.”
— Lihong Hicken
When a tool gets priced out of reach, the habit dies. And when the habit dies, the muscle atrophies. Today’s builders aren’t skipping user research because they think it doesn’t matter. They’re skipping it because they never had the chance to see what it actually does.
What the feedback loop needs to look like now
The solution isn’t to slow down. The speed of vibe coding is real, and it’s not going away. Teams that try to reintroduce six-week research cycles into a two-day build cycle are going to lose. That’s just the reality.
The solution is to make user feedback move at the speed of building.
That means a few things:
Watch real users, not just their data. Usage metrics tell you what happened. Observation tells you why. The why is where the real product decisions live. Even a handful of sessions watching real people use your prototype will surface things that months of analytics miss.
Test earlier and rougher. The point of user testing isn’t to validate a polished product. It’s to find out you’re wrong before you’ve built too much. A lo-fi prototype tested with five users is worth more than a perfect product launched to the wrong audience.
Build feedback into the workflow, not on top of it. The teams that do this well don’t treat research as a gate. They treat it as a continuous signal that runs alongside the building, always on, always informing, never blocking.
Make it affordable enough that the habit can form. This is the structural problem. When the cost of curiosity is zero, teams ask questions. When it’s $30,000 a year, they stop. The tools have to come back down to a price point where testing every hypothesis is possible, not just the big ones.
“If I can understand what two months of real customer testing would look like and get that signal in a day or two, that changes how fast I can move with confidence.”
— Arbind Duhan
Speed plus understanding.
That’s what the next generation of product teams needs. Not one or the other.
The real differentiator isn’t how fast you build. It’s how well you listen
Product Hunt has thousands of new launches every week. Most of them will go nowhere. Not because the builders weren’t fast enough or talented enough, but because they shipped something users didn’t actually need, or couldn’t figure out how to use, or didn’t come back to after the first session.
Speed is table stakes now. Every team has access to the same AI tools, the same vibe coding workflows, and the same ability to ship fast. The teams that win aren’t the ones that build faster. They’re the ones that stay closest to their users while building fast.
That requires a feedback loop that moves at the speed of the product. And right now, for most teams, the gap between how fast they build and how fast they listen is getting wider every month.
Banner
Close the gap between building and listening.
TheySaid runs AI-moderated user testing in hours, not weeks, at a price point where testing every hypothesis is possible. Sign up free at theysaid.io
Listen to the full episode on UX Stories: You're Building 10x Faster Than You're Learning (Here's the Fix)
.svg)
