The Questions You Don't Ask Become the Problems You Get

Almost every project that goes badly can be traced back to a question nobody asked at the start. The client wanted something different from what you understood. There was a decision-maker you never met who rejected everything at the end. There was a real deadline behind the vague one. There was a previous attempt at this that failed, and nobody mentioned why. None of these are exotic problems; they're all things that would have surfaced from a single well-aimed question in the first conversation, and instead they surfaced three weeks in, as expensive surprises.

The first conversation with a new client is the cheapest opportunity you will ever have to prevent problems, and most people waste it. They spend it describing their services, walking through their process, and establishing credentials — talking, in other words — when the entire value of that conversation lies in what they could have learned. What you find out at the start determines how well the work goes, what you're able to deliver, and whether the relationship is a good one; what you fail to find out becomes the friction, the rework, and the disappointment later.

There's a second benefit that most people miss entirely. Good questions don't just gather information — they demonstrate expertise more convincingly than any pitch can. A client who's asked a sharp, specific question they hadn't considered immediately understands they're talking to someone who knows this territory, because only someone who's done this before would know to ask that. This is why the questions you ask are frequently more persuasive than the answers you give, and why treating the first conversation as an information-gathering exercise rather than a performance tends to win more work, not less. [BACKLINK PLACEHOLDER → suggestion: internal link to article #43, why the discovery call is mostly performance / asking real questions instead of performing expertise]

So this is a practical companion piece: what to actually ask a new client before starting work. Not a script to run through mechanically, but the areas that matter, the questions that surface real information, and the ones most people skip — usually because they're slightly uncomfortable, which is exactly why they're valuable.

Key Takeaways

• Unasked questions become later problems. Most project disasters trace back to something that would have surfaced from one good question in the first conversation.
• Ask about the real goal behind the request. Clients describe solutions, not problems. Finding out what they're actually trying to achieve often changes what you'd recommend.
• Find out who actually decides. The person you're talking to may not be the one who approves the work — discovering that at the end is how projects die.
• Ask what's been tried before and why it failed. The history of previous attempts is the single most informative thing you can learn, and almost nobody asks.
• Ask the uncomfortable questions. Budget, real deadlines, and what "success" means are awkward and essential. Avoiding them doesn't make the issues go away.

Ask What They're Actually Trying to Achieve

Clients almost always arrive with a solution rather than a problem. They ask for a video, a website, a campaign, a specific deliverable — because they've already done some internal translation from "we have this problem" into "so we need this thing." That translation is where a lot of projects go wrong, because it's usually done by someone without your expertise, and the thing they've concluded they need often isn't the best answer to the problem they actually have.

So the most valuable early question is some version of: what are you hoping this will achieve? What's the situation that made this feel necessary? What would be different if this worked? These questions move the conversation back from the requested solution to the underlying goal, which is where you can actually apply expertise. Sometimes the answer confirms their request was right. Often it reveals that what they need is somewhat different, or that the deliverable they asked for won't accomplish what they're after — which is exactly the kind of insight that makes you valuable rather than order-taking.

This also protects you later. A project defined by a deliverable ("make this video") can be delivered exactly as specified and still leave the client unhappy, because the underlying goal wasn't met. A project defined by an understood goal gives you something to steer by, and gives you the standing to say "this would serve the goal better" when it matters. Understanding the real objective is what lets you make a recommendation rather than just take an order. [BACKLINK PLACEHOLDER → suggestion: internal link to article #55, clients don't want options, they want a recommendation / understanding the goal is what makes a recommendation possible]

Find Out Who Actually Decides

This is the question people skip most often and regret most sharply. The person you're talking to may not be the person who approves the work, controls the budget, or signs off on the final deliverable — and discovering that at the end, when someone you've never spoken to rejects work you've already done, is one of the most demoralising ways for a project to fail. Ask early: who else is involved in this decision, who needs to approve the final work, and whose opinion will matter along the way.

The follow-up matters as much: how will approval actually work? A project with one decision-maker runs very differently from one where a committee reviews everything, and knowing which you're in changes how you plan, how much revision time you allow, and how you present work. Committee approval isn't a problem in itself; unexpected committee approval is. Similarly, if there's a senior person who will see the work only at the end, that's crucial to know — you'll want to surface their expectations early rather than discovering them after everything is built.

