Most product managers obsess over users.
What they need. What frustrates them. What would make their lives easier.
This isn’t wrong. It’s just incomplete.
The best product managers I know think about something else entirely: buyers.
Not the people who use the product. The people who decide whether to purchase it.
And in complex B2B environments—which is where most expensive products live—these are rarely the same person.
The Gap No One Talks About
I’ve spent twenty years across sales, marketing, procurement, and strategy.
I’ve watched product managers present features that users loved and buyers rejected.
I’ve seen products that solved real problems fail because they didn’t understand how purchasing decisions actually get made.
The pattern is consistent:
Product managers who only understand users build products that get praised in demos and stall in procurement.
Product managers who understand buyers build products that actually get purchased.
The difference isn’t in the product quality.
It’s in understanding leverage.
What “Thinking Like a Buyer” Actually Means
Buyers and users want different things.
A user wants a tool that makes their daily work easier.
A buyer wants a tool that:
- Fits their procurement process
- Aligns with their existing vendor relationships
- Doesn’t disrupt contracts already in place
- Justifies itself to finance in ways that match how finance measures value
- Integrates with systems procurement has already approved
- Comes from a supplier that won’t create new risk exposure
Notice something?
Almost none of that is about the user experience.
It’s about organizational leverage.
And product managers who don’t understand this build products that users champion internally and buyers reject for reasons that never make it into the user feedback.
The Product Manager Who Got It
I knew a product manager targeting enterprise procurement teams.
She did everything right from a user-centric perspective: interviewed procurement professionals, understood their pain points, built features they explicitly requested.
The product failed to gain traction.
Not because users didn’t want it. Because buyers—the CFOs and CPOs who actually authorized the purchase—had different questions:
-
How does this integrate with our existing ERP system?
-
What happens to the vendor contracts we spent two years negotiating?
-
Who else in our industry uses this, and can we call them?
-
What does this replace, and how do we justify retiring that investment?
The product manager had built for the user’s stated needs.
But she hadn’t built for the buyer’s unstated constraints.
Then she changed her approach.
She started spending time not just with users, but with the people who held budget authority. She shadowed procurement meetings. She sat in on vendor negotiations. She talked to finance about how they evaluated software investments.
What she learned changed everything she built.
Users wanted faster supplier searches.
Buyers wanted integration with their existing supplier database—because replacing that database would invalidate eighteen months of data cleanup work.
Users wanted better analytics.
Buyers wanted analytics that matched the KPIs their board was already tracking—because introducing new metrics meant explaining why the old ones didn’t matter.
Users wanted automation.
Buyers wanted automation that didn’t threaten the headcount allocation that justified their department’s budget.
None of this appeared in user interviews.
All of it determined whether the product got purchased.
The Uncomfortable Truth
Here’s what thinking like a buyer reveals:
The best solution for the user is often not the purchasable solution.
The optimal feature set runs into organizational constraints.
The elegant design conflicts with integration requirements.
The innovative approach requires changing processes that the organization has spent years standardizing.
Product managers who only think about users keep building the optimal solution.
Product managers who think about buyers understand which optimizations are actually available given the buyer’s leverage constraints.
This doesn’t mean compromising on user value.
It means understanding that user value only matters if the product can actually be purchased.
What Leverage Actually Looks Like
I’ve sat on both sides of complex purchasing decisions.
As a seller: trying to understand what would make a buyer say yes.
As a buyer: evaluating products where the sales team clearly didn’t understand how my organization made decisions.
The products that won weren’t always the best products.
They were the products whose teams understood leverage:
-
Which existing relationships could accelerate approval?
-
Which integration points were actually make-or-break versus nice-to-have?
-
Which stakeholders had veto power, and what were their real concerns beneath the stated objections?
-
What budget cycles and approval processes determined timing?
-
Which metrics mattered to the people who controlled budget—not which metrics should matter, but which ones actually did?
A product manager who understands leverage builds differently.
They don’t just build features. They build purchasability into the product from the beginning.
They know that a slightly less elegant solution that integrates seamlessly with existing systems will beat a perfect solution that requires replacing infrastructure.
They understand that “this replaces three tools you’re already paying for” is more compelling to a buyer than “this is 20% better than what you currently use.”
They think in terms of buyer economics, not just user experience.
The Meeting That Revealed Everything
I was in a steering committee evaluating three different software platforms.
All three solved the same user problem. All three had similar features. All three had good references.
The user group preferred Platform A—slightly better interface, more intuitive workflows.
We purchased Platform B.
Not because we didn’t trust the users. Because Platform B:
- Integrated with our existing ERP without custom development
- Came from a vendor we already had a relationship with, which meant faster procurement approval
- Fit our data governance requirements without exceptions
- Could be implemented within the budget cycle that was already approved
Platform A required:
- Custom API development (6-month delay)
- New vendor onboarding (procurement process we didn’t have time for)
- Security review for a new data category (compliance cycle we couldn’t accommodate)
- Budget reallocation across fiscal years (political complexity no one wanted)
To the users, this looked like we ignored their preference.
To the buyer, it looked like we chose the only option that was actually implementable.
The product manager for Platform A had built a better user experience.
The product manager for Platform B had built a more purchasable product.
What This Changes About Product Strategy
If you’re building B2B products, here’s what thinking like a buyer means:
Stop asking only what users want.
Start asking what buyers can actually approve.
Who controls the budget?
What approval processes exist?
Which existing systems create integration constraints?
What vendor relationships affect purchasing decisions?
Which metrics drive their performance reviews?
What risks are they personally accountable for?
These questions don’t replace user research.
They complete it.
Because a product that perfectly solves the user’s problem but can’t navigate the buyer’s constraints is just an expensive prototype.
The Reframe
Most product management advice focuses on empathy.
Understand your users. Feel their pain. Solve their problems.
This is necessary but not sufficient.
The best product managers I know practice a different kind of empathy:
Empathy for the buyer’s position.
Understanding that saying yes to your product means saying no to something else.
That every purchase is a bet they’re making with organizational capital.
That their decision will be judged not just by whether users like it, but by whether it was easy to implement, whether it delivered measurable value, and whether it avoided creating new problems.
User empathy tells you what to build.
Buyer empathy tells you how to make it purchasable.
Most product managers master the first.
The ones who master both build products that actually scale.
What I Watch For Now
When I evaluate product teams—whether as a potential buyer or as someone advising on product strategy—I ask a simple question:
“Can you describe your buyer’s approval process?”
Not their user journey. Their approval process.
If the product manager can’t articulate:
- Who needs to say yes
- What each person actually evaluates
- What constraints they’re working within
- Which relationships or existing contracts affect the decision
Then they don’t understand their own product’s purchasability.
They might build something users love.
But they’re leaving their commercial success to chance.
The best product managers don’t leave it to chance.
They build leverage into the product from the beginning.
Users tell you what they need.
Buyers tell you what’s actually possible.
The product managers who listen to both—who understand that these are different conversations requiring different kinds of empathy—build products that don’t just solve problems.
They build products that organizations can actually say yes to.
And in complex B2B environments, that distinction is everything.
Not because user needs don’t matter.
Because user needs only matter if the product can navigate the buyer’s world well enough to get purchased in the first place.
The best products don’t just serve users beautifully.
They understand leverage clearly.
And knowing the difference is what separates product managers who build great demos from product managers who build great businesses.