The Discovery Question That Saves Me the Most Trouble

What is the one discovery question worth asking every client?

Who has to approve this before it goes live? I ask it early, before scope, before budget, before anything technical. It sounds administrative and it is the single strongest predictor I have found of whether a project will run smoothly or turn into six weeks of revisions nobody planned for.

I have run discovery calls for six years across more than 70 projects and 25 clients, and the questions I started with were not these. I used to ask about goals, audience, and competitors, which are reasonable questions that produce reasonable answers and tell you almost nothing about how the project will actually go.

What goes wrong in projects is rarely the brief. It is the invisible third party who appears in week five with opinions, or the founder who wanted something different from what their marketing lead described. Approval structure predicts that. Goals do not.

Why does an approval question predict trouble better than a brief?

Because a brief describes the work and approval describes the decision. Two people can agree completely on a brief and disagree completely on whether a specific page is finished. Every painful project I have been part of was painful at the point of judgement, not at the point of specification.

There is also an information problem. The person writing the brief usually knows what they want. What they often do not know, or do not volunteer, is that their founder reviews everything personally, or that legal signs off on any page mentioning customers, or that a board member has strong views about the logo. None of that appears in a brief and all of it appears in week five.

The question also works because it is easy to answer honestly. Nobody is defensive about who approves things. Ask what the budget is and you get negotiation. Ask who approves and you get a straightforward organisational fact, offered freely, that tells you more about the project than the budget did.

What do the different answers actually tell you?

Three answers cover most cases and each implies a different way of working. One name means fast decisions and a single taste to understand. Two or three names means you need alignment before you build. I do not know means the project has a risk that nobody has priced, including the client.

When the answer is one person and that person is on the call, that is the best case and I structure the work around their availability. When the answer is one person who is not on the call, that is quietly the worst case, because I am about to build to a brief written by someone who is not the decision maker. I would rather spend thirty minutes with the approver than three hours with a document.

When the answer is a committee, that is not automatically bad. Committees are fine when you structure the project around scheduled review points rather than continuous feedback. What breaks a committee project is treating it like a single approver project and discovering the disagreement late.

What is the follow up question that does the real work?

What has that person rejected before? This is the one that produces the useful material, because rejection history reveals taste far more accurately than any description of taste does. People are bad at describing what they like and excellent at remembering what they turned down.

The answers are consistently specific in a way that aspirational answers are not. Somebody will tell you their founder rejected three homepage concepts because they felt too corporate, or that the last agency's copy got sent back for being vague. That is a constraint you can design against on day one instead of discovering it on delivery.

It also surfaces the projects where the approver's stated preference and actual behaviour differ. If a client tells me they want something bold and then describes rejecting everything bold the previous team produced, I now know which of those two statements to believe. That single insight has saved me more rework than any other part of discovery.

How do you ask this without sounding like you expect problems?

Frame it as scheduling rather than suspicion. I ask so that I can plan review points around the right people's availability, which is true, and which makes it a logistics question rather than an audit. Nobody minds being asked how to make reviews efficient.

Tone does the work here. Asking who needs to sign off so I can build the review schedule around them lands completely differently from asking who is going to make this difficult, even though I am gathering the same information. The first question gets a full answer. The second gets a defensive one.

I also ask it in the first call rather than in a form. Written discovery questionnaires get answered by whoever has time, often with the organisationally tidy answer rather than the true one. In conversation you hear the pause before someone says well, technically me, but my co founder has strong opinions. The pause is the answer.

What happens when a client cannot answer it?

I slow down. Not knowing who approves the work is not a small gap, it means the internal conversation has not happened, and it will happen during my project instead. I would rather surface that in week zero when it costs a conversation than in week five when it costs a rebuild.

What I do is ask them to find out before we scope, and I say why. Usually this takes them a day and comes back with a clear answer, which is a good outcome. Occasionally it comes back revealing that two people both believe they own the decision, which is an extremely good outcome to discover before any work exists to argue about.

I have declined projects at this point. Not often, and not because uncertainty is disqualifying, but because a client who cannot establish who decides after being asked directly is telling you something about how the project will run. Saying no early is cheaper for both sides than saying it in month two.

How does this change what you put in a proposal?

It sets the revision structure. On a single approver project I offer fewer, deeper review rounds. On a multi approver project I build in an explicit alignment step before design begins, and I price it, because getting three people to agree is real work that has to happen somewhere.

I work on fixed fees, mostly between one thousand and ten thousand dollars, which means scope discipline is not optional for me. Unpriced alignment work is exactly how a fixed fee project stops being profitable, and approval structure is the best early signal of how much of it there will be.

Naming it in the proposal also changes the client relationship. Writing down that we will hold one alignment session with the three named approvers before design starts makes the dependency visible and shared. If that session does not happen, the delay is legible to everyone rather than becoming my problem silently. I wrote about the related failure in what I do when a fixed fee project goes over scope.

What else belongs in the first call?

Less than most people think. I want to know who approves, what that person has rejected, what already exists that I have to work with, and what happens if we do nothing. Four questions. Everything else can wait for a written round or emerge during the work itself.

The what happens if we do nothing question is the other one I would not drop. It separates projects with a real driver from projects that exist because somebody felt the site looked dated. Both are legitimate work, but they need different conversations about success, and confusing them produces a client who cannot tell you at the end whether they got what they wanted.

Keeping the list short is deliberate. A first call crowded with questions turns into an intake interview, and clients disclose less in an interview than in a conversation. I would rather ask four questions and listen properly than work through fifteen and hear none of the hesitations. There is a longer version of my sequence in the discovery questions I ask before an AEO project.

What should you do next?

Add the approval question to your next discovery call and put it early, before scope. Then ask what that approver has rejected before. Two questions, maybe four minutes, and you will learn more about how the project will go than the rest of the call combined.

Then look backwards. Take your last three difficult projects and ask whether the difficulty was about the brief or about the decision. In my experience it is almost always the decision, and once you see that pattern you will stop trying to fix it with more detailed specifications.

If you are building a freelance or small studio practice and want to compare notes on how you structure discovery, I am genuinely interested in how other people handle this. Reach out and let's chat.