If you grew up as a teenager in the 1980ies like me, you are probably familiar with the quote “There can only be one” from the first Highlander movie. Interestingly, this statement is also true for product owners: There should only be one product owner per product. But don’t worry: You don’t have to become an immortal warrior to understand the Highlander principle. Reading this blog post will do the trick.

There can be many

Traditionally, product ownership tends to be distributed across several individuals: A product marketer, for instance, writes a product concept or market requirements specification, and a product manager turns it into a product requirements specification. A project manger is then tasked with executing the project, and works with a business analyst, requirements engineer, or architect to analyse and refine the requirements.

While distributing product management responsibilities supports a linear, phase-and-gate-based process, it is not well suited for an agile environment characterised by rapid delivery and fast learning. Additionally, the handoffs between the different individuals can cause defects, delays, loss of information, and other waste; decision-making can be slow and may result in weak compromises; and if the product fails, a blaming game is likely to start.

“There can only be one”

The alternative is to put one person in charge of the product; the individual leads the product development and owns the product on behalf of the company. This integrates strategic and tactical product management aspects. It unites authority and responsibility, and speeds up decision-making.

Meeting the user needs, creating a desirable user experience, and designing a sustainable business model receives the attention and leadership it requires. It increases the likelihood of realising the vision by delivering an attractive, well-rounded product.

“We are brothers”

Just like Connor, the main character in the Highlander movies, needs friends and allies, so does the product owner. To mitigate the risk of a single product owner being overworked or making suboptimal decisions, the Highlander principle must be complemented by collaboration: Leveraging the ideas of users and customers by gathering feedback on working software; and using the knowledge and creativity of the development team by jointly grooming the product backlog.

Immortals Only?

Working with a single product owner role can be particularly challenging on complex products or large projects. But you certainly don’t have to be an immortal or in the movie business to apply the role effectively. On complex products or large projects, you have two options: You can either employ a product owner hierarchy with a chief product owner in charge of the entire product and product owners responsible for features.

The alternative I prefer is to break up complex, feature-rich products into several lean, vertically aligned sub products, each owned by a single product owner.

A benefit of working with a product suite is that the sub products can be developed and released largely independently. Additionally, scaling issues can be avoided or at least reduced.

Summary

Learning from user feedback quickly requires effective decision-making. By putting one person in charge of the product, rapid experimentation, learning, and delivery are facilitated. Combining strong product leadership with collaboration and teamwork increases the chances of creating a great product.

No immortal warriors required. Promise.

Roman Pichler - Roman Pichler's Thoughts on Agile Product Management Roman Pichler

When I teach product owners I ask what qualities the product backlog should fulfil. More often than not, a key property is missed: emergence. This corresponds to my experience of how product backlogs are commonly used: as a requirements list that doesn’t change much. Instead of being rigid and fixed, the product backlog should be dynamic. It should continuously evolve based on customer and user feedback thereby facilitating the discovery of the right product features, as this blog posts explains.

Ideas, not Requirements

At the beginning of a new product development projects, there are many unknowns, and we often do not know what the product should look like and do in detail. Our initial thoughts about the product resemble more ideas than hard-and-fast requirements. We should therefore treat the items of an initial product backlog as assumptions that have to be validated and refined using the feedback from customers and users. This allows us to better understand how we can best solve the customers’ problem, and what the product should really look like and do.

Learning from Customer Feedback

To turn your backlog into a learning tool, expose product increments early and regularly to customers and users, for instance by demoing the increment or by releasing it. Then evaluate the feedback you receive, and decide which changes are required in your backlog, as the following diagram illustrates:

When evaluating feedback, avoid two common mistakes: clinging on to your ideas and ignoring what your customers and users tell you, and saying yes to every piece of feedback, any new idea, or feature request.

Analyse the feedback carefully with your product vision in mind. Ask yourself if the feedback is helpful turn the vision into a great product – assuming that your vision is valid. If the answer is yes, incorporate the insights gained. Remove or change existing product backlog items, and add new ones. Your product will consequently evolve through on-going dialogue with customers and users.

Facilitating Change

Adjusting a large, detailed product backlog usually takes too much time and is error-prone. Focussing your backlog and keeping the majority of its items coarse-grained helps you achieve the necessary conciseness.

If you are developing a brand new product, you may want to restrict the backlog scope to creating a first product increment that allows you to gather customer feedback (aka minimal viable product or MVP). Then use the feedback to decide if and how to proceed.

