How I Write Discovery Questions That Surface What Clients Actually Need.

Why Do Most Discovery Calls Miss What Clients Actually Need?

Most freelance Webflow discovery calls follow a predictable script. How many pages do you need? What is your budget? What is your timeline? Do you have existing brand guidelines? These questions produce data, but they rarely surface what the client actually needs from the project. The result is scope documents that describe the right pages with the wrong emphasis, and projects that technically deliver but do not produce the business outcomes the client was hoping for.

After 70+ client projects, I have learned that the questions that surface real needs are completely different from the questions that feel natural to ask. The useful questions are uncomfortable. They force clients to articulate things they have not yet put into words. They often produce silences while the client thinks. And they consistently lead to better project outcomes than the standard questions produce.

Here are the discovery questions I now ask in every initial call, why they work, and how they reshape the project scope before a single line of HTML gets written.

What Is the Business Outcome You Are Really Trying to Achieve?

This is the question I ask first, before any questions about pages, design, or timeline. "What business outcome are you trying to achieve with this website project?" Most clients initially answer with a description of the website itself. "A modern site that represents our brand well." This is not an outcome. It is a deliverable.

I push for specificity. "If the new site is wildly successful, what specifically changes about your business six months after launch?" Now the answers become useful. "We close 40% of discovery calls instead of 20%." "Inbound leads go from 10 per month to 40." "We raise our prices by 30% without losing deals." "We attract enterprise clients instead of only small businesses."

These specific outcomes reshape the entire project. A site designed to increase close rates looks different from a site designed to increase lead volume. A site designed to attract enterprise clients looks different from a site designed to serve small business buyers. Without asking this question, I would design for generic assumptions about what good websites do.

Who Is the Single Person You Want to Reach With This Site?

Clients describe their audience in demographic terms when asked. "SaaS founders, ages 30 to 50, with companies doing $1M to $10M in revenue." This is segmentation, not a person. Segmentation is useful for media buying. It is less useful for website design because you cannot write copy to a segment. You can only write to a person.

I ask: "If you could only attract one specific person with this website, who is that person? What do they do on a typical Tuesday? What is the most frustrating part of their job? What are they thinking about at 11pm when they cannot sleep?"

The answers produce character sketches rather than demographic profiles. "She is a VP of Marketing at a 200-person SaaS company. Her CEO just asked her why the website looks outdated and she is embarrassed because she knows it does. She does not have time to run a 4-month RFP process. She needs someone who can make it happen quickly without requiring her to manage every decision." That character sketch informs every copywriting and design choice downstream.

What Will Make You Say This Project Was Worth the Money?

Budget questions usually ask "what is your budget?" I ask the inverse: "What would make you say, six months from now, that this project was worth the money?" This reframes the conversation from price to value.

The answers reveal what the client actually cares about. Some clients say "if we see a measurable revenue increase." Others say "if our team stops complaining about our website." Others say "if I can update content myself without asking a developer." Each of these answers suggests different project priorities that would not be obvious from a budget number alone.

This question also surfaces misalignments before they become problems. If a client says "if we rank #1 for our primary keyword within 30 days," I can immediately explain that SEO takes longer than 30 days and reset expectations, or I can decline the project if the client's definition of success is unrealistic.

What Have You Already Tried That Did Not Work?

Every client considering a new website has done something before. Maybe they hired a previous developer. Maybe they used a template. Maybe they tried to build it themselves. Understanding what did not work prevents you from accidentally repeating the same mistakes.

I ask: "What have you already tried on this website or related projects, and what specifically did not work about those attempts?" The answers reveal patterns. Clients who tried three previous developers and were unhappy with all three are either difficult to please or have been choosing wrong developers for their needs. Both are information I use to evaluate whether we are a good fit.

This question also surfaces context I would otherwise miss. "We launched a redesign 18 months ago that caused our traffic to drop 60% and we never recovered." That single sentence tells me the new project must preserve existing SEO carefully, which becomes a non-negotiable requirement rather than a nice-to-have.

Who Will Be Editing This Site After Launch, and How Technical Are They?Most clients do not think about post-launch maintenance during the discovery call. They focus on what the site will do on launch day. But the site's long-term value depends on who maintains it and how capable they are.

I ask: "After we launch, who on your team will be making content updates? How comfortable are they with web tools? What have they used before?" The answers determine how I build the CMS, what I document, how I configure the Client Editor interface, and how I structure the handoff training.

A site that will be edited by a non-technical marketing manager needs a different CMS architecture than a site edited by a developer. Generic "we'll make it easy" assumptions produce handoffs where the client cannot actually edit the site after launch. This question prevents that outcome.

What Is the Most Important Thing on the Current Site That Must Not Change?

Rebuilds often assume everything needs to change. But many existing sites have elements that are working well and should be preserved: specific pages that rank well, conversion elements that have been tested, brand positioning that the team has invested in.

I ask: "What on your current site is working well that you want to protect or carry forward?" Sometimes the answer is "nothing, everything needs to change." Sometimes it is "our case studies rank well and we cannot afford to lose that traffic." Sometimes it is "our pricing page was A/B tested and converts well, so please do not redesign it without data."

These constraints shape the project. A site with legacy SEO value needs careful URL preservation and redirect mapping. A site with tested conversion pages needs to preserve the tested elements while improving around them. Skipping this question means accidentally breaking things the client valued.

What Would Happen If We Did Nothing?

This is my favorite question and the one clients find most uncomfortable. "What would happen if you did not do this project at all? What specific business cost would you incur?"

The answers reveal urgency (or the lack of it). Clients who say "we would continue to lose 10 qualified leads per month to competitors who have better sites" have measurable urgency that justifies investment. Clients who say "well, nothing specific, we just think we should update things" have low urgency, which predicts scope creep, indecision, and probable project cancellation.

I use this question to qualify projects. Low urgency projects often result in unhappy outcomes for both parties. High urgency projects have clear success criteria and typically go well. Asking this question upfront saves both of us from bad-fit projects.

How to Implement This Discovery Framework This Week

Before your next discovery call, write out these seven questions. Practice asking them in an order that feels conversational rather than interrogative. Leave space for silence after each question; clients often need 10 to 20 seconds to formulate a useful answer.

For the client evaluation framework that discovery questions feed into, my reflection on why I turned down my highest-paying client covers how to use discovery insights to decide whether to take a project. For the audit process that complements discovery, my guide on auditing a prospective client's website covers the technical side of pre-project evaluation. And for the scoping practices that turn discovery into deliverables, my article on lessons from 50 client projects covers the scope document framework.

Better discovery questions produce better projects. The seven questions above replaced my old standard script a year ago, and every project since has started with sharper scope, clearer success criteria, and better aligned expectations. If you want help developing a discovery framework for your Webflow practice, I am happy to chat. Let's connect.