Tag Archives: prioritising


Product Owner vs. ScrumMaster

The product owner and ScrumMaster are two different roles that complement each other. If one is not played properly, the other suffers. As the product owner, you are responsible for the product success — for creating a product that does a great job for the users and customers and that meets its business goals. You therefore interact with users and customers as well as the internal stakeholders, the development team and ScrumMaster, as the following diagram shows.


The grey circle in the picture above describes the Scrum Team consisting of the product owner, the ScrumMaster and the cross-functional development team.

The ScrumMaster is responsible for the process success — for helping the product owner and the team use the right process to create a successful product, and for facilitating organisational change and establishing an agile way of working. Consequently, the ScrumMaster collaborates with the product owner and the development team as well as senior management, human resources (HR), and the business groups affected by Scrum, as following pictures illustrates:


Succeeding as a product owner requires the right skill set, time, effort, and focus. So does playing the ScrumMaster role. Combining both roles – even partially – is not only very challenging but means that some duties are neglected. If you are the product owner, then stay clear of the ScrumMaster duties!

What the Product Owner should Expect from the ScrumMaster

As a product owner, you should benefit from the ScrumMaster’s work in several ways. The ScrumMaster should coach the team so that the team members can build a great product, facilitate organisational change so that the organisation leverages Scrum, and help you do a great job:


The following table details the support you should expect from the ScrumMaster:

Service Details
Team coaching
  • Help the team collaborate effectively and manage their work successfully so that they can make realistic commitments and create product increments reliably.
  • Encourage the team to work with the product owner on the product backlog.
  • Ensure that the team has a productive work environment.
Organisational change
  • Work with senior management, HR and other business groups to implement the necessary organisational changes required by Scrum.
  • Educate the stakeholders about what’s new and different in Scrum, explain their role in the agile process, and generate support and buy-in.
  • Resolve role conflicts such as product owner vs. product manager and product owner vs. project manager.
Product owner coaching
  • Help the product owner choose the right agile product management techniques and tools.
  • Support the product owner in making product decisions and tackle product owner empowerment issues.
  • Help establish agile product management practices in the enterprise.

The ScrumMaster supports you as the product owner so that you can focus on your job – making sure that the right product with the right user experience (UX) and the right features is created. If your ScrumMaster does not or cannot provide this support, then talk to the individual, and find out what’s wrong. Don’t jump in and take over the ScrumMaster’s job. If you don’t have a ScrumMaster, show the list above to your senior management sponsor or to your boss to explain why you need a qualified ScrumMaster at your side.

What the ScrumMaster should Expect from the Product Owner

It takes two to Tango, and it’s only fair that your ScrumMaster has expectations about your work as the product owner. The following picture illustrates some of them:


The table below describes the ScrumMaster’s expectations in more detail:

 Service  Details
Vision and Strategy
  • Provide a vision to the team that describes where the product is heading.
  • Communicate the market, the value proposition and the business goals of the product.
  • Formulate a product or release goal for the near to mid term.
Product Details
  • Proactively work on the product backlog. Update it with new insights and and ensure that there are enough ready items.
  • Provide direction and make prioritisation calls.
  • Invite the right people and choose the right techniques to collect feedback and data, for instance, invite selected users the review meeting and carry out a usability test.
  • Be available for questions and spend time with the team.
  • Buy into the process and attend the sprint meetings.
  • Manage the stakeholders and make tough decisions; say no to some ideas and requests.

You can find more a more comprehensive description of the product owner duties in my post “The Product Owner Responsibilities“.

Learn More

To learn more about the collaboration between the product owner and the ScrumMaster attend my Certified Scrum Product Owner training course. Please get in touch if you have in questions or if would like me to teach the course on-site.

If you feel that your ScrumMaster would benefit from improving her or his work, then I recommend Geoff Watt’s book “ScrumMastery: From Good to Great Servant Leadership”.

Working with a sprint goal is a powerful agile practice. This post helps you understand what sprint goals are, why they matter, how to write and to track them.

The Sprint Goal Explained

A sprint goal summarises the desired outcome of an iteration. It provides a shared objective, and it states why it’s worthwhile undertaking the sprint. Sample sprint goals are “Learn about the right user interaction for the registration feature”, or “Provide the missing reporting functionality”.

As a rule of thumb, every sprint should have one shared goal. This ensures that everyone moves in the same direction. Once the goal has been selected, the team implements it. Stakeholder feedback is then used to understand if the goal has been met, as the following picture shows.

Sprint Goal Benefits