Keep the majority of your backlog items sketchy and coarse-grained. A great way to do this is to employ my product backlog board and to capture ideas as epics. Identify the epics that exhibit risk and uncertainty, and select the ones you want to test with the next product increment. Then derive small stories from the epics and make them high priority.

Summary

Viewing the product backlog as a learning tool facilitates the development of successful products. But it requires overcoming the misconception that the requirements of a new product can be correctly determined upfront. We stand a better chance of success by using early and frequent feedback from customers and users to validate our ideas. As Ken Blanchard says: “Feedback is the breakfast of champions.”

Roman Pichler - Roman Pichler's Thoughts on Agile Product Management Roman Pichler

With the term startup we usually associate starting a new company and pursuing a new idea with a small, creative team. While Scrum has been used for many years in startup companies – companies with a limited operating history – I have found that setting up a Scrum team as a “startup” within an established enterprise is a powerful approach to create a new product, and to pilot a new way of working.

A Scrum Startup consists of the product owner, the ScrumMaster and the development team. Together, they form is a self-contained unit that is loosely coupled to the rest of the organisation and in charge of developing and releasing the product. The product owner acts as an intrapreneur, an entrepreneur within the larger organisation.

The Scrum Startup

An Enterprise Scrum Startup

The first Scrum project I helped run in 2004 had ambitious plans: It was tasked with creating a new enterprise telecommunications software product. The company had high hopes for the product: It was considered vital to the business group’s future. To create an environment that encouraged innovation and creativity, we opened up a new development site, and assembled a new team.

We also made sure that the product owner was able to act as an intrapreneur and received the backing from senior management. The individual had a product vision and a budget to turn the vision into reality. The Scrum Startup controlled the product under development including the development and test environment, and it experienced few changes to the team composition. The individuals had a personal stake in the outcome: Everybody desperately wanted the new product to succeed knowing that it would shape future of the group.

We didn’t quite realise it, but we had created a startup within a well-established, large enterprise: Siemens, a company which has more than 420 000 employees and is over one hundred years old. The resulting product became part of OpenScape Unified Communications. It has won a number of awards, and is still selling well.

Autonomy

Setting up a Scrum team as a startup is so powerful as it disentangles the team from the rest of the organisation. Think of a Scrum Startup as a new house in the enterprise village, or a new tree in the corporate garden.

The Scrum Startup and the Enterprise

The members of the Siemens telecommunications project were free to literally think outside the box, to try out new things and to be creative. Most importantly, it created a safe environment for experimentation: for testing new ideas and for failing. Our first minimal viable product (MVP), the product increment of the second sprint, turned out to be a failure: We had chosen the wrong component technology, and the product did not live up to the users’ performance expectations.

Our first process experiment ended in failure too: We had started using a heavily tailored, lightweight version of the Rational Unified Process (RUP) that included development practices from Extreme Programming. After a few iterations, we decided to switch to Scrum. The RUP iteration management and collaboration practices simply did not work for us.

Without those early failures and the learning that they enabled, we probably would have not been able to deliver a successful product.

Collaboration

As important as autonomy is, it needs to be balanced with collaboration: working together within the Scrum Startup and with the stakeholders. A healthy, trustful relationship between the product owner and the team, the product owner and the ScrumMaster, and the ScrumMaster and the team is a prerequisite for applying Scrum successfully and for creating a great product. But it’s no less important to invite internal stakeholders to participate in the development process, and to use the feedback from target customers and users to create a product with the right features for the right people.

Scrum Startup and Collaboration

When we created the telco product, we invited representatives from marketing, sales and service to the sprint review meetings, and we demoed MVPs to other development groups destined to build on the product. Releasing early product increments to employees in other parts of the enterprise is another great way to benefit from the ideas of the rest of the organisation, and to keep people informed about the progress. Exposing product increments early and frequently to target customers and users in form of demos or releases helps to achieve a great product market fit.

Scrum Startup Qualities

To help your enterprise Scrum Startup succeed, make sure it fulfils the following four properties: It should be loosely-coupled to the enterprise and in control of the product; the people working on the product should have a personal stake, and the startup organisation should be stable. The following diagram depicts the four qualities:

Desirable Qualities of a Scrum Startup

