Hiring: 82 Scrum Product Owner Interview Questions to Avoid Agile Imposters

TL; DR: 82 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 82 interview questions useful to identify the right candidate. They are derived from my sixteen 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 10,000 times.

🗞 Shall I notify you about articles like this one? Awesome! You can sign up here for the ‘Food for Agile Thought’ newsletter and join 34,000-plus other subscribers.

🎓 Join Stefan in one of his upcoming Professional Scrum training classes!

Download the 82 Product Owner Interview Questions Ebook

The free 82 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.

Cannot see the subscription form?
Please click here

82 Product Owner Interview Questions

Scrum is not a methodology but a framework. There are no rules that apply to each scenario, just good practices that have worked in other organizations before. Hence, you have to figure out on your own what is working for your organization. Finding this answer is a process and not a destination.

The role of the Product Owner itself is making the hiring process difficult to handle. The Product Owner is the least well-defined accountability within the Scrum framework and—at the same time—the one Scrum role with the most facets. (Please note that I will continue using ‘role’ on occasions throughout this document, although the Scrum Guide 2020 now speaks of ‘accountabilities.’)

A Product Owner is an innovator at heart and thus a value creator for customers and organizations if given a chance to work in an agile manner. The Product Owner is also the most vulnerable Scrum role. Turn them into a [fill-in a ticket-system of your choice] monkey or deprive them of the ability to say ‘no’—as in being the guardian of the Product Backlog—, and the Product Owner quickly becomes the Achilles heel of any agile organization.

The Product Owner role depends on the size of an organization, the industry it is operating in, its culture, and the lifecycle stage of that organization’s product(s). Lastly, there is an overlap with the product manager role. (Spoiler alert: they aren’t identical.)

The following interview questions are neither suited nor intended to turn an inexperienced interviewer into an agile software development expert. But in a seasoned practitioner’s hands, they support figuring out who of the candidates has been successfully working the agile trenches in the past. Remember, “Agile” is a mindset, not a methodology. Hence, no checklist can drive your recruiting success to the desired outcome.

The Product Owner interview questions in this PDF are modeled after a holistic model of agile product development for software products:

In this model, product discovery is moved as far as possible to the left to keep costs of validating hypotheses—derived from a vision and strategy—low and increase the speed of experimentation. In this approach, the Product Owner needs to coach the Scrum Team on how to adopt such a holistic model, teaming up with the Scrum Master in the process.

Therefore, the PDF contains additional background and contextual information, how the following set of questions can be interpreted as well as guidance on desired or acceptable ranges of answers for each question. The questions themselves are grouped into six categories.

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 82 Product Owner interview questions to identify suitable candidates for the role of Product Owner:

Scrum Product Owner Interview Questions Set 1: The Role of a Scrum Product Owner

This category addresses the meta-level of the Product Owner role and the Scrum process. Please keep the following in mind when asking the questions:

1. What is the purpose of being agile in the first place?

   As the “Manifesto for Agile Software Development” states, it is mainly about adaptability over following a plan. Or, to put it with Peter Drucker, it is about doing the right things, and less about doing the things right. Concerning product development, being agile is about postponing deciding to invest in the latest economically feasible moment. This is achieved by testing hypotheses as fast and as inexpensive as possible, thus mitigating risk and maximizing the development team’s work. It also means to have the courage to stop an effort in case the chosen course is no longer viable.

2. How would you characterize your role as Product Owner? Are you a facilitator, a coach, a manager, a visionary, a tactician, a coordinator, or a “driver?”

   This is an open-ended question better to understand the candidates’ perception of their role. A Product Owner is a leadership role, yielding no authority in a traditional management sense. In that way, the Product Owner is featured a bit by all the labels mentioned in the question. The Product Owner role has also been dubbed as “bottleneck” or the “Achilles heel of the Scrum process”; any mentioning of that would undoubtedly be a plus. If a candidate is mostly referring to something like “I am the one creating the user stories,” I would dig into that.

3. How would you characterize our role as Product Owner, particularly concerning the product manager role? Or are both roles just different labels for “product people” and are basically identical?



   Full-stack “product people”—covering the product manager & Product Owner role in one person—are rare. Often, it takes too much time to cover all responsibilities: from communication to stakeholders and customers to organize the operational work within the Scrum process. Depending on the product, Product Owners hence can quickly spread themselves too thin to become a meaningful player in the process. (Speaking of which: a Product Owner is not a requirements engineer, not a business analyst, and not a user stories expert either.) As a result, you may observe that large organizations split the responsibilities among two or more individuals. Here, the product manager is often responsible for strategic aspects, while the Product Owner is a more tactical role. For smaller or less complex products, Product Owners may very well cover both roles simultaneously.

4. To what extent is the Product Owner a “product manager”?

   There is a fine line between a product manager and a Product Owner role, and it depends on how the role is crystallized in the company’s structure and culture. Usually, besides product management duties, Product Ownership entails establishing the product vision and strategy, its alignment with the company’s goals and objectives, and managing any internal and external stakeholders in this process.

5. When was the last time you told a stakeholder “No”? How did you approach this situation, and what was the reason for it?

   Saying “no” is an essential qualification—and empowerment—for each Product Owner. For example, it is required to protect the team from a stakeholder’s pet project of a doubtful value. Or to put an end to silo thinking and local optimization within the organization. Product owners create value by shipping the right product and maximizing the amount of work deliberately not done. Because of that, the organization has to respect a “no” from them. Otherwise, they will not fulfill their role: maximizing the product’s value across the whole organization. Applying “Scrum” without an empowered Product Owner creates a great “Waterfall 2.0” process. The Product Owner’s empowerment to decide over the Product Backlog can therefore act as a litmus test of the organization’s adoption of agile principles.

   


6. Your Product Backlog is gated by a “product committee.” It is meeting regularly and applies a kind of Stage Gate® process to approve new features. Can you act as a credible Product Owner if you’re not in control of the Product Backlog?

   Suppose a person or a group of individuals, for example, a product council, exercises control over the Product Backlog. In that case, you’re not a Product Owner but a proxy. You’re probably more a product manager that happens to work with an agile team that uses a subset of Scrum. That may work fine, depending on the organization’s nature, culture, and product. But it cannot be called Scrum.

   


7. What “labels” come to your mind when you think of your role as Product Owner?

   CEO of the product, product visionary, strategic thinker, servant leader w/o authority, entrepreneur/intrapreneur, innovator, systems thinker, single wringable neck.

