Discovery Questions for Understanding an Unfamiliar Business Domain

Welcome back. In the previous lesson, you created a stakeholder-specific elicitation plan: who to involve, what each person can credibly contribute, the technique to use, and who confirms key decisions. That plan now becomes practical. For each session, you need a question guide that helps you uncover the business reality without treating the meeting as an unstructured conversation or prematurely designing a solution.

This lesson shows how to prepare a structured discovery-question set for an unfamiliar domain. You will learn to move from a problem statement and an information gap to focused, neutral questions about goals, workflow, rules, data, exceptions, risks, and success measures. The result is an interview guide that can be reused in a portfolio case study and defended in a Technical Business Analyst or Requirements Analyst interview.

---

A discovery guide is an evidence plan, not a list of questions

Suppose a finance sponsor says:

“We need an employee expense-claim portal. Reimbursements are taking too long.”

If you are new to the expense-management domain, it would be tempting to ask, “What features should the portal have?” That question assumes both the solution and the real problem. Delays might instead arise from incomplete receipts, unclear policy rules, slow manager approval, finance workload peaks, or errors when claim data moves into payroll.

A better discovery objective is:

Understand where and why reimbursement delays occur, which users and rules are affected, what evidence establishes the baseline, and what outcome an improvement must achieve.

Your question guide should be designed to fill specific information gaps. Each major question needs four properties:

Element	Meaning	Example
Information goal	What you need to understand or decide	Identify the largest contributors to claim-processing delay
Primary question	An open, neutral prompt	“Please walk me through the most recent claim that took longer than expected.”
Probes	Follow-ups that uncover detail, evidence, and exceptions	“What happened after submission?” “Who was involved?” “How long did each stage take?”
Expected evidence	The artifact, fact, metric, rule, or model the answer should support	Current-state process, approval rule, delay baseline, or exception scenario

This structure keeps questions purposeful. It also prevents a familiar failure mode: gathering many opinions but leaving the session without enough information to draw a process model, document a rule, or distinguish an assumption from a fact.

A useful rule is:

Ask questions that help you create or validate an analysis artifact.

For example:

• A process model reveals gaps about triggers, sequence, handoffs, decisions, waiting time, and exceptions.
• A user story reveals gaps about user roles, desired outcomes, and business value.
• A context diagram reveals gaps about actors, external systems, inputs, outputs, and ownership.
• A decision table reveals gaps about conditions, rule combinations, and outcomes.
• A success-measure definition reveals gaps about baseline, calculation, target, data source, and reporting frequency.

This approach is particularly helpful in an unfamiliar industry. You do not need to arrive as the domain expert; you need to arrive knowing which evidence must exist before you can responsibly define a requirement.

---

Start with a question architecture

A discovery guide should have a reliable structure, but it should not be a rigid script. The previous elicitation plan tells you who to speak with and why. The guide tells you what information to seek from that specific participant.

For a 30 to 45-minute interview, use a small number of primary questions, often six to ten, with probes nested beneath them. A participant may answer several planned questions while explaining one recent incident. Listen, record the evidence, and skip questions already answered rather than reading mechanically from the page.

The following architecture works across domains, from automotive operations to retail, health services, fintech, internal platforms, and customer-support processes.

Discovery area	What you are trying to learn	Neutral question patterns
Business outcome	Why the change matters and what success means	“What outcome are we trying to improve?” “What would be different if this problem were solved?”
Users and roles	Who performs, receives, approves, supports, or is affected by the work	“Who is involved from start to finish?” “What responsibility does each role have?”
Recent real workflow	What actually happens, rather than what policy says should happen	“Tell me about the last time this occurred.” “What happened first?”
Triggers and timing	What starts the process, when it happens, and what deadlines apply	“What event starts this work?” “Are there cut-off times, peak periods, or service targets?”
Rules and decisions	The conditions that determine different paths or outcomes	“What determines whether this is approved, rejected, or escalated?”
Information and data	Inputs, outputs, definitions, sources, quality, and ownership	“What information do you need to make that decision?” “Where does it come from?”
Systems and handoffs	Tools used, integrations, manual transfers, and ownership changes	“Which systems are used at this step?” “How does information move to the next team?”
Exceptions and workarounds	Edge cases, failures, rework, and informal practices	“When does the normal path not work?” “What do you do then?”
Measurement and evidence	Baseline, frequency, impact, and available reports	“How do you know this is a problem?” “Which report or record supports that?”
Scope, constraints, and risk	Boundaries, dependencies, policies, and concerns	“What must remain unchanged?” “What could prevent this from working?”