While the Scrum team should be loosely coupled to the rest of the organisation, it still requires its support, for instance, its financial support, its sales force, and its marketing knowhow. Being in control of the product implies that the product owner is empowered to decide when which functionality is released and how to act on feedback received. The development team must be in charge of their development and test environment. The software should be largely self-contained with few dependencies to other products. Having a personal stake in the outcome of the development effort may include a bonus, stock shares, awards, or some other incentive. Last but not least, the Scrum team should be stable and experience few changes to its composition: Stable teams facilitate effective teamwork and learning.

Summary

Reflecting on more than ten years of experience using agile techniques to create products and helping organisations establish Agile, I am convinced that combing the introduction of Scrum with a new product development effort and setting up the Scrum team as a startup can facilitate product and process success. Give it a go.

Roman Pichler - Roman Pichler's Thoughts on Agile Product Management Roman Pichler

I find the Lean Startup concept of a minimal viable product (MVP) rather exciting: It entails creating a first product version to test the vision as quickly and cheaply as possible. This could be a throwaway prototype such as a mock-up or a product increment, working software that is tested and documented. The MVP works together with a build-measure-learn cycle: developing software, gathering customer feedback, and learning from it.

With roots in the Scrum tradition, this sounds rather familiar to me: Validating assumptions by gathering customer feedback using product increments is called empirical management or inspect-and-adapt in Scrum. But Scrum advocates the use of a product backlog containing the outstanding work necessary to create a successful product. How does the backlog fit into the picture? And can the product backlog be helpful to create a minimal viable product?

This blog posts answers this question and investigates how Lean Startup and Scrum concepts can be combined successfully.

The Product Vision

“If I had asked people what they wanted, they would have said faster horses,” said Henry Ford famously. A vision, an idea of the future product, is the start of any successful innovation. Without a vision, we lack a shared goal, a common direction. But every vision is a hypothesis: It contains assumptions about the future product including the target group, the needs the product will address, a sketch of the product, and the value it should create for the organisation developing and selling it. (See my vision board for a handy tool to capture and display the relevant information.) These assumptions must be validated. A great way to do this is to create the minimal viable product and to release it to target customers and users.

The Product Backlog

Unfortunately, the product vision is often too coarse-grained to be used as a direct input for writing software. It can therefore be helpful to take an intermediate step, and to identify the work that is required to validate the vision. The corresponding items are then placed in a sketchy, lightweight product backlog. To put it differently, the backlog is derived from the product vision; it makes the vision implementable.

Vision and Backlog

From Backlog to Minimal Viable Product

Once we have a vision and initial product backlog available, we create the minimum amount of functionality necessary to test our assumptions. This may take a day or two, or one or more sprints with a preference for the shorter timescales. Our goal is to find out quickly if the product generates a positive response amongst the target users and customers, and if the target group members use the product in the intended way. Once we’ve created the MVP, we release it and gather the feedback.

Vision, Backlog and MVP

Note that releasing the MVP can be limited to a small group of customers and users if the respondents are representative for the target group. Google, for instance, released early versions of its Chrome browser internally and asked its employees to test the software and to provide feedback before a first public beta was released in October 2008. An example where internal releases did not work so well is Google Buzz: The software was apparently loved by Google engineers but unfortunately not by the rest of the world.

Learning from the Feedback

Once we’ve gathered and evaluated the feedback, we need to decide if and how to act upon it. If the feedback invalidates any assumptions made in the vision – which is likely to be the case when a new product is developed – we should adjust the vision and the product backlog. We may decide to change the target group or the needs selected, for instance; maybe the features or the look and feel envisioned is not right; or the business model does not work as expected, for instance, users never click on the ads displayed. Changing the vision can require restocking the backlog – depending on how much the vision has changed. We then continue with the next cycle, develop a new MVP, and gather new feedback.

The Vision is Invalid

If the feedback confirms the vision, we adapt the product backlog, for instance, by adding new requirements that help us turn the vision into a successful product. Depending on the quality of the MVP, we may have to throw away any mock-ups and prototypes created so far, and start afresh developing tested and documented software using agile development practices. If the MVP is a product increment, we can progressively transform it into a shippable product using a series of sprints.

The Vision is Valid

Summary

Validating the product vision using a minimal viable product is a powerful concept that be used in harmony with Scrum’s approach of creating working software, exposing it to customers and users, investigating their feedback, and making the necessary adaptations.

Many thanks to Stefan Roock for feedback on the MVP of this post.

Roman Pichler - Roman Pichler's Thoughts on Agile Product Management Roman Pichler

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

Roman Pichler - Roman Pichler's Thoughts on Agile Product Management Roman Pichler