Stop Building What Your Clients Ask For

I know it sounds backwards. The client is paying you. They know their business. They told you exactly what they want. Why wouldn't you just build it?

Because what a client asks for is almost never what they actually need.

Patients don't write their own prescriptions

Think about the last time you went to a doctor. You didn't walk in and say, "Give me 500mg of this, twice a day, for ten days." You told the doctor what was wrong. Where it hurts. When it started. What makes it worse.

Then the doctor did their job. They asked follow-up questions. They examined you. They ruled things out. And only then did they decide what to prescribe. Usually the simplest treatment that would actually fix the problem.

Now imagine a doctor who just wrote down whatever the patient asked for. You'd never trust that doctor. Yet that's exactly how a lot of builders treat their clients.

As a product designer or builder, your job is the doctor's job: diagnose the problem, then come up with the solution. The client brings the symptoms. You bring the prescription.

A feature request is a guess

When a client says, "I need a button that does X, and it should work like Y," they aren't handing you a requirement. They're handing you their best guess at a solution, based on the tools they already know.

That guess isn't worthless. It's a symptom, and symptoms point to the real problem. But if you build the guess exactly as described, you've let the patient write the prescription.

So we should not rely on the client to tell us what features they want. We should rely on them to tell us two things:

• The problem they have. What is getting in their way today?
• The outcome they need. When this is solved, what's different?

Everything else, what the feature is and how it works, is our job to figure out.

A real example: the Excel export

A client asks: "Can you give me an Excel export out of my CRM with these fields?"

If you just build what they asked for, it's easy. A few minutes of work, ship it, done. Client's happy, right?

But ask one more question: what do you do with that export?

Turns out he opens it in Excel, sorts it by last contacted date, and uses it to figure out who to call next.

That's the real problem. He doesn't need a spreadsheet. He needs to know who to call next. The export was just his workaround.

Build the export, and every single day he has to log in, click export, open the file, sort the column, and scan the list. Build for the outcome, and the CRM simply shows him who to call next the moment he logs in. Same result, zero steps.

That's the difference between taking an order and solving a problem.

The goal: minimum input, maximum outcome

Once you know the problem and the outcome, the design question becomes simple:

What is the least the client has to do to get the result they need?

Every click, every field, every screen you put between the client and their outcome is friction. A good doctor picks the simplest treatment that works. A good builder designs the feature with the fewest steps possible for the client.

Before you build anything, run through three questions:

• What is this for? Find the real problem behind the request.
• What outcome do they want? Define what "solved" looks like in their words.
• What's the least they have to do? Design the shortest path from their input to that outcome.

Clients pay for outcomes, not features

Nobody actually wants an export button. They want to know who to call. Nobody wants a report builder. They want to know if their business is growing. The feature is just the vehicle.

When you build for the outcome instead of the request, something interesting happens. The client doesn't feel like you ignored them. They feel like you understood them better than they understood themselves.

So the next time a client tells you exactly what to build, don't start building. Start diagnosing.

Want posts like this as soon as they go live? Subscribe on the GHowTo homepage and I'll send you an email and a text each time I publish something new about building and scaling a SaaS business.