The categories are prompts for analysis, not a demand to ask every question in every session. A sponsor interview may concentrate on business outcome, priority, scope, and success metrics. A frontline interview may concentrate on a recent real workflow, system friction, exceptions, and workarounds. A technical lead may focus on data ownership, interfaces, constraints, and operational risk.

---

Ask for a real incident before asking for a general process

People often describe an idealized process when asked, “How does expense reimbursement work?” They may omit rework, informal communication, waiting time, and unusual cases because those details are routine to them.

A more reliable opening prompt is:

“Please take me through the most recent expense claim you submitted or processed, from the moment the expense occurred until the claim was reimbursed.”

This is an experience-based question. It anchors the conversation to observable events and helps the participant remember details. Once the real incident is understood, you can ask whether it was typical and explore variations.

General statement versus discoverable evidence

Consider the difference between these question styles.

Weak or risky question	Why it is weak	Better discovery question
“Do you need a portal to submit claims?”	Assumes a portal is the answer and invites a simple yes or no	“What makes submitting a claim difficult today?”
“Is manager approval causing the delay?”	Suggests the cause before evidence exists	“Where does a claim usually wait longest, based on your experience?”
“Does the process work well?”	“Well” is undefined and the question is too broad	“What was the easiest and most difficult part of the last claim you handled?”
“Why did you not approve it quickly?”	Can sound accusatory	“What information or conditions do you need before you can approve a claim?”
“Do all employees follow the policy?”	Encourages an unreliable generalization	“What are the most common reasons a claim cannot be processed as submitted?”
“How long does approval take?”	May produce an unverified estimate	“Can we look at a recent claim or report to identify the submission and approval times?”

The aim is not to avoid directness. It is to avoid embedding an untested conclusion in the question.

When you need the rationale behind a rule or practice, a direct “why” can be useful but may make a participant defensive. Prefer conversational alternatives:

• “What problem is this check intended to prevent?”
• “What happens if that information is missing?”
• “What makes that condition important?”
• “How did the team arrive at this rule?”
• “What would be the consequence of handling it differently?”

---

Build questions in layers: primary prompt, probes, and evidence check

A useful interview guide moves from easy, concrete questions into deeper analysis. It should not begin with difficult debates about policy or blame.

The NN/g interview sequence below captures the practical rhythm: define what you need to learn, prepare and pilot a guide, begin with easy prompts, establish rapport, and probe the details that matter.

For the expense-claim scenario, a 45-minute frontline-employee interview guide could look like this.

Question area	Primary question	Useful probes	Evidence to capture
Context and role	“Please describe your involvement in submitting expense claims.”	“How often do you submit them?” “What types of expenses do you claim?”	User role, frequency, claim types
Recent incident	“Tell me about the most recent claim you submitted.”	“What prompted it?” “What did you do first?” “What happened after you submitted it?”	Trigger and real workflow sequence
Inputs and systems	“What information and documents did you need?”	“Where did you obtain each item?” “Which systems, forms, or spreadsheets did you use?”	Data inputs, source systems, manual work
Friction	“Which part of that experience required the most effort?”	“What made it difficult?” “How often does that occur?” “What do you do to get around it?”	Pain points, frequency, workarounds
Status visibility	“How did you know where your claim was after you submitted it?”	“What information was available?” “What information was missing?” “Who did you contact?”	Status gaps, support contacts, communication needs
Exceptions	“Can you recall a claim that did not follow the usual path?”	“What was different?” “Who resolved it?” “What happened to the claim?”	Exception path, escalation, rework
Desired outcome	“If one part of this experience could become easier, what would make the greatest difference?”	“What result would that give you?” “What must not change?”	User need, outcome, potential scope boundary
Validation	“Have I understood your experience correctly?”	Summarise the workflow and ask for correction	Confirmation of notes and unresolved questions