8. How do you collaborate with the other Scrum Team members?

   Early, often, respectfully, transparently, being available regularly, and responding with adequate speed and attention. As the Scrum Guide 2020 states: “The Scrum Team is responsible for all product-related activities from stakeholder collaboration, verification, maintenance, operation, experimentation, research and development, and anything else that might be required.”

9. Would you feel bothered if your Scrum Master suggested a possible course of action concerning product development?

   Self-organization is at the core of any serious agile framework, Scrum included. Suppose a candidate feels uncomfortable with the concept that the Scrum Team or the Scrum Master have ideas on how product discovery and delivery might improve in the future. In that case, you should dig deeper into that. It’s not a good idea to substitute silos at the department level with “functional silos” within Scrum, when communication, sharing ideas and creating a shared understanding are paramount for Scrum Team’s success.

10. If you are the “client” and the Scrum Master is the representative of the delivery entity, how do you best collaborate?

    The best way of collaboration for PO and Scrum Master is embracing Scrum Values. Both serve in leadership roles without yielding any authority. Both depend on each other for the Scrum Team’s success, for example, accomplishing a Sprint Goal. They are both also allies concerning coaching the organization to become agile. Daily, the Product Owner is responsible for promptly providing feedback on product matters, clarifying goals, and ensuring that everyone on the Scrum Team understands the product vision. The Scrum Master, in return, needs to support the Product Owner in building an actionable Product Backlog while facilitating an effective collaboration within the Scrum Team in general.

11. What roles would you deem necessary for a cross-functional Scrum Team delivering software?

    Generally speaking, in an ideal world, the members of a cross-functional team cover all skills that are required by the Scrum Team to deliver value to customers independently. This may work for a product at an early stage when one team is handling everything. When the organization needs to scale, dealing with interdependencies—here: other teams—becomes a necessity. Depending on that, the actual composition of a team highly depends on what the team is delivering. Typical roles in cross-functional teams are business or data analysts, UX and UI designers, Developers (front-end, back-end), QA Developers, and probably DevOps engineers.

12. In what Scrum events shall the Product Owner be participating?

    The Product Owner is expected to participate in all events: Daily Scrums, Sprint Planning, Sprint Review, and Sprint Retrospectives. Otherwise, the Product Owner cannot answer possible questions quickly, and impediments cannot be solved in a timely fashion, which would contradict the core of being agile.

13. Is it necessary to have a product vision to be successful as a Product Owner?

    Absolutely. Or, to cite Lewis Carroll: “If you don’t know where you’re going, any road will get you there.” The agile product stack starts with the vision and strategy of the company. It then is broken down into a product portfolio—where applicable—and the product roadmap for each service and product, and ends with the corresponding Product Backlogs and Sprint Backlogs. The Product Owner needs to be familiar with all levels of the agile product stack.

14. In what way is the Product Owner a bottleneck for the Scrum Team?

    This question deals with how Product Owners can mitigate the risk they pose to the Scrum Team. Often, they slow down the team because the Product Backlog management process is insufficient. There might be several reasons for that: Product Backlog items are created shortly before a Sprint is supposed to start. Or work items do not meet quality standards, as they cannot allocate enough time for their creation and refinement. Beyond the Product Backlog management, they might not be available on short notice to answer questions during a Sprint. A useful way of Product Owner risk mitigation involves the other Scrum Team members at an earlier stage. Or they are encouraging collective ownership of the product by the Scrum Team. This approach is much supported by creating a shared understanding of goals at the team level. (Start with the “Why are we doing this?”)

15. How do you know that you are a good Product Owner?

    Adding user stories to the Product Backlog merely proves that the PO can handle the ticket system. Measuring real value to customers, however, requires a different approach. Suitable KPIs of the Product Owner’s contribution to the team would focus on the outcome, not output. Examples of such metrics are the lead-time from idea to an available feature, cycle time for valuating ideas, or NPS scores. (Learn more about Evidence-Based Management for Product Owners.)

Set 2: Product Discovery and External Stakeholders

This category of the Product Owner interview questions is branching out into the areas of product discovery and product management:

1. Do you think that Scrum is adequately handling the product discovery process?

   Lean UX, Lean Startup, Design Thinking, or Service Design are other agile practices that are much better suited for product discovery than Scrum. All that Scrum refers to is that the Product Owner is accountable for managing the Product Backlog. Supposedly, the Product Owner is the individual who knows what is valuable at any given time. But Scrum doesn’t elaborate on how the Product Owner gains this insight.

2. How do you learn about new ideas and requirements?



   Here, Product Owner candidates should explain their ideas of a product discovery process: From idea, via hypothesis, and experiment and validation. There are various ways to come up with ideas: Through analyzing market needs, industry trends, your data (analytics, NPS, etc.), and the competition. Also, regular sessions with stakeholders, such as sales and customer care, and the Scrum Team(s) tend to be fruitful. Empowering team members to spend a part of their work-time on new ideas is also a powerful practice. (Think of Gmail.) Most importantly, observing customers regularly by running continuous user tests is an effective way of gaining insights for new features, products, and services. This approach is even more useful when the whole Scrum Team actively participates in the process.

3. What practices and frameworks can you hire to learn about your customers’ needs?

   The candidate should name a few of the leading agile frameworks, such as Jobs-to-be-done, Lean UX, Lean Startup, Design Sprints, Service Design, design ethnography, and lean user testing, NPS, Voice of the Customer, and others.

4. How do you include user research in the product discovery process?

   User research, or better: user testing, should be a continuous, regular exercise in any product-driven organization. It’s a vital part of the agile build-measure-learn cycle. Practically, this means that communicating with UX designers and researchers becomes an integral part of the work of the PO and the entire Scrum Team. (Ideally, they belong to the team itself.) Also, customer feedback is continuously gathered by running frequent user interviews and observations. Moreover, these ideas also apply to technical projects, for example, API services.

   


5. How much time do you allocate to user research and understanding your customers’ needs?

   Spending 50 % of their time with customers would be great. However, if it’s less than 10 %, and if no one else is handling product discovery on behalf of the Product Owner, the product discovery process needs to be improved. For example, by relieving the PO from administrative tasks, such as user story writing. (Note: the Product Owner is not primarily a user story author.)