I have found that working with a sprint goal has five main benefits, particularly for new products and new features: It facilitates prioritisation and effective teamwork; it makes it easier to obtain and analyse feedback; and it helps with stakeholder communication.

Supports Prioritisation

A shared sprint goal facilitates prioritisation: It makes it easier to determine which stories should be worked on in the next cycle. Here is how I do it: I first select the goal. Then I explore which epics have to contribute to it, and I break out small detailed stories from the epics. Finally, I order the new ready stories based on their contribution to the goal.

Creates Focus and Facilitates Teamwork

Sprint goals create focus, facilitate teamwork, and provide the basis an effective sprint planning session. A shared objective guides the development work, encourages creativity, and enables commitment. Teams don’t commit to individual stories in Scrum; they commit to the sprint goal.

Helps Obtain Relevant Feedback

Employing a sprint goal makes it easier to collect the right feedback. If the goal is to evaluate the user experience, for instance, then it is desirable to collect feedback from actual target users. User representatives should therefore attend the sprint review meeting. But if the goal is to reduce technical risk by evaluating different object-relational mapping tools, then it is probably more appropriate to invite an experienced developer or architect from another team to discuss the solution.

Makes it Easier to Analyse the Feedback

Working with a sprint goal helps analyse the feedback obtained. If the team works on several unrelated stories in the same sprint then it can be tricky to relate the feedback to the right user story. This makes it harder to understand if the right product with the right features is being built.

Supports Stakeholder Communication

Finally, imagine meeting the big boss in the elevator and being asked what you are working on. Chances are that without a sprint goal, the boss will be bored to death, jump onto a specific story, or he will have left the elevator before you are finished listing all the things you do. Using a sprint goal helps you communicate the objective of the sprint to the stakeholders. This allows them to understand what the sprint is about and to decide if they should attend the next sprint review meeting.

Writing Great Sprint Goals

Like any operational goal, a sprint goal should be SMART: specific, measurable, attainable, relevant, and time-bound. As sprints are time-boxed iterations, every sprint goal is naturally time-bound: It has to be reached by the end of the sprint.

A relevant sprint goal helps you address the most important challenge, and it moves you closer towards your vision or release goal. For a new product or a bigger product update, the main challenge in the early sprints is to resolve uncertainty and to mitigate the key risks. To determine where the greatest risk currently is, I use the three innovation drivers – desirability, feasibility, or viability – as the following picture shows.

A sample goal of an early sprint is to learn more about the desired user experience (a desirability aspect), the software architecture (feasibility), or the pricing model (viability). To pick the right goal, choose the risk that is likely to hurt you most if it is not addressed immediately.

When selecting your sprint goal, remember that trying out new things requires failure. Failure creates the empirical data required to make informed assumptions about what should and can be done next. Failing early helps you succeed in the long term.

After you have run a few sprints, the emphasis usually starts to shift from resolving uncertainty to completing features so that they can be released – at least to selected users. This allows you to gather quantitative data and to understand how users employ your product in its target environment. The shift should be reflected in your sprint goal, which now focuses on “getting stuff done” rather than testing ideas, as the picture below illustrates. (I explain this development in more detail in my post “Get Your Focus Right“.)

Employing a specific and measurable sprint goal allows you to determine success. For instance, don’t just state “Create a prototype” as your sprint goal. Be explicit about the type and its purpose. Say instead: “Create a paper prototype of the user registration feature to test our user interaction ideas.”

The default mechanism in Scrum to determine success is to analyse the stakeholder feedback. Scrum suggests that the feedback should be obtained in the sprint review meeting by presenting the product increment. If this is not appropriate for you, then I suggest you make your approach explicit in your sprint goal. Write, for instance: “Test the user interaction design of the registration feature by conducting a user test in the sprint review meeting.”

Carrying out sprint planning activities ensures that the sprint goal is attainable. Traditionally, this involves selecting user stories that are required to reach the goal until the team’s capacity has been consumed. Sprint planning hence allows the product owner and the team to understand if the goal chosen can be reached. This helps you to invite the right stakeholders and be confident that they can provide meaningful feedback. Unrealistic sprint goals waste the stakeholders’ time and undermine their willingness to participate in the process.

Visualising and Tracking the Sprint Goal

To ensure that the sprint goal is fully leveraged, I visualise it. My Product Canvas tool contains a ready section with items for the next sprint, as the picture below shows. I place the sprint goal at the top of the ready section, and I determine the stories required to reach the goal. These are then listed underneath the goal.