Notice what this guide does not ask: “What screen should we build?” A user can identify outcomes and problems, but interface design should follow only after the workflow, rules, information needs, and constraints are understood.

Add specialist question modules

Use the same core structure, then add a small module that matches the participant’s knowledge and authority.

For a process owner or finance operations lead

Focus on end-to-end ownership, volume, KPIs, and decision paths.

• “What events begin and end the reimbursement process?”
• “Which teams own each stage, and where do handoffs occur?”
• “What are the normal processing-time expectations?”
• “At which stages do claims wait, return for correction, or escalate?”
• “How are urgent, international, policy-exception, or high-value claims handled?”
• “Which measures do you review regularly, and how are they calculated?”
• “Which part of the process creates the greatest operational cost or risk?”

For a policy owner or compliance representative

Focus on policy intent, control points, exceptions, and retention.

• “Which policy rules determine whether an expense is eligible?”
• “What evidence is mandatory, and are there different rules by expense type or amount?”
• “Who is authorized to approve exceptions?”
• “What audit evidence must be retained, for how long, and by whom?”
• “Which personal, financial, or sensitive data require restricted access?”
• “Are there regulatory, tax, or geographic rules that affect processing?”

For a technical lead or data owner

Focus on systems, interfaces, information quality, and practical constraints.

• “Which systems create, store, approve, and pay claim information?”
• “Which system is the authoritative source for employee, cost-centre, and reimbursement status data?”
• “How does information move between systems?”
• “Which transfers are automated, scheduled, or manually performed?”
• “What data-quality problems occur today, such as duplicate claims, missing receipts, invalid cost centres, or delayed updates?”
• “What technical, security, or integration constraints would limit possible changes?”
• “What monitoring or audit information exists when a claim fails to move between systems?”

For a sponsor or accountable decision-maker

Focus on the intended business result and the decision boundaries.

• “What business problem led to this initiative?”
• “Who is most affected, and what is the impact on them and the organization?”
• “What baseline evidence supports the urgency of the problem?”
• “How will we measure success after the change?”
• “What target, time frame, and reporting approach would make the initiative successful?”
• “Which outcomes are essential for the first release, and which can wait?”
• “What constraints are fixed: budget, deadline, policy, staffing, or technology?”
• “Who makes final decisions if stakeholder needs conflict?”

---

Use a question bank as a starting point, not an interview script

A generic checklist reduces the risk of missing an important category in an unfamiliar domain. It must still be tailored to the stakeholder, initiative, and available evidence.

When adapting a generic question, make it specific enough to uncover evidence:

Generic prompt	Tailored question for the scenario
“Who are your customers?”	“Who receives the outcome of the expense-claim process: employees, managers, finance, payroll, or another group?”
“What systems do you use?”	“During the last claim, which system did you use to submit receipts, check status, request approval, and receive payment?”
“How do you measure success?”	“Which measure shows whether reimbursement delay is improving: calendar days to payment, percentage processed within target, rework rate, or employee status-enquiry volume?”
“What are the risks?”	“What could go wrong if claims were processed faster but policy checks were weakened?”

This tailoring is what turns a list of generic prompts into business analysis.

---

Prepare your guide as a working document

A good guide is short enough to use during a conversation and detailed enough to prevent missed evidence. Use a format like the one below.

