Consultative Discovery for Complex Software Architectures

TL;DR — Discovery is not requirements gathering. It’s a structured investigation that surfaces the constraints, politics, and assumptions that will make or break the architecture. Three artifacts make it real: a question bank, a stakeholder map, and a written discovery brief that survives review.

The hardest part of any non-trivial architecture project isn’t the design. It’s the part that comes before, when the problem is still fuzzy, stakeholders haven’t agreed on what they want, and you’re trying to figure out whether the thing you’ve been asked to build is even the thing the business actually needs. This is discovery, and most engineers do it badly because they were never taught to do it.

I picked up most of what I know about discovery from consultants, not engineers. The good ones treat it as a craft with techniques and artifacts and a quality bar, the same way a senior engineer treats code review. The bad ones run two meetings, write a one-pager, and call it a kickoff. Guess which group ships systems that survive contact with reality.

This post is the discovery playbook I use for architecture work that crosses team boundaries, involves a customer-facing product change, or commits the company to a design that will be hard to reverse. If you’re being handed problems where the brief is two sentences and a deadline, this is for you.

What discovery actually is

Discovery is the structured process of turning ambiguity into a written decision-ready brief. It has three goals, in priority order. First, surface the real problem, which is almost never the stated problem. Second, map the constraints (technical, political, regulatory, financial) that will bound any solution. Third, produce an artifact that a small group of senior people can read in twenty minutes and either approve, redirect, or kill.

If your discovery doesn’t end in a written brief that someone could disagree with, you didn’t do discovery. You did stakeholder management. That’s a different thing.

The consulting world calls this “consultative selling” when used commercially, but the technique transfers directly. The book that most influenced how I do this is The Trusted Advisor by Maister, Green, and Galford. Don’t be put off by the sales framing. The mechanics of building trust and asking high-leverage questions are exactly what an architect needs.

The four phases of structured discovery

I work through four phases. They’re not rigid, but skipping any of them is how discovery quietly fails.

Phase 1, frame the inquiry

Before you talk to anyone, write down your current understanding of the problem in one paragraph. Then write the three questions you most need answered. This is your starting hypothesis. You’ll be wrong about most of it, but you need a starting point so you can notice when reality diverges from your assumptions.

Without this, every interview becomes free-form and you’ll lose track of patterns. With it, you have a baseline to compare each conversation against.

Phase 2, map stakeholders

A stakeholder map for an architecture project usually has more entries than people expect. The minimum set:

• The sponsor (whose budget pays for this)
• The accountable executive (whose neck is on the line)
• The primary product owner
• One or two engineering leads of teams that will own the result
• One engineer per upstream system you’ll integrate with
• One person from security, one from compliance if regulated
• One support or operations person who’ll carry it post-launch
• One customer-facing role (sales engineer, customer success, etc.) if external customers are involved

Each entry gets three columns: name, role, what they care about most. Update as you learn. You’re not done with discovery until you have a real answer in the third column for every row.

Phase 3, structured interviews

This is where most of the work happens. Block thirty to forty-five minutes per stakeholder. Send the question set in advance. Take written notes during the conversation. Send back a one-paragraph summary the same day, confirming what you heard. That last step is non-negotiable. It catches misunderstandings while they’re cheap to fix.

I keep a question bank organized by stakeholder type. The full set has about sixty questions. The ones I use almost every time:

For the sponsor:

1. If this project succeeds beyond your expectations, what does that look like in twelve months?
2. What’s the cost of doing nothing for another year?
3. What’s the budget reality, both numeric and political?
4. Who else needs to be convinced before this moves forward?
5. What’s the failure mode you’re most worried about?

For engineering leads of affected teams:

1. What’s the part of your system you’re most afraid we’ll touch?
2. What’s a previous integration with your team that went badly, and why?
3. If we gave you one wish for how this gets built, what would it be?
4. What’s a constraint you’re operating under that I might not know about?
5. Who on your team would catch a bad design earliest?

For ops and support:

1. What’s the most common reason this kind of system gets paged on?
2. What’s a recurring customer complaint you suspect is architectural?
3. If we shipped this tomorrow, what would break first?

Notice the shape. These aren’t “what do you want” questions. They’re “what do you know that I don’t” questions. The difference is everything.

Phase 4, synthesize and write the brief

After the interviews, you’ll have twenty pages of notes and a head full of conflicting signals. The temptation is to start designing. Don’t. Write the brief first. The brief is what makes discovery a real artifact instead of a vibes-based summary.

The discovery brief template

Here’s the template I’ve refined over the last few years. It’s deliberately structured to be readable in twenty minutes and to force you to take positions instead of hedging.

