Discovery is one of the most important stages of Business Analysis.
It is where a Business Analyst begins to understand why an initiative exists, what problem needs to be solved, who is affected, what the current environment looks like, and what a successful future state should achieve.
Poor discovery often leads to poor requirements.
If the underlying problem has not been properly understood, even perfectly documented requirements can lead to the wrong solution.
A good Business Analyst therefore does more than ask stakeholders:
“What do you want the new system to do?”
Instead, they ask structured questions that uncover the problem, context, stakeholders, processes, constraints, priorities and desired outcomes.
Here are 10 questions every Business Analyst should consider during discovery.
1. What Problem Are We Actually Trying to Solve?
This should be one of the first questions asked.
Projects often begin with a proposed solution:
“We need a new CRM.”
“We need to automate this process.”
“We need a new reporting platform.”
“We need to replace the existing system.”
But these statements describe solutions, not necessarily the underlying problem.
The Business Analyst needs to understand:
- What isn’t working today?
- Who experiences the problem?
- How often does it occur?
- What impact does it have?
- Why does it need to be addressed now?
- What evidence demonstrates that the problem exists?
For example:
Proposed solution:
“We need a new customer portal.”
After investigation, the underlying problem might be:
Business problem:
“Customers cannot access real-time information and are contacting the service centre for routine enquiries, increasing operating costs and response times.”
That is a much stronger starting point.
BA Tip
Try to express the problem as:
Current Situation + Problem + Business Impact
If stakeholders cannot clearly explain the problem, more discovery is probably required.
2. Why Does This Need to Change Now?
Understanding the problem is important.
Understanding why the organisation is acting now is equally important.
There may be a specific trigger:
- Regulatory change
- Expiring technology
- Increasing operating costs
- Customer complaints
- Business growth
- Organisational restructuring
- New strategic priorities
- Cybersecurity concerns
- Vendor contract expiry
- Poor system performance
The answer helps establish the business driver behind the initiative.
For example:
“The current system isn’t ideal.”
is very different from:
“The vendor will stop supporting the current platform in 12 months.”
The second creates a clear timeframe, risk and business imperative.
BA Tip
Ask:
“What happens if we do nothing?”
This is often one of the most powerful discovery questions.
It helps expose the real cost, risk and urgency of the problem.
3. What Does Success Look Like?
Stakeholders often know what they dislike about the current environment but have not clearly defined what successful change should achieve.
Ask:
“If this initiative is successful, what will be different?”
Possible answers might include:
- Processing time reduced
- Fewer manual activities
- Improved customer satisfaction
- Better reporting
- Reduced operational cost
- Improved compliance
- Increased automation
- Better data quality
- Fewer errors
- Improved employee experience
Where possible, turn these into measurable outcomes.
Instead of:
“Improve processing.”
consider:
“Reduce average processing time from five business days to two.”
This creates a basis for later evaluating whether the solution actually delivered value.
BA Tip
Don’t only ask what the solution should do.
Ask what the organisation should be able to achieve because of it.
4. Who Are the Key Stakeholders?
Once the problem is understood, determine who needs to be involved.
Ask:
“Who understands this problem, who is affected by it, and who has authority over the outcome?”
Consider stakeholders across:
Business
Process owners, managers, operational teams and SMEs.
Technology
Architects, developers, integration teams, data teams and support.
Governance
Security, privacy, legal, risk, compliance and finance.
Leadership
Sponsors, executives and steering committees.
External
Customers, suppliers, regulators, vendors and partners.
Missing the right stakeholder during discovery can result in missing critical requirements later.
BA Tip
Ask every stakeholder you interview:
“Who else should I speak to?”
It’s a remarkably effective way to discover stakeholders you may have overlooked.
5. How Does the Current Process Work?
Before designing the future, understand the present.
Ask stakeholders to walk through the process step by step.
For example:
Trigger → Activity → Decision → Handover → System → Output
Explore:
- Who performs each activity?
- What information is required?
- Which systems are used?
- Where are decisions made?
- Where do delays occur?
- Where is data entered manually?
- What happens when something goes wrong?
- What exceptions exist?
Often the documented process and the actual process are very different.
BA Tip
Don’t ask only:
“What is the process?”
Ask:
“Can you show me what you actually do?”
Observation can reveal workarounds and pain points that interviews alone may not uncover.
6. What Are the Biggest Pain Points?
Once the current process is understood, explore where the problems occur.
Ask:
“What frustrates you most about the way this works today?”
Typical pain points include:
- Duplicate data entry
- Spreadsheet dependency
- Manual approvals
- Slow processing
- Poor system integration
- Inconsistent processes
- Limited reporting
- Data quality problems
- Unclear ownership
- Excessive handoffs
- System limitations
Then go deeper.
If someone says:
“The process takes too long.”
ask:
“Where specifically does the delay occur?”
Then:
“Why does that delay occur?”
The objective is to move from symptoms to root causes.
BA Tip
Don’t assume every pain point requires a technology solution.
Sometimes the underlying issue is process, policy, governance, capability or unclear responsibility.
7. What Business Rules and Constraints Must We Consider?
Projects rarely operate without boundaries.
Ask stakeholders about:
Business Rules
What policies or conditions govern how the process operates?
For example:
Purchases above $50,000 require executive approval.
Regulatory Requirements
Are there legal, privacy, security or compliance obligations?
Technology Constraints
Does the solution need to integrate with existing platforms?
Budget Constraints
Is there a defined investment limit?
Time Constraints
Is there a regulatory deadline or contract expiry?
Organisational Constraints
Are there resourcing, capability or change-readiness limitations?
Understanding constraints early prevents unrealistic requirements and solution designs.
BA Tip
Ask:
“What can we not change?”
Sometimes this reveals more useful information than asking what stakeholders want to change.
8. What Information and Data Are Required?
Data is often overlooked during early discovery.
Ask:
- What information does the process require?
- Where does the data come from?
- Who owns it?
- Is it reliable?
- Is information duplicated?
- What reports are required?
- What decisions depend on this information?
- How long must data be retained?
- Are there privacy or security considerations?
For system implementations, poor understanding of data can create significant problems later.
For example, replacing a system may require:
Data Migration → Data Cleansing → Mapping → Validation → Ownership → Governance
These requirements need to be understood early.
BA Tip
Whenever a stakeholder says:
“The system should automatically…”
ask:
“Where will the information required to do that come from?”
That question frequently uncovers hidden dependencies.
9. What Should the Future State Look Like?
Discovery should not focus entirely on current problems.
The BA also needs to understand the desired future.
Ask:
“If we could redesign this from the beginning, how should it work?”
Explore:
- What should be automated?
- What should remain manual?
- What should users be able to do?
- What information should be available?
- Which approvals are genuinely necessary?
- Which processes could be simplified?
- What customer experience is desired?
- What capabilities does the organisation need?
The objective is not to design the final solution during discovery.
It is to establish a clear future-state direction.
A useful structure is:
Current State → Pain Points → Future State → Gap → Requirements
BA Tip
Separate needs from solutions.
A stakeholder may say:
“We need Salesforce.”
The actual need might be:
“We need a single view of all customer interactions.”
That distinction keeps solution options open.
10. What Are the Priorities?
Discovery usually generates more ideas and requirements than can realistically be delivered.
Prioritisation is therefore essential.
Ask:
“If we could only solve three things, what would they be?”
This forces stakeholders to think about relative importance.
Requirements can later be classified using techniques such as MoSCoW:
Must Have — essential for success.
Should Have — important but not essential for initial delivery.
Could Have — valuable if time and resources allow.
Won’t Have Now — deliberately deferred.
Other factors may include:
Business Value | Risk | Cost | Urgency | Dependency | Regulatory Need
BA Tip
When everything is described as a priority, nothing is actually prioritised.
Ask stakeholders to explain why something is important.
Don’t Stop at the First Answer
The quality of discovery depends not only on the questions but also on the follow-up questions.
Some of the most powerful Business Analysis questions are extremely simple:
Why?
What happens next?
Who does that?
How often?
What happens if it fails?
Can you give me an example?
How do you know?
Who else is affected?
Is that a requirement or a preferred solution?
What would happen if we didn’t do this?
A skilled Business Analyst learns when to keep exploring rather than accepting the first response.
Turning Discovery into Structured Analysis
Discovery should produce more than meeting notes.
The information gathered needs to be organised into useful Business Analysis artefacts.
Depending on the initiative, these might include:
- Problem Statement
- Business Objectives
- Stakeholder Register
- Current-State Process Maps
- Pain Point Analysis
- Root Cause Analysis
- Business Rules
- Assumptions and Constraints
- High-Level Requirements
- Future-State Vision
- Gap Analysis
- Risks and Dependencies
- Requirements Register
- Prioritised Opportunities
The goal is to move from:
Conversations → Evidence → Analysis → Shared Understanding → Requirements
That is where Business Analysis adds real value.
A Simple Discovery Framework
The 10 questions can be organised into a practical framework:
WHY
- What problem are we solving?
- Why does it need to change now?
- What does success look like?
WHO
- Who are the stakeholders?
CURRENT STATE
- How does the current process work?
- What are the pain points?
CONTEXT
- What rules and constraints apply?
- What information and data are required?
FUTURE STATE
- What should the future state look like?
PRIORITY
- What matters most?
This gives Business Analysts a simple structure they can take into almost any discovery engagement.
Discovery Is About Creating Clarity
Good discovery is not about asking hundreds of questions.
It is about asking the right questions, listening carefully, challenging assumptions and connecting information from different stakeholders.
An effective Business Analyst should leave discovery with a much clearer understanding of:
Why are we doing this?
What problem are we solving?
Who is affected?
How does it work today?
What needs to change?
What constraints exist?
What does success look like?
What should we prioritise?
When these questions have clear answers, the organisation is in a much stronger position to move into detailed requirements, solution design and delivery.
And that is ultimately the purpose of discovery:
Create enough clarity to make better decisions about what happens next.
Build Your Discovery & Stakeholder Skills
AgileBA’s Business Analysis training helps aspiring and practising Business Analysts develop practical skills in discovery, stakeholder engagement, workshop facilitation, requirements elicitation and process analysis using realistic business scenarios, templates and structured techniques.