Most design conversations start in the wrong place.
They start with: How should this look? Or What’s the best UI pattern for this flow? Those are real questions worth asking. But only after you’ve answered a more fundamental one: are we actually building the right thing?
I’ve seen it too many times. A product team spends six months executing beautifully, with solid process, regular reviews, clean user flows, and launches something nobody needs. Perfectly crafted. Completely wrong.
The Real Cost Nobody Accounts For
We talk about the cost of bad design constantly. Confusing interfaces, broken onboarding, dead-end flows. These are measurable problems. You can run tests, track drop-off rates, and iterate your way out. The feedback loop is tight.
But building the wrong product? That’s a different kind of cost. You don’t get a clear signal until it’s very late. Your team ships, celebrates, then slowly notices: engagement is flat, the feature request list doesn’t shrink, and when the product goes down for maintenance, nobody complains.
That silence is the most expensive thing in tech.
The direct cost, like salaries, design tools, development sprints, infrastructure, is the part you can put in a spreadsheet. But the real damage is the opportunity cost. The six months you spent building the wrong thing is six months you weren’t learning what the right thing actually is. Every sprint you invested in the wrong direction is a sprint you didn’t spend getting closer to product-market fit.
Opportunity cost doesn’t show up in a post-mortem. But it’s always there, compounding quietly.
The Warning Signs You’re Off Track
I’ve developed a few questions I ask before any design work begins. They’re not clever or proprietary. They’re just honest questions that most teams skip in the excitement of building.
Who gets genuinely frustrated when this doesn’t work? If you can’t name a specific type of person immediately, that’s a signal. Every product worth building has an obvious, identifiable person who would be disrupted if it disappeared overnight. If the answer is vague, like “businesses” or “our users”, you probably haven’t defined the problem well enough yet.
What does the user do today without this product? The workaround tells you everything. How painful is it? How long does it take? Does it cause real frustration, or is it just mildly annoying? If the existing workaround is good enough, your product is a nice-to-have. And nice-to-haves don’t get adopted.
Are we solving the user’s problem, or the business’s assumption about the user’s problem? These are different. One comes from observation, from watching people struggle, from interviews where you ask uncomfortable follow-up questions. The other comes from a conference room, from people who are too close to the product to see it clearly. One leads to products that stick. The other leads to products that get sunset after 18 months.
The most expensive line of code ever written is the one that solves the wrong problem. It doesn’t matter how clean it is or how elegantly it was tested. Wrong is wrong.
The Validation Trap
Here’s where it gets nuanced: most teams think they’re validating. They run surveys. They conduct user interviews. They build prototypes and watch people click through them. They ship an MVP and collect feedback. And still, somehow, they build the wrong thing.
The issue isn’t that they skip validation, but that they validate the wrong questions. They ask “do you like this?” instead of “do you need this?” They ask “would you use this?” instead of “what would you stop using if this existed?” They ask “does this feel intuitive?” without first asking whether it solves a real problem.
Confirmation bias is powerful and insidious. When you’ve already decided what to build, every user interview can be shaped to support that decision. You hear what you’re listening for. Users are polite. They’ll tell you what you seem to want to hear. Real validation requires asking questions that could genuinely make you abandon the direction entirely, and being willing to act on what you learn.
What Good Design Can Actually Do Here
Good design has an underrated role in this conversation, not in execution, but in early detection.
A designer who only asks “how should this look?” is working too late in the process. The real value of design thinking isn’t in the quality of the mockups. It’s in the ability to model a user’s actual situation and ask: does this product intervention actually change anything meaningful in their life?
Before opening Figma, a good designer should be in the room asking uncomfortable questions. Not to be obstructive, but because the earlier you catch a wrong direction, the cheaper it is to change course. A conversation costs nothing. A sprint costs a week. A shipped feature costs months of technical debt and user confusion.
This is what I mean when I say I operate as a strategic design partner. The work starts before the first wireframe. The most important design decisions happen before anyone picks up a stylus.
If you’re already in Figma before you’ve answered why, not just what and how, but why this, why now, why for these people, you’re already behind. A product that solves the right problem with average UI will almost always win over a product that solves the wrong problem with beautiful UI.
Build less. Validate the right questions. Design for what actually matters.