I consider the first conversation to be the beginning of the Discovery Phase. Discovery is where we figure out what we’re actually building, why we’re building it, who we’re building it for, and what it will take to get there. Eventually, that means defining requirements, identifying challenges, establishing goals, breaking the work into user stories, and creating a roadmap for design and development.

But we’re not going to figure all of that out in the first conversation.

For larger projects, it wouldn’t even be reasonable to try. Instead, that first conversation is about understanding the shape of the project: the major features, existing systems, constraints, timeline, budget expectations, and the obvious unknowns.

And that creates an interesting problem.

How can someone tell you what a project will cost before they’ve spent hours figuring out exactly what needs to be built?

The answer is that, early on, they usually can’t—not with absolute precision. The challenge is to create a useful estimate from incomplete information. My goal in that first conversation is to learn enough that I can at least establish a reasonable ballpark.

I sometimes refer to that initial estimate as a Sophisticated Wild-Ass Guesstimate—or SWAG.

Despite the name, it isn’t just a number pulled out of thin air. It’s an informed estimate based on what we currently know, what we don’t know, my experience with similar work, and the assumptions we’re making about the project.

My SWAG will often include a range. On one end is the sunny-day estimate: things go largely as expected, the assumptions hold, and we don’t uncover any major surprises. On the other is the rainy-day estimate: we leave reasonable room for complications, unexpected requirements, and the kinds of challenges that tend to reveal themselves once development begins.

How wide that range is depends on how much we know. A well-defined project might produce a relatively narrow range. An idea that’s still taking shape will naturally produce a wider one. Either way, the purpose isn’t to pretend we know exactly what the project will cost. It’s to learn enough to understand what we’re actually looking at.

That’s why the first conversation isn’t about secretly doing the entire discovery process for free. It’s about asking enough of the right questions to understand the problem. What are you trying to accomplish? Who is it for? What already exists? What are the major features? What constraints are we working within? And, perhaps most importantly, what don’t we know yet?

For a relatively straightforward project, those answers may be enough to produce a reasonable estimate and start planning the work.

For something larger or more ambiguous, the appropriate answer may simply be: we need to do some discovery first.

In that case, Discovery becomes part of the project rather than something that has to happen before it. A smaller initial engagement can be used to define requirements, develop user stories, explore architecture, establish priorities, and create the roadmap needed to estimate the larger body of work with greater confidence.

In other words, we don’t need to know everything to start a conversation. We just need to learn enough to determine what needs to happen next.

Some questions to think about before we talk.

You don’t need to have answers to all of these. They’re simply useful things to think about before our first conversation.

• What are you trying to accomplish? What should be different when this project is finished?
• What problem are you trying to solve? Why are you considering this project in the first place?
• Who is it for? Customers, employees, members, administrators, or someone else?
• What do people need to be able to do? Think about capabilities rather than pages or technical features.
• What do you already have? An existing website, application, branding, content, database, hosting, designs, or other systems?
• What isn’t working today? If you’re replacing or improving something, what are its biggest problems?
• What absolutely has to be included? Are there features or requirements you already know are non-negotiable?
• What’s nice to have? What could potentially wait for a later phase?
• Does it need to work with anything else? Existing software, APIs, payment processors, authentication systems, CRMs, analytics, etc.
• Do you have a deadline? And importantly, why is that the deadline? A product launch or event is different from “we’d like it done by June.”
• Do you have a budget or budget range in mind? Not because I want to spend all of it, but because it helps determine which solutions are realistic.
• Who makes the decisions? Who needs to review or approve the work?
• What are you worried about? Cost, timing, maintainability, usability, an existing system, a previous bad experience—this can reveal quite a bit.
• What don’t you know yet? This might actually be one of the most valuable questions.