Session information	Example
Initiative	Reduce expense-claim reimbursement delays
Stakeholder	Finance Operations Lead
Session objective	Understand the current process, key delay points, approval rules, exception paths, and available baseline measures
Duration	45 minutes
Evidence already reviewed	Expense policy, monthly reimbursement report, sample claim records, support tickets
Artifacts to update	Current-state process sketch, decision log, assumptions log, KPI definition, open-points list

Then document each question in the guide.

No.	Information goal	Primary question	Planned probes	Expected evidence or follow-up
1	Establish scope	“Which claim types are included in this process, and which are handled differently?”	“Are travel, local conveyance, equipment, and client expenses different?”	In-scope and out-of-scope candidates
2	Understand workflow	“Please walk me through a standard claim from submission to payment.”	“Who owns each step?” “What system is used?”	Current-state process steps and handoffs
3	Identify bottlenecks	“Where do claims spend the most time waiting?”	“How do you know?” “Is it consistent or seasonal?”	Delay hypotheses and report sources
4	Capture rules	“What determines the approval path for a claim?”	“Does amount, cost centre, employee grade, or expense type matter?”	Candidate decision-table conditions
5	Find exceptions	“Which claims cannot be processed through the normal path?”	“What causes that?” “Who resolves it?”	Exception and escalation paths
6	Define success	“What measurable result would show that this initiative worked?”	“What is the current baseline?” “What target is realistic?”	KPI definition and target
7	Identify constraints	“What must remain unchanged even if we redesign the workflow?”	“Which policy, audit, payroll, or integration constraints apply?”	Constraints and dependencies
8	Confirm understanding	“What have I missed that would materially affect the process or outcome?”	“Who else should validate these findings?”	Open points and additional stakeholders

During the interview: listen for four kinds of statements

Do not write every answer as though it were a confirmed requirement. Classify it while taking notes.

What you hear	How to record it	Example
Verifiable fact	Record source and evidence	“The report shows 38% of claims exceeded the five-day target last month.”
Business rule	Capture condition and outcome, then validate owner	“Claims above a defined amount need an additional approval.”
Assumption or belief	Mark it for validation	“Most delays probably happen because managers are busy.”
Open point	Record the question, owner, and due date	“Confirm whether payroll can accept daily reimbursement batches.”

This discipline prepares directly for the next lesson, where you will extract assumptions, constraints, risks, and dependencies from discovery notes.

---

A short quality review before you use the guide

Before the session, review the guide against these standards:

• Every primary question supports a stated discovery objective.
• Questions are open enough to invite explanation, but focused enough to produce usable evidence.
• You ask about a recent real event before asking for general opinions.
• Each major category has relevant probes for timing, participants, inputs, decisions, exceptions, and impact.
• You have separated stakeholder needs from proposed solution features.
• You have avoided leading, double-barrelled, accusatory, and jargon-heavy wording.
• You know which answers require documentary, data, or stakeholder confirmation.
• You have reserved time for a summary and correction at the end.
• You know what artifact you will update after the conversation.

For your portfolio practice, take the service-request status-visibility scenario from the prior lessons, or use the expense-claim scenario above. Prepare one 45-minute guide for a frontline user and one 30-minute guide for the sponsor. Reuse the same discovery categories, but make the questions, probes, and expected evidence appropriate to each person’s authority and knowledge.

---

Key takeaways

A discovery-question guide is a structured way to obtain evidence in an unfamiliar domain. Begin with a focused learning objective, then derive questions from the information gaps in the artifacts you need to create: processes, context models, rules, data definitions, KPIs, and scope boundaries.

Use open prompts about a recent real incident to uncover actual work. Follow with probes that clarify sequence, timing, decisions, data, exceptions, and impact. Tailor the guide to the stakeholder: frontline participants reveal day-to-day reality, specialists explain rules and constraints, technical stakeholders clarify systems and data, and sponsors confirm outcomes, priorities, and decisions.

Next, you will turn the notes produced by these conversations into a disciplined analysis of assumptions, constraints, risks, and dependencies.