There's a category of B2B software that gets purchased, deployed, mandated, and then quietly ignored.
The contract is signed. The rollout email goes out. Accounts are provisioned for everyone. And within two months, usage has collapsed to a handful of people who had to use it, doing the minimum required to satisfy whoever is checking. The tool is technically in place. Nobody uses it. It renews anyway, for a while, because the person who signed the contract isn't the person who abandoned it, and the gap between those two people is wide enough that the failure takes a year to become visible.
This is shelfware, and it's the most expensive failure mode in B2B product design. It happens because B2B products have two distinct audiences with structurally opposed interests, and most products are designed for whichever one the company is currently more afraid of losing.
Two People, Not Two Modes
It's worth being precise about the distinction, because it's easy to confuse with a different one.
A product has novice users and expert users — the same person at different points in their learning curve, needing different things as they progress. A product also has prospects evaluating it and customers using it daily — again, often the same person, at different moments in their relationship with the tool.
This is a different problem. In B2B, the buyer and the user are frequently different human beings with different jobs, different incentives, and no shared experience of the product. The VP who approves the purchase may never open the tool. The procurement officer who negotiates the contract certainly won't. The IT administrator who deploys it uses a completely different set of screens than anyone else. And the forty people who actually work in the product every day had no input into the decision to buy it and no ability to reverse it.
These aren't stages of one relationship. They're separate relationships with separate requirements, and a design that serves one well can actively damage the other. That's what makes this harder than the usual novice-versus-expert calibration: the needs don't just differ in degree, they conflict in direction.
What the Buyer Needs the Product to Do
The buyer is evaluating a purchase they'll have to justify. Their requirements come from that position, and they're consistent across organizations.
Visibility. The buyer needs to see what's happening — who's using the tool, how much, to what effect. Not because they're surveilling anyone, but because they signed for it and will be asked whether it was worth it. A product that gives the buyer no way to answer that question is a product they can't defend at renewal.
Control. The buyer needs to enforce policy. Who can access what, what data can leave the system, what happens when someone leaves the company, whether the settings an individual chooses can override what the organization requires. Control features are risk management, and risk is the thing buyers are actually managing.
Standardization. The buyer usually wants everyone doing things the same way. Templates, required fields, defined workflows, locked configurations. Consistency across a team is the point of buying a tool for the team rather than letting everyone use whatever they prefer.
Proof. The buyer needs evidence of value in a form they can present upward. Usage reports, outcome metrics, time saved, something that translates the tool into the language their own leadership speaks.
Every one of these requirements is legitimate. And every one of them, implemented carelessly, makes the product worse for the person using it.
What the User Needs the Product to Do
The user's requirements come from a completely different place: they have work to do and this tool is now in the way of it or in service of it.
Speed. The user is measured on their actual job, not on their use of the tool. Every second the product costs them is a second taken from the work they're accountable for. Friction that a buyer would consider trivial — one extra required field, one additional approval step — is a tax the user pays repeatedly.
Autonomy. The user wants to work the way they work. Standardization that a buyer sees as consistency, a user often experiences as being forced into someone else's process, usually one designed by a person who doesn't do their job.
Absence of surveillance. Visibility features look very different from below. A dashboard that shows a manager who's using the tool and how much is, from the user's perspective, a monitoring system. Users who feel watched engage defensively — doing the minimum that registers as compliance, keeping their real work elsewhere.
Not being blamed for the tool. When a mandated product is slow or confusing, the user still has to hit their targets. They will route around the tool to do so — keeping the real spreadsheet on their desktop, using the old process and back-filling the new system afterward. This is the mechanism by which shelfware happens: not refusal, but quiet parallel workflows.
Where the Two Sets of Requirements Collide
The conflicts are specific and predictable, which means they're designable rather than merely regrettable.
Permissions and access. The buyer wants granular control. The user wants to not hit a wall while trying to do their job. Poorly designed permission systems produce a product where users regularly encounter things they can't do, with no explanation of why or path to resolution. The design question isn't whether to have permissions — it's what a user experiences at the moment they hit one. A blocked action with a clear reason and a one-click request path is a minor friction. A blocked action with a generic error is an obstacle that sends the user looking for a workaround.
Required fields and mandatory workflow. The buyer wants complete data. The user wants to enter what's relevant and move on. Every required field is a small negotiation between data quality and adoption, and products routinely resolve it in favor of data quality without noticing that a field users don't want to fill produces garbage data anyway — entered carelessly to get past the requirement.
Reporting and analytics. The buyer needs reporting. The user generates the data the reporting depends on. Products often solve this by requiring users to categorize, tag, and label their work in ways that serve reporting rather than the work itself. The user is doing data entry for someone else's dashboard, and they know it.
Onboarding mandates. The buyer often wants a rollout: everyone trained, everyone onboarded, adoption tracked. The user experiences this as a mandatory tutorial for a tool they didn't choose. Onboarding designed to satisfy a rollout requirement rather than to make an individual successful is onboarding that people click through without reading.
The Failure of Winning the Buyer
A product optimized entirely for the buyer wins deals and loses usage. It has excellent admin controls, comprehensive reporting, robust permissions, and a daily experience that nobody would choose if they had a choice.
This failure mode is slow and therefore easy to miss. The deal closes, revenue is recognized, and the product looks successful for two or three quarters. Usage data declines but there's always an explanation — rollout takes time, adoption is a change management problem, the customer's team needs more training. The product team hears the buyer's feedback loudly, because the buyer is the one in the QBR, and hears the user's feedback not at all, because the user has no channel and no leverage.
The bill arrives at renewal. The buyer, asked to justify the spend, looks at usage and finds it can't be justified. Or a competitor arrives with a product the team actually wants to use, and the users lobby internally for the switch in a way they never lobbied for the incumbent. Churn that took eighteen months to build up appears as a single event, and it's usually attributed to pricing or to a competitor's feature rather than to a design that was never serving the people whose usage the renewal depended on.
The Failure of Winning the User
The opposite failure is less discussed but equally real, and it's the characteristic failure of bottom-up products.
A product that users love and that spreads organically inside organizations eventually hits a ceiling: it reaches the point where someone in procurement, security, or IT has to approve it as an official tool. At that moment the product is evaluated by people who have never used it and don't care how pleasant it is. They ask about SSO, audit logs, data residency, role-based access control, admin provisioning, and compliance certifications. A product with none of these fails the review, and the delightful daily experience is irrelevant to the outcome.
This failure is usually framed as a feature gap — the product needs enterprise features — and it is that. But it's also a design problem, because the admin and governance surfaces of a product that grew bottom-up are typically built late, quickly, and by whoever was available. They work, in the sense of technically functioning, and they feel like a completely different product bolted onto the side of the one users like. The buyer's experience of the product is the admin console, and if the admin console is an afterthought, the buyer's entire impression of the product is an afterthought.
Designing for Both
The resolution isn't compromise — a product that splits the difference between the buyer's needs and the user's is usually worse for both. It's separation and honesty about which surface serves whom.
Treat the admin experience as a real product. The admin console has its own users, its own jobs to be done, and its own quality bar. It deserves the same design attention as the primary product, not a table of toggles built in a sprint. A well-designed admin experience is a competitive advantage in enterprise sales, and it costs the daily user nothing because they never see it.
Keep governance out of the daily path. Most control requirements can be satisfied in configuration rather than in workflow. Policies enforced by settings the administrator configures once are invisible to the user, who simply experiences a product that behaves consistently with organizational policy. Policies enforced by prompts, confirmations, and required steps in the user's workflow are a tax paid by everyone, every time.
Derive reporting from behavior, not from data entry. The most user-hostile reporting requirement is one that asks users to categorize their work for someone else's benefit. Reporting built on data the product can observe — what was done, when, by whom, with what outcome — gives the buyer visibility without conscripting the user into data entry. This is more work to build and dramatically better for adoption.
Make blocked paths informative. Since permissions will block users sometimes, the design question is what happens then. An explanation of why, and a path to request access, converts a dead end into a minor delay. This single pattern removes a large share of the friction that permission systems otherwise create.
Give the user something the buyer didn't ask for. The most durable position in B2B is a product that users would choose even without a mandate. That requires deliberately designing value for the individual — something that makes their specific job easier, independent of the organizational reason the tool was purchased. Products that achieve this convert mandated users into advocates, which is the thing that makes renewals safe.
The Question Worth Asking
For any design decision in a B2B product, there's a clarifying question: which of these two people is this for, and what does it cost the other one?
Most decisions have an answer. This admin control serves the buyer and costs the user nothing, because it's configured once and invisible afterward. This required field serves the buyer and costs the user four seconds every time, forever. This keyboard shortcut serves the user and costs the buyer nothing. This mandatory categorization step serves reporting and costs the user their willingness to use the product honestly.
Asking the question doesn't automatically resolve it — sometimes the buyer's requirement genuinely outweighs the user's cost, and it's a legitimate trade. But making the trade knowingly is different from making it by default, and most B2B products make it by default, in the buyer's favor, because the buyer is the one in the room.
The user isn't in the room. They're just the reason the contract renews.