You’ve been there. You sit down with your users, conduct hours of interviews, and carefully document every single feature they beg for. You build it. You ship it. And then… it’s a bloated, useless mess that no one actually uses and your engineering team resents you for building it.
Why? Because you listened to your users.
In the consumer tech world, user-centric design is gospel. The user is always right. But in enterprise and B2B systems, treating the user as the ultimate authority is a fatal mistake.
In B2B systems, the user isn’t a free agent. They are a rule-executor.
The user doesn’t get to decide what they want to do, how long they can do it, or what data they need to see. The business rules dictate all of that. The user is simply the human tasked with pressing the buttons the system requires them to press.
When you ignore the rules and focus only on user habits, you build a system that might be incredibly easy to use, but is fundamentally irrelevant to the business. Usability only matters inside the boundaries the rules set. Ignore the user, and the solution is unusable. Ignore the rule, and the solution is irrelevant.
Here is the hard truth about those user requests you’ve been diligently collecting:
Most user requests aren’t actual needs. They are amateur solutions proposed by people who don’t understand the rules.
When a user says, “I need a custom dropdown menu here,” they are usually just proposing a band-aid for a workflow they don’t fully understand. If you build that dropdown, you aren’t solving the problem—you’re hardcoding a layperson’s flawed logic into your system. That is exactly how duplicated development costs and bloated features are born.
I saw this firsthand building a platform for an integrated electricity trading company. The company had both power plants and retail electricity sales. On paper, the users for both sides had the exact same job title: “Trader.” You’d think you could just build one system and let both sides use it, right?
Dead wrong.
The rules made them fundamentally different roles. Power plant traders had to report both volume and price. Retail sales traders only had to report volume. Power plants were settled at node prices; retail was settled at market average prices. They looked at different data, maintained different objects, and had completely different profit calculations.
They had the same title, but the rules gave them completely different DNA. If we had just listened to the “users” and built a shared system, it would have been a catastrophic failure. We had to split the architecture entirely, not because of user preference, but because the rules demanded it.
Before you talk to a single user, you have to become a domain expert. If you’re building a financial system, you need to understand accounting. If you’re building a CRM, you need to know the sales process inside and out. Your first stop isn’t the user interview; your first stop is the rulebook.
Rules draw the boundaries. Users just fill the space inside.
Does this mean user research is dead? No. It means user research has a very specific, contained scope. The rules dictate *what* must be done. User research only dictates *how* it gets done.
The rules require the power plant trader to report volume and price. That boundary is fixed. But *how* they analyze the market to decide on that price—that’s where user research comes in. You study their workflow to make the process faster, smoother, and less painful within the boundaries the rules have already drawn.
But if the rule doesn’t require a feature, no amount of user begging should make you build it. Usability is just the icing on the cake. If the rules don’t support the cake, the icing is useless.
Stop building what users ask for. Start reverse-engineering the rules that dictate their jobs. That is the only way to turn yourself from a feature-pushing ticket-taker into a true domain expert.
FAQ
Q: Doesn't ignoring user requests lead to terrible, clunky software?
A: No, ignoring the rules leads to terrible software. If you build a beautiful UI for a workflow the rules don't actually support, the system is useless. You aren't ignoring the user; you're prioritizing the framework that actually defines their job.
Q: How do I actually start reverse-engineering business rules?
A: Read the documentation. Before you schedule a single user interview, read the accounting manuals, the legal frameworks, and the standard operating procedures. You have to become a domain expert before you can even understand what the users are complaining about.
Q: What if the users don't even know the rules themselves?
A: They rarely do completely. Users only know their specific slice of the workflow. That's exactly why you can't trust their feature requests—they are proposing solutions based on an incomplete picture of the system. You have to find the rulemakers and the documentation to see the whole board.