As part of creating the task board or sprint backlog, I move the sprint goal from the product canvas onto the board. This helps ensure that the team keeps the goal in mind when implementing the individual stories.


“You’ve got to be very careful if you don’t know where you are going, because you might not get there,” says Yogi Berra. Employing a sprint goal increases that chances of getting where you want to go, of creating a successful product.

You can find out more about employing sprint goals effectively by attending my Certified Scrum Product Owner training course.

One of the things I love about user stories is their flexibility. A user story can be big, medium-sized, or small. This allows us to sketch a product with big stories, and then progressively add more detail and refine them into smaller user stories, as we learn more about how to meet the user needs.

But this flexibility comes at a price: I often see user stories that are too small or too big, that contain too much or not enough information. Deriving the right stories, and getting the level of detail right can be challenging.

This post suggests a simple, yet effective solution: distinguishing between two types of user stories, epics and ready stories, and deriving the ready stories with the help of a shared sprint goal or hypothesis.


Epics are big, coarse-grained user stories. An epic sketches a feature or bigger piece of functionality. It acts as a placeholder for more detailed stories. Think of the epos Odyssey. It’s a collection of stories about the adventures of Ulysses including meeting the Sirens, and defeating a Cyclops.

Epics allow you to sketch the product functionality without committing to the details. This is particularly helpful for new products or major product updates, as it buys you time to learn more about the users and how to best meet their needs. It also reduces the time and effort required to integrate new insights: If you have lots of detailed stories, then it’s often tricky to relate the feedback you receive to the right stories, and it can be a big effort to change them without introducing inconsistencies. Let’s have a look at a sample epic:

The epic above tells us that the persona John wants to register for an event. The details of the event and the registration are left open for now. Similarly, the acceptance criteria – captured on the right card – are sketchy too. The details will emerge, as we learn more about the event registration by developing software and exposing it to the right people.

Ready Stories

Ready stories are small, detailed stories that can be implemented. These stories have to be clear, feasible, and testable: Everyone should have a shared understanding of the story’s meaning; the story should not too big or complex; and there has to be an effective way to determine if the functionality works as expected.

A ready story should also take into account additional aspects: the user interface design and the operational qualities that are specific to the story. Examples of the latter are performance or interoperability. I prefer to work with a paper-based design sketch to capture the user interface, and constraint story cards to describe the qualities, as the following picture shows.

The ready story above is much more specific and detailed than the sample epic discussed earlier: The details enable the development team to implement and test the story successfully.

From Epics to Ready Stories

So far we’ve simplified things by distinguishing between epics and ready stories. But we haven’t discussed yet how ready stories are derived from epics. My solution is to identify a sprint goal or hypothesis for the next iteration before the ready stories are written, as the following picture illustrates:

Step 1: Write the Epics

Let me show you how this process can be applied using my Product Canvas tool. The canvas is essentially a multi-dimensional backlog that allows you to describe your product holistically.

The Product Canvas supports working with epics and ready stories by providing dictated sections. It also offers the context for finding the right epics: The user journeys – scenarios, workflows, or storyboards – are a great hunting ground for epics. The epics are placed on the “Epics” section, as the following picture illustrates.

Step 2: Select the Goal of the Next Sprint

Once the epics sketching the product’s main functionality have been written, I populate the design and constraints sections on the canvas. Then I select the goal of the next sprint – either to address the most critical risk and/or to deliver functionality to the stakeholders including the users. Examples of a sprint goal are: “Validate our central user interface design ideas”, or “Be able to release epic B”. The sprint goal is placed at the top of the Ready Stories section, as the following picture shows.

I find it very beneficial to involve the entire team, the product owner and the development team, in selecting and formulating the sprint goal. This leverages the team’s collective knowledge, and ensures that the goal is shared. The latter ensures that the entire team is moving towards one goal. This encourages teamwork, and it makes it easier to analyse the feedback.

Step 3: Derive the Ready Stories

After selecting the sprint goal, I determine which epics contribute to the sprint goal, for instance, epic A and C on the canvas above. I then derive small stories from the appropriate epics, and I order the new stories depending on their importance to reach the sprint goal, as the picture below illustrates.

Finally, I ensure that each story is ready and has the necessary sketches and constraints attached. The entire teams should carry out this step to ensure that the stories are clear, feasible, and testable. The right amount of ready stories are then pulled into the sprint and implemented.

Step 4: Update the Canvas and Repeat the Process