6. How would you design a process to handle product ideas from stakeholders and other members of the organization?

   Actively involving stakeholders and members of the general organization in the product discovery process is a sound approach. People like to have a purpose in life and be a part of something larger than themselves. So, providing a possibility to contribute to everyone without regard for their position in the organization will make working as a PO easier. A process for this level of inclusion doesn’t require fancy technology. A simple, shared spreadsheet or form is enough to kick-start it. An initial template to suggest new product features could comprise questions that address the why, the what, and the for whom. It could handle the tactical or strategic nature of the suggestion, a possible time-frame, or an estimate of the expected return on investment. Most importantly, designing the process should be kept agile: start with a simple solution, then improve it once the first experience has been made.

7. At what stage do you involve the Scrum Team in the product discovery process?

   It is highly recommended to involve the Scrum Team as early as possible in the product discovery process. There are mainly three reasons for that practice: (1) The sooner the Developers participate in the product discovery process, the lesser the chances are that solutions are pursued that are technically not viable or would not result in a return on investment. (2) An early involvement ensures that the Product Owner and the other Scrum Team members develop a shared understanding and ownership of what they will build. This helps significantly allocate resources to the right issues, maximize the customer’s value, and mitigate the investment risk. (3) Developers’ early involvement also ensures their buy-in, a higher commitment level, and the Scrum Team’s willingness to participate in all product development phases. This will provide additional motivation on the Scrum Team’s side to participate in any change needed to accomplish the goals defined for each Sprint/product release.

8. How do you determine whether an idea is a worthwhile investment?

   There are quantitative and qualitative categories, such as revenue increases, cost-cutting benefits by internal process improvements, increased customer satisfaction rates (NPS), sign-ups from customers for new products, positive customer feedback in customer care, etc. With this open question, Product Owner candidates should demonstrate their knowledge of determining what content constitutes an actionable Product Backlog, maximizing the value of the Developers’ work on behalf of the customers. It opens the area of product metrics broad. It allows for a discussion of outcomes vs. outputs, the escape from the feature factory, and how to overcome the industrial paradigm in general.

9. How do you avoid misallocating resources on features or products that no one wants?

   Product Owners can avoid misallocating resources by a firm decision at the moment when it is clear that a product or feature is not valuable or not feasible. This means that a continuous monitoring process, such as metrics or regular user tests, needs to be established. Once the build-measure-learn cycle provides proof that an idea or a product is unlikely to succeed, the resource allocation needs to stop. (Don’t allow the “sunk cost” fallacy to cloud your judgment: no matter how much has been already spent, it does not justify to continue working on the product.)

10. During which stages are Product Owners participating in planning activities?

    There are several stages in which a Product Owner should participate, starting at the portfolio level to the product stage, to the release planning, and the Sprint Planning. Participation during the vision and strategy stages is highly recommended, though.

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:

1. 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.

2. 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.

3. 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.)

4. 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.

5. 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.

6. 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.

7. 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.

8. 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?”

1. Product vision and strategy are kept confidential in your organization to prevent competitors from stealing the 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.

2. 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.

3. 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.

4. 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.

5. 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.

6. 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.

7. 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.

8. 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.)

Set 5: Product Backlog, Refinement, Work Items, Forecasts, and Estimations

This category of the Product Owner interview questions covers the Product Owner’s home turf: the Product Backlog, its refinement, and work item creation:

1. What is the purpose behind the Product Backlog refinement?

   The refinement is a continuous process to create actionable Product Backlogs that allow a Scrum Team to have a Sprint Planning at a moment’s notice.

   The Scrum Team accomplishes this level of preparedness by regularly refining Product Backlog items in small groups or with the whole Scrum Team, and not just once every Sprint as part of the Sprint Planning. The idea behind the refinement is to create a shared understanding with all team members, why a particular work item is valuable, what the Developers shall create, and how to realize the work item technically.

2. How much time should you spend on Product Backlog refinement?

   While the Scrum Guide 2020 drop the previous guidance on the time allocation, it remains a practical rule of thumb that the Scrum Team should reserve up to 10% of its time for the Product Backlog refinement.

3. How would you organize the “refining” process of Product Backlog items?

   In general, it is beneficial to structure the refinement process around questions such as:

   • What items are no longer relevant?
   • What items need to be split?
   • What items can be updated with new information?
   • Does this update change previous estimations?
   • Has the priority of specific items changed?
   • Do we have any new topics or learnings that haven’t yet been considered? (If yes, these need to be captured as new Product Backlog items.)

4. How many Product Backlog items can you work on in parallel to ensure continued relevance to customers and the company?

   It depends on several issues, such as the balance between stakeholder communication, customer research, and the Product Owner’s commitment to their Scrum Team. Working on more Product Backlog items than the team can handle in two to three Sprints at the same time might prove to be difficult, though. Often, if Product Owners cannot allocate sufficient time to a single item, they waste resources on half-baked work items of a questionable value.

5. You love using the Product Backlog as a kind of repository, adding ideas to continue working on them at a later stage. Over time, you have created over 500 tickets in various stages. What is your take: Can a Scrum Teamwork effectively on 500 tickets?

   From my experience, any Product Backlog that is larger than the scope of three or four Sprints is barely manageable if you want to maintain an actionable Product Backlog. Misusing a Product Backlog by adding hundreds of items to it is a clear sign that the Product Owner needs help from the Developers and the Scrum Master to better cope with the influx of ideas, suggestions, and requirements to avoid misallocating resources.

   Lastly, beware of appeasing nagging stakeholders by merely adding their “requirements” to the Product Backlog. This does not solve the issues; it just postpones the inevitable discussion as the stakeholders will now expect that the Scrum Team will create their Increment.

6. At what level do you include other team members in the refinement process?

   When the foundation of a Product Backlog item is ready for that. The readiness isn’t easy to generalize since it depends on the nature of the product itself, the Scrum Team’s experience, and the organization’s leadership style.

   From my experience, this influences the readiness and availability of a Scrum Team to contribute to the refinement process effectively. For creating a shared understanding of the why, what, and how of a work item among all team members, the precise moment of involvement is crucial. If the team is involved too early, the Developers may consider this a waste of their time. If the Scrum Team is involved too late—for example, all specifications have already been prepared—, they may feel not respected. If in doubt, the Product Owner should include the Scrum Master in the process.

