Before You Build: Adopting a Problem-First Mindset in Product Development
You’re working on some really exciting research. You’re developing a novel piece of technology. Excitement is building and you start thinking about the possibilities for impact outside the lab through the development of a commercial product.
You’d be forgiven for thinking that this is an inevitable journey. Keep working through the technology readiness levels (TRLs) and you’re bound to end up with a successful product that customers love.
“Build it and they will come is a prayer, not a strategy.” Steve Blank
To be clear, I’m not a researcher. I’m a product designer. But I’ve spent most of my career working with researchers, academics, and technology innovators – helping them move from research to production.
Through this work, I’ve seen some incredible ideas take shape. I’ve also seen teams pour years of time, energy, and funding into building something truly impressive… that no one actually wanted.
The truth is, as soon as you start thinking about product development, you begin a new journey in parallel with your research. A product journey. And the first thing to do is to lock your technology in a dark room and forget about it – at least for now.
The biggest mistake innovators make is falling in love with their solution.
Instead, you need to fall in love with a problem your users are facing.
And the only way to do that is to talk to them. A lot.
1. Start with a Problem Hypothesis
When working with researchers, they often arrive with a well-formed product idea. After listening to it carefully, the first – and often hardest – thing I ask them to do is forget it.
To truly adopt a problem-first mindset, you need to become ambivalent about any particular solution. At this stage, product ideas often act as Trojan horses for assumptions – about who your users are, what they care about, and how your technology fits into their world.
So what should you do instead?
Start by forming a hypothesis about who you might be able to help and in what scenario. This is called a use scenario.
A nurse is a potential user.
A nurse working independently on a night shift, caring for five patients in intensive care – that’s a use scenario.
Context is key.
Too often, we get hung up on demographics and job titles. Personas can help in some cases, but they often add noise rather than clarity. What really matters is what users are trying to do in a specific context – and what’s getting in the way.
Once you’ve identified a few relevant use scenarios, try to hypothesise the problems or frictions those users might face. These can (and should) be informed guesses for now – you’re building something to test and iterate against.
I often use problem statements in this format:
I am…
I am trying to…
However…
Because…
Meaning…
Armed with a few of these, you’re ready to start learning from real users.
2. Gather First-Hand Insights
There are many ways to gather evidence, but at this early stage, nothing beats a one-to-one conversation with a real user.
Start by revisiting your use scenario and writing a quick spec for who you want to speak to. For example:
“A currently employed nurse who works night shifts and has experience being in sole charge of multiple patients.”
If you have a relevant network, now’s the time to use it. If not, this is your chance to build one. That user network will be vital throughout development – not just for research, but also for cultivating early adopters.
Can’t find anyone? Consider using user recruitment services. People are often happy to share their experiences, especially when there’s a small incentive (even a modest voucher can help).
How many interviews?
There’s no magic number, but I recommend starting with at least five. Remember – this isn’t a box-ticking exercise. Speaking with users should be a habit, not a one-off task.
What to ask?
Skip the formal script. Avoid yes/no questions. Your goal is to uncover stories and emotions – things users wouldn’t necessarily offer unprompted.
Try open-ended prompts like:
- “Tell me about the last time you did X.”
- “What was your last shift like?”
- “What was the most frustrating part of that?”
Then dig deeper:
- “How did that make you feel?”
- “What happened next?”
- “Did that affect anything else?”
Behind the scenes, you’re comparing what you hear with your original assumptions — but don’t test these directly. Listen for signals.
After five interviews, you should revisit your problem statements. They’ll still contain assumptions, but they should now feel more grounded. Your confidence in them should be growing.
3. Dig Deeper into the Problem Space
Now that you’ve got some real insight, it’s time to map the problem space.
Not all problems are equal. Some are mere annoyances. Others are high-stakes, mission-critical challenges. Your job is to figure out which is which.
I use a three-level model:
- Negative Outcomes
- Problems
- Causes
Ask yourself:
- Moving up: What does this lead to?
- Moving down: What causes this?
This works well as a tree diagram. At the top: one or two high-level negative outcomes. At the bottom: specific causes. You’re building a map that helps you zoom out from micro-frictions to big-picture consequences.
Why this matters
A fiddly process might seem trivial
But what if it leads to delayed treatment or staff burnout?
Zooming out helps you frame the real value proposition of your product.
You’re not “making a device easier to use” – you’re “reducing treatment time,” or “improving safety,” or “increasing efficiency.” That’s what users and stakeholders will care about.
How to use your map
Each cause should connect to a higher-level problem and outcome. If it doesn’t link to something meaningful, it probably isn’t worth addressing.
You won’t be able to tackle everything. That’s OK. Focus on causes that have the biggest impact on the outcomes that matter.
A quick tip
When I build these maps with teams, we colour-code based on confidence:
- Red: No evidence yet (assumption)
- Orange: Some supporting insight (medium confidence)
- Green: Strong evidence (high confidence)
This helps you visualise where your certainty lies – and where you need more research.
Here is a quick guide and example of a simple Problem Tree:
4. Learn from Real-World Examples
The world is full of examples of products that didn’t quite hit the mark – despite incredible technology.
Think Segway. Think Humane AI Pin. Think Meta’s VR glasses.
These were built by brilliant teams with incredible engineering. But they struggled to answer a simple question:
“Who is this really for, and what problem does it solve?”
Let’s take the VR glasses. Technically impressive? Absolutely. But most people aren’t crying out for notifications beamed directly into their eyeballs. It feels more like a solution in search of a problem.
Contrast that with the Kindle.
Technologically, it’s modest. The screen isn’t high-res. It lacks flashy features. But it solves a clear, tangible user problem:
“I want to carry a library in my pocket and read anywhere.”
That’s a product built around real user needs.
That’s what you’re aiming for.
Conclusion
Adopting a problem-first mindset is hard. Especially if you’re already deep in a research project or developing a specific technology. You’re not starting from a blank page – and that can make it harder to be truly open.
But if you want to create something people actually want, this is the work.
Sometimes that means realising your original idea isn’t quite right for the problem you hoped to solve. That might feel disappointing. But it’s far better to make that discovery now – not two years down the line after you’ve built it.
What Next?
🚀 This post is part of a wider guide I’m developing to help research-led innovators move from idea to impact.
📥 A downloadable version of this guide – plus bonus tools and templates – will be available soon. Watch this space!
💬 Have questions about your product idea or want to chat about your approach?
You can book a free 1:1 call with me here.