After exposing the outcome of the iteration to the right people, the insights gained from analysing the feedback are worked into the canvas: Existing epics are adjusted or removed, new epics may be added. Then the next cycle starts. A new goal is selected, and new ready stories are written.


Working with epics helps you sketch the product’s functionality, and ready stories provide the input for the next cycle. This focuses your user story writing effort when developing a new product or new features. Employing a shared goal or hypothesis makes it easier to decide which ready stories should be written, facilitates teamwork, and makes it easier to analyse the feedback.

If you have any questions or feedback on working with epics and ready stories or on using the Product Canvas, then I’d love to hear from you! Post a comment, contact me on Twitter, or email me.

You can learn more about epics and ready stories by attending my Certified Scrum Product Owner training course or my Mastering the Product Backlog training course.

A Sample Canvas

The best way to understand the Product Canvas is to look at an example. Image that we want to develop a game that helps children enjoy music and dancing. A canvas for such a game could look like the one below.


The sample Product Canvas above contains the product name, the product (or release) goal and the metrics to measure if the goal has been met. The first bigger section states two personas characterising the target users and customers with their needs. The next section sketches important aspects of the product using epics to describe the product’s functionality, a mock-up to capture the user interface design, a storyboard to illustrate the user interaction, and a constraint card to express the platform for which the game is developed. The section on the right provides a goal for the next sprint and the details necessary to reach the goal.

The Sections Explained

As you have probably noticed, the Product Canvas combines form and function, a structure together with suggested techniques. The following diagram and the text below the sections of the canvas. You can download the canvas template for free from romanpichler.com/tools/product-canvas or by simply clicking on the picture below.


Name simply states the name or version of the product.

The Goal is the product or release goal, the objective that should be met, for instance, to acquire, activate or retain users. If you use the GO product roadmap than you can simply copy the relevant goal stated on the roadmap.

The Metrics provides the measure to determine if the goal has been met, for instance, number of downloads or daily active sessions. If you use the GO product roadmap than just copy the relevant roadmap metrics.

The Target Group describes the target customers and users as personas. The section explains who we believe is likely to use buy and use the product and why. I discuss personas in more detail in my post A Template for Writing Great Personas. Choose one primary persona – the persona you mainly create the product for. Employing a primary persona helps you make the right prioritisation decisions and create a product with a great user experience. Your primary persona should be at the top of the building block to signal its importance.

The Big Picture describes what is takes to meet the persona goals. It captures the user journeys, and the visual design required to create the desired user experience. As its name suggests, it wants to describe your product holistically at a high-level. The section is similar to the outline of a book: It captures the contents without discussing the details.

Scenarios, storyboards, workflow diagrams, and story maps are great techniques to describe the user journeys on the Big Picture. Each journey shows how a persona interacts with the product and the steps the individual has to take to meet a goal. The product functionality on the Big Picture is best captured as epics, which are big and coarse-grained user stories. Epics allow you to describe your ideas without having to commit to the details. This saves time, and it makes it easier to update the canvas with new insights. Constraint stories help you capture the nonfunctional requirements that impact the user experience and the software architecture. You can capture your visual design ideas on the Product Canvas as design sketches, mock-ups, screen-shots, and photos. The Big Picture design artefacts should focus on the critical design aspects of your product—for instance, the design of selected screens or pages.

None of these techniques are mandatory, of course. They rather provide you with a starting point. Choose those techniques that are appropriate for your product. Use additional ones as it suites your needs.

The Product Details provide a goal for the next iteration and just enough implementable items to reach the goal, for instance, to address a risk and to acquire relevant knowledge, or to complete a feature. Depending on the goal, I use different techniques to capture the implementable items. For goals that require coding, ready stories are very helpful. These are small, detailed stories that feed the next cycle and that help create a product increment or minimal viable product (MVP). They are derived from the epics, and are necessary to reach the sprint goal. Make sure you write acceptance criteria for your ready stories. Order the implementable items from one to n, for instance, first, second, third, and so on, to maximise the chances that you reach your goal.

Putting the Users First

The canvas is designed so that the information flows from left to right starting with the personas. This puts the user at the center of the development effort, and it ensures that you develop a product that is beneficial and desirable.

The scenarios, storyboards, epics, design sketches, and constraints describe the future product, and the ready stories ensure that there are implementable items. I explain in more detail how you can create you canvas in my post “The Product Canvas Creation Workshop“.

Learning and Emergence

