Asking better discovery questions

Question types and when to use them

Not every question does the same job, and the strongest discovery conversations move through several kinds in a deliberate order.

Open questions invite a wide answer and belong early, while you're still working out how things fit together. "Tell me how the current process works" or "what happens when an application is rejected" give people room to tell you what you didn't know to ask about. Probing questions chase something specific they've already said: you mentioned it takes six weeks, so where does most of that time actually go. That is usually where the real insight sits. Clarifying questions guard against the most dangerous assumption of all, that you understood when you didn't: when someone says real time, do they mean within a second or the same day, and when they say all users, how many people is that. Challenging questions test the thinking and take a little courage, like asking whether something is a legal requirement or a preference; frame them as curiosity rather than criticism and they land far better. Hypothetical questions like "what if the deadline moved a month" and scaling questions like "on a scale of one to ten, how firm are these requirements" pull out priorities and risk tolerance that direct questions miss. Run them roughly in that order: open to explore, probing to deepen, clarifying to confirm, challenging to test, then hypothetical and scaling to push on the edges.

The right question at the right time reveals what matters. Everything downstream depends on it.

Different stakeholders hold different pieces

No single person sees the whole service, so your questions have to change with who's in the room.

Policy teams hold the intent and the legal context, so ask what outcome the policy is chasing, how it might shift over the next two or three years, what legislation sits underneath, and what happens when someone fails to comply. Operational teams hold the reality: walk me through a typical day, what causes the most frustration, what workarounds you've built and why, because those workarounds describe the real problem better than any process map. Security teams hold the limits, the data classification, the threats to design against, the approved patterns and the route to sign off. Technical teams hold the current estate, the debt, the interfaces you can integrate with and the skills the team actually has. Senior leaders hold the priorities and the risk appetite, so ask what success looks like for them personally, where the political sensitivities are, whether the timeline is the announced one or the achievable one, and whether they'd rather deliver late or deliver the wrong thing. Then do the part that matters most, which is comparing the answers and looking hard at the gaps between them.

The constraints nobody mentions

The constraints that hurt you are rarely the ones in the brief. They're the ones so baked into how the organisation works that nobody thinks to say them out loud. Procurement is a common one: you can only use suppliers on a certain framework, or an existing contract ties you to a platform for three years, or anything over a threshold triggers a fresh procurement exercise, and any of those can quietly remove half your options. Organisational constraints shape how you build and run: operations works Monday to Friday only, nobody knows Kubernetes, the change board meets monthly and wants two weeks notice. Political constraints shape your appetite for risk: the minister has announced the date, the last attempt failed in public, another department tried something similar and got criticised by the NAO. Data constraints block more projects than almost anything: the data you need is owned by another department that won't share it, or it's in a format that won't migrate, or three systems hold three versions of the same thing. The way to find all of these is simple and takes discipline. For every assumption in your design, ask what could stop this being true, then go and find out rather than guess.

The Five Whys, government style

The Five Whys is the habit of asking why several times to trace a problem to its root. The textbook version stays close to the process: the report is late because the data wasn't ready, because it arrived in the wrong format, because submitters used different templates, because the guidance was ambiguous, because the person who wrote it didn't understand the data requirements. The root cause is that the data team and the guidance team weren't talking to each other. In government the chain usually runs somewhere less technical. Ask why often enough and you tend to land on something organisational, political or historical: a system can't produce the reports a minister now wants, because it was never designed for analytical queries, because that need didn't exist when it was procured, because the procurement locked in a fixed set of features with no room to change. The fix might be technical, but the lesson is about designing for change and steering clear of contracts that freeze the requirements. A few adaptations help. Go easy on blame, and ask what led to this rather than who decided this. Follow the chain across team and department boundaries even when it leaves your scope. Accept that some root causes sit outside your control, where the value is understanding the constraint well enough to design around it. And treat five as a guideline: sometimes two whys are enough, sometimes you need seven.

Real requirements or assumed ones

A surprising share of what arrives labelled a requirement is really an assumption nobody has checked. Six questions sort one from the other:

