My first product role was at Chemarc, where I was the bridge between large B2B chemical manufacturers and our internal engineering team. A big part of the job was listening to what our top clients needed and turning that into something engineering could build.
What I learned quickly is that enterprise feedback arrives as solutions. "We need an export button." "Add a field for batch number." "Can it email us when this changes?" Each request is reasonable. Collect enough of them and you have a wishlist that pulls the product in fifty directions.
Capture the problem, not just the request
When a client asks for something, I try to write down three things:
- What they asked for, in their words.
- What they're trying to do, in mine.
- What happens today without it.
The second and third lines are where patterns show up. Three different clients asking for an export, a report and an API might all be trying to get the same data into their own system. That's one problem, not three features.
Keep it in one place
Feedback scattered across email, sales notes, support tickets and meeting notes is almost useless. You can't see patterns if you can't see it all together.
| Field | Why it's useful |
|---|---|
| Account and role | Is this the buyer, an admin, or an everyday user? |
| Underlying problem | Lets you group similar requests |
| Workaround today | Shows how painful it really is |
| Business context | Renewal, expansion, or just a nice-to-have |
| Source | Sales call, support ticket, QBR, interview |
| Date | Old requests may no longer apply |
It doesn't need to be fancy. A shared spreadsheet worked for a long time. What matters is that everyone logs feedback in the same way.
Weigh it, don't just count it
Counting requests is a start, but it favours the accounts that talk to you most. A large client with a dedicated account manager will generate more feedback than ten smaller clients combined.
I'd look at the spread across accounts, how painful the workaround is, and whether the problem affects many users inside each account or just one person. A request from a single power user at a big client might matter less than a quiet problem every user hits.
When one important account wants something nobody else needs, that's a commercial decision as much as a product one. I wrote about handling those trade-offs in the stakeholder management post.
Close the loop
The part most teams skip is going back to the client. Even when the answer is "not now," telling them what you heard and what you decided builds a lot of trust.
When we did build something a client had asked for, I'd tell them directly and ask them to try it. That often led to the most useful feedback of all, because they were already invested in the problem.
When we decided not to build something, a short honest explanation went further than silence. Enterprise clients understand trade-offs. What frustrates them is not knowing whether anyone listened.
Review it on a schedule
I'd review the feedback log monthly with whoever handles sales and support. Look at new themes, check whether old themes are still active, and decide what to investigate further. That keeps feedback feeding the roadmap without turning every request into an emergency.
Some of the best things we shipped at Chemarc weren't what any one client asked for. They came from noticing that several clients were describing the same problem in different words.