A conversion problem might actually be a trust problem, or a support problem might actually be a product problem, or a usability problem might actually be a decision problem. I investigate before I redesign because the first version of a problem is rarely the problem worth solving.
Start with what is actually happening
Don't accept the problem statement at face value. Teams rarely come to design with a perfectly framed problem. They come with symptoms:
Conversion is down.
Support calls are up.
Users are dropping off.
A feature isn't being adopted.
Someone wants a redesign.
I treat these as signals, not diagnoses.
SYMPTOM → INVESTIGATION → ROOT CAUSE
Before asking what we should build, I want to know what changed, who is affected, where it happens, and what evidence supports the assumption.
Example: CashKaro
The initial signal: nearly 60% of returning users weren't completing purchases.
The obvious response would have been to optimise conversion.
Instead, I followed the journey and found a much broader problem involving discovery, cashback visibility, trust and the post-purchase experience.
The conversion problem was a symptom. It wasn't the diagnosis.
Experience the problem yourself
As basic as this sounds, I am surprised how teams ignore to experience the product themselves.
You don't only look at dashboards. You also use the product.
Data tells me what is happening. It doesn't always tell me what the experience feels like.
So I put myself through the journey.
I complete the task.
I try the edge cases.
I look at what happens before and after the moment everyone is focused on.
And when possible, I ask people outside the product team to do the same.
Don't investigate a product from inside the product team.
Triangulate the evidence
One source gives you a signal. Multiple sources give you confidence.
I rarely trust a single source of evidence.
Quantitative data can tell me where something is happening.
Qualitative research can help explain why.
Customer support can reveal problems customers don't articulate in research.
Operational teams can expose constraints customers never see.
My own observation can reveal friction that dashboards don't capture.
QUANT → WHAT
QUAL → WHY
OPERATIONS → CONTEXT
OBSERVATION → EXPERIENCE
The goal isn't to collect more research. It's to build a more complete picture.
Find the pattern, not the anecdote
Individual complaints are useful. Patterns are better. I look for repeated behaviours, contradictions and unexpected relationships between what people say, what they do and what the business measures. One example, product team initially assumed users needed more education. But when I looked deeper, an unexpected pattern emerged: Users who consumed more information were actually raising more support tickets. That contradiction mattered. It challenged the existing assumption and forced me to ask a better question: Were users confused because they lacked information or because the information wasn't giving them confidence?
Turn observations into a problem worth solving
I don't consider an investigation successful because I've produced a research report.
It's successful when the team can articulate:
Who is struggling?
What are they trying to accomplish?
Where does the experience break down?
Why does it matter?
What evidence makes us believe this is the problem worth solving?
A good problem statement should change what the team does next.
Make the problem visible to the team
Investigation is not a solo exercise.
If the insight only exists in my head, it isn't useful to the organisation.
I turn what I've learned into something the team can interrogate together — journeys, evidence, behavioural patterns, hypotheses, opportunities and unanswered questions.
The goal is shared understanding before shared execution.
Investigate until the problem changes.
Sometimes investigation confirms the original problem.
Sometimes it changes the scope.
Sometimes it reveals a completely different problem.
That's not failure.
That's the work.