• Origin: where did this come from? If someone mentioned it in a meeting, treat it as an assumption. If it comes from legislation or user research, it's more likely real.
• Consequence: what happens if we leave it out? If the service breaks or you're in breach of the law, it's real. If it would just be nice, it isn't.
• Evidence: what proof is there that it's needed? Research, usage data and operational experience beat opinion and precedent every time.
• Specificity: can you be more precise? "User friendly" is almost always an assumption; "users can complete the form in under fifteen minutes" is something you can design and test against.
• Priority: if we could deliver only five of these twenty, which five? Forced to choose, people drop what they merely wanted.
• Stability: how likely is this to change within a year? Anything volatile is often a guess about the future dressed up as a fact.

A worked example makes it concrete. A policy team asks for real time validation against the Companies House register. Walk it through the tests: the origin is a kick off meeting, the consequence of not doing it is manually checking around twenty applications a day, which is perfectly manageable, and the evidence is an assumption that it would be more efficient. The real requirement is to confirm the company exists and is active before processing. The real time part was never needed, and that distinction matters, because a nightly batch check is simple and resilient while a live integration is complex and a dependency you then manage forever.

Half of what arrives labelled a requirement is an assumption nobody has tested yet.

Asking the hard questions well

Some of the questions that matter most are the ones that feel awkward, because they challenge an assumption or expose a risk. A few framings let you ask them honestly without putting people on the defensive. Instead of "why are you doing it that way", which sounds like an accusation, try "help me understand the thinking behind this". Instead of "this won't work", try "what would happen if", and let the other person find the problem themselves. Instead of "you're making a mistake", try "I saw something similar go badly on another project, how do we avoid that here". The devil's advocate framing lets people raise concerns without owning them: if someone wanted to attack this approach, what would they say. The premortem is better still. Imagine it's a year from now and the project has failed, what went wrong; people will tell you things in that frame that they'd never otherwise volunteer. Two more habits earn their keep. After you ask a question, stay quiet and let the silence work, because the most useful thing someone says often comes after the pause. And every so often, play back what you've heard to check it: so the main issue is X, caused by Y, with an impact of Z, have I got that right.

A discovery question bank

Experienced architects keep a personal stock of questions that have earned their place, and it helps to organise them by what you're trying to understand:

• The problem: what are we actually trying to solve rather than build, who feels it, how is it handled today, and how will we know it's fixed?
• The users: who are they really rather than who we imagine, what range of digital confidence do they have, what devices and connectivity, and what frame of mind are they in when they reach the service?
• The constraints: what's the real deadline and what's driving it, how firm is the budget, what must you integrate with, and who will run the thing in production?
• The risks: what's the worst outcome, what has failed before on similar work, what are you most uncertain about, and what would make a minister start asking questions?
• The future: how might the policy move over the next few years, is the user base set to grow or shrink, and how long is this service expected to last?

You won't ask all of these every time. Pick the ones that fit, but read the whole list before you start, so you don't skip an entire area by accident. The question you fail to ask is the constraint you fail to discover, right up until it's too late to do anything about it.

From questions to architecture insights

Asking well is only half the skill. The other half is turning the answers into something your design can use, and it starts with listening for the signals.

When someone says the data arrives in different formats, that points to a transformation layer. When they say usage spikes every March, that points to scaling that can flex. When they say the team is three people, that points to an architecture three people can actually run. Capture every constraint you find and mark it hard or soft: a hard constraint you can't move, and it draws the edges of your solution space; a soft one you can move with good reason, and it shapes the choices inside those edges. Write down the assumptions too, yours and everyone else's, and decide how each will be tested, because "we assume the Companies House API can handle our volume" is something you can check rather than quietly hope holds. Map the dependencies early, since that's where projects come apart: a dependency on another team's system is a risk, one on a system with no API is a bigger risk, and one on a system being switched off is a problem to raise now. Then step back after each session and pull it together: what's the problem, who's affected, what constrains us, what risks are surfacing, what's still open. The best architects connect these threads, so they can see how the reporting need shapes the data model, how the size of the team shapes the deployment, and how the security classification flows through to hosting, then cost, then the business case.

Gathering the answers is half the skill. Connecting them into a design is the other half.