Understanding your users: the product foundation
Most product teams say they "know their users." Pressed for specifics, what they actually have is a vague sense of who's signed up — a sketch built from sales calls, the loudest voice in support, and the founder's gut. That sketch is not a mental model. It's a guess wearing the costume of a guess.
Real understanding is more boring than that, and harder to fake.
The gap between "users" and "the people who use this"
When you say "our users," your brain reaches for a composite — a cartoon, really. Friendly. Predictable. Conveniently aligned with the feature you're already planning to build. The cartoon is useful for slide decks and useless for design decisions.
The people who actually use your product are stranger than the cartoon. They have constraints you don't know about. They've developed workarounds for problems you didn't realize they had. They're using your product in contexts you'd never have predicted — between meetings, on a phone, with a colleague leaning over their shoulder, after their previous tool got deprecated, while debugging something completely unrelated.
You can only design for the second set. The first set will accept anything because they don't exist.
What understanding actually looks like
Understanding is not "we did 5 user interviews last quarter." It's a working answer to questions like:
- Why did this person pick us over the four competing options? What did they almost pick instead, and why didn't they?
- What were they doing immediately before they signed up? What were they trying to get done?
- What would they have done if our product didn't exist? (This is the real comparator — not other products, but their default workaround.)
- What does success look like for them this week? Not in the abstract — this Tuesday.
- What's the embarrassing, awkward, or technically-out-of-bounds thing they're using our product to do?
The teams that ship things people actually want can answer these without flinching. The teams that ship things people politely ignore tend to answer with a roadmap.
How to build the model without spending six months on it
The cheapest way to build a real model is to talk to fewer users, more carefully. Not five interviews — three. But three where you ask follow-up questions until you're embarrassed by how specific they get.
A good rule: for every claim a user makes, ask "what does that look like?" twice. The first ask gets you a generality ("it's slow"). The second gets you the actual moment ("Tuesday morning, I had to load the report twice because the first time it timed out, and I couldn't tell if it was working or not"). The actual moment is the design brief.
You're not collecting opinions. You're collecting operating conditions.
Why teams skip this
Three reasons, in roughly this order:
- It feels low-status. Talking to one user doesn't feel as productive as designing a feature for everyone.
- It produces uncomfortable answers. Real understanding often shows that the next thing on the roadmap is wrong, or that the team has been solving a fake version of the problem.
- It can't be delegated. A research firm can run interviews, but they can't pattern-match against your product knowledge in real time. The best understanding lives in the heads of the people building.
The teams that get past these three things ship better products. Not because they have more empathy — that's a moralizing way to describe it — but because they're working from a more accurate map.
A starting habit
If your team isn't doing any of this: pick one user, schedule a 30-minute call this week, and don't end the call until you can describe what their Tuesday morning looks like with our product and without it.
Do this every two weeks. After ten of these, you'll have a model. After thirty, your roadmap will be unrecognizable from what you'd have built without them.