The biggest challenge when developing a new product is to deal with uncertainty and lack of knowledge. We may not know, for instance, if there is enough demand for the product, or how users will interact with the product. The Product Canvas is designed as a learning tool: to sketch our initial ideas, to get enough stories ready for implementation, and to adapt and refine the content based on the insights gained. The following picture illustrates this cycle.

Consequently, you should expect that your canvas changes as you learn more about the users and customers, and how to best address their needs. It’s common to deal with bigger changes involving clearing out and refilling one or more canvas sections including the section on personas.

The Business Model

The Product Canvas describes the target group and the product features, but not the business model including the revenue sources and the cost structure. While I have intentionally kept the canvas focussed, I have designed it to be compatible with the Alexander Osterwalder’s and Yves Pigneur’s Business Model Canvas. You can use the two canvases together, as the following picture illustrates.

As the picture above suggests, I use the Business Model Canvas to capture the market and value proposition at a high-level, and I state the details for a specific product on the Product Canvas.


I like to work with a physical Product Canvas placed on the office wall, as this has three main benefits: First, it ensures that the relevant information is visible to the product owner and the team. Second, working with simple, yet effective tools such as paper cards and paper sheets facilitates effective collaboration. Third, having to work with limited wall space creates focus and prevents capturing everything that might be relevant. To create your own paper-based canvas, download and print out my free Product Canvas template.

If you require an electronic canvas, then consider using a wiki, or try Jolien Coenraets’ Google Drive template. There are also several software tools, which allow you to create a Product Canvas including the BMFiddle Product Canvas, the ProdPad, and the Canvas Model Design iPad app.

If you work with JIRA, I suggest you keep the personas and the big picture in your wiki or project management tool, and manage the product details in your JIRA board.


The Product Canvas brings together the key pieces of information necessary to create a new product: the users and customers with their needs, the product’s functionality and design, and the user interaction. It’s intended to be a collaborative tool that helps you state your ideas and assumptions, test them, and integrate the insights you gain. Try it out, and let me know how the canvas works for you! I’d love to learn how using the canvas has worked for you.

You can learn more about the Product Canvas by attending my Certified Scrum Product Owner or my UX and Scrum training course. Please contact me if you want me to teach the course onsite or if you are interested in a virtual training.

This post was last updated on 20th March 2014.

Grooming the product backlog means managing the backlog. This is necessary, as the product backlog changes and evolves: The team gains knowledge from exposing a product increment to the users, and the latest insights lead to a backlog update, as the picture below shows.

Much of the existing advice on product backlog grooming focuses on getting the backlog in shape to supply the development team with concise stories. Unfortunately, evaluating user feedback and integrating it into the backlog has been underemphasised. This blog posts tries to set the record straight by offering a holistic, five-step grooming process – from analysing user feedback to getting the backlog “ready”. Please note that I focus on new or innovative products rather than incremental updates of mature products.

Step 1: Analyse the Feedback

Grooming the product backlog starts with analysing the feedback collected from exposing a product increment to target users and customers. The increment may be working software, or in the case of a brand-new product, a paper prototype. The data obtained may be quantitative, qualitative, or both depending on what’s feasible and beneficial. I prefer to work with both, qualitative and quantitative data.

When evaluating the feedback, focus on the data that is relevant to test your ideas and answering your questions. Have the courage to say no to new ideas and requests if these are not helpful to move you closer to your vision. Otherwise, your product is in danger of becoming a feature soup, a loose collection of features with little or no connection, which usually results in a poor user experience.

Be aware of the cognitive bias we all have, your hidden assumptions and wishes, as these can lead to ignoring or misinterpreting data. To mitigate the risk, analyse the feedback together with the team members. Remember that negative feedback is good feedback: If all you ever hear is positive, you are not learning anything new.

Step 2: Integrate the Learning

Once you have analysed the feedback, incorporate your insights into the product backlog. This results in removing, adjusting, and adding content: epics, operational constraints, design and workflow sketches. If the feedback invalidates you assumptions regarding the target group, the user needs, and the business model, you may have to adjust your vision board, remove the product backlog content, and restock your backlog.

Note that in the image above, the product backlog board’s top section is empty, as the high-priority items have been consumed, and new ready stories still have to be created. (This is done in step 4.)

Step 3: Decide what to do Next

After incorporating the learning into your backlog, decide what to do next. Ask yourself why you want to carry out the next cycle. What do you want to learn? Which ideas and assumptions do you want to validate? Which functionality do you want to provide? For new products or innovative features, your goal should be a testable hypothesis, for instance, by using the following format: If we do x, we will achieve y.

My goal for writing this blog post, for instance, is twofold: Consolidate my knowledge about the grooming process and understand if my recommendations resonate with my readers. The first sub goal is met by making time to write the post. The second one is attained if the post gets a comparatively high number of hits, generates a certain amount of Twitter traffic, and attracts meaningful comments.

Step 4: Create Small Stories

Next, carve stories out of the epics in order to reach your goal. Then make the stories high-priority, and order the stories according to their importance for reaching the goal, as the image below shows.

You may also want to ask the team to estimate any epics that have been added or adjusted as well as the newly formed stories. This allows you to understand how much effort is roughly contained in the backlog.

Step 5: Get the Stories Ready

With small, ordered user stories in place, you are close to starting the next cycle. But before you do so, ensure that the stories are “ready”: clear, feasible, and testable. This may entail creating a user interface design sketch and one or more operational quality constraints for the stories, as the image below illustrates.

Getting the stories ready may also require resolving dependencies between teams if several teams work on the same product. The stories should now be ready to be pulled onto the sprint backlog or the Kanban board.

Leverage Teamwork

When I talk to product owners about grooming their backlog, I often discover that the individual carries out the work largely alone. This wastes a massive opportunity: to mitigate the product owner’s cognitive bias, to create shared ownership of the backlog, and to leveraging the team’s collective wisdom and creativity.

As the product owner, involve the team members in the grooming steps. This reduces your workload, and it is likely to result in a better product. Don’t be afraid, however, to facilitate the discussions and to make a decision if no consensus can be reached. You don’t want to get stuck in analysis-paralysis but move on, and test your new ideas and assumptions.


When grooming your product backlog, don’t forget to collect and to analyse the user feedback. Integrate your insights, select your next goal, write small, detailed stories, and get them ready for implementation. Rely on your intuition as well as the data analysis, and involve the team in the grooming steps.

If you want to learn more about the product backlog, book a place on my Mastering the Product Backlog course in May in London or in September in Cambridge, or contact me.

Applying the product owner role can be challenging, as no two products are the same. While products and projects vary, I have found two common ways to employ the role: Asking the customer or a customer proxy such as a product manager to take on the product owner role. This post discusses when the two alternatives are appropriate together with their advantages and challenges.

The Customer Plays the Product Owner Role

One way to apply the product owner role is to ask the customer to play the role. This option is particularly useful for the development of bespoke (custom) software. For instance, if a web application is developed for a company’s marketing group – either by an in-house team or by an external software provider – a member of the marketing group should take on the product owner role. This approach is illustrated by figure 1:

Figure 1

Advantages: The customer steers and controls the development of the software directly. This allows the customer to own the product, speeds up decision-making, and increases the likelihood of creating a product that serves the customer needs.

Challenges: The customer must be available, qualified, and empowered to create a successful product. The customer and the team must value transparency and develop a healthy, trustful relationship. The latter tends to be particularly challenging when the customer and the team have different interests, for instance, getting the essential features shipped as soon as possible vs. maximising revenue, or if they have had difficulties to collaborate in the past (“IT never delivers”).

A Customer Proxy Fills the Product Owner Role

Alternatively, we can decide to separate the customer and the product owner role. This option is applicable when software is developed for several customers, for instance, when a commercial software product is created or when different departments of the same company use software developed in-house. In both scenarios, the product owner acts as a customer proxy who listens to the ideas and requirements of the customers and users but decides when which features are released. Figure 2 summarises this option:

Figure 2

For commercial software, a product managers typically takes on the product owner role. For software developed in-house, a project manager or business analyst may play the role. Note that figure 2 illustrates the main communication paths. Team members talk to customers and users directly of course, for instance, in the sprint review meeting when discussing improvements to the product. (But ultimately the product owner decides which improvements are implemented.)

Advantages: Separating the customer and the product owner role helps create a product that addresses all the needs selected. It also provides the opportunity to employ professional full-time product owners with the right skills: Product managers, project managers, and business analysts can focus on playing the role effectively.

Challenges: Empowerment of the product owner can be difficult to achieve: Product owners often require the trust and support of senior management to be able to make the necessary decisions, to have the clout to say no, and to create stakeholder alignment. Companies that regard IT largely as a commodity can find it difficult to value product ownership and to invest in developing product owners.

Mix and Match

I recommend that you apply one of the patterns described above to each of your products. To put it differently, a product should either be managed by a customer or by a customer proxy. But there is no reason why you cannot mix and match the two patterns across your portfolio: Choose customer product owners for bespoke products and customer proxies for products that serve several customers.