Consultative Discovery for Software Projects, Beyond the Requirements Doc

TL;DR — Stated requirements describe a solution someone already imagined, not the problem / discovery is the practice of working backwards to the actual problem / structure beats charisma — a good framework gets better answers than a smart improviser.

A few years ago I spent six weeks building exactly what a client asked for. Clean architecture, good tests, on time, on budget. They hated it. Not the implementation — the thing itself. It turned out the feature they’d asked for was their best guess at solving an operational problem two layers deep, and we’d faithfully delivered their guess instead of the solution to the actual problem. The retro on that project changed how I run discovery.

This post is about consultative discovery: the structured conversation you have with a stakeholder, client, or even an internal product partner before you commit to building anything. It’s a skill that compounds. Get it right and you save weeks of misdirected work. Get it wrong and you end up in the same spot I was in — clean code, sad customer.

This is the second post in my December leadership series, following last week’s post on the senior-to-lead transition. The rest of the month gets more tactical from here.

Why Stated Requirements Lie

When someone says “we need a dashboard that shows X, Y, and Z,” they have almost always done some private work to get to that statement. They observed a problem, formed a mental model of the cause, sketched a solution in their head, and then translated that solution into a request. By the time it reaches you, three layers of inference have happened, and any one of them could be wrong.

A few common patterns I see:

• Solution-shaped problems. The stakeholder describes the answer they already imagined, not the question. “We need a Slack integration” really means “we don’t know what’s happening in operations and we want fewer surprises.”
• Symptom-shaped problems. They describe the pain they’re feeling without context for what’s causing it. “Reports are slow” might mean the query is slow, or it might mean someone is exporting to Excel every morning to do work the reports should do for them.
• Authority-shaped problems. Someone senior said something offhand, and now it’s a project. The actual urgency and importance are far lower than the request suggests, but nobody wants to push back.

The job in discovery is to peel back these layers without making the stakeholder feel interrogated. Rob Fitzpatrick’s The Mom Test is the canonical reference here, mainly aimed at startup founders but the techniques translate cleanly to internal stakeholder conversations. The core idea: stop asking about your idea, start asking about their life.

The Four-Phase Discovery Conversation

I run discovery in four phases. Not always in one session — for bigger projects this might span three or four conversations across two weeks — but always in this order.

Phase 1: Context and Cast

Start with people and processes, not problems. Who’s involved? Who’s affected? What does the current workflow look like, end-to-end, with names of real teams and real tools? You’re building a map of the territory before deciding where to dig.

Questions that work here:

• Walk me through what happens today, from the moment X starts until it ends
• Who else is involved that we haven’t mentioned?
• Where does this currently live — what tools, what systems, what spreadsheets?
• Who would be unhappy if this changed, and why?

The last one is underrated. Every operational process has someone who depends on its current shape, often invisibly. Surface them now or be surprised by them later.

Phase 2: Pain and Frequency

Once you have the map, you can ask about pain. The trick is to anchor pain in concrete recent events, not hypothetical scenarios. Hypotheticals invite confabulation; recent events invite memory.

• Tell me about the last time this caused a problem. What happened?
• How often does that happen? Once a week? Once a quarter?
• What did you do about it? Workaround, escalation, just live with it?
• If we did nothing, what’s the worst thing that happens in the next six months?

The frequency question is critical. A painful problem that happens twice a year is not worth a six-week build. A mildly annoying problem that happens forty times a day is probably worth a quarter of effort.

Phase 3: Jobs and Outcomes

Now you can start translating pain into desired outcomes — without jumping to solutions. This is where jobs-to-be-done thinking helps. Clayton Christensen’s classic framing, “what job is the customer hiring this product to do,” forces you to think in terms of outcomes rather than features.

• When this is solved, what does a good day look like?
• What’s a measurable signal we’d see if this got better?
• What would you be able to do that you can’t do today?
• What would you stop doing that you currently have to do?

The “stop doing” question is the goldmine. Most operational improvements are about removing work, not adding features. If you can quantify the removed work, you have a business case.

Phase 4: Constraints and Sacred Cows