# Discovery Brief, <project name>

**Author:** <you>
**Date:** <date>
**Status:** Draft / Under Review / Approved / Rejected
**Decision required by:** <date>
**Decision owners:** <names>

## 1. Problem statement (3 sentences max)
What is the business problem, in language a non-engineer would recognize?

## 2. Why now
What changed that makes this the right quarter to tackle this?
What's the cost of waiting another six months?

## 3. Stakeholder map
| Name | Role | What they care about most | Position on this work |
|------|------|---------------------------|------------------------|
| ...  | ...  | ...                       | Supportive / Neutral / Skeptical |

## 4. Constraints
- Technical (specific systems, SLAs, data models we can't change)
- Regulatory or compliance (concrete, with the rule cited)
- Organizational (teams, timelines, headcount)
- Financial (budget envelope, ROI horizon)

## 5. Options considered (at least three)
For each option:
- One-line summary
- Effort estimate (in team-quarters)
- Primary risk
- Who would own it post-launch

## 6. Recommended option, and why
The case for, in three paragraphs. Be opinionated. If you can't take a position, you're not done with discovery.

## 7. Open questions
The things you still don't know that would change the recommendation if answered.

## 8. Decision asked of reviewers
Approve / Approve with conditions / Reject / Send back for more discovery

## 9. Appendix
- Interview notes (linked)
- Existing system diagrams (linked)
- Relevant prior ADRs (linked)

The shape matters. Sections 1 through 4 are facts. Section 5 is range. Section 6 is your judgment. Section 7 is your honesty. Reviewers can disagree with any of them, and the disagreements will be specific.

Discovery questions that actually unlock conversations

Some questions reliably produce signal beyond their literal wording. I’ve collected these over the years from consultants, therapists, and one excellent product manager I worked with for two years.

1. “Help me understand the history here.” People will tell you about three failed attempts, the political fallout, and the person who quit over it. That history is the constraint nobody documents.
2. “What would have to be true for us to not do this?” This inverts the framing and surfaces the assumptions baked into the project’s existence.
3. “If we did nothing, who would notice first?” Tells you who the real customer is, which is rarely who the org chart says it is.
4. “What’s the version of this you wish someone would propose?” People are usually willing to share their secret design preference if you ask directly.
5. “What am I not asking that I should be?” End every interview with this. The answers are gold and the question signals humility, which earns you future candor.

Common Pitfalls

• Over-interviewing. You don’t need thirty conversations. You need the right twelve. After interview eight or nine, you should be hearing the same things back. If you’re not, you haven’t framed the inquiry well enough.
• Skipping the skeptics. It’s tempting to talk only to the people excited about the project. The skeptics know where the bodies are. Talk to them first, not last.
• Writing the brief alone. You’ll fall in love with your own framing. Get one trusted peer to read a draft before it goes wide. They’ll spot the place where you hand-waved.
• Treating discovery as a phase you exit. Discovery doesn’t end at the brief. New facts surface during design and implementation. The brief is a living document until the project ships.
• Confusing consensus with alignment. Everyone smiling in the meeting does not mean alignment. Alignment is when stakeholders can independently summarize the decision back to you the same way. Test for it.

When This Goes Wrong

Stakeholders won’t make time for interviews. This is almost never a calendar problem. It’s a signal that the project isn’t actually prioritized. Escalate to the sponsor and ask whether the project should proceed at all. If you can’t get forty-five minutes from the people who’ll be affected, you don’t have a project, you have an aspiration.

Every conversation contradicts the last one. Two interpretations. Either you’re surfacing real disagreement that the org has been papering over (good, this is what discovery is for), or you’re asking leading questions and getting different answers based on framing (bad, fix the questions). The diagnostic: present the contradiction explicitly to your sponsor. If they’re surprised, it’s the first case. If they shrug, it’s the second.

The brief gets rejected. This is fine. A rejected brief is better than a half-built system. Treat the rejection as more discovery data. What did the reviewers see that you didn’t? Often the answer is a political constraint nobody told you about. Write a v2 with that constraint named explicitly.

Wrapping Up

Discovery is a learnable skill, not a personality trait. The engineers I know who do this well aren’t naturally diplomatic or unusually patient. They have a process, they trust it, and they refuse to start designing until the process is done.

If you take one thing from this post, take the discovery brief template. Use it on your next ambiguous project. The first time you ship one, you’ll feel like you’re over-engineering the kickoff. By the third one, you’ll wonder how you ever shipped without it. The brief is the artifact that turns architecture work from a series of meetings into a chain of defensible decisions.

Architecture without discovery is craft without context. Discovery without an artifact is conversation without commitment. Do both.