7. How do you identify the value of a Product Backlog item?

   Some proven categories to define value are projected revenue increase, cost cutting effects, a projected growth of the customer base, and an increase in customer satisfaction rates.

   More metrics are available from Scrum.org’s Evidence-Based Management model.

8. How do you communicate to your team members the value of a backlog item?

   Product Owners communicate value with any information suitable to further the Scrum Team’s understanding. That communication can be quantitative, such as analytical data describing how a process is utilized, financial projections, an increase in conversion rates, acquiring new customers, etc.) It can also be qualitative, such as transcripts, screencasts, or videos from a user testing session.

   Preferably, the Scrum Team members already know in advance as they are regularly participating in user research activities.

9. What are good practices to order Product Backlog items?

   Criteria to determine the order of a Product Backlog item, for example, are value, risk, work estimates, available expertise, and dependencies.

10. How do you handle bugs and technical debt when many valuable new features are competing for resources?

    Focusing solely on shipping new features is a slippery slope that quickly leads to the build-up of technical debt. You trade a short-term win—shipping more features—for a long-term liability. Technical debt will inevitably slow down the creature of new Product Increments in the future, probably to a point where the product seems to be at a standstill.

    In other words: By accruing technical debt, the very purpose of becoming agile—learning faster as an organization than the competition, thus being able to exploit market opportunities—is at stake.

    Hence it is a good practice to allocate around 20 percent of the Scrum Team’s capacity to keeping technical debt at bay at any given time. Experienced Product Owners support this long-term thinking.

11. Why is user story mapping a useful technique for Product Owners?

    User story mapping a great way to visualize the “big picture” within a Product Backlog. Additionally, user story mapping is an instrumental means to improve communication with stakeholders and the Scrum Team. These workshops create a shared product understanding across teams, roles, and departments.

12. How do you best create Product Backlog items?

    The best way to create Product Backlog items, particularly user stories, is a collaborative and iterative approach, using collective inspection and adaptation, including the whole Scrum Team. User story creation should not blindly follow a specific template but rather be a lively negotiation with the team, focusing on reaching a shared understanding of “why,” “what,” and “how” with all team members.

