Business Analyst / Product Owner interview preparation
Use this guide to prepare for Business Analyst / Product Owner interviews, with a focus on elicitation plan, business analysis, current state. Explain your reasoning and connect it to experience you can substantiate.
These preparation themes come from the questions in this role’s bank. They help you organise your examples; individual employers may assess different things.
Elicitation plan
Business Analysis
Current state
Business vs solution need
Ambiguity
NFR elicitation
A useful preparation sequence
Choose your experience level and the round you expect.
Answer one question in your own words before opening its guide.
Compare your reasoning, evidence and trade-offs; adapt the answer to your experience.
Practise the follow-up, then revisit one answer you want to improve.
Representative questions and answer guidance
Open any question to read its answer. The complete guidance is included on this page.
Technical · Mid-level
1. How do you prepare for a requirements workshop?
Answer guide
Good workshops are won before the day. I start with the decision or outcome the session must produce and the scope boundary. Then I identify who needs to be in the room, where their interests conflict, and who has authority to decide. I read existing process maps, tickets and earlier documents so my questions are sharper, and I pick methods to suit the topic, such as walkthroughs, prototypes or ranking exercises. I also plan how outcomes will be confirmed, for example a written summary within a day with named owners for open points.
What this question explores
Whether you prepare with a clear purpose, stakeholder insight and a plan to confirm outcomes, rather than just booking a room.
Common mistakes
They send a generic agenda and expect requirements to emerge from open discussion on the day.
They invite everyone but ignore decision authority, so conflicts surface late and nothing is settled.
Practise a follow-up
How would you handle two senior stakeholders who disagree openly during the session?
When would you choose interviews or observation over a workshop?
2. How would you evaluate a business analyst whose documentation is excellent but repeatedly misses important operational needs?
Answer guide
I would review the analyst's stakeholder coverage, evidence collection, exception analysis and validation practices, since excellent documents can sit on thin evidence. Then I check whether the artefacts support real decisions and outcomes. I would coach through representative operational cases, for example shadowing frontline staff, and measure improvement in missed needs and rework over a few months. Assessing document polish alone rewards the wrong thing, and the analyst would keep producing handsome documents that miss the point.
What this question explores
Whether you assess an analyst on evidence, coverage, validation and decision value rather than document quality, and coach with measurable improvement in missed needs.
Common mistakes
They praise the analyst for polished documents and take no action on the missed operational needs.
They criticise the analyst without examining stakeholder coverage or validation, offering no practical coaching.
Practise a follow-up
Which indicators would you track to show fewer missed needs?
How would you give this feedback to an analyst proud of their documentation?
3. Users describe a workaround as a requirement. How do you find the real need?
Answer guide
A workaround is evidence of a need that the current process fails to meet, but it is not the need itself. I would watch the work being done, then ask what outcome the workaround protects, what goes wrong without it and how often. For example, staff keeping a private spreadsheet of approvals may really need visibility of pending items, which a report could give more safely. Once I understand the outcome, I explore alternatives with users, weighing constraints such as policy and data ownership, and I confirm the redefined requirement with them before it goes into scope.
What this question explores
Whether you dig beneath a stated solution to the underlying outcome by observing work and testing alternatives with users.
Common mistakes
They copy the workaround into the requirements list as stated and build a faster version of a broken process.
They dismiss the users' habit as bad practice without understanding what problem it solved.
Practise a follow-up
How do you handle users who resist giving up a workaround they trust?
What observation technique would you use when the workflow spans several teams?
4. How do business, stakeholder and solution requirements differ?
Answer guide
Think of them as three levels of detail. Business requirements say why the organisation is acting, for example reduce customer onboarding time so more applicants complete signup. Stakeholder requirements say what a group such as branch staff or compliance needs in order to work toward that outcome. Solution requirements then describe what the system must do and how well, such as validating identity documents within a set time. I keep links between them so every solution item traces back to a real need, and I avoid naming a technology too early because that closes off cheaper or simpler options.
What this question explores
Whether you can separate outcomes, group needs and system behaviour and keep them traceable without jumping to a solution.
Common mistakes
They use the three terms as if they meant the same thing and list features as business needs.
They write requirements that name a specific tool or screen before the underlying need is understood.
Practise a follow-up
Can you give a short example that links one business need to one solution requirement?
How does a non-functional requirement fit into these three levels?
5. How do you rewrite 'the screen should be fast' as a usable requirement?
Answer guide
Fast means nothing until it is measurable, so I turn it into a statement someone could test. I identify the transaction, such as opening a customer record, the population and expected concurrent load, the acceptable response time expressed as a percentile, and the environment and data volume in which it is measured. For instance, ninety-five percent of record searches complete within two seconds with a defined number of users on production-like data. I then agree with the business how it will be tested and what happens on a miss, so the requirement is a shared promise rather than a mood.
What this question explores
Whether you can convert a vague quality wish into a measurable, testable requirement with agreed conditions.
Common mistakes
They just replace fast with a single number such as two seconds and ignore load, data and percentile.
They leave out the test method, so nobody can later prove whether the requirement was met.
Practise a follow-up
Why is a percentile usually better than an average for response time?
How would you handle a stakeholder who cannot say what fast means?
6. A sponsor only describes features for a public portal. What else do you ask?
Answer guide
A feature list describes what the portal does, not how well or how safely it must do it, so I would widen the conversation early. I would ask about accessibility for the public, security and privacy duties for personal data, availability and peak load, performance targets, languages, support hours, retention and audit needs. I would push for measurable acceptance on each, such as a response time under a stated load, because vague wishes cannot be tested. The sponsor may not have considered these, so I offer examples and the cost of missing them.
What this question explores
Whether you look beyond features to quality attributes and obtain measurable, owned non-functional requirements from a sponsor.
Common mistakes
They gather a feature list and assume the developers will decide security and performance later.
They ask about non-functional needs in generic terms and accept answers like it must be secure without measures.
Practise a follow-up
How would you prioritise non-functional requirements when the budget cannot cover them all?
Which non-functional need is most often missed on public-facing systems, and why?
7. What distinguishes an acceptance criterion from a task?
Answer guide
An acceptance criterion describes what must be true when the work is finished, in terms someone can observe, while a task is a step the team takes to get there. Tasks such as create the table or write the API belong in the plan, whereas a criterion reads like a customer can reset their password and receives a confirmation within a minute. This distinction matters because criteria let the business and testers agree on done without prescribing the design, and they leave the team free to choose the route. If a criterion mentions how the code is written, it has probably slipped into being a task.
What this question explores
Whether you understand that acceptance criteria state observable outcomes and stay separate from implementation activities.
Common mistakes
They list build activities such as create the database table as if those were acceptance criteria.
They write criteria so vague, such as works well, that no tester could pass or fail them.
Practise a follow-up
Can you write a criterion for a password reset feature that a tester could verify?
Who should agree the acceptance criteria before development starts?
8. Every stakeholder labels their requirement critical. What do you do?
Answer guide
When everything is critical, nothing has been prioritised, so I move the conversation from opinions to criteria. I would agree with the sponsor a small set of measures such as business value, legal or regulatory necessity, risk if delayed, dependencies and deadline, and score each request against them in the open. Then the trade-offs are visible, for example that a compliance item outranks a convenience feature. Decision ownership matters too, so I name who breaks ties. I present the ranked result and what is deferred, so stakeholders see the reasoning and can challenge the criteria rather than the person.
What this question explores
Whether you use transparent criteria and clear decision ownership to resolve competing priorities without taking sides.
Common mistakes
They accept every request as critical and try to deliver all of it, which spreads the team thin.
They decide alone on personal judgement, so stakeholders dispute the outcome and the person who made it.
Practise a follow-up
What would you do if the sponsor overrides the agreed prioritisation criteria?
How do you handle a stakeholder whose deferred item later turns out to be urgent?
9. How do verification and validation of requirements differ?
Answer guide
The two questions are different. Verification asks whether the requirements are well made: clear, complete, consistent, testable and free of conflicts. Validation asks whether they are the right requirements, meaning they truly represent what stakeholders and the business need. A document can pass verification and still fail validation, for example a precise specification of a report nobody will use. I verify through reviews and checklists, and validate by walking scenarios or prototypes through with real users and the sponsor and tracing each item to a business objective.
What this question explores
Whether you can distinguish building requirements correctly from building the right requirements, and name how each is confirmed.
Common mistakes
They say the two are the same thing or that validation means testing the finished software.
They rely only on a document review by the analyst team and never involve the actual users.
Practise a follow-up
Give an example of a requirement that passes verification but fails validation?
Which review techniques do you prefer for verifying requirements quality?
10. What does requirements sign-off actually mean in an adaptive project?
Answer guide
Sign-off means the right people accept a specific version as the basis for the next step, not that learning has stopped. In an adaptive project I would seek it per slice, such as a release backlog or a set of acceptance criteria for the next iteration, with a version, a date and a clear route for change. It gives the team a stable target and the sponsor a record of what was agreed. It does not forbid discovery, because new findings go through the agreed change path. The risk to watch is treating sign-off as blame protection, which makes people avoid honest revision.
What this question explores
Whether you understand sign-off as an agreed, versioned baseline for a slice of work that still allows controlled learning.
Common mistakes
They treat sign-off as a one-time freeze and refuse any change afterwards regardless of new information.
They collect signatures as protection against blame rather than as a shared, versioned agreement.
Practise a follow-up
What would you do if a signatory later claims they never agreed to the scope?
How does sign-off differ between a fixed-price contract and an agile delivery?
11. What would you send a stakeholder before a requirements interview about a new approval workflow?
Answer guide
I would send a short note explaining which decision the interview will inform, the topics to be covered, the expected duration and the examples I would like them to bring, such as a few recent approvals including a problematic one. I would ask for representative cases and known exceptions, but not ask the stakeholder to design the whole solution. Preparation should improve the quality of the evidence while leaving room for unexpected needs, so I keep the note brief and say that no formal preparation is needed beyond gathering a couple of examples.
What this question explores
Whether you prepare stakeholders for elicitation in a way that improves evidence, with purpose, topics, examples and time, without asking them to design the answer.
Common mistakes
They send a long list of detailed questions that the stakeholder has no time to read, so the interview starts cold.
They ask the stakeholder to come with the proposed solution, which narrows the discussion to features instead of needs.
Practise a follow-up
Which examples would you ask the stakeholder to bring and why?
How would you handle a stakeholder who arrives with no preparation at all?
12. How do you handle a requirement change after design and testing begin?
Answer guide
A late change is not automatically bad, but it must be handled as a decision. I first assess what it touches: design, test cases, data, contracts, cost and schedule, and I note anything already built that would be reworked. Then I present the impact and options to the person with authority, who approves, defers or rejects it. If approved, I update the baseline, the traceability links and the affected teams, so nobody keeps working from the old version. For example, a new reporting field that alters the data model may need retesting of earlier modules, and that cost belongs in the decision.
What this question explores
Whether you handle late change through impact analysis, an authorised decision and updated traceability, not ad hoc agreement.
Common mistakes
They accept the change informally to keep the stakeholder happy, then discover the test and cost impact late.
They reject every late change on principle without weighing the business value of the request.
Practise a follow-up
How would you decide whether a change is small enough to skip formal impact analysis?
How do you keep testers informed when requirements change mid-cycle?
Choose one answer containing an example or practical sequence. Explain what you would actually do, what you would check and when you would ask for help. Keep claims about your experience honest.
For technical or regulated work, check current documentation and applicable local requirements alongside this practice material.