You built for the person who approved the budget, not the person doing the work.
Why products fail when you optimize for the executive meeting instead of the daily user.
I spent the early 2010s building sales tools for mortgage lending. We moved fast, shipped features constantly, and watched our roadmap fill up with requests from sales leadership.
Most of the prioritization was based on features leadership perceived would drive more sales. Quality of the feature? Didn’t matter as much as which sales leader was pushing for it.
The pattern was brutal. A feature would get built. If it drove adoption, great. But that adoption came from how hard the sales leader pushed their team to use it, not from how good the feature actually was.
If it didn’t drive a sales bump within a few weeks, we’d just move on. Leave it as technical debt. Next feature.
We were optimizing for the wrong success metric.
Building for applause instead of adoption
The triage feature was supposed to be our big win.
Sales leaders wanted seamless lead routing. When a banker got a call from a customer they couldn’t help (wrong state license, wrong product specialty), they should be able to route that lead to the best-qualified person in the organization. Optimal conversion. Maximum revenue capture.
Makes total sense in the conference room.
We designed it to work seamlessly. The hand-off would be smooth. The customer wouldn’t know they’d been transferred. The lead would land in the best possible hands.
Sales leadership loved it. Approved the budget. We built it.
Nobody used it.
The bankers wanted their teams to get credit for the lead. They’d rather hand it to someone on their own team (even if that person was less qualified) than send it into some optimal routing system where another group would get the commission.
We built what leadership asked for. We solved the leadership’s problem. But the people who actually had to change their daily behavior had a completely different set of incentives.
So they just didn’t use it. Kept doing what they’d always done.
Why this keeps happening
This wasn’t unique to that feature.
We were moving so fast that there was never time for a post-mortem. No conversation about “did we build for the wrong user?” Just onto the next thing leadership wanted.
The early 2010s were all custom development for our org. Now there are off-the-shelf tools that handle team-based routing. They learned from failures like ours.
But the fundamental mistake wasn’t technical. It was strategic.
We kept confusing the person who approved the purchase with the person who had to use it daily. And nobody in the room had the incentive to point that out. Leadership got the feature they asked for.
Engineering has to ship something. The only people who lost were the bankers we never talked to.
What I’d do differently
In retrospect, I would have explored how to get that lead to the right people, closer to the team member, so their groups could get credit.
But here’s what we should have done before writing a single line of code: actually ask the bankers what they needed. Not in a conference room with their VP present. Not in a feedback session after we’d already built it.
A simple survey with a tool like Survey Monkey to the people who’d use it daily: “When you get a lead you can’t help, what would make handing it off easier for you while keeping your team’s numbers intact?”
The answer probably would have been obvious. We just never asked because we were too busy building what leadership assumed they wanted.
The question isn’t “what does leadership want?” It’s “what makes the daily user’s job easier?”
Before you build for stakeholders
After enough of these failures, I started mapping stakeholder dynamics before any feature gets prioritized.
Four questions to surface misalignment early:
Who approves the purchase? This is who shows up in your roadmap meetings. The person with budget authority. The VP who says, “We need this feature.”
Who actually uses it daily? This is the person whose behavior has to change. The banker taking calls. The sales rep logging activities. The customer success manager updating tickets.
Whose behavior has to change? Be specific. What will they have to start doing? Stop doing? Do differently? If the answer involves extra steps or lost control, you’re in trouble.
What incentives exist that might block adoption? Commissions. Team metrics. Personal efficiency. Political capital. These invisible forces kill more features than technical limitations ever will.
If those answers point to different people with different goals, you could end up wasting engineering time if you’re not careful.
Where most products go wrong
The best products don’t just satisfy the buyer. They make the user’s actual job easier in ways their boss can measure.
That’s harder than building what leadership asks for. It requires saying, “before we build this, let me talk to the people who’ll actually use it.”
Most product teams skip that step. They build for the executive meeting instead of the daily grind.
Then they wonder why adoption is a sales leader pushing their team, not the feature pulling users toward it.
I built a technically seamless feature nobody wanted. You probably have one on your roadmap right now.
The difference is whether you catch it before shipping.
Until next week,
Mike Watson @ Product Party
P.S. Want to connect? Send me a message on LinkedIn, Bluesky, Threads, or Instagram.