Asking this is straightforward and reads as professional rather than presumptuous, because it obviously serves the project. Something as simple as "who else will be involved in reviewing this, and how does sign-off usually work here?" gets you most of what you need, and the answer routinely reveals structures you'd never have guessed. The cost of asking is a few seconds of mild awkwardness; the cost of not asking can be an entire project.

Ask What's Been Tried Before

If I could only ask a new client one question, it might be this: have you tried to solve this before, and what happened? The history of previous attempts is extraordinarily informative and almost nobody asks for it. It tells you what didn't work and why, what the client's expectations have been shaped by, what they're quietly worried will happen again, and often what the real obstacle is — which is frequently something other than the thing that appears to be the problem.

It also surfaces the landmines. If they've worked with three providers on this already, that's important information — it might mean they've been unlucky, or it might mean something about the brief, the internal politics, or the client themselves makes success difficult. Either way you want to know before you're the fourth. If a previous attempt failed because of something structural — no internal buy-in, unrealistic expectations, a decision-maker who blocks everything — you're about to walk into the same wall unless you find out now. [BACKLINK PLACEHOLDER → suggestion: internal link to article #35, the five clients you should never accept / early signals worth taking seriously]

Ask it neutrally and without judgment, because you want an honest answer rather than a defensive one: "has anyone worked on this before, or have you tried other approaches? What happened?" Most clients answer this readily and in detail, because it's their story and they've thought about it a lot. And what they tell you will shape your approach more usefully than almost anything else in the conversation.

Ask the Uncomfortable Questions

Three questions feel awkward and are essential, and avoiding them is how avoidable problems become unavoidable ones.

Budget. Asking what they've allocated feels crass, and not asking wastes everyone's time — you can spend hours scoping and proposing work that was never within reach. You don't have to demand an exact figure; a range, or a sense of what scale of investment they had in mind, is usually enough to know whether you're in the same universe and to scope appropriately. Framing it around serving them helps: "so I can propose something realistic rather than wasting your time, do you have a budget range in mind?" Most clients answer, and the ones who refuse entirely are telling you something too.

The real deadline. Clients often state a deadline that's softer than it sounds, or, more dangerously, a soft one that's hiding a hard one behind it. Ask what's driving the timing: is there an event, a launch, a contractual date, or is this a preference? Knowing whether a date is real changes how you plan and whether you should take the project at all — and it prevents the manufactured urgency that degrades work for no reason. [BACKLINK PLACEHOLDER → suggestion: internal link to article #53, most of your urgent deadlines aren't real / finding out whether a deadline is genuine]

What success looks like. This is the question that prevents the most disappointment, because "good" is defined differently by different people and you cannot deliver to a standard nobody has stated. Ask how they'll judge whether this worked, what a great outcome looks like specifically, and what would make them feel it had failed. Vague answers are themselves useful information — a client who can't articulate what success means is a client whose satisfaction will be unpredictable, and that's worth knowing before you start.

Listen More Than You Talk

The technique underneath all of this is simple and hard: talk less. The instinct in a first client conversation is to fill it with your credentials, your process, and your ideas, because that feels like demonstrating value. But every minute you spend talking is a minute you're not learning, and the information you need is entirely on their side of the conversation. A rough rule that serves most people well is that the client should be doing substantially more of the talking, and if they aren't, you're probably pitching when you should be listening.

Practically, that means asking open questions rather than ones with yes/no answers, then leaving space for the answer instead of filling silences. It means following up on what they say rather than moving mechanically to your next question — the most valuable information usually comes from the second or third follow-up on something they mentioned briefly, not from the prepared list. And it means taking notes visibly, which both ensures you capture things and signals that you're taking their situation seriously.

Resist the urge to solve the problem live, too. Offering a confident solution in the first conversation feels impressive and is usually premature, because you don't yet have enough information for the solution to be good. Demonstrating that you understand the problem is far more persuasive than demonstrating that you can produce an instant answer — and the understanding you show by asking a sharp question does more for the client's confidence than a hasty recommendation would. Save the recommendation for when you've earned it with information.