The moment every founder dreads
You shipped the product.
People signed up.
And then they left.
Now you’re staring at the data trying to figure out what went wrong. Is it the product? The onboarding? The messaging? Every day without an answer is another day of runway gone.
Most founders in this moment do one of two things.
They start adding features. Or they start thinking about pivoting.
Both are expensive guesses.
The real problem is almost never the product
It’s the assumptions that shaped it.
One you can fix in a sprint. The other costs months and money before it becomes visible.
I know because I lived it.
A product nobody used
Before Design Labs Consulting, I worked on building an internal tool. It was for a 365 day 24/7 environment inside a Network Operations Center.
Leadership had a strong vision. Napkin sketches. A clear idea of what to build.
They didn’t see the need to talk to anyone first. Discovery felt like a delay. So they skipped it.
They hired a designer. Fleshed out the vision. Developers built it. Pushed it live and expected everyone to sign up and love it.
Nobody did.
Curious people used it once and never came back. The only accounts created were from the team that built it.
Leadership called it a failure and told me to move on.
I wasn’t ready to kill it. Not without validation.
So I investigated after hours. Not because anyone asked me to. But because I wasn’t ready to kill it without understanding what was happening.
What the job looked like
Picture what a shift looks like for a NOC engineer.
Managing a live network. 40 plus calls coming in from Tier 1 support. Every shift bombarded because customers are furious their internet is down. Everyone scrambling to triage in real time.
Did this happen before or is this new? Is this a router issue or something deeper? Does this need a specialist? Was a ticket created for this? How severe is it and who needs to know? Was there an email about this already?
More than five tools open at once. Constant context switching. And somewhere in the middle of that, documenting everything so the next shift knows what to watch out for.
If that gets forgotten, the morning crew walks in blind.
It’s relentless. 365 days a year.
The problem was simple. Find a way to simplify the chaos. Instead the product added another step to an already overwhelming workflow.
Another thing to open. One more form to fill out. And another place to remember before the shift ends.
The mistakes were piling up fast.
Leadership assumed more structure meant more efficiency.
The NOC engineers knew better. But it’s not the user’s job to fix anything.
When a user finds a product lacking, they stop using it. Quietly.
How I approached the diagnosis
Before talking to anyone I started with three things.
First the data.
Where were people dropping off? Which segment was engaging and which one wasn’t? What did the first session look like? Where did the workflow break down completely?
The data told me where to look and who to talk to next.
Then the product walkthrough.
I used the tool the way a real user would. Fresh eyes find what familiarity hides.
Where value breaks down. Where the experience fails. The exact moment a user would give up without anyone on the inside noticing.
When you built it you already know where everything is. You can’t see it the way a first time user does. That perspective has to come from outside.
The walkthrough confirmed what the data was pointing to. The tool wasn’t broken. It was fighting against the way people already worked.
Then the interviews.
The product wasn’t failing across the board. It was failing for specific people in specific moments. Without the data and the walkthrough it’s easy to make a common mistake. Walking into conversations talking to the wrong people about the wrong things.
But data and a walkthrough only get you so far.
The dangerous part is arriving at those conversations already convinced of the answer. After staring at the numbers long enough a theory forms. And theories are dangerous in interviews. Questions start confirming what already feels true. You hear what you’re listening for.
That’s not discovery. That’s expensive confirmation bias dressed up as research.
The skill is holding the data loose enough to let the user surprise you.
What users needed
What I found was simple and uncomfortable.
They didn’t need more tools. They needed fewer.
Something that worked the way they already worked. Find the problem, fix it or notify the right person, document what the next shift needs to know. That’s the flow. Everything else was noise.
The data showed where it was breaking. The walkthrough showed where the experience failed. The conversations showed why. Together they pointed to exactly which part of the experience to fix first and what to leave alone.
The turnaround
So we rebuilt around that.
Simplified the flow. Removed the steps that created friction. Integrated what they were using instead of replacing it. Made the handoff natural instead of an afterthought.
Adoption spread slow at first.
Then users started requesting more features. Sessions increased. Data was flowing.
A tool nobody used became something people relied on every single shift.
It saved $75K annually.
Years later I ran into someone from the NOC.
He told me the tool was still in use.
Why this is so hard to see from the inside
Most founders think a failed launch means the product is wrong.
It means the understanding was wrong.
And that gap is almost impossible to see from the inside.
The people who built the NOC tool weren’t careless. They were confident. They had a vision and the conviction to execute it. That confidence is what makes a founder a founder.
It’s also what makes this so hard to catch alone.
When you believe in something enough to build it, the assumptions behind it start to feel like facts. When you’re attached to an idea, it’s hard to be objective. That distance has to come from outside.
What an outside diagnosis changes
That’s where an outside diagnosis changes everything.
Because the right questions are hard to ask when you’re too close to the product to see it clear enough.
A good diagnosis starts with the data. Finds the segment where things are breaking. Walks through the product with fresh eyes. Then talks to the right people without an agenda. Listening for what’s happening instead of confirming what already feels true.
Once that’s clear it makes sense to start fixing things. Redesigning the flow around what users need. Validating before building. Shipping with confidence instead of guessing.
One path costs everything. The other saves the product.
Where to start
That’s where Product Diagnosis starts.
Not with solutions. With the right questions.
What’s broken, where it’s breaking, and why. A structured outside look at the product, the data, and the assumptions underneath it. So every decision becomes grounded in evidence.
Once the diagnosis is clear, that’s when Product Strategy picks up. Redesigning the flow, validating with real users, and building a plan the team can act on.
If something isn’t landing, that’s the starting point. Learn about Product Diagnosis.
The assumption that costs everything
The most expensive mistake is pushing features or pivoting too fast after a quiet launch.
Challenge that assumption before you build. Spend less. Build faster. Ship something people use.
The ones who don’t? They find out the hard way.
