The slightly inconvenient thing about understanding your users is that they might invalidate a very well-made plan.
Most teams are prepared for research to change a feature. Fewer are prepared for it to change what they think the product is for.
I think this explains some of the distance between doing research and actually understanding an audience. We collect observations, find a plausible explanation, and move into solutioning. Somewhere in that handoff, what we think the data means becomes what we say the research proved.
The interviews happened. The survey happened. The interpretation barely got interrogated.
Data → inference → insight. These 3 are related; not interchangeable.
Most teams collapse all three into one word: “insight.” Dashboard, quotes, three-pillar framework, ChatGPT research summary. All get called insight. That gets expensive when the product is hard to explain, the workflow is unfamiliar, and being wrong has consequences beyond a screen.
Data
Data is what happened before you dressed it up: clicks, tickets, win/loss, regen counts, “users asked for chat,” “buyers stalled after demo.” Quantitative or qualitative, noisy or incomplete — still material, not insight.
Good designers notice more than the brief: workarounds, hesitation before approval, features that never enter the workflow. They notice what people have quietly absorbed into their day because the product doesn’t account for it.
Noticing is still collection. If the readout only restates what occurred, you have data. Useful. Not finished.
Inference
Inference is what you conclude from the data — first meaning-making, and dangerous because it feels like progress.
It happens when we attach an explanation to a behaviour. People repeatedly regenerate an AI response, so we conclude the model isn’t good enough. Users don’t return, so onboarding must be broken. Buyers stall after a demo, so the pitch needs work.
Reasonable explanations. Often useful. Also remarkably easy to agree on while the real problem sits untouched.
Inference answers what probably explains what we saw? — not yet what should we build instead?
With feature requests this becomes even more difficult to notice.
Users ask for sources, and we add citations, assuming the request tells us enough about why they need them. Are they checking accuracy, building an argument, or gathering evidence for someone else’s approval? The same request can point to different problems.
The request becomes the explanation and the solution in one movement. Directionally fine, rarely worldview-changing.
Insight
Insight is built on top of data and, more often, on the inferences we draw from it.
It’s the “aha” moment when those interpretations reveal something specific about a system: how it is organised, why it behaves the way it does, and where an intervention could change a part of it—or the whole.
It gives you a way of seeing that makes something previously puzzling suddenly intelligible, and a possibility for change visible.
Insight transforms your perspective — sometimes altering your entire view of a situation, product, industry, or company. It is never a generic observation.
It reshapes how you perceive a problem, a target audience, an ecosystem, or a system, along with their interrelationships: how they are organised (structural), what flows between them (transactional), and the attitudes that influence those interactions (attitudinal/behavioral).
You can see this shift even in a single interaction. In an AI product, people repeatedly regenerating a response might lead us to infer that they want better answers. But suppose they want to keep 80% and fix 20% without destroying context.
Imagine asking a colleague to change the last paragraph and watching them start the whole document again.
Regenerate starts to look like a very blunt instrument. The problem changes: how does someone correct the system’s work without losing what was already useful?
Now we’re designing for the user’s ability to judge what’s worth keeping, change what isn’t, and continue from there. The object of design moves from response quality to collaborative judgment under uncertainty.
A better model may still help. It doesn’t resolve the need to intervene precisely.
An insight needs somewhere to go
And this is where an insight becomes useful for solutioning: how might we let someone correct part of the work while preserving what they already trust?
You have a problem worth tinkering with. Something to prototype against, test, and refine.
The insight has an actionable edge.
A lot of times; startups bring user research conclusion statements like - “Users need more control” sounds useful until you try to design against it. Control over what? At which point? To protect what?
Here, it’s the judgment the user has already exercised: what they’ve read, evaluated, and decided is useful. Regenerating everything asks them to repeat that work. The system can produce another answer cheaply because the cost of checking it belongs to someone else. A better response can still mean more work for the person using it.
The problem statement should carry that understanding into the prototype: can someone make a correction, understand what changed, and continue without re-evaluating everything? If they still have to start again, we may have added control without resolving the problem.
This is the movement I care about: an observation becomes an interpretation; an insight changes the problem; the problem statement gives us something to test. Each step should carry the understanding forward.
Otherwise, the research changes how we talk about the problem without changing how we solve it and it completely destroys the purpose of leveraging user research to enhance customer experience in an actionable way.
The buying decision happens beyond the demo
The same shift can happen in B2B buying. Demos go well; deals stall. We infer that we need better visuals, a stronger deck, another feature. But perhaps the buyer wants the product and can’t feel safe explaining the purchase inside their company.
Now the experience includes the conversation you won’t be in. What can they defend? What happens after approval? Who carries the risk if the purchase goes wrong?
The website, the implementation story, and the evidence all become part of the product’s ability to be bought. Clarity becomes GTM infrastructure.
Inference is socially easy; insight is socially expensive.
Inference stays in the category and within the box.
Example: “improve chat.” It can criticise the execution quite aggressively while leaving the premise untouched. The team, the budget, the success metric — all still make sense. Everyone gets work. The premise gets another quarter.
Insight threatens a category or a worldview.
Example: “maybe chat isn’t the centre.” Perhaps the answer is only an intermediate step, and the actual job is evaluating evidence, resolving uncertainty, and deciding what to do. Taking that seriously changes what the product supports, who needs to own it, and what counts as success. Fewer messages might mean a better experience. Yesterday’s engagement metric might have been measuring how much work the product left unresolved.
That’s the social expense. An insight can be understood perfectly and still be resisted because accepting it would require something to change. The hard part is following the observation far enough that it is allowed to inconvenience the plan.
In the work I care about, this is why prompt-as-textbox, citation-as-footnote, and regen-as-repair deserve more scrutiny. Each contains an assumption about the job. Repeating those patterns can make a product recognisably “AI” before we’ve established whether they help someone do the work.
Insight rarely stays on one screen. It reaches into workflows and permissions, fear and trust, what gets approved, paid for, and recorded.
Real insight should outlast the conditions that produced it
The strongest insights become founding principles for category-defining products, services, and business models that change how people live and how industries operate. Their value keeps unfolding across multiple business cycles, extraordinary circumstances, and market shifts.
Real insight should outlast a sprint, a model release, and multiple business cycles — remaining useful through extraordinary circumstances, global disruptions, and market shifts.
In my experience, the bar is at least two or three business cycles in that industry; three to five years at a bare minimum, ideally much longer.
The core solution offering built on that insight may become obsolete before the insight does.
The same understanding that helped you build one product can help you see what should follow it — and, over time, become the seed from which category-defining products, companies, and entire ecosystems grow.
A pandemic changes the conditions. An AI revolution changes what’s possible. A strong insight should help you make sense of both — even when they render your existing solution obsolete. It may be the reason you can see what should replace it.
If nothing in the roadmap, interface, or GTM flips when you say it, you’re still in inference — maybe wearing a framework cloak. An insight should change what you see today and keep informing what you build tomorrow.
I hold that bar across consumer and prosumer products, air purification and climate tech, grassroots healthcare and medical devices, and pharma and life-sciences supply chains. The solution can change completely while the underlying understanding keeps earning its place.
Push it until something breaks
That doesn’t make an insight immune to new evidence. Push it. Extrapolate from it. Test what it explains between the observations you already have, and beyond the conditions that produced it.
Play with it in every dimension until something breaks — then examine what broke: the insight, its application, or an assumption you attached to it.
But if it dies with a trend, it was probably fashion.
Test before you call it insight:
Name the data. Otherwise, it’s opinion.
Separate the inference. Don’t smuggle the conclusion into the observation.
What flips if true? Something in your understanding or your decisions should move.
Can it become a useful problem statement? Give yourself something to tinker with, without deciding the solution in advance.
Will it outlast the conditions that produced it? Look beyond the next release or trend cycle.
Data without inference is inert. Inference without insight is confident mediocrity. Insight without data is vibes — B2B doesn’t buy vibes for long.
I think the most useful insights eventually bring you back to the company itself: what you’ve assumed about your customers, what you’ve built around those assumptions, and what you’re asking people to work around.
At some point, understanding the customer means reconsidering a decision you thought you’d already made.