13. What shall a good user story look like? What is it structure?

    For software development, the attributes of an exemplary user story are:

    1. The description is available,
    2. Acceptance criteria are defined,
    3. The story can be delivered within a Sprint,
    4. All UI deliverables are available,
    5. All (probable) dependencies are identified,
    6. Performance criteria are defined,
    7. Tracking criteria are defined and
    8. The story is estimated by the team. (I do believe that you cannot “not estimate” one way or another. Even the #noestimate approach includes a sizing model that is based on a kind of unspoken estimation.)

    Product Owners should be familiar with Ron Jeffries Three-Cs—Card, Conversation, Confirmation—and Bill Wake’s INVEST principle.

14. Where are you discussing user stories, only during refinement sessions?

    The best way to discuss a user story is by doing so synchronously with all involved team members to ensure that a shared understanding is created. This approach works for co-located as well as distributed Scrum Teams.

    Asynchronous discussions may be an option when team members cannot participate in a discussion or when the Product Owner is in the field, and feedback is required.

    It would help if you avoided, though, lengthy discussions via comments on tickets. That’s a sign of a weak refinement process as it creates unnecessary queues of idleness.

15. What are typical pitfalls of the Product Backlog refinement?

    Some of the typical pitfalls of a backlog refinement are:

    1. There are not enough refinement sessions, resulting in a low quality of the Product Backlog.
    2. There are too many refinement sessions, resulting in an overly detailed Product Backlog, resembling an upfront planning from the old waterfall planning ages.
    3. Turning requirement documents from stakeholders into user stories without involving the Scrum Team.
    4. Not involving the whole team in the refinement process, probably just the “lead engineer”.
    5. Not involving stakeholders.

    This open question is an invitation to Product Owner candidates to share from their previous experience and how it influenced their current understanding of proper Product Backlog management.

    There is an extensive list of anti-patterns available in the following article: 28 Product Backlog and Refinement Anti-Patterns.

16. Is it necessary to include detailed acceptance criteria with a user-story?

    Generally, acceptance criteria define the functional and non-functional requirements that need to be met. The level of detail may vary depending on the nature of the task. Hence, it is a good practice to include the Scrum Team in their creation as some of those requirements may already be addressed by the team’s Definition of Done.

17. The Scrum Team requires time to investigate a technical issue with a user story to understand its requirements better. How do you continue with the refinement process of the particular user story?

    Borrow from XP and run a spike during the next Sprint. Once the team can provide better insights to its technical side, come back to the user story, and resume the refinement.

18. One of your stakeholders presents you with such elaborate requirement documents that you copy them into Product Backlog items. Nevertheless, your Scrum Team is not pleased with this approach. Why is that?

    Product Backlog items are a token for discussion to create a shared understanding and secure the Developers’ buy-in. If the Developers are not involved in devising, disseminating, and capturing these, they do not see any ownership in such work items. This likely results in a lower level of engagement, which may negatively affect the value created for customers.

19. When would you remove a feature?

    The best way to “remove” useless features is not to build them in the first place. Simplicity and radical focus on value delivered to customers is key to any successful agile product organization.

    Should—despite all validation efforts during product discovery—a feature of lesser value slip into the Product Backlog and be delivered, it should be removed as soon as possible from the live product. The same applies to an existing feature that has outlived its usefulness.

Scrum Product Owner Interview Questions Set 6: Sprint Planning, Sprint, Sprint Review, and Retrospective

The sixth category that addresses the Sprint itself:

1. You are pushing for a critical user story to be selected for the next Sprint. Unfortunately, the final front-end designs still are missing, but the designers promise to deliver no more than two days late into the Sprint. The Scrum Master, however, rejects this idea; the work item is not ready to be selected for a Sprint. What can you do?

   It is a negotiation with the Scrum Team. The answer depends on the team’s situation and experience: If the designers are likely delivering—they have always kept their promises in the past—, and the Developers could accomplish the user story nevertheless within the Sprint, and the Developers agree with the situation, it is probably an acceptable exception.

   Ultimately, the Scrum Team’s decision is whether to pick the work item for the next Sprint.

2. Do you recommend that a Product Owner shall assign work items to individual members of the Scrum Team?

   That is unacceptable behavior, as the Developers are self-organizing. Hence distributing tasks among themselves is their prerogative.

3. Should the Product Owner attend the whole Sprint Planning?

   Let’s have a closer look at the Sprint Planning:

   The Product Owner presents the business objective of the next Sprint to the Scrum Team. Collaboratively, the Scrum Team creates the Sprint Goal. The Developers then pick— considering all circumstances, for example, available capacity—those Product Backlog items they deem necessary to achieve the Sprint Goal. The presence of the Product Owner during this part of the Sprint Planning is essential.

   Often, the Developers now add details to the Sprint Backlog items, for example, splitting them up into tasks, identifying parts that need further clarification, or agreeing on who will be working on what tasks. Product Owners do not necessarily need to participate in this part of the Sprint Planning. But they need to be on stand-by for additional questions.

4. Should the Product Owner attend the Daily Scrums?

   By all means, yes. That way, the Product Owner can answer quickly, thus avoiding unnecessary delays.

5. Your Scrum Team, at least that is your impression, regularly estimates work items at the upper end of the possible range. You believe that they are playing safe, creating buffers for “rainy days.” How do you address this?

   Trust is the beginning of all. And the Developers do not trust the process, or the line management, or the stakeholders. This mistrust might be rooted in the organization’s culture, a former experience, or the work item’s quality. The team might also be too junior to understand some work items’ implications fully. Or the product is suffering from technical debt, which makes estimates generally more volatile.

   The candidate should name some reasons for the behavior and suggest joining with the Scrum Master to provide the team with a path to let this habit go. The issue would make an outstanding topic for the Sprint Retrospective.

6. A stakeholder tends to broaden the scope of a user story in retrospect by claiming the Scrum Team did not deliver what was requested. How do you deal with that?

   This kind of stakeholder behavior is not acceptable. It is the Product Owner’s objective to understand the scope of a feature request in advance clearly. Sneaking in features through the backdoor a typical Scrum anti-pattern that needs to be investigated and addressed.

   This question opens the discussion on how to deal with selfish stakeholders, particularly in organizations that haven’t yet fully embraced the Product Owner concept.

7. Does the Product Owner have a veto when the release of Product Increments is concerned?

   The Scrum Guide is not explicit about this situation. On the one side, the Scrum Team decides on when to release what Increment to the customers. On the other side, the Product Owner is “is accountable for maximizing the value of the product resulting from the work of the Scrum Team.”

   This question opens the discussion on Scrum’s built-in checks and balances and how effective collaboration within the Scrum Team might work.

8. Do you have to release every Product Increment that was finished during a Sprint?

   The Scrum Team decides on when to release what Increment to the customers. There is no automatism for the release.

9. How would you organize the Sprint Review?

   It is not the Product Owner’s task to organize the Sprint Review, but the whole Scrum Team should be eager to experience it. The Sprint Review is a critical opportunity to inspect the previous Sprint’s outcome and adapt the Product Backlog to serve the customers with the next Sprint best.

10. During the Sprint Review, the Developers show new functionality you have never seen before. How do you react?

    This behavior is undoubtedly an anti-pattern of a successful Scrum Team as it violates several Scrum principles, for example, providing transparency or adhering to openness and respect.

    First of all, Developers should never work on items the Product Owner does not know. Bypassing the Product Owner in that respect shows a significant deficit in understanding Scrum basics and should immediately be addressed in collaboration with the Scrum Master. (Learn more: Gold-Plating Beyond Done — Making Your Scrum Work #7.)

11. At the end of the Sprint, do you participate in the Retrospective?

    Absolutely, Product Owners are members of the Scrum Team. Hence they participate in the Sprint Retrospective.





PO Interview Questions Set 7: Product Owner Anti-Patterns

The seventh category of the Product Owner interview guide addresses PO anti-patterns from the management of the Product Backlog—including refining Product Backlog items—to the Sprint Planning and to the Sprint Review:

Product Backlog and Product Backlog Refinement

Question: What anti-patterns come to your mind when you think of the Product Owner’s responsibility to manage the Product Backlog?

Some of the typical Product Owner anti-patterns in handling the backlog are as follows:

• Storage for ideas: The Product Owner is using the Product Backlog as a repository of ideas and requirements. (This practice is clogging the Product Backlog, may lead to cognitive overload, and makes alignment with the ‘big picture’ at portfolio management and roadmap planning level very challenging for all participants, be it stakeholders or Scrum team members.)
• Part-time PO: The Product Owner is not working daily on the Product Backlog. (The Product Backlog needs to represent the best use of the Developers’ time at any given moment. Therefore, it needs to be “actionable” 24/7. Updating it once a week before the next refinement session or Sprint Planning does not suffice to meet this condition.)
• Copy & paste PO: The Product Owner creates user stories by breaking down requirement documents received from stakeholders into smaller chunks. (That scenario helped to coin the nickname “ticket monkey” for the Product Owner. Remember: Product Backlog item creation is a team exercise in most cases.)
• Dominant PO: Checks and balances: The Product Owner creates Product Backlog item by providing not just the ‘why’ but also the ‘how’ and the ‘what’. (The team answers the ‘how’ question – the technical implementation –, and both the team and the PO collaborate on the ‘what’ question: what scope is necessary to achieve the desired purpose.)
• Prioritization by proxy: A single stakeholder or a committee of stakeholders prioritizes the Product Backlog. (The strength of Scrum is building on the solid position of the Product Owner. The PO is the only person to decide what work items become Product Backlog items. Hence, the Product Owner also decides on the ordering of the Product Backlog. Take away that empowerment, and Scrum turns into a pretty robust waterfall 2.0 process.)
• 100% in advance: The Scrum Team creates a Product Backlog covering the complete project or product upfront because the release scope is limited. (Question: how can you be sure to know today what to deliver in six months from now—even if you believe you understand the scope today?)
• Over-sized: The Product Backlog contains more items than the Scrum Team can deliver within three to six Sprints, give or take. (This way, the Product Owner creates waste by hoarding issues that might never materialize.)
• Outdated issues: The Product Backlog contains items that haven’t been touched for six to eight weeks or more. (That is typically the length of two to four sprints. If the Product Owner is hoarding backlog items, the risk emerges that older Product Backlog items become outdated, thus rendering previously invested work of the Scrum Team obsolete.)
• Everything is estimated: All items of the Product Backlog are detailed and estimated. (That is too much upfront work and bears the risk of misallocating the Scrum Team’s time.)
• Component-based items: The Product Backlog items are sliced horizontally based on components instead of vertically based on end-to-end features. (This may be either caused by your organizational structure. Then move to cross-functional teams to improve the team’s ability to deliver. Otherwise, the Scrum team needs to strengthen their skills of writing user stories probably.)
• Missing acceptance criteria: There are work items in the Product Backlog without acceptance criteria. (While it is unnecessary to have acceptance criteria at the beginning of the refinement cycle, they would make the task much more manageable.)
• No more than a title: The Product Backlog contains item that comprise of little more than a title. (See above.)
• Issues too detailed: The Product Owner invests too much time upfront in creating Product Backlog items making them too detailed. (If a work item looks complete, the team members might not see the necessity to get involved in further refinement. This way, a “fat” item reduces the team’s engagement level, compromising the creation of a shared understanding. By the way, this didn’t happen back in the days when we used index cards given their physical limitation.)
• No research: The Product Backlog contains few to no spikes. (This often correlates with a Scrum team spending too much time discussing future problems instead of researching them hands-on as part of an iterative creation process.)
• What team? The Product Owner is not involving the entire Scrum Team in the refinement process and instead is relying on just the “lead engineer” (or any other member of the team independently of the others).

Sprint Planning Anti-Patterns

Question: What comes to your mind when you think of PO anti-patterns during Sprint Planning?

Some of the typical Product Owner anti-patterns during the Sprint Planning are as follows:

• What are we fighting for? The Product Owner cannot align the business objective of the upcoming Sprint with the overall product vision and the Product Goal. (A serious goal answers the “What are we fighting for?” question. It is also a negotiation between the Product Owner and the rest of the Scrum team to a certain extent. It shall be focused and measurable. The Developers’ forecast, the Sprint Goal, and the business objective go hand in hand.)
• No business objective, no Sprint Goal: The Product Owner proposes Product Backlog items that resemble a random assortment of tasks, providing no cohesion. Consequently, the Scrum Team does not create a Sprint goal. (If this is the natural way of finishing your Sprint Planning, you probably have outlived the usefulness of Scrum as a product development framework. Depending on the maturity of your product, Kanban may prove to be a better solution. Otherwise, the randomness may signal a weak Product Owner who listens too much to stakeholders instead of ordering the Product Backlog appropriately.)
• Unfinished business: UUnfinished Product Backlog items from the last Sprint spill over into the new Sprint without any discussion. (There might be good reasons for that, for example, a task’s value has not changed. It should not be an automatism, though; remember the sunk cost fallacy.)
• Last-minute changes: The Product Owner tries to squeeze in some last-minute Product Backlog items that are not ready yet. (Principally, it is the prerogative of the Product Owner to make such kinds of changes to ensure that the Development Team is working only on the most valuable tasks at any given time. However, if the Scrum Team is practicing Product Backlog refinement sessions regularly, these occurrences should be a rare exception. If those happen frequently, it indicates that the Product Owner needs help ordering the Product Backlog and communicating with the team. Or the Product Owner needs support to say ‘no’ more often to stakeholders.)
• Output focus: The Product Owner pushes the Developers to take on more tasks than they could realistically handle. Probably, the Product Owner is referring to former team metrics such as velocity to support their desire. (This behavior is a road to becoming a feature factory and deserves attention from the team’s Scrum Master. Furthermore, it violates both the Developers’ prerogative to pick Product Backlog items for the Sprint Backlog and Scrum Values.)
• No preparation: The Product Owner does not prepare the Product Backlog to provide valuable Product Backlog items in time. (Product Backlog needs to represent the best possible use of the Developers’ work from a customer value perspective at any given moment. In other words, your Scrum Team’s Product Backlog has to be actionable 24/7. By my standards, that means that you need to be capable of running a meaningful Sprint Planning instantly. Therefore, preparing a few basic Product Backlog items an hour before the beginning of the Sprint Planning is not enough.)

Sprint Anti-Patterns

Question: Could you please name some PO anti-patterns that might occur during the Sprint?

Some Sprint-related Product Owner anti-patterns are as follows:

• Absent PO: The Product Owner is absent most of the Sprint and is not available to answer questions of the Developers. (As the Sprint Backlog is emergent and the Developers may identify new work to achieve the Sprint Goal, this attitude might leave the Developers in the dark, risking the accomplishment of the Sprint Goal.)
• PO clinging to tasks: The Product Owner cannot let go of Product Backlog items once they become part of the Sprint Backlog. For example, the Product Owner increases the scope of a work item. Or, they change acceptance criteria once the Developers accept the issue into the Sprint Backlog. (There is a clear line: before a Product Backlog item becomes part of the Sprint Backlog, the Product Owner is responsible. However, once it moves from one backlog to the other, the Developers become responsible. If changes become acute during the Sprint, the team will collaboratively decide on how to handle them.)
• Inflexible PO: The Product Owner is not flexible to adjust acceptance criteria. (If the work on a task reveals that the agreed-upon acceptance criteria are no longer achievable or wasteful, the Scrum Team needs to adapt to the new reality. Blindly following the original plan violates core Scrum principles.)
• Delaying PO: The Product Owner does not provide feedback on work items once those are done. Instead, they wait until the end of the Sprint. (The Product Owner should immediately provide feedback on work items; that is essential for a good workflow with the team. Otherwise, the Product Owner will create an artificial queue within the Sprint, unnecessarily increasing the cycle time. This habit also puts reaching the Sprint Goal at risk.)
• Misuse of Sprint cancellation: The Product Owner cancels Sprints to impose their will onto the team. (It is the prerogative of the Product Owner to cancel Sprints. However, the Product Owner should not do this without a serious cause. The Product Owner should also never abort a Sprint without consulting the other team members first. Probably, the team has an idea of how to save the Sprint. Lastly, misusing the cancellation privilege also indicates a severe team collaboration issue.)
• No Sprint cancellation: The Product Owner does not cancel a Sprint whose Sprint Goal can no longer be achieved. (If the Scrum team identified a unifying Sprint Goal, for example, integrating a new payment method, and the management then abandons that payment method mid-sprint, continuing working on the Sprint Goal would be a waste. In this case, the Product Owner should consider canceling the Sprint.)

PO Interview Questions Set 8: The Product Mindset

Becoming an agile, learning organization focused on creating customer value is about developing a product mindset everywhere, from the individual to the C-level. Employing Scrum can be a major stepping stone on this journey when the management empowers Product Owners and is not merely regarding Scrum as a delivery means to ship more features, products, and services within the constraints of the iron (project) triangle.

Again, a fully formed and empowered product owner is crucial for a transformation success at that level. The following set of questions regarding the product mindset is designed to better understand a candidate’s perspective: Do they probably have what it takes to fill the shoes of the Product Owner role?

Q 77: First Principles of the Product Mindset

Looking back at your professional experience, can you name some first principles of a Product Owner with a product mindset?

This question allows the Product Owner candidate to reflect on their core beliefs of product management in general and the Product Owner role in particular. My top three choices of the first principles of the product mindset are:

1. A successful Product Owner is an agile product manager at heart.
2. Product Ownership is a leadership position in the first place. It is not about churning out deliverables at an ever-increasing speed to maximize the output of the Scrum team. Great Scrum teams abandon the feature factory early.
3. Stakeholder collaboration is essential to becoming a successful Product Owner. Having the final say on the composition and ordering of the Product Backlog does not mean monopolizing the decision-making process. Successful Product Owners learn to lead and delegate early.

Q 78: The Product Focus of Successful Product Owners

You have worked with Product Owners (and product managers) in the past. How did the successful ones master the challenges of the role? Moreover, where did the less successful ones fail?

In my experience, successful Product Owners manage to split their time between different responsibilities and stakeholders without getting lost in details or failing to communicate appropriately while guiding everyone in the right direction: Accomplishing the product vision.

The key to achieving this level of alignment among the critical stakeholders is that they know how to delegate decisions while being transparent about the underlying system. Moreover, they include everyone at a meaningful level in the subsequent communication and collaboration, respectively, using the “vision, validation, value” approach.

A less successful PO typically fails to have a product mindset and act as a team player. They fail at being product leaders. Instead, they are typically stuck in the scribe mode, refusing to delegate work that others can perfectly handle for them. For example, there is no reason why a PO would create and write all Product Backlog items themselves. In my experience, Developers can author PBi very well.

Also, they tend to shield the rest of the Scrum team from communicating with stakeholders, namely customers and users. Establishing these team-internal functional silos — Developers develop and do not talk to customers — often lowers innovation and productivity. Generally, they tend to create a bubble for themselves where falling victim to confirmation bias is not uncommon. They start loving their solution instead of the customers’ problem.

Additionally, less successful Product Owners also tend to invest less in creating a product mindset throughout the organization. For example, they rely less on joined work sessions with stakeholders like user story mapping, value stream mapping, or impact mapping. Also, they are less transparent about the status quo and where the Scrum team is heading.

Q 79: The Product Mindset in a Quickly Growing Organization

Your new product proves to be very desirable in the market, and your organization—and hence the number of Scrum teams and stakeholders—is increasing rapidly in size. So, how do you preserve a product mindset as the responsible Product Owner?

Here, the candidate should point at the importance of embracing empiricism, self-management, and autonomy to deliver value to customers within the constraints of the organization while creating a sustainable return on investment for the latter:

• Embrace self-management as a good way to cope with increasing demands regarding the Product Owner’s contributions.
• Delegate work to other Scrum team members, particularly regarding Product Backlog management and refinement.
• Create a transparent system to structure product discovery by including stakeholders.
• Be transparent about the upcoming work and artifacts to allow for inspection and adaptation.
• Go the extra mile with stakeholders (internal and external) to ensure their active participation in Scrum events.
• Generally, foster alignment and collaboration among stakeholders and Scrum team members.
• Set up and support a training program for stakeholders to understand the needs and opportunities of the product department better.

Q 80: Growing the Product Mindset as a Product Owner in Your Organization

In what ways can you support your personal growth as a Product Owner if your organization is still stuck in the old ways and far from developing a product mindset?

Even the longest journey starts with the first steps. If the “Product Owner” position is currently that of a glorified scribe taking requirements from stakeholders, and you aim to move to the entrepreneur level, I would at least explore the following steps:

• Convince the organization that becoming a learning organization by applying Scrum in a complex environment is not just a hiring technique but a sound business decision. Achieving business agility will pay dividends for everyone.
• The best way to do so is to succeed as a Scrum team within the given constraints.
• Consequently, support your Scrum team on its path to fully embrace Scrum, namely self-management, as the entrepreneur level is focused on product leadership. The groundwork, such as Product Backlog item creation and refinement, will need to be handled by others.
• Invest in networking within the organization by including stakeholders in the Scrum team’s work, for example, regarding product discovery. The further towards the entrepreneur level a PO moves, the more support they need from the C-level.
• Be transparent in everything you do. Moreover, be unbiased and non-corruptible at the same time.
• Be generous in supporting stakeholders in whatever form is necessary, for example, by offering training classes, authoring internal newsletters, or promoting Scrum events within the organization.

Q 81: Spreading the Product Focus among Scrum Teammates

How can you help other Scrum team members, namely the developers, develop a product mindset?

Speaking with John Doerr, you want missionaries, not mercenaries on your team. To achieve that state, I would recommend taking the following steps:

• Encourage Product Backlog management by Developers, for example, by ensuring that Developers fully understand the big picture, starting with the ‘Why.’
• Possible other Scrum team activities are collaboratively working on Product Goals, customer and user personas, impact maps, user story maps, prototypes, marketing strategies, business plans and models, stakeholder maps/radars, etc.
• Involve Developers in product discovery activities, for example, user research. (Having Developers observe or talk to customers and users is highly beneficial in my experience.)
• Encourage everyone on the team to regularly work in customer care to better understand everyday issues our product or service causes.

Please note that not all Developers feel comfortable with the idea of investing much time in communicating or collaboration with stakeholders while neglecting to build the product or service. (Some just like to solve puzzles all day long — which is okay as you cannot force people to get involved in these activities.)

Q 82: Engaging with Stakeholders to Further the Product Focus

So, embracing a “customer problem first” perspective, thus developing a product mindset throughout the organization, seems to be a good bet to create value for everyone. How would you engage with different groups of stakeholders in the process? How have you done so successfully in the past?

The question is designed to provide the Product Owner candidate with room to share their experience and shine. Also, it is about understanding whether they have a holistic approach to stakeholder communication and what drives a stakeholder to interact with a Scrum team. Interacting comes in many different forms, from exercising control to pursuing goals (probably also personal agendas) to being kept in the loop. The candidate should have explored some of the following approaches to stakeholder engagement:

Engaging with users:

• Invest in continuous user research, including all Scrum team members.
• Invite users to Sprint Reviews.
• Invite users to collaborative exercises, for example, user story mapping, etc.
• Encourage Scrum team members to work in customer care to understand better user needs regularly.
• Create a transparent system to support continuous product discovery and invite your users.

Engaging with providers:

• Apply the same rules to providers and contractors that apply to everyone on the team or within the organization.
• Make providers and contractors “full” team members, down to the level of email addresses.
• Consequently, do not privilege internal team members over external ones if not mandated for legal or governance reasons.

Engaging with governance people:

• Understand the constraint they are working under; try walking in their shoes.
• Include the governance people as early as possible in the Scrum team’s work, for example, regarding creating a Definition of Done.
• Align with them on roadmaps, Product Goals, and other near- and mid-term planning exercises.
• Know your (governance) stakeholder: The best tech is not necessarily the best solution from a compliance perspective. (In my experience, for example, a continuous delivery capability can turn out to be unnecessary gold-plating and thus waste if a legally required audit takes a week anyway.)
• Be cautious, though, that some governance stakeholders may be tempted to use your openness to strengthen their position within the organizational power-play.

Engaging with influencers:

• Learn to distinguish between the formal role of “influencer” and the individual that genuinely exercises influence. Sometimes, the formal role bearer and the real influencer are not identical.
• Invest in networking within the higher levels of the organization to build rapport with prospective influencers and learn early about change coming your way.
• Keep your friends close, keep your opponents closer.

Update 2022-01-13: The Product Owner Interview Questions: The Product Mindset

This latest update to the interview guide addresses product mindset; see questions 77 to 82.

Update 2021-09-21: The Product Owner Interview Questions Enhanced by Product Owner Anti-Patterns

This latest update to the interview guide addresses Product Owner anti-patterns from Product Backlog management and refinement to the Sprint Review; see questions 72 to 76.

Update 2020-06-20: The Product Owner Interview Enhanced by Remote Scrum with Distributed Teams

How can we learn during the Product Owner interview whether a candidate has experience with facilitating remote agile events?

To figure out the candidate’s competence level, I like to run a Liberating Structures-based exercise during the interview. I use TRIZ to task the Product Owner candidate to come up with suggestions on how to sabotage a remote Scrum approach effectively when talking to teammates, internal stakeholders or customers. (Who is considering running user tests in person at the moment?)

These are some of the remote agile anti-patterns the candidate should be able to identify:

• Remote Agile is just standard work-life plus Zoom: Pretending that working remotely is the same as usual except for the video cameras. (This approach ignores all the challenges that distributed teams face, for example, not investing enough in getting to know each other better to build trust. We are Social animals and need to meet In person sooner or later to build lasting trust among teammates, thus creating psychological safety. Moreover, there are difficulties in reading the virtual room in general, which means that taking decisions to the team or calling out introverts manifest themselves differently in a remote working setup. Trust is the beginning of all; without it, transparency, inspection, and adaptation would be able to work their magic, and we end up as distributed feature factories.)
• Neither fish nor meat: Hybrid events create two classes of teammates — remote and co-located — where the co-located folks are calling the shots. (Beware of the distance bias—when out of sight means out of mind—thus avoiding the creation of a privileged subclass of teammates: “Distance biases have become all too common in today’s globalized world. They emerge in meetings when folks in the room fail to gather input from their remote colleagues, who may be dialing in on a conference line.” (Source.) To avoid this scenario, make sure that once a single participant joins remotely, all other participants “dial in,” too, to level the playing field.
• Surveillance: Trust won’t be built by surveilling and micro-managing team members. Therefore, don’t go rogue; the prime directive rules more than ever in a remote agile setup. Trust in people and do not spy on them — no matter how tempting it might be. (Read more about the damaging effect of a downward spiraling trust dynamic from Esther Derby.) https://www.estherderby.com/the-future-may-be-remote-must-it-include-surveillance/
• Mindless rituals: Leadership belief and or facilitation practices turn once useful routines into mindless rituals. (For example, think of Groundhog Day-style retrospectives over and over again. Answering the same three questions every single time is the easiest path to kill any form of creativity and collaboration. While this is hard to avoid in face-to-face environments, it requires much more dedication and energy in a remote agile setting.)
• Death by PowerPoint: Meetings still revolve around an individual broadcasting a slide deck. (While you might get away with this approach for some time in face-2-face environments, it will not fly with distributed teams. Sessions need to inclusive, interactive, and engaging to entice collaboration, think Liberating Structures, and Training from the Back of the Room.)
• Unstructured communication: “Didn’t you get the memo?” (There is no clear practice on how to communicate which kind of information to whom. Are we talking about email, Slack, the team wiki, a Github comment, or the biweekly remote brow bag session? This lack of structure and agreement leads to stress—how can I avoid missing important news now that there is no longer a watercooler; do I have to monitor all Slack channels in real-time—and probably a feeling of being excluded. Maybe, this effect is just a missing update to the working agreement or team charter. But what if it is done deliberately? (Honi soit qui mal y pense.) in a remote agile environment always requires to overcommunicate and be completely transparent.)

For a comprehensive list of anti-patterns, read Remote Agile (Part 4): Anti-Patterns — Pitfalls Successful Distributed Teams Avoid.

Conclusion: How to Use These 82 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.

Regarding certifications of candidates, I recommend looking out for those with PSPO I, PSPO II, and particularly PSPO III certificates from Scrum.org.

📖 Related Posts

60 Scrum Master Interview Questions to Identify Suitable Candidates.

Product Owner Anti-Patterns — 31+2 Ways to Improve as a PO.

Peer Recruiting: How to Hire a Scrum Master in Agile Times

The Scrum Guide Reordered — understand the Scrum Guide’ patterns and concepts quickly to avoid hiring imposters.

Download the ’Scrum Anti-Patterns Guide’ for Free

✋ Do Not Miss Out: Join the 11,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.

📅 Scrum Training Classes, Workshops, and Events

You can secure your seat for Scrum training classes, workshops, and meetups directly by following the corresponding link in the table below:

See all upcoming classes here.

You can book your seat for the training directly by following the corresponding links to the ticket shop. If the procurement process of your organization requires a different purchasing process, please contact Berlin Product People GmbH directly.

Tags: Product Owner