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

To create a new product, we have to peek into the future and anticipate what the product will roughly look like and do. For anyone not blessed with perfect foresight, predicting the future correctly is notoriously difficult. After all, the only thing certain about the future is that it is uncertain! No market research technique can deliver a forecast that is 100% accurate. And in the case of disruptive innovations, it’s not possible at all to make a sound prediction, as Clayton Christensen observes in his book The Innovator’s Dilemma: “Markets that do not exist cannot be analysed.” Investing in a new product hence always involves risk. We may have targeted the wrong market segment, envisioned the wrong product or the wrong features, or the market may have changed by the time the product is launched.

Envisioning a Lean, Minimal Product

A great strategy to minimise the investment risk is to envision a lean, minimal product with the smallest possible feature set. I refer to such a product as the minimal marketable product. It contains just enough functionality to be viable – to launch, market and sell the product successfully. Developing a minimal product is quicker and cheaper than a more ambitious, feature-rich one. If the product bombs less time and money is lost. If it is a success, the product starts earning money sooner. Additionally, a minimal product allows us to receive feedback earlier so we adapt the product quicker to the market response. Rather than trying to create the perfect product, we follow the motto “get it out, then get it right.” Note that the product’s quality must be right from the start. Otherwise it will be difficult to adapt the product; bugs may hinder its adoption, or even damage the brand.

The iPhone

An example of a minimal marketable product is the original iPhone, which launched in 2007. One of the secrets behind its success is the narrow set of customer needs Apple selected. The company avoided the trap of trying to please too many people at once, of trying to copy all the features competitors offered. Instead, Apple took a fresh look at what smartphones should look like and do, and deliberately left out some functionality. The original iPhone shipped without many features standard on existing phones: copy and paste, the ability to send text messages to multiple recipients, and a software development kit, for instance. These limitations, though, did not hinder its success. Paring down the functionality allowed Apple to develop and ship the product within a competitive timeframe and gave the company a significant lead over its competitors. Building on the success of the first iPhone version, Apple started to extend the capabilities of the phone both in terms of hardware and software with the launch of the 3G model in 2008. This version also allowed the company to enter a new market segment by targeting business users.

The Apple Newton

Developing a minimal marketable product may sound like a no-brainer. But my experience suggests that many start-ups and established companies alike find it hard to restrict the features of a new product. It’s often too tempting to opt for a big-bang release trying to satisfy as many users and customers at once in order to maximise revenue. Contrast the iPhone with another Apple product: the Apple Newton, first launched in 1993 after five long years of development. Remember those Apple ads that promised a PDA that could do all sorts of wonderful things, including recognising your handwriting? When it was finally shipped, the Newton proved to be too bulky and heavy. Worse, its most important feature, the handwriting recognition, did not work properly. The product underperformed and was finally withdrawn from the market in 1998. In hindsight, Apple was overly ambitious with its Newton plans. The company launched a product that tried to do too much at once, and failed.

The Steps towards a Minimal Marketable Product

To create a lean, minimal product, limit the target group and “build a product for the few, not the many,” as Steve Blank recommends in his book The Four Steps to the Epiphany. For instance, if you use personas to describe members of your target group, consider the impact of removing a persona. Would the product still sell? If yes, reduce the target group by dropping the persona. Once you have done a great job for your early customers, you’re in a position to build on the initial success with a new, incremental release that attracts new customers.

Second, understand your product’s value proposition and only select the features that are essential to address the needs of the target group. Have the courage and discipline to discard all others for now. Selecting the minimal set of features does not mean creating a bland, boring or simplistic product. It means focusing on those properties that are essential for the product success. If you work with user stories, for instance, review each story or epic, and ask yourself if the product can be shipped with out it. If yes, exclude the story. As the French writer and poet Antoine de Saint-Exupery put it:

“Perfection is achieved, not when there is nothing more to add,
but when there is nothing left to take away.”

Side Note: Marketable or Viable, Product or Feature Set – Huh?

“Words are but sound and fury,” says Macbeth, and there are several similar but confusing terms to denote minimal products. My termminimal marketable product is a reference to Mark Denne and Jane Cleland-Huang’s work. In their book Software by Numbers they coin the term minimal marketable feature set to denote the smallest amount of functionality creating value for a customer. As I view a product as more than a set of individual features, I prefer to talk about products rather than feature sets. The idea of quickly delivering a small set of features and enhancing the software incrementally dates back to Tom Gilb’s evolutionary delivery method developed in the 1980ies by the way.

Eric Ries has more recently popularised the term minimal viable product, which he defines as “the product that allows a team to collect the maximum amount of validated learning about customers with the least effort.” Based on this definition, the minimal marketable product may or may not be the minimal viable one. Independent of the differences, all terms share the idea to quickly launch an initial product to learn from the market response, and to adapt the product accordingly. And that’s what matters.

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