Last, you ask about the boundaries of the solution space. What’s off limits? What’s already been tried? What’s politically charged?

• What have you already tried, and why didn’t it work?
• Are there systems we shouldn’t touch, regulations we need to respect, integrations that must keep working?
• Who needs to bless this, and what would make them say no?
• What’s the budget — not just money, but attention, headcount, calendar weeks?

This phase is where you learn whether the project is actually feasible inside the political and technical reality of the organization. Skipping it produces beautifully designed solutions that get killed in steering committee.

A Reusable Discovery Template

Here’s the template I bring to most discovery sessions. I share it with the stakeholder beforehand so they can think before we meet. Sharing it isn’t cheating — pre-loaded answers are still real answers, and the conversation goes deeper when they’ve had time to reflect.

# Discovery Session — <Project Name>

## Participants
- Stakeholder(s):
- Engineering:
- Product / Design:
- Date:

## 1. Context
- Current workflow (end-to-end):
- Systems and tools involved:
- People and teams involved:
- Recent changes to this area:

## 2. Pain
- Most recent painful incident (when, what happened):
- Frequency of pain (per day / week / month):
- Current workaround:
- Cost of doing nothing (next 6 months):

## 3. Outcomes
- Definition of "good" outcome (in user-visible terms):
- Measurable signal of success:
- Things people will stop doing:
- Things people will start being able to do:

## 4. Constraints
- Already tried (and why it didn't stick):
- Off-limits systems / regulations / integrations:
- Decision-makers and sign-off path:
- Budget — money, headcount, calendar weeks:

## 5. Open Questions
- Things we need to investigate before scoping:
- Assumptions we're making that need validation:

## Next Steps
- Owner:
- Date:
- Output: <RFC / spike / proposal / next discovery session>

This template doesn’t replace the conversation. It scaffolds it. The most useful parts often come from the gaps — the section the stakeholder couldn’t fill in, the question that surfaced a disagreement between two people in the room, the constraint that nobody had written down.

What to Do With What You Learn

Discovery output should not become a slide deck. It should become one of three artifacts:

1. A scoped problem statement — one or two paragraphs describing the problem in the stakeholder’s language, with the success criteria you’ve agreed on. This is the contract.
2. An RFC or design doc — if the solution space is clear enough, you can go straight here. I’ll cover RFC patterns in a later post this month.
3. A spike or prototype request — if the solution space is genuinely uncertain, the next step isn’t a doc, it’s a small build to learn.

Whichever artifact you produce, send it back to the stakeholder within a week. The half-life of context from a discovery session is short. If you wait three weeks to produce the writeup, half the nuance is gone and you’ll have to do the session again, badly.

Common Pitfalls

Leading the witness. “So it sounds like what you need is a dashboard, right?” You just put the answer in their mouth. Stay neutral, especially when you think you already know the answer.

Confusing volume with signal. The loudest stakeholder in the room is not necessarily the most representative one. After every group session, do one-on-one follow-ups with the quieter people. The disagreements you’ll hear there are usually the real insight.

Underweighting current workarounds. When someone says “we just deal with it manually,” dig in. Manual workarounds are perfect product spec material — they tell you exactly what the solution needs to automate and exactly how much effort it currently costs.

Promising before you understand. Avoid the temptation to commit to a delivery date in the discovery session itself. “I want to make sure we get the problem right before I scope this” is a perfectly professional thing to say. Stakeholders respect it more often than not.

Skipping the writeup. A discovery conversation without a written artifact is a conversation, not discovery. Write it up, share it back, get explicit agreement on the problem statement. If you can’t get agreement on the problem, you definitely can’t get agreement on the solution.

Wrapping Up

Consultative discovery is one of those skills that’s invisible when it works and catastrophic when it doesn’t. Get it right and the project feels obvious, almost easy. Get it wrong and you spend the next six months relitigating scope. The good news is it’s learnable, and the framework above is roughly what I’ve converged on after a lot of failed projects.

Next week I’ll get into specific question patterns — the discovery questionnaire I actually use — including the Mom Test moves I borrow most often.