71 Scrum Product Owner Interview Questions (2): Internal Stakeholders & Product Roadmaps
TL; DR: 71 Product Owner Interview Questions to Avoid Imposters
If you are looking to fill a position for a Product Owner in your organization, you may find the following 71 interview questions useful to identify the right candidate. They are derived from my fourteen years of practical experience with XP and Scrum, serving both as Product Owner and Scrum Master and interviewing dozens of Product Owner candidates on behalf of my clients.
So far, this Product Owner interview guide has been downloaded more than 7,500 times.
🗞 Do you want to get this article in your inbox in the future? You can sign up here for our weekly ‘Food of Agile Thought newsletter’ and join 29k other subscribers.
Download the 71 Product Owner Interview Questions Ebook
The free 71 Product Owner Interview Questions PDF is not merely listing the questions, but also contains background information on:
- Why the questions are useful in the process, and…
- A range of appropriate answers.
Two to three questions from each category will provide more than enough ground for an engaging initial 60 minute-long conversation with candidates.
Product Owner Interview Questions: The Organization of Questions and Answers
The ebook provides both questions as well as guidance on the range of suitable answers. These should allow an interviewer to deep dive into candidates’ understanding of Scrum and their agile mindset. However, please note that:
- The answers reflect the personal experience of the author and may not be valid for every organization: what works for organization A is probably failing in organization B,
- There are not suitable multiple choice questions to identify a candidate’s agile mindset given the complexity of applying “agile” to any organization,
- The author has a holistic view of agile practices: agile equals product discovery (what to build) plus product delivery (how to build it).
Please find the following 71 Product Owner interview questions to identify suitable candidates for the role of Scrum Master or agile coach. (See also part one of this three-part series.)
Set 3: Internal Stakeholder Management
This category of the Product Owner interview questions deals with specific aspects of relationships of the Product Owners with internal stakeholders:
- Your organization has recently decided to become agile and product-driven. How do you educate your stakeholders about the implications?
A good starting point would be working with the “Manifesto of Agile Software Development,” particularly ensuring that stakeholders understand that adapting to change over following a plan is paramount for the organization’s future success. Stakeholders also need to understand that “requirements” (and thus probably local optimizations efforts) are no longer a valid form of the product delivery process. Instead, continuous product discovery and iterative and incremental product creation become the guiding principles, elevating experiments, and accepting failure to good practices. Becoming agile means competing with other—probably more valuable—product ideas for scarce resources and accepting that the PO is the gatekeeper to the Product Backlog. It means that there are no more arbitrary delivery dates, but delivery intervals, projecting the knowledge of today into the future. Lastly, stakeholders will need to understand the magnitude of abandoning the command & control management style and empowering autonomous and self-organizing teams for product delivery.
- How do you organize the collaboration with stakeholders and improve it over time?
Communication and transparency are critical to effective collaboration with stakeholders. There are various ways to establish and improve this communication over time. For example, institute regular meetings with each stakeholder or have stakeholders name product ambassadors, who then act as “liaison officers” and train them accordingly. Arrange workshops with stakeholders and ambassadors, and ask your Scrum Master and the Developers to join the effort. Team up with the user experience people and run, for example, user journey or user story mapping workshops. Or invite stakeholders to Product Backlog refinement sessions to explain a user story’s value to the rest of the Scrum Team. Sprint Reviews and user interviews are also well suited to improve collaboration and communication over time.
- How do you communicate with uncooperative stakeholders?
An often promising way to deal with uncooperative stakeholders is to win them over by demonstrating the value of agile product development. Early in the transition process, it is advisable to educate them with product-related workshops on agile principles. Proven examples are user story mapping or product roadmap planning workshops. (It is recommended to secure the help of an experienced coach at this stage.) It has also proven to help establish a close communication schedule with the stakeholders, for example, by having regular meetings. Also, educating members from stakeholder teams to act as “liaison officers” to the product organization significantly improves cooperation. It mitigates the usual feeling of losing control on the stakeholders’ side. At a later stage, typical agile events, such as Sprint Reviews, also work well by demonstrating what value the Scrum Team created for them. Generally, it is a process that will take time, and there are no shortcuts available. As a last resort, if everything else hasn’t worked out, the PO might need support from a C-level sponsor. (Read more: 11 Proven Stakeholder Communication Tactics during an Agile Transition.)
- A new feature is overdue and has been drastically underestimated due to unexpected technical debt. Nevertheless, your most important stakeholder insists on “finishing it” because so much effort has already been invested. How do you deal with that?
Agile first principles require to adapt to change over executing a plan in the first place. If a project is late, it probably has lost some of its original value to the organization and its customers. In this case, reevaluating its benefit before pouring more resources into it is a necessity. If the project still delivers value, you should probably go for it. Keep in mind that there is always competition from the other investment opportunities comprising the Product Backlog. However, continue building it merely because of the prior investment means that the stakeholder has fallen for the sunk cost fallacy.
- How do you deal with pet projects?
Submit the pet project to the usual, standardized process that every product idea has to master. Just continuously update the business case behind such a pet project and have it compete with valuable projects. Sooner or later, common sense will end this kind of misallocation of resources, as pet projects rarely provide a return on investment. Other stakeholders with valuable projects make good allies in this conflict.
- In the middle of a quarter, the sales department suggests features of doubtful value. Your Scrum Team believes that these features are merely wild guesses to secure the sales bonus. Consequently, they are reluctant to talk about them. How do you handle the situation with the salespeople?
This problem is generally comparable to the pet project problem and could be dealt with accordingly. However, the distinguishing factor, in this case, is the urgency and probably the party’s different status that’s demanding the features. In a sales-driven organization, the sales team can often secure sponsorship from the C-level for such suggestions. This tends to happen when sales forecasts are missed. In this situation, the Product Owner can often only rally support from other stakeholders to fight off the demand based on opportunity costs. If the usual process is overridden by executive intervention, the Product Owner needs to address this issue immediately. You can’t have the (agile) cake and eat it, too.
- The sales department often sells new features to close deals without talking to you first. How do you deal with that?
Usually, this kind of attitude is encouraged by the management in pursuit of meeting sales targets. It reflects a non-agile, opportunistic mindset that values instant gratification—more sales—over a sustainable product development strategy. To change this mindset, it certainly helps to reach out to the sales department and offer them support on the sales process’s technical side as early as possible. However, given the sales team’s usual incentives, a real change will only happen if the management buys-in to agile product development principles. These might include an adaptation of the remuneration scheme for sales.
- How do you deal with suggestions for new features and products from stakeholders and other members of the organization?
Providing an idea management system is a good starting point. This can be a simple template for the suggesting party covering the what, why, when, for whom, and ROI questions. Start communicating with the person in question throughout the evaluation. If a suggestion is accepted for realization, include the suggesting person in the following process. (For example, invite the individual to a user story mapping workshop or user tests.) Lastly, provide continuous feedback throughout the whole development and delivery cycle with regular checkpoints against the original targets. Finally, 3-12 months after shipping, update the stakeholder whether the expectations—for example, ROI, cost savings, engagement, and other KPI—have been met out in the field.
Scrum Product Owner Interview Questions Set 4: Product Portfolio and Roadmap Planning
The questions in this set concern one of the most contentious topics in the profession: “How do we build agile product roadmaps that work?”
- Product vision and strategy are kept confidential in your organization to prevent competitors from stealing ideas. Will that impede your work as a Product Owner?
Yes, it would significantly impede the Product Owner’s work, as transparency is required to innovate most effectively within an organization. Nowadays, innovation is a team sport. The brilliant individual—creating great innovations single-handedly—is a myth. (Not even Mr. Jobs considered himself to be such an individual.) Such a joined team effort always starts with a shared understanding of product vision and strategy.
- Aren’t portfolio and product roadmap planning anachronisms in an agile organization?
No, that practice is not anachronistic at all. A product portfolio encompasses strategic objectives and goals at the company level. These endeavors are related not only to the overarching goal. They are also associated with their sustainability from a financial point of view. One initiative, for example, can act as a source of investment for another one. Or all these endeavors have a common investment source. A portfolio plan helps structure investment sources, thus contributing to better financial management while illustrating business value sources.
- What is your approach to creating product roadmaps?
In general, you would consider a top-down approach, starting with the company goals and the general product vision. Once several iterations with the leadership and stakeholders have been performed, it is usually advisable to combine the first draft with a bottom-up initiative. Meeting somewhere in the middle guarantees those crucial aspects, while probably of a more detailed nature, aren’t lost in the process.
- How often shall product roadmaps be planned—once a year?
Product roadmap planning is a continuous exercise to analyze products at all stages: live, in development, under planning, or on the brink of being phased-out. Depending on the organization’s maturity, the size of the product portfolio, its products and service, the industry, and its level of regulation, this can be a quarterly or even monthly practice.
- How do you connect teams to the product vision and show them how their contributions impact bringing that vision to life?
The recommended way to achieve this goal is to include the Scrum Team in the product discovery process actively. Suppose Developers are merely confronted with requirement documents. In that case, they rightfully feel disrespected, as they only have limited options to become self-organized as they are told what to do. (Which leads to a cog-in-the-machinery syndrome, tempering with their idea of autonomy.) There are various ways how the Product Owner can include the Developers in the product discovery process, for example, by user story mappings with other stakeholders, inclusion in the portfolio and product roadmap planning, participation in user tests, to name a few.
- Who shall participate in the product roadmap planning?
Usually, it’s the internal stakeholders, Scrum Team members or their representatives, and the Product Owners. Adding customers to the mix is a bonus.
- How much of your time do you spend talking with customers and researching industry trends?
As a rule of thumb, 50% are supposed to be allocated to stakeholder communication of all kinds.
- What has Monte Carlo to do with projected delivery dates?
A Monte Carlo simulation is an algorithm-based statistical approach to obtain numerical results. Product Owners can use this approach to forecast probable delivery windows of releases or features based on the previous Scrum Team performance. (This question opens the discussion on how to deal with deadlines, forecasts, and other legitimate inquiries of stakeholders regarding product delivery.)
Conclusion: How to Use These 71 Scrum Product Owner Interview Questions
Scrum has always been a pragmatic business, and to succeed in this mindset, candidates need to have a passion for getting their hands dirty. While the basic rules are trivial, getting a group of individuals with different backgrounds, levels of engagement, and personal agendas, to continuously deliver value by creating a great product is challenging. The larger the organization is, the more management level there are, the more likely failure in one of its many forms is lurking around the corner.
The Product Owner interview questions are not necessarily suited to turn an inexperienced interviewer into an agile expert. However, they support figuring out what candidate has been working in the agile trenches and who’s more likely to be an imposter. (You should avoid inviting candidates from the latter category to a trial.)
Hence it’s probably a good idea to look for a pragmatic veteran who has experienced failure—and success—in other projects before and the scars to prove it.
✋ Do Not Miss Out: Join the 9,000-plus Strong ‘Hands-on Agile’ Slack Team
I invite you to join the “Hands-on Agile” Slack team and enjoy the benefits of a fast-growing, vibrant community of agile practitioners from around the world.
If you like to join now all you have to do now is provide your credentials via this Google form, and I will sign you up. By the way, it’s free.
📖 Related Posts