Product · 3 min read
Listening to users
The systems that keep the whole team, not just the PM, in regular contact with the people we build for, and what we do with what we hear.
The fastest way to build the wrong thing well is to build it far from the people who'll use it. So the most important system a product manager runs is the one that keeps the team close to its users: regular contact, a real place to keep what you learn, and the discipline to actually use it. The goal is not for the PM to talk to users and relay a summary. It's for the PM to make it easy for everyone, especially the engineers, to talk to users directly.
Regular contact, not a research project
Discovery here is a habit, not an event. The PM makes sure there's a standing system for the team to hold calls with users regularly: interviews, sessions where you watch someone use the product, sometimes visiting them where they work, conversations with the person who just filed an angry piece of feedback. Something every week, not a big study every quarter.
The reason it has to be regular is that a one-off round of interviews gives you a snapshot that's stale by the time you've acted on it. A steady drip keeps the whole team's intuition current, so the hundred small daily decisions engineers make land in roughly the right place without anyone having to ask.
Engineers talk to users too
This is the part that surprises people coming from elsewhere: the engineers get on the calls. Not a summary passed through the PM, the actual conversation. It's the single fastest way for the person writing the code to understand what's really wrong and whether what they shipped helped. The PM sets up the system that makes this easy; they don't stand in the middle of it. There's more on why in how to do product as an engineer.
A PM who becomes the only channel to users has made themselves a bottleneck and made the team a little dumber. The job is to remove the distance between engineers and users, not to be it.
Store feedback so it's findable, not buried
We keep what we hear somewhere retrievable, so that when a decision comes up, someone can go and find what users actually said about it. What we don't do is take every piece of feedback and drop it straight into the backlog as if it were a committed task.
That distinction matters. Feedback is evidence, not a work order. A hundred stored comments are a resource you draw on when you're weighing what to build. A hundred backlog tickets are a guilt pile that makes the team feel behind on work it never agreed to do. Keep the signal; don't let it masquerade as a plan.
What listening is for
All of this feeds two things. It tells you whether what you already shipped is working, which is half of owning a feature. And it builds the shared understanding of users that makes deciding what to build something the team can do well, together, instead of a guess dressed up as a roadmap. Listening isn't a phase before building. It's the thing that runs underneath all of it.