Product Owner interview questions: answer with real situations
The kinds of questions in a PO interview, how to answer with a concrete situation, what to do when you do not know, and what to ask the interviewer.
Written by Phan Lam Duy Khoi
Prepare by question type, then answer with a concrete situation: the context, your part, the decision and its cost, the result and what you learned. When you do not know, say so and explain how you would find out, and at the end ask questions that show whether the role is a real PO role.
A Product Owner interview coming up, but you have never been a PO?
This is an illustrative situation. Vy spent three years in customer support for a food delivery app, taught herself Scrum and applied for an entry-level Product Owner (PO) role at another company. She read the Scrum Guide carefully, knew the definition of the Product Backlog and could name prioritisation frameworks such as MoSCoW and RICE.
In the interview she was asked: “At the same time you have a payment bug, an urgent request from sales and an idea from the director. The team can only finish one. What do you choose?”. Vy explained MoSCoW, then said she would try to get all three done. The interviewer asked again: “So which one first?”. Vy went quiet.
Vy was not short of knowledge. She was short of a way to turn knowledge into a reasoned choice, and of a real story showing she had done it before. This article helps you prepare exactly those two things: knowing what each kind of question checks, and answering with situations rather than definitions. Every sample question here is illustrative, not something a particular company asks.
Why are PO interviews hard for beginners?
A PO interview differs from a technical interview in that few questions have one right answer. The interviewer wants to hear how you think: what you ask first, what you choose, what you accept losing and how you would check afterwards. Memorising theory helps you understand the words, but it does not answer “so which one do you pick”.
- You do not have the PO title, so it is easy to think you have no stories. In fact a lot of work in your current role already involved decisions; you have just not told it that way.
- Pressure pushes you to overclaim. Changing your title, claiming the team's work or rounding numbers up can feel safe, but one follow-up question exposes it.
- Every company uses the word PO differently. In some, the PO orders the backlog and talks to users. In others, the PO mostly writes documents to other people's requests. You need to know which kind you are applying for.
- Questions mix several formats. One interview can include theory, a hypothetical case, an on-the-spot story exercise and questions about real experience. Each needs a different kind of answer.
The good news is that all four can be prepared in advance. You cannot gain more experience in a week. You can reorganise the experience you have, practise answering with a structure, and prepare questions that reveal the real role.
What kinds of questions come up in a Product Owner interview?
The table groups questions into six kinds. The examples only illustrate the style. When you prepare, think about what the interviewer is trying to check, because the same idea can be asked in many ways.
| Question type | Illustrative example | What the interviewer checks | How to prepare |
|---|---|---|---|
| Role understanding | How is a PO different from a BA or a PM? | You understand the PO is accountable for value and backlog order, not only for writing documents | Explain the role in two sentences, with one example of a PO choosing between two pieces of work |
| Prioritisation case | Three urgent items, time for one. What do you choose? | You ask before choosing, you dare to choose and you can name the cost | Practise the four-part answer below, with assumptions stated out loud |
| Stakeholder conflict | Tell me about a time you disagreed with someone more influential | You listen, restate the problem, offer options with costs and keep the relationship | Prepare one real story; a story that did not end the way you wanted is fine too |
| Story or AC on the spot | Write a user story for password reset | You start from the user and the outcome, write testable conditions and think about failure cases | Practise one story with three or four AC in ten minutes for a few familiar features |
| Metrics | After release, how do you know the feature worked? | You can tell done from useful | Prepare one outcome measure, one measure that must not get worse, and a measurement period |
| A decision | Tell me about a decision you made and what happened | You separate your part from others', and are honest about the result and the lesson | Prepare three to five real stories using the template at the end |
On role understanding: the Scrum Guide 2020 says the PO is accountable for maximising the value of the product resulting from the Scrum Team's work, and for effective Product Backlog management (the ordered list of work for the product). The PO is one person, not a committee. Scrum.org's “What is a Product Owner?” page also lists some misconceptions about the role, such as seeing the PO as just a story writer or a gatekeeper. If you can say these things in your own words with one example, your answer is far stronger than a recited definition.
How should you structure a situational answer?
For experience questions, you can use the STAR structure. MIT's career office (CAPD) describes STAR as four parts: Situation, Task (your responsibility), Action (what you did) and Result. It also advises using real examples, saying clearly what “I” did when describing team work, preparing around three to five stories, and not memorising them as scripts.
For a PO role, this article suggests a small variation: give the decision and its cost a part of their own. The core of the PO job is choosing, and every choice makes something else wait. Interviewers want to hear that you can see that cost.
- Context: Which product, who had what problem, your role
- Your part: What you did yourself, who did or decided the rest
- Decision and cost: The options, what you chose, what had to wait
- Result and lesson: The measure, the period, what is still uncertain
For a hypothetical question, replace context with one or two clarifying questions and assumptions said out loud, and replace the result with how you would check your choice.
Keep the context short, just enough for the listener to follow. Make your part explicit: “I proposed”, “I called four customers”, “my manager chose option two”. The decision is where your PO thinking shows, so mention the options you rejected and why. The result should have a number with its measurement period if you have one; if you did not measure, say so. If the result was not what you hoped for, it is still a good story when you can say what you learned.
If you do not yet have a story with all four parts, the article on moving from BA, QA or development to PO shows how to build experience inside your current job, with a template for telling one decision without overclaiming.
How to prepare for each kind of question
Prioritisation case. Do not answer with the name of a framework. Ask one or two questions about impact and real deadlines, state your assumptions, choose an order, then say what has to wait and who you would tell. A framework such as RICE helps you state assumptions; it does not replace the choice.
Stakeholder conflict. The interviewer wants to see that you do more than say yes or no. A good answer restates the problem in the other person's words, offers two or three options with the cost of each, and says how you kept in touch afterwards.
Story or AC on the spot. Before writing, ask who the feature is for and what it should achieve. Write one story in the form “As a [user], I want [task], so that [outcome]”, then three or four acceptance criteria (AC, the conditions that show the story was done right), including at least one failure case. Say out loud what you would ask the development team if you had more time.
Metrics. Name one measure that shows users benefit, one measure that must not get worse, and how long you would measure. “Released on time” is output, not a result.
What should you say when you cannot answer a question?
You may meet a question you cannot answer, perhaps about a tool, a metric or a process they have not used. Inventing experience is the worst option, because the next question goes into detail. A safer approach has three steps:
- Take a few seconds to think, or ask for clarification: “Do you mean how this metric is calculated, or how it is used in a decision?”.
- Say honestly what you have not done, then what you understand: “I have not worked on this directly. My understanding is…”.
- Say how you would find out on the job: who you would ask, what data you would look at, how you would test small.
This answer shows the interviewer that you are honest and know how to learn, two things a PO needs every day. It is also far better than a confident wrong answer.
What should you ask to find out whether it is a real Product Owner role?
When you are invited to ask questions at the end, do not skip it. This is your chance to check the role you are about to take. The Scrum Guide 2020 says that for Product Owners to succeed, the entire organisation must respect their decisions. The questions below show how close the company's reality is to that.
A position called Product Owner
- Does the person in this role order the backlog? Ask who decides the order. If you would only write documents to request, the role may be closer to a BA
- Does the PO talk to users or see their feedback? Ask where user information comes from, and whether you could propose a way to reach users
- Does the team measure results after release? Ask how they know a feature worked, and note this is something you would have to build
- Do the PO's decisions hold when someone wants to change priorities? Ask for a recent example of a priority change and what happened
The role has the core parts of a PO role. Now weigh the product, the team and the working conditions
Ask with curiosity, not as if you are testing the interviewer. The best questions ask for a specific example, because examples show reality more clearly than a job description. The full list to copy is in the templates below.
Example: a weak and a strong answer to a prioritisation case
This is an illustrative example. The shop and all numbers are assumptions. The question: “You are the PO of Gom May, an online pottery shop. At the same time there are three things: payments through one bank are failing for some orders; sales wants discount codes for specific customer groups for a campaign in two weeks; the director wants a homepage redesign. Next sprint the team can only finish one large item. What do you choose?”
| Part of the answer | Weak answer | Stronger answer |
|---|---|---|
| Clarify | Asks nothing, answers immediately | Asks: how many orders fail, and can customers pay another way? Is the campaign date fixed, and can codes be created by hand today? |
| Assumptions | None stated | Assume about 1 in 10 orders through that bank fails without the customer being told, the campaign date is fixed, and the admin panel can create a general code but not codes per customer group |
| Decision | Uses MoSCoW, all three are Must, the team does overtime to get everything done | Fix the payment bug first. Run the campaign with a general code created by hand. Postpone the homepage until the director says what it should change |
| Cost | Not mentioned | The campaign cannot target customer groups. The homepage slips by at least one sprint. Tell sales and the director straight away, with the reason |
| Check | None | Track the failure rate for that bank for one week before and after the fix, and the number of orders using the campaign code |
| If an assumption is wrong | None | If very few orders actually fail, reconsider the order against the discount codes |
Put together, the stronger answer sounds like this: “Before choosing, I would ask how many orders the payment bug affects and whether the campaign date is fixed. Assuming about one in ten orders through that bank fails, I would fix the bug first, because it loses revenue every day and costs customer trust. I would ask the Developers for an estimate to make sure it fits the sprint. For the campaign, I would propose a general code created by hand. The cost is that sales cannot target customer groups yet, and I would tell them that the same day. I would postpone the homepage and ask the director what it should achieve so we can measure it. After the fix, I would track the failure rate for a week. If fewer orders fail than I assumed, I would reconsider.”
The weak answer is not wrong on knowledge. It is weak because it does not choose, does not see the cost, and promising “overtime to get everything done” is not a PO's promise to make for the team. Here the PO orders the work, while the Developers estimate and decide how much fits into the sprint. The strong answer also does not need to match the interviewer's own choice. If they ask “what if the director insists on the homepage first?”, go back to the same structure: ask the director why, state the cost of changing the order, then let the person with authority decide with full information.
Templates: an interview preparation sheet and questions to ask
Use these two templates before the interview. The first organises your stories and exercises. The second lists questions to ask the employer. Copy them and fill them in for the role you are applying for.
Role: [role title, company] Three things the job description stresses: [1], [2], [3] Their product: [who uses it, what for, one thing I think could be improved] Story 1, for questions about: [prioritisation / stakeholders / a decision / metrics] - Context: [product, users, my real title at the time] - What I did: [work I did directly] - What others did or decided: [who, what] - Options and their cost: [options, what had to wait] - Result: [before measure] -> [after measure], over [period] - What I learned or am unsure about: [...] (Repeat for 3 to 5 stories) Two likely follow-up questions for each story, and my honest answers: [...] On-the-spot practice: write one user story and 3 to 4 AC, including one failure case, for [a feature in their product], in 10 minutes. One outcome measure and one measure that must not get worse for that feature: [...] Final check: the title, scope and numbers in every story match what really happened.
1. Who decides the backlog order, and who settles disagreements? 2. Has anyone recently wanted to change priorities mid-way? How was it handled? 3. Does the PO here talk to users directly, and how often? 4. How does the team know a feature worked? Has a recent feature been measured after release? 5. What does a PO's week on this team involve? 6. Which stakeholders does the PO work with, and where do requests usually come from? 7. Is the development and testing team dedicated to this product? 8. After three months, what would the person in this role need to have done for you to call it a good start? 9. What is the biggest challenge for the product right now?
You do not need to ask all nine. Pick the three or four that matter most to you, with priority on questions one, two and four, because they show most clearly whether the role is close to a real PO role.
Common mistakes in Product Owner interviews
- Inflating your title, scope or numbers. Writing “owned the product” when you were a QA, or saying “cut it by 50%” without the measurement period, falls apart at the second question. Stick to the truth and be clear about your part.
- Answering with a framework name. Saying “I would use RICE” is not a choice. If you mention a framework, use it to state your assumptions, then make the choice.
- Saying “we” from start to finish. The interviewer cannot tell what you did. Make your part clear and give others credit where it is due.
- Leaving out the cost. Every choice makes something else wait. Not mentioning it sounds as if you have never had to choose for real.
- Promising on the team's behalf. “The team will do overtime” or “I will tell the developers to finish in two days” shows you are unclear about who decides how much goes into a sprint.
- Asking nothing back. Skipping your questions means missing the chance to learn what the role really is, and can look like a lack of interest in the product.
- Blaming former colleagues or employers when describing a conflict. Describe the problem and how you handled it, not who was wrong.
Summary
- A PO interview may include six kinds of question: role understanding, prioritisation, stakeholders, a story or AC on the spot, metrics, and a decision you made. Each checks a different skill.
- Answer with a situation in four parts: context, your part, the decision and its cost, the result and the lesson. For hypothetical questions, clarify, state your assumptions and say how you would check.
- When you do not know, say so, explain what you understand and how you would find out. Never invent experience.
- At the end, ask who orders the backlog, whether the PO meets users and how the team measures results, to learn whether it is a real PO role.
- Keep your title, scope and numbers accurate. A modest story you can defend is stronger than a big one you cannot.
I am writing more PO situations in this same format, with templates you can use straight away. If you would like the next one by email, subscribe to the newsletter below.
Frequently asked questions
What can a Product Owner interview ask about?
You may meet six kinds of question: understanding the PO role, a prioritisation case, a stakeholder conflict, writing a user story or acceptance criteria on the spot, measuring after release, and a decision you made. Each checks a different skill, so prepare for each one separately.
How do I answer experience questions if I have never been a PO?
Tell a real story from your current role that you followed from problem to result, and say clearly what you did and what others decided. Keep your real title, scope and numbers, because the interviewer may follow up on the details.
What is the STAR method in interviews?
STAR is a way to tell an example in four parts: Situation, Task (your responsibility), Action (what you did) and Result. For a PO role, also say which option you chose and what that choice cost.
Sources to check
Related articles
- PO vs PM vs BA: what is the difference?: How PO, PM and BA really differ, how the lines move between outsourcing firms, product companies and startups in Vietnam, and how to read a job description to see which role it actually is.
- Your first 30 days as a Product Owner: what to do each week: A four-week plan for a new PO: listen and map, understand users and metrics, own a small slice of the backlog, then make a first decision and agree expectations with your manager.
- Can you be a Product Owner without coding?: A PO does not need to write code, but does need enough technical literacy to ask good questions, respect the Developers' ownership of “how”, and talk about trade-offs clearly.
- From BA, QA or developer to Product Owner: what to learn?: Which BA, QA and developer strengths carry over to the PO role, which blind spots to watch, and how to build PO experience inside your current job.