Talk to users first. Design decisions become clearer after.
There's a particular kind of waste in product development that's easy to miss because it looks like progress. A team builds out a feature—interface polished, interactions thoughtful, implementation clean. Ships it. Watches adoption flatline. Discovers six months later that nobody actually wanted the thing they built.
The cost isn't just the wasted development. It's the opportunity cost. The runway burned on something that didn't move the needle. The team's momentum lost to a feature that should never have been built in the first place.
Most of the time, this isn't a result of poor design or engineering. It's a result of building before validating. Spending craft and resources on executing a solution before confirming that the problem was worth solving.
I've learned this the hard way multiple times. And the pattern is always the same: the teams that talk to users before designing have fundamentally easier design conversations. Because the problem space is already defined. The solution isn't theoretically elegant; it's practically grounded in something real.
The cost of designing without validation
Here's what I've noticed: designing without validation feels efficient. You skip the research phase, move straight to execution, start shipping faster. But what you're actually doing is optimising for the wrong thing.
You're optimising for speed to launch, not speed to product market fit. And those are not the same thing.
I worked on a productivity tool where the founding team was convinced users wanted a particular automation feature. It was obvious to them. They'd all experienced the pain. So they designed it. Built it. Shipped it. The feature was technically sound. The interface was clear. Nobody used it.
The conversation with actual potential users would have revealed something important: the problem was real, but the solution they'd imagined didn't match how people actually worked. The automation needed to be triggered differently. The output needed to flow into a different system. The assumptions embedded in the design were invisible until someone asked a potential user to actually try it.
That conversation would have taken two hours. It would have saved six months of development pointing in the wrong direction.
What validation actually means at early stage
There's a misconception that validation requires formal research, statistical significance, controlled conditions. Early stage validation is different. It's simpler and less formal, but also more consequential.
At early stage, you're not trying to prove a market exists. You're trying to understand whether the specific problem you think exists is real and acute enough that someone would pay to solve it. Whether your assumed solution actually addresses the friction. Whether you're solving the right problem for the right people.
This requires talking to people outside your founding team. Actually talking to them, not convincing them. Someone who experiences the problem. Someone who's tried to solve it themselves. Someone who would be a potential user.
What you're listening for is specificity. A potential user shouldn't have to think hard about whether they experience the problem. It should be obvious. They should be able to describe the friction in concrete terms. They should have workarounds they've already built because the pain is acute enough to justify the effort.
When someone has to think about whether a problem matters to them, that's signal. Not that the problem doesn't exist, but that it's not acute enough to drive adoption.
The question that matters most
Here's the one question I think deserves the most attention at validation stage: "What do you do today?"
Not "would you use X?" Not "how much would you pay for Y?" But a straightforward request to walk through the current workflow. How do they solve this today? What workarounds exist? Where does the friction actually live?
This single question teaches you more than abstract discussion about the problem space. Because you get to see where the person's attention actually goes. What they complain about. What they've built to work around the limitation. What they've accepted as "just how it is."
I watched a designer conduct research on a team communication tool. She started with "what problems do you face in team communication?" Generic question, generic answers. Then she asked "walk me through how you communicated about the project last week." Suddenly everything was concrete. The person described specific friction points that hadn't come up in the abstract discussion. They described workarounds they'd invented. They revealed that the problem they'd initially described wasn't actually the thing causing the most friction.
That's the power of grounding in actual workflow rather than abstract problem statements.
Validation changes the design conversation
Here's what happens when you validate before designing: the design conversations become fundamentally different.
Instead of debating whether a feature should exist, you're debating how to implement something you've already confirmed people need. Instead of defending an assumption, you're working from evidence. Instead of designing for an imagined user, you're designing for someone whose workflow you've actually observed.
This shifts what designers spend energy on. Less time defending the "why." More time optimising the "how." Less second guessing about whether you're solving the right problem. More focus on solving it well.
The other thing that changes: stakeholder alignment. When you've talked to actual potential users and confirmed they experience the problem, it's much harder for someone to argue the solution doesn't matter. You're not designing based on opinion. You're designing based on observation.
The risk of asking too formally
One thing I see teams get wrong is making validation too formal. They build out a research plan. Schedule interviews. Create discussion guides. By the time they're ready to validate, weeks have passed and they've already invested so much in the validation process that there's pressure to find confirmation rather than genuine signal.
Early stage validation can be much simpler. Grab coffee with someone. Walk through their workflow. Listen. Take notes. Repeat with five people. Identify the patterns.
Formal research is valuable, but it's not a prerequisite for early stage learning. What matters is directness. Real conversations. Genuine curiosity about how someone actually works.
The teams that validate fastest are usually the ones doing this casually. Founder goes for coffee with a potential customer. Asks real questions. Listens without defending. Reports back to the team. Repeats.
What validation doesn't guarantee
I want to be clear about what validation does and doesn't do. Confirming that a problem exists doesn't guarantee you have the right solution. Talking to five people doesn't mean the whole market wants what you're building. Validation de risks the existence and acuity of the problem. It doesn't eliminate all uncertainty.
But it eliminates a particular kind of waste: the waste of building something for a problem that doesn't actually matter. And that's worth the two hours of conversation.
I've also seen validation used as a delaying tactic. A team validates, finds some confirmation, uses it as a reason to research more. To validate further. To keep talking instead of building. There's a point where you have enough signal to move forward, and continuing to validate becomes avoidance.
The discipline is knowing the difference. Do you have enough clarity on the problem to start building? Or are you in genuine uncertainty about whether it matters? If it's the former, you've validated enough. Ship. Learn from real usage.
Building with validation in mind
What I've come to understand is that validation isn't a separate phase. It's a discipline that should inform how you approach early stage work from the beginning.
It means: before you spend significant effort on something, talk to a handful of people about whether they experience the problem you're trying to solve. Not to convince yourself you're right, but to understand whether the friction is real and where it actually lives.
It means: designing with what you've learned from those conversations in mind. Not designing for the user you imagined, but for the user whose workflow you've observed.
It means: staying curious about whether you're right. Launching with humility. Using early usage data to refine, not to defend.
The products that achieve product market fit fastest aren't usually the ones with the most polished design or the most comprehensive feature set. They're the ones where someone took time upfront to understand the problem before they committed to a solution. Where validation informed design instead of design creating the need for validation.
That's not inefficient. That's the most efficient possible use of a team's resources.
