DEV Community

Cover image for Stop building what your customers ask for
Jonathan Murray
Jonathan Murray

Posted on

Stop building what your customers ask for

I was at a conference this week.

Bunch of stakeholders on stage. Hospital admins, big-name buyers, a couple of policy folks. The message to founders was loud and clear:

"You need to be consulting us. You need to be adapting your products to our suggestions."

And honestly? I hated it.

Not because they were completely wrong. They were half right. They were just shouting the half that was wrong.

Here's the part that's true

Building in a vacuum is how you ship things nobody uses. Founders, especially technical ones, have a real habit of deciding what the world needs from inside a Notion doc.

So yes. Talk to users. Ride along. Watch people struggle with your product. All of that.

The stakeholders aren't crazy for wanting a seat at the table.

Here's the part that breaks things

"Listen to us" slowly turns into "do what we say."

And that's where it gets weird.

Because every dev on earth has learned this lesson already. It's called a bug report.

A user says "the login is slow." You dig in. The login isn't slow. They're on hotel wifi and there's no loading spinner, so it feels frozen. The complaint was real. The proposed fix, "make the login faster," was useless.

Stakeholder feedback works exactly the same way.

The pain is the signal. The proposed fix is a guess. Usually a bad one.

A senior eng who shipped whatever the ticket said would get laughed out of the room. Why do we call a founder who ships whatever the customer asks for "responsive"?

Why the fix is almost always wrong

Three reasons, no mystery to any of this:

1) Stakeholders see their slice. Not the whole system. Of course their fix is local.
2) They imagine solutions inside the workflow they already have. Which is often the exact workflow you're trying to change.
3) The thing that would actually solve the problem doesn't exist in their vocabulary yet. That's kind of your job.

When a cardiologist says "add a button that auto-generates the referral letter," the real signal is referrals are friction. The button might be the worst possible version of the fix. Maybe the letter shouldn't exist. Maybe the referral shouldn't need a letter. That's a conversation. Not a ticket.

The receipt: healthcare AI just ran this experiment for us

For years, stakeholders told the industry they wanted "AI that can pass the medical boards."

The industry listened. Every model got tuned on USMLE-style questions. Board-exam scores became the benchmark everyone pointed at.

This month, JAMA Network Open dropped a study across 21 top LLMs (ChatGPT, Claude, Gemini, DeepSeek, Grok). Final-diagnosis accuracy on complete cases? Over 90%.

Differential diagnosis, the thing an actual doctor does all day? Failed more than 80% of the time.

The stakeholders asked for the wrong benchmark. Founders shipped it. We now have a generation of models that ace trivia and fold on reasoning.

The founders who had pushed back, the ones who said we hear you want trustworthy AI, we're not going to chase board scores to prove it, would look prescient right now. The ones who obeyed built an industry of exam-passers.

How to actually do it

When a stakeholder hands me a feature request, I try to never put it in the backlog as written. Three questions first:

1) What were they trying to do when they felt the pain?
2) What's the actual friction, stripped of their proposed fix?
3) What would "solved" feel like, regardless of how it gets built?

Rule of thumb: if a stakeholder ask fits neatly into a Jira ticket, I haven't translated it yet.

Back to the conference

I get why the stakeholders were on that stage. They've been burned by founders who ignored them. They want to be heard.

But "heard" is not the same as "obeyed." And founders who treat customer feedback as a spec instead of a bug report end up building slightly nicer versions of the thing that already isn't working.

Listen obsessively.
Obey selectively.
And be willing to tell the room that the button they're asking for isn't the thing they actually need.

That's not arrogance. That's the job.

What's a piece of stakeholder feedback you took literally and regretted? Or one you translated into something better and it worked?

Top comments (0)