A few years ago a startup founder called me. His opening line was short: "We have this new digital service almost ready. Could you make it look prettier?"
I said yes, probably. But first, a few questions. Who is it for? What problem does it solve? Why would someone pay for this instead of whatever they're doing now?
There was a pause on the other end of the line.
Then he started answering, and with every answer the picture got worse. The code worked and the team had spent months on it. What didn't exist was a validated answer to any of the questions I had just asked. No tested problem and no business model beyond "we'll figure it out once people start using it."
The only thing missing, from his point of view, was that the UI wasn't polished enough.
I've thought about that call a lot over the years. It's not the exception. It's the pattern.
The call was about a button. The real problem was upstream.
When the founder asked me to make the product "prettier," he was asking the wrong question about the wrong layer of the problem. He assumed the issue was cosmetic. The real issue sat three levels above that: the team had built a solution without defining the problem.
This is where a lot of startup and enterprise product work goes wrong in exactly the same way. The conversations focus on what can be seen and touched: the screens, features, and buttons. Those are the visible part of the iceberg. The invisible part is everything that should have happened before a single line of code was written. What problem are we solving, for whom, and why would they pay for it instead of whatever they do today?
If you skip that invisible part, no amount of polish on the visible part will save you. A beautiful interface on a product nobody wants is still a product nobody wants.
The founder thought he had a design problem. He had a stack of untested assumptions, and the UI was only the top one.
Three questions he never tested
When I walked backward from "make it prettier" to the foundations, three gaps showed up almost immediately. These three show up in almost every version of this story I've seen since.
Desirability — is the problem real and painful enough? He had built something he thought people would want. He had never sat down with five of those people and asked them how they solve the problem today, what they've tried, and what they'd happily pay for. The hypothesis had been treated as a conclusion.
Viability — can the business actually make money from this? No pricing model had been tested against real willingness to pay. Nobody had answered the simple question: if 100 people sign up tomorrow, does this business work or lose money?
Feasibility beyond the code. The technology worked. But the team hadn't thought through whether they could operate the service at scale. Who handles support? What happens at three in the morning when something breaks? Is the legal structure even right for the market they were targeting? Technical feasibility is the easy kind. Operational and business feasibility is where most ideas die.
Any one of these gaps would have been enough to stall a launch. Together they meant the product was sitting on an untested foundation built from three kinds of guesses.
The leadership decision underneath the design question
Here's the part I want to be careful about, because it's easy to get wrong.
It's tempting to look at this story and conclude "the founder should have done more design work first." That framing isn't quite right. Concept validation sits at the intersection of design, product, and business leadership. The tools come from design, the work shapes what gets built, and the call about whether to do it at all belongs to the person who controls the budget.
Telling this founder "you needed service design" would have missed the point. Service design, done well, could have uncovered most of what was wrong — but only if someone had commissioned it before the code was written. The gap wasn't which method he should have used. The gap was that nobody had decided to validate anything before committing the budget.
The leadership decision he skipped was this one: Before we commit real money and real months to building something, we're going to spend a small amount of money and a small amount of time finding out whether we're right about the things we're assuming.
Designers can run the work once that call is made. They can't make the call for the person in charge. This is the same translation gap I wrote about in The Monday Morning Test — the point where a strategy either lands as a real choice or stays a document.
What he should have done instead
The cheap version of what he should have done takes a few weeks and costs a fraction of what the build had already cost.
Five to ten conversations with people who have the problem he thought he was solving. Individual interviews, not a survey or a focus group. You ask how they handle this today, where it hurts, and what they've already tried. That single exercise kills roughly half of all early-stage ideas, because the problem turns out to be smaller or different from what the founder assumed.
A landing page describing the product as if it already existed, with a signup button and a small ad budget pointed at the target audience. You watch whether people click, sign up, or come back. If the response rate is weak on a clear message, you learn something important about demand without having built the product at all.
A paper or interactive mockup of the core flow, shown to the same five to ten people in the second half of the conversation, after they've already walked you through how they handle the problem today and where it hurts. Once that context is on the table, the prototype gives them something concrete to react against: does this fit how I actually work, and would I pay to replace what I'm doing now? You learn far more from that comparison than from showing a polished concept cold and asking whether they like it.
A simple financial sketch of the business — what would it cost to acquire a customer, what would they pay, what does the service cost to deliver, and does the math work at any realistic volume. A page of numbers, not a plan.
None of this is expensive. None of it requires specialised tools. The total cost is small, the time is short, and the return is a decision you can defend. Go, adjust, or stop — backed by evidence rather than enthusiasm.
Why this story keeps repeating
I've told this story in workshops and in client meetings, and every time at least one person in the room nods the specific nod that means "we're doing this right now and I know it." The pattern shows up in startups and enterprises, in product teams and strategy teams, regardless of whether the organisation has a dedicated innovation unit.
The reason it repeats has less to do with ignorance than with incentives. Coding, writing specs, and running status meetings all feel productive. Asking "wait, are we sure about this?" feels like slowing things down, and in most organisations slowing things down is the thing nobody gets rewarded for.
But pausing at the start to ask the right questions isn't slowing down. It's how you avoid losing months, sometimes years, at the other end.
The founder who called me eventually launched anyway. The product didn't survive the year. He told me later that he knew, somewhere around month three of the build, that the answers he wasn't getting were the ones that mattered. He kept building because stopping felt worse than being wrong.
Before you commit
If you're staring down a product bet worth real money and you want the assumption stack pressure-tested before you commit, that's what a Focused Start is for. A few weeks, one clear recommendation, the evidence behind it.
The cheap question to ask yourself first: which assumption in your current bet, if false, would change the whole picture?
I'm Jenni. Most strategies stay vague. I help organizations define what their strategy actually means in practice, then build the operating models, processes, and concepts to execute it. Founder of Digital Rebel.