Familiarize yourself with these interview questions and answers on Product Owner to crack the Product Owner interview. Each and every answer to the questions are designed by our team of experts so that the candidate can crack these Product Owner Interview Questions easily.
The answer will vary a bit from candidate to candidate. If he is in a large organisation where there are multiple team working together on the same product lines, he will talk about his peers and coordination, the product line chain (something like Product Owner, Area PO, Product manager, Chief PM) or in case of distributed agile team, he will also talk about Proxy PO at off shore. If he is from a small organisation, he will talk about him directly discussing and coordinating with Business executive and Sales guys.
A Product owner is someone who focuses on product vision, roadmap and changing priorities. He does not give the solution. A Business analyst largely translates the product vision into solutions and at times recommends different ways or solutions. While Scrum does not requires a Business analyst, there is practise in many organisation to have a PO, who is focussed on product part and a BA, at times called as BA or even proxy PO, who is a techno-functional person who helps in defining then acceptance criteria, a solution etc.
MoSCoW is a Product backlog refinement technique, where Mo stands for Must be, S stands for Should be, Co stand for Could be and W stands for Won’t be.
MoSCoW is a very basic prioritisation technique. Most of the PBI will be falling under Mo and S. An experienced PO would be using various other ways to differentiate between Mo and S. Popular one is WSJF – Weighted Shortest Job First. WSJF = Cost Of Delay / Job Size.
The answer will vary from candidate to candidate based on their exposure and the size of organisation they are working in. For a small organisation the PO might be directly involved in creating the roadmap however in large organisation, he would be someone whose input would be required.
Typically the answer would evolve around : Continuous exploration – Taking feedback after every release , checking how the features has been perceived by the market, analysing competitor’s offerings and our customers’ reaction to it. Not doing upfront design and freezing the requirements. Having features variable for future releases and creating a roadmap which will follow Cone Of Uncertainty.
Cone of uncertainty shows, how much is known about the product over time. Its more variables and less fixed initially but as we move, it will have more fixed and less variable.
The answer may vary from person to person and organisation to organisation. If the person says that they spend 50% of their time on user research, that’s excellent. However, if a product owner says they spend 10% or less time, it’s not good. This means they are not doing enough customer exploration and feedback and might also be ignoring changing market condition.
When valuable new features are competing with bugs and technical debt in a product backlog, as a product owner, with every sprint, along with the features I will include a limited number of the most important bugs and the most pressing issues caused by technical debt. Based on the product, we can also have some basic thumb rule set for it, such as allocating 10% of the resources to bugs, 15% to technical debt and rest to new features.
The best (and perhaps the only) way to deal with uncooperative stakeholders is to win their confidence by engaging them through regular meeting and discussions and demonstrating the value of agile product development. ID it still fails, the product owner should seek help from sponsor.
While team estimates the current sprint backlog, for future roadmap, which is highly flexible it is advisable, not to involve the team in estimation. The product line (Product manager, Product Owner etc) could do the rough estimation based on historical data.
It is very much required that the scrum team is aware of the changes happening in market place. It is one of the responsibility of the product owner. The PO does it continuously as a part of his informal interactions with development team and SM. He also does that through formal discussions and meetings.
No, it is not required to release every sprint. While deployment is a planning activity and could be per sprint or continuous, release is a business and strategic activity. The development team may continue to create a shippable product, the shipping is a business decision. The PO or the product manager will plan a release date , when it makes sense from business perspective.
Major stake holders with whom a Product Owner interacts are – Customers, Sponsors, Key decision makers, professionals, regulators.
A PO can manage desire of various stakeholders by coordinating and collaborating with them through discussion while designing product roadmap, seeking their input and feedback in designing and defining Product backlog items and preparation of sprint events. A consistent and constant collaboration would help.
As a Product Owner, we should not out rightly reject any of ideas, nor can we accept all of them. Every idea that comes needs to be analysed. So ideation needs to be followed up with analysis. The analysis can be done in several ways like analysing through creating a prototype, working on pilot customers, based on experience etc. Based on the result of analysis, the idea should be added to the product backlog.
Systems thinking means holistic thinking. It gives the complete view. For a Product Owner, it is very important to have the complete view of the product, then only he will be able to design a product vision. Also if he has in an environment where there is a complete product management line of product managers above him, a holistic view will help him to understand why there has been change in the Product roadmap and why he should adjust the product backlog items
That’s a great position . But with great position comes greater expectation.
The answer of this question will unwrap the product owner inside a candidate. Different candidate may answer it differently. Someone may talk about adding new look and feel feature or adding UX (User Experience) etc, while few may talk about how gmail as a product would evolve, such as its integration to other existing product, or vice versa something like G-Pay integrated with Gmail or making it a one stop shop for all your needs – communication, collaboration, banking , shopping etc. This shows the vision of the person.
If the requirement is such that it may create new opportunity or help in gaining the market share for first mover (such as it happened for fintech companies like PayTM in India during demonetization announced by government in 2016), the product owner should act on it. The Product Owner has the authority and can cancel the current sprint if he deems it fit, adds item to product backlog and reprioritize it.
Yes. A DevOps team also works around a product. With automation, CI/CD, it becomes more important for DevOps team to understand business requirement and needs and then automate the delivery pipeline. The business need could not be understood correctly, and doubts answered without a Product Owner.
Next-gen product owner is not someone who just maintains and prioritize the product backlog with multiple features, next-gen PO is someone who plans how the whole product evolves and changes with time, how new product lines evolves from the same product branch and how it remains relevant and front runner with changing market and taste
This would be one of the initial questions, which will help interviewee to open up and also will give interviewer the opportunity to understand the exposure of the candidate.
The answer will vary a bit from candidate to candidate, but will typically will be: Sprint Planning, Sprint Review, Sprint Retrospective, Grooming. If the PO says Daily Scrum (Daily Standup), ask what he does there. It is ok for PO to attend daily scrum, but he just need to be observer there and should not speak.
Yes. PO helps the team in understanding the user story which will help them in right user story splitting and correct estimation. While PO will act as an SME for User story point of view, he will help team to understand it better, he will NOT give or suggest story points in User story estimation.
No. Product Owner and Scrum Master are two separate roles and mixing them can have a very negative effect on the development process. Both role requires 100% involvement. One person will not be able to fulfil all his responsibilities in 100 %. Scrum Master sometimes needs to act as a mediator between the development team and PO when their goals start to diverge. In such case, if the same person is acting as both, there will be a conflict of interest.
Typical answer will be MoSCoW – Mo (Must be), S(Should be), Co(Could be), W(Won’t be). But a good and experienced PO will also talk about other techniques such as WSJF.
A good product backlog item should be DEEP – D (Detailed appropriately), E (Estimated), E (Emergent), P (Prioritized).
Product backlog refinement meeting is for upcoming sprint. The Items in the current Sprint are no longer on the Product Backlog. They are in the Sprint Backlog.
No. A Product owner gives a big user story to the development team. It is the team that discusses it further and splits it.
A good user story should be Independent (I), Negotiable (N), Valuable (V), Estimable (E), Small (S), Testable (T). In short – INVEST.
As a Product owner, I will see if there is any challenge understanding the large user story given by me or in understanding the business requirement. I will discuss and with them and will answer those queries. However, if the issue is because of incorrect splitting technique, I will inform Scrum Master to further facilitate it and plan for any grooming or training session.
Definition of Done (DoD) is the shared understanding of what “Done” means for a user story. It is a simple list of activities such as writing code, coding comments, unit testing, integration testing, release notes, design documents, etc.
The Development team creates DoD
Acceptance Criteria is a set of accepted conditions or business rules which the user story or feature should satisfy and meet, to be accepted by the Product owner. They are a set of statements, each with a clear pass/fail result, that specify both functional and non-functional requirements applicable at the current stage of project integration.
The Product owner sets the acceptance criteria.
Definition of Done (DoD) is a simple list of activities such as writing code, coding comments, unit testing, integration testing, release notes, design documents, etc.
Definition of Ready (DoR) is a sort of criteria or at times checklist that determine whether a story is “Ready” to be picked it for next sprint.
As long as it’s the same product on which different teams are working and the product owner can give sufficient time to each of the team, is it acceptable.
No. A team should not have more than one PO or a committee of product owner acting as a PO. PO is someone who steers the scrum team towards the product vision and goal. Having more than one PO will create confusion and issues of alignment of development team with the product.
Burn-down chart is a graphical representation of work left to do versus time. The outstanding work (or backlog) is often on the vertical axis, with time along the horizontal. That is, it is a run chart of outstanding work. It is useful for predicting when all of the work will be completed
Yes. It’s only the product owner who has the authority to cancel the sprint. However, this should be in consultation with business stake holders and development team.
In case the sprint is cancelled, any ‘Done’ product backlog item should be reviewed. If they are potentially releasable, product owner will accept it.
Sprint backlog item which could not be completed during the sprint as per DoD, will not be demonstrated during sprint review. Extending it to next sprint might not be good idea. Rather than extending it to next sprint, the right approach is to move it to product backlog and then re-evaluate, if it should be picked for next sprint.
There is nothing wrong in a Product Owner coming from a technical background, but a PO should never be part of the development team. Also, a PO coming from technical background should practise restrain and should not act as a technical SME during story splitting etc.
It is very important for Product Owner to look and understand the reason for development team failing the sprint commitment. There might be multiple reason for that. It might be because of incorrect estimation or over commitment. It might be because of lack of trust and collaboration in the team. It might be because of not understanding the user story and not slicing it correctly. A PO needs to identify it and based on it, needs to work with the development team and Scrum master to find the solution.
Yes. While development team is one who measures sprint performance, it’s the product owner, who measures project performance.
In practise, distributed agile projects , especially those working on on-shore/off-shore model has a proxy product owner. Proxy product owner acts as local product owner to answer to development team questions. They do not own the product backlog but helps the product owner in managing and maintaining it.
Product owner. Defining sprint goal or objective is one of the most important goal of product owner.
A good product owner is someone who should be
A product increment is the cumulative sum of all the PBIs completed during the sprint and the value of the increments of all previous sprints.
Since a product owner is part of estimation meeting, for larger stories, he may try to explain it to the development team to ensure that they have understood it correctly and have sliced it properly. If still he finds a challenge, he could further discuss it with Scrum master. The SM can coach the team further.
There cannot be a fix answer to this question. What interviewee will be looking for is that the product owner should talk about design, functionality and usefulness of the product and should clearly articulate it. Also, the interviewer will give some point on the creativity of the product being picked.
Agile manifesto uses the term ‘Over’, which means a higher preference to working software, it does not say that we do not need any documentation in agile. This means one should do the necessary documentation to support the development and use of the product. An open discussion explaining the development team about it with involvement of Scrum master would help.
The role of PO and SM has some overlaps and a good coordination between the two is key to a successful scrum team. Scrum Master facilitates activities like backlog grooming, Scrum master communicates the outcome of sprint retrospective to Product owner so that next sprint could be improved. Since Scrum master works closely with scrum team, he also helps the product owner to overcome any teaming challenge within development team. In general, the role of SM and PO complements each other.
Early design in Agile means creating just enough design up front to give a good foundation to start from and helps to mitigate risk, without wasting unnecessarily time. As the product evolves, the design emerges.