It’s not uncommon for me to visit a new client and to discover that the scrum teams change frequently, sometimes after every single sprint. Changing the team composition too frequently is undesirable for the individuals and the organization. To flourish, teams need stability. With markets, requirements and technologies frequently changing in an agile world, a stable scrum team provides security and continuity.

To create stable scrum teams, follow these recommendations:

First, carefully consider who should be on the Scrum team. Find the right individuals to play the product owner, ScrumMaster and team role in order to develop a great product. Having the right individuals on board is most likely the biggest success factor for any development effort.

Second, minimize any changes to the Scrum team within and across releases. It takes some time for a group of individuals to become a true team – a tightly knit unit with members that trust and support each other and that work together well. Changing the team composition makes this teambuilding process start all over again and, as a result, productivity and self-organization suffer. Avoid loosing team members while a release is being developed. A good time for people to leave and new members to join is after the release of a new product version. But ensure that the majority of the team members continue to work on the product to avoid loss of information, defects and delays.

Last but not least, establish a long-term partnership between a Scrum team and its product; every product should be developed by one or more dedicated teams. This not only facilitates ownership and learning, but it simplifies the allocation of people and resources.

The product owner should always be a permanent member of the Scrum team. This allows the individual to manage the entire product lifecycle, from gestation to its discontinuation. It also encourages balancing short-term wins with long-term success.

Find out more about employing stable teams by reading my book Agile Product Management with Scrum or by attending my product owner course.

What is an Agile Product Roadmap?

A product roadmap is a high-level plan that describes how the product is likely to grow. It allows you to express where you want to take your product, and why it’s worthwhile investing in it. An agile product roadmap also facilitates learning and change. A great way to achieve these objectives is to employ a goal-oriented roadmap – a roadmap based on goals rather than dominated by many features.

Here is a sample agile product roadmap that shows the anticipated development of a dance game app for kids:

The roadmap above states the date, the name, the goal, the key feature, and the metrics for each major release or product version. It is a goal-oriented product roadmap, and it applies the GO roadmap template, which is explained in more detail in my post “The GO Product Roadmap”.

The benefit of a goal-oriented roadmap is that it shifts the conversation from arguing over features to agreeing on shared goals. This mitigates the conflict between viewing roadmap features as commitments and agile teams who only commit for next few weeks.

What Benefits does a Product Roadmap Provide?

A product roadmap can provide the following five benefits: First, it helps you communicate how you see the product develop.

Second, it helps align the product and the company strategy. By anticipating how the product is likely to grow you can show how the product helps the organisation reach its goals. This makes it easier to secure a budget for the next fiscal year.

Third, a product roadmap helps manage the stakeholders and coordinate the development, marketing, and sales activities.

Fourth, a product roadmap facilitates effective portfolio management, as it helps synchronise the development efforts of different products.

Last but not least, using a roadmap supports and complements the Product Canvas and the product backlog. This allows the canvas and backlog to focus on the tactical product development aspects, as I explain in more detail below.

When should I Use a Product Roadmap?

I usually create a product roadmap once I can confidently look beyond the next major release. If you cannot look further, then do not employ a roadmap! What’s more, I want to ensure that the assumptions about the target group, the needs to be addressed, and key aspects of the business model have been validated, as the picture below illustrates:

In the picture above, the market and business model assumptions are captured on a Vision Board. But you can also use the Business Model Canvas or Lean Canvas to state and validate your ideas. While the Vision Board and the two canvases are helpful tools, they not tell us how the strategy will be executed. This is where the product roadmap comes in.

How do the Product Roadmap and the Product Canvas/Backlog Relate?

Using a product roadmap can benefit your Product Canvas and product backlog . Here is why: As the roadmap takes care of the strategic product planning aspects, it frees the canvas/backlog to focus on the tactical work, as the picture below illustrates.

Say you release a new product version every three months. I would then suggest that your product roadmap should capture the next four major releases, while your Product Canvas or product backlog focuses on creating the next product version.

The following table summaries the differences between the product roadmap and the product backlog:

Who Owns the Product Roadmap?

As the product roadmap captures decisions about the product’s futures, the individual responsible for the product success should own the roadmap. In an agile context, the product owner should hence manage the product roadmap. The team members and stakeholders contribute, as the following picture suggests.

Having one person in charge of the product roadmap and the Product Canvas/backlog unites the strategic and the tactical product planning aspects, and establishes clear authority and responsibility.

Wrap-up

A product roadmap allows you to communicate where you want to take your product. If applied correctly, the product roadmap and the product backlog complement each other nicely. But before you create your roadmap, make sure that you are able to forecast how your product is likely to develop in the future.

Learn more about working with product roadmaps by attending my Agile Product Planning training course. You can also download my GO product roadmap template that allows you to create goal-oriented, agile roadmaps.

This post was last updated on 15 January 2014.

The Three Stages of Innovation

Innovation forms a continuum ranging from maintaining an existing product to creating a brand-new one. To select the right practices, I find it helpful to divide the continuum into three stages: a maintenance stage, a new feature stage, and a new product stage, as the image below shows. The diagram is inspired by Nagji and Tuff’s HBR article “Managing Your Innovation Portfolio”.

In the image above, the degree of uncertainty and innovation rises from left to right. Whereas stage three focuses on protecting existing assets, stage one and two are about investing in the future.

The three innovation stages correspond to the product’s lifecycle: Every product starts in stage one. After its launch, the product moves into stage two, and eventually arrives in stage three.

Understanding the Innovation Stages

Stage 3: Maintaining a product means making small incremental updates to ensure that the product stays competitive and profit goals are met. The product management focus is typically on maximising the return of investment: to minimise cost and increase revenue. The innovation is low, and there is little uncertainty about what the product should look like and do, and how it is built. Experimentation and failure are hence not desirable. Planning the work and executing the plan works well. Most products in an established company fall into this category, and companies often optimise their processes and structures for this stage.

Stage 2: One or more new features are created. This enhances an existing product, for instance, to increase the market share, or to enter a new market. Creating new features may require dealing with a new target group or addressing new needs, changing the user experience, or employing new technologies. Consequently, there is a significant amount of uncertainty present. Experimentation and failure are helpful to acquire the necessary knowledge and to develop the right features in the right way.

Stage 1: A brand-new product aimed at a new or an existing market is created. Developing the product may involve addressing a new target group or new user needs, creating a new user experience, employing new technologies or a new business model. There are many more unknowns than knowns. The innovation present is high to very high. Rapid experimentation is a must, as it helps the team fail fast to succeed sooner: to create the right product for the right people. The stage-one products usually form the smallest group in a mature enterprise.

Employing the Right Practices

Distinguishing between the three innovation stages enables us to choose the right practices. These include the process and the project organisation employed, and the way product ownership is implemented. The table below summarises my observations.

As stage three aims to maximise ROI, a linear process tends to work well – it facilitates efficiency. Employing a Kanban-based approach that leverages pull, collaboration, and visualisation is usually beneficial. The product ownership may be shared amongst several individuals, for instance, a product marketer, a product manager, and a project manager or business analyst. Collocated team members is a plus but often not mandatory.

In stage two the focus shifts form efficiency to effectiveness: quickly resolving uncertainty by acquiring the relevant knowledge. This requires an iterative process that supports experimentation such as Scrum. A single product owner is beneficial to enable effective decision-making. The team members should be collocated, and product owner and team should collaborate on an on-going basis.

In stage one, effective experimentation becomes even more important. Scrum with short sprints, or Lean Startup combined with Kanban work well. The latter allows running experiments in varying lengths in parallel, but it tends to be more difficult to master. Product owner and team should form an incubator, a new, temporary organisation that is loosely coupled to the rest of the company. This provides the team with the freedom to try out new things and to literally think outside the box.

The following image visualises the three innovation stages and the different practices:

Conclusion

Choose your innovation practices to suit your needs: Your mature products are likely to benefit from practices that facilitate efficiency such as a linear process. To develop new features or a new product, you should select different practices, practices that help resolve uncertainty and acquire new knowledge. Applying an iterative, experimental process, and enabling collaboration will be key.

You can learn more about employing the right agile and lean innovation practices by attending my Agile Product Management training course.

Step 1: Do the Prep Work

Before you create your GO product roadmap, you should carry out the necessary problem validation work. Investigate the target group, the problem to be solved, the business goals, and the technical feasibility of your product. The Vision Board, the Business Model Canvas, and the Lean Canvas are great tools to capture and validate your ideas.

To see how this can work in practice, take a look at the Vision Board below. The board captures the idea of creating a digital dance game together with the intended audience, the benefits, the key features, and some aspects of the business model:

Step 2: Build the Roadmap

The Vision Board, Business Model and Lean Canvas are helpful tools to describe the market, the value proposition, and the business model. But they not tell us how the strategy will be executed. Will the first product version deliver the entire value proposition and generate the desired business benefits, for instance, or will this take longer? Say we focus the first version of the dance game on user acquisition. While this is a necessary step towards the vision, it does not answer the question when revenue will be generated. This is where the GO roadmap comes in.

I used the Vision Board above to create the roadmap shown below. You can download a PDF and Excel template by clicking on the picture.

The roadmap above takes the Vision Board contents, and shows how the strategy is executed over the next 12 months. It states the planned major releases with their goals, key features, and metrics. Version 1, for instance, is focussed on user acquisition, version 2 on activation and revenue generation. Version 3 is about retaining existing users, and version 4 targets a new segment and tries to acquire new users. (I discuss in more detail in my post “The GO Product Roadmap”.)

Your roadmap should tell a coherent story about how the product is likely grow: Choose the goals carefully and consider their relationships.

Which timeframe your roadmap should cover and how often you want to create a major release / new product version depends on your product. You should be reasonably confident about your roadmap and avoid speculation. You can regard the roadmap goals as hypotheses, but they should be informed assumptions, and not wild guesses.

If you cannot look further than the next release, then do not employ a roadmap!

Step 3: Derive your Product Canvas/Backlog

With your GO roadmap in place, you can now take the next step and use the product roadmap to stock your Product Canvas or product backlog. The GO roadmap provides you with the goal for the next major release, the two to three key features, and the metrics, which are a great starting point for discovering the product details including the user journeys, epics, the visual design, and the nonfunctional requirements.

The GO roadmap connects the Vision Board / Business Model Canvas to the Product Canvas/backlog; it links market insights and business model with the product. What’s more, the roadmap allows you to focus your Product Canvas/backlog on the next major release, which results in a smaller and more manageable canvas/backlog that is easier to change and update.

Step 4: Pivot or Persevere?

The process I have suggested so far sounds rather sequential: Do some problem validation work, then build the roadmap, and derive the Product Canvas to develop the product. This may give the impression that the GO product roadmap is a fixed plan that simply has to be executed. But the opposite is true.

Whenever we create something new – be it a brand-new product or new features – the one thing we can be sure of is that our initial ideas don’t work out as planned. As you collect feedback from users and customers on your prototypes, product increments, and MVPs, you should always ask yourself if your product strategy is still valid.

Say we expose an early prototype of the dance game to a test group. But unfortunately, we have to recognise that the kids are less excited by the game and playing it much shorter than anticipated. This data should make us rethink our strategy by asking ourselves if our market assumptions (segment and problems/needs) are wrong or if the user experience provided by the product is adequate. In both cases we have to pivot and change the strategy together with the product roadmap, as the following picture shows.

Note that the picture above assumes that the Vision Board / Business Model has to be changed in addition to the roadmap. That’s not necessarily true if the UX or features of the product are inappropriate but the market and business model-related assumptions are valid.

Be prepared to throwaway your existing GO product roadmap and to create a new one.

To minimise any rework, do the necessary problem validation work recommended in step one, and keep your product roadmap focussed and concise. The more details you add the more attached you become to your roadmap, and the harder it is to let go.

Once you have reached product-market fit and are confident that you are building the right product for the right people, I recommend you review and adjust your roadmaps on a regular basis, for instance every two months, as part of your portfolio management process.

Learn more

You can learn more about working with the GO product roadmap by attending my Agile Product Planning training course.

Please contact me for product roadmap workshops and webinars.

The Three Elements of an Effective Strategy

A product strategy is a high-level plan that helps you realise your vision or overarching goal. It describes who the product is for and why people would want to buy and to use it; what the product is and why it stands out; and what the business goals are and why it is worthwhile for your company to invest in it, as the following picture shows.

The market describes the target customers and users of your product, the people who are likely to buy and to use it. The needs comprise the main problem your product solves or the primary benefit it provides. Think of a product like Google Search or Bing that solves the problem of finding information on the Internet. Compare it to a product like Facebook that allows you to stay in touch with family and friends.

The key features and the differentiators are those aspects of your product that are crucial to address the main problem or create the primary benefit and that make people choose it over competing offers. Don’t create a mini backlog or a wish list. Instead focus on the three to five key aspects that make people buy and use the product. Take, for example, the first iPhone with mobile Internet, iPod-like digital music player, and touch screen as its key features; or the Google Chrome browser with its focus on speed, safety, and simplicity.

The business goals capture how your product is going to benefit your company. Is it going to generate revenue, help sell another product or service, reduce cost, or increase the brand equity? Being clear on the business goals allows you to select the right key performance indicators (KPIs) and to measure your product’s performance. Take the iPhone and the Google Chrome browser mentioned earlier. While the iPhone currently generates the largest portion of Apple’s revenue, the Chrome browser does not earn any money for Google. But it allows the company to control the way people access the Internet and it has reduced Google’s dependency on third-party browsers such as Mozilla’s Firefox and Microsoft’s Internet Explorer. Both are important business benefits.

You can capture your product strategy with the Product Vision Board, a simple yet effective tool shown in the following picture. You can download it from romanpichler.com/tools/vision-board or by clicking on the picture below.

The Product Vision Board above captures the vision at the top. The four sections underneath it describe the strategy. The questions help you provide the right information. You can find more information about the tool in my post “The Product Vision Board”.

Strategy Focus and Inflection Points

The product strategy is not a static, fixed statement or document that you create for a new product. It changes as your product grows and matures. The following picture shows the product lifecycle with four key events: launch, product-market fit, rejuvenation, and end-of-life.

The strategy for a new product should first help you get to launch, then achieve product-market fit (PMF), and finally sustain the growth of your product. Think, for instance, of the changes Apple has made to the iPhone since its launch in 2007 to keep it attractive and preserve its growth, from adding apps to changing the its size. Once the growth starts to stagnate you have reached another strategic inflection point: You either revitalise your product, for instance, by rejuvenating it or taking it to a new market, or you let it mature and eventually decline and die. To use the product strategy to proactively manage your product, you should review and adjust it on a regular basis – I recommend once a quarter as a rule of thumb.

The Product Strategy in Context

If the product strategy describes the key elements required to develop a success product as I suggested above, then where are the vision and the product roadmap? The following picture shows how I relate the three artefacts.

I view the vision as the ultimate reason for creating the product that describes the positive change your product should bring about as I describe in more detail in my post “8 Tips for Creating A Compelling Product Vision”. If you think of the strategy as a path to the vision, then the vision guides the strategy. Say I want to create a health app that helps people become aware of what and how much they eat. The vision could be to help people eat healthily, and the strategy might be to create an app that monitors the food intake. But that’s not the only way to attain my vision. If it turns out that the app is not a great idea, I could pivot and write a book on healthy eating, for instance, while still following my vision.

As the picture above shows, the product strategy provides an input for the product roadmap. The roadmap states how the strategy is implemented and describes how the product is likely to grow. The two work in tandem, as I describe in my article “10 Tips for Creating an Agile Product Roadmap”.

Learn More

You can learn more about creating an effective and valid product strategy by attending my Product Strategy and Roadmap training course and by reading my book Strategize: Product Strategy and Product Roadmap Practices for the Digital Age.

Big vs. Small

What’s a big and a small product owner? “Big” and “small” define levels of ownership. A big product owner owns the entire product; a small one takes care of the product details, as the following picture shows.

The picture above distinguishes three areas: vision, strategy, and tactics. The vision describes the ultimate reason for creating the product. The strategy covers the product strategy, the product roadmap, and the business model. The tactics refer to the product details such as epics and user stories, design sketches, scenarios, and interaction diagrams, which are typically captured in the product backlog. Distinguishing between a big and a small product owner is nothing new by the way; Rich Mirnov wrote about it in 2008 in his article “How Are We Defining Product Owners?”.

While this distinction may seem a bit theoretical, I find it rather common in practice. Many product owners I meet seem to focus first and foremost on the tactics. That’s not a problem if someone else takes care of the vision and the strategy and if the individuals work together well. But sadly, that’s not always the case.

Good vs. Bad

Being a certain height has its benefits and drawbacks just like working as a big and a small product owner. The advantage of being a big product owner is that you control all aspects of the product. As there are no hand-offs, and you should be able to make consistent decisions in a timely manner. But you may find it challenging to take on all responsibilities, as it requires a diverse set of skills and it may be too much work for a larger product.

Being a small product owner allows you to focus on the product backlog and the product details. This can help you do a great job and prevent you from getting overworked. But it requires that you effectively collaborate with the individual who owns the vision and the product strategy. Otherwise you may suffer from hand-offs, waiting and delays, loss of knowledge, inconsistent decision-making, and confusion about who decides what. Bear in mind that an effective collaboration requires that you have at least some knowledge of the strategic product aspects just like the individual looking after the vision and strategy should know what a product backlog is and how to manage it effectively.

The following table summarises the benefits and the drawback of the two product owner variants:

Right vs. Wrong

If both variants have the benefits and drawbacks, when is it then better to be small product owner and when to be a big one? I find a big product owner particularly beneficial when a product is young and it evolves fairly rapidly. Once it grows steadily or it has become mature, employing small product owner can be helpful to share the workload and facilitate scaling. In other words, you should make your choice based on the lifecycle stage of your product, as the following picture illustrates.

As long as your product is young and you are trying to achieve growth, it is advantageous to have person in charge of the product and to work with a big product owner. The reason for this is simple: While the strategy directs the tactics, the latter influence the former. How customers and users respond to product increments and releases can have a profound impact on the strategy. It can even cause a pivot, a significant strategy change. Take, for instance, YouTube, Flickr, and Instagram, which all changed their strategy to become successful. If several people share the product management responsibilities then the individuals will have to agree on the appropriate actions. This can slow you down significantly. In the worst case, you end up with a decision-by-committee scenario and a weak product full of compromises.

As powerful as a big product owner is, playing the role can become overwhelming once your product experiences growth, attracts more features, and becomes bigger. What’s more, as your product tends to be more stable now, and bigger changes are less likely to happen. Sharing the responsibilities across several people and employing small product owners is therefore a good option – unless you decide to unbundle your product and to promote some features to new products. Think of Facebook taking the messenger functionality of its main app and turning it into a new product , the Messenger app.

Product Manager vs. Product Owner

“The world calls them product managers,” writes Rich Mirnov about big product owners. Rich is right to point out that a big product owner largely corresponds to a traditional product manager, apart from the on-going attention to the product details and the level of collaboration with the development team. Should you hence use the term product manager instead of product owner? It’s entirely up to you. Use whichever term works best in your organisation.

But I recommend that you call the individuals who look after products either product owners or product managers to avoid confusion. A product owner is a big product owner by default in my view – just like a product manager should manage the product in its entirety. Small product owners and technical product managers are specialised roles. Use them wisely.

Learn More

You can learn more about effectively applying the product owner role by reading my book Agile Product Management with Scrum and by attending my Certified Scrum Product Owner training course.

Theory and Practice

In theory, your product backlog should be prioritised with the high-priority items at the top and the low priority items at the bottom. The top items should be detailed and fine-grained. But as their priority decreases, they should become more and more coarse-grained. You could capture your top items as small user stories that are ready to be implemented in the next sprint. But further down in the backlog you would use epics, which are big sketchy stories. How detailed an items is therefore depends on its priority, as the following picture shows.

If your product backlog does not look like the one above, does this mean it is wrong?

The Product Lifecycle

I find that a product backlog like the one pictured above is optimised for a young product. At this stage, you typically have to experiment with new ideas and change your product frequently, for instance, to discover the right user experience and features or to enhance and optimise them. As a consequence, you want to be able to easily change your backlog, keep it concise, and use only a small amount of detailed items. Otherwise, updates are too much effort and take too long.

But as your product stabilises and eventually matures, you have learned to better understand the market, the customer needs, and how to address them. This increases your ability to anticipate how your product is likely to evolve. Consequently, you can add more details to your backlog.

How detailed your product backlog should be is therefore tied to the lifecycle stage of your product: Young product should have a concise backlog with few details; older, stable products tend to benefit from a more detailed backlog, as the following picture shows.

The product backlog on the left-hand size of the lifecycle curve carries only a few detailed items; most of its contents are coarse-grained. But the backlog on the right-hand side is the opposite: It contains many more detailed items and fewer coarse-grained ones. As a consequence, it is larger and less concise. But watch out that your backlog does not grow in an uncontrolled fashion or morph into a wish list. Complement it with a product roadmap to capture the longer-term outlook of how your product is likely to grow.

While the product lifecycle is great to gauge the right level of detail, it is not enough. You should also consider where your product’s position in the release cycle.

The Release Cycle

As you start working on a new product version or a major release – think of iOS 8.4 or Windows 10 – you typically encounter more unknowns and risks than towards the end of the project. If you address the risks on early, then your product backlog is particularly volatile in the first few sprints. As you test assumptions and address the risks, you are likely to discover that some of your assumptions were wrong and generate new ideas. The new insights and ideas make it necessary to change the product backlog, and some of the change can be rather big, particularly if your product is young. You will therefore benefit from a concise and coarse-grained backlog at the start of a new release.

But once you have addressed the key risks and critical assumptions, your focus shifts to completing and optimising the features, as I explain in my post “Get Your Focus Right: Learning and Execution in Scrum“. At this point your product backlog should start to stabilise and experience fewer and smaller changes. As a consequence, you can add more details to it.

As a rule of thumb, use few details at the start of a project or release and more once you have addressed the key risks and the product backlog has started to stabilise.

Conclusion

Use the product lifecycle and release cycle to determine how detailed the product backlog should be. This is true for traditional backlogs as well as Jeff Patton’s storymaps and my Product Canvas. To put it simple, the more uncertainty and change you experience the more coarse-grained and concise the backlog should be.

As your product develops and grows adjust your product backlog and the way you manage it. There is no one right level of detail.

Learn more

You can learn more about the product backlog by reading my book Agile Product Management with Scrum and by attending my Certified Scrum Product Owner training course.

When is Scrum Most Helpful?

A process like Scrum is a great fit for your product when it is brand-new or young, and when you extend its life cycle, as shown in the picture below. This means that not every product will benefit from Scrum: Products that are maturing or declining won’t benefit from Scrum—at least not to the same degree.

The picture above shows the traditional, bell-shaped product life cycle curve with three key events: launch—the product first becomes available; achieving product-market fit (PMF)—your product is ready to serve the mainstream market; and end of life—you decide to discontinue the product. Note that your product’s actual trajectory may differ significantly from the one above: it may be much steeper or flatter. In order to leverage the product life cycle model, you have to define the business benefits your product delivers and then track them over time. For revenue-generating products revenue is commonly used, for example. But if your product exists to sell another product or service, then the number of active users might be the appropriate metric. (See my post 10 Tips on How to Choose the Right Product Key Performance Indicators for more information on selecting the right metrics.)

The younger your product is, the more it is likely to benefit from Scrum. Why? When working on a brand-new product, trying to achieve PMF, or struggling to keep the product growing, you typically face many unknowns and a substantial amount of uncertainty and change. You may not fully understand the value it should create for its users and customers, the features and user experience (UX) it should provide, the business goals it should serve and the business model it should use, and the technologies that should be used to develop it. Scrum is a great fit at this stage: Your product will benefit from an iterative, cyclic process that allows you to quickly test an assumption, address a risk, generate new insights, and come up with new ideas. This accelerates learning and mitigates the risk of developing the wrong features, providing the wrong UX, and applying the wrong technologies, as I describe in more detail in my post The Scrum Cycle.

But as your product grows and eventually matures, the amount of uncertainty and change gradually declines. After achieving PMF, you usually understand how to meet the user needs, and know how to develop, market, and sell the product to the mainstream market. Your focus tends to switch to penetrating the market and fending off competitors by keeping your product attractive and refining it. This typically results in smaller, often incremental product changes. A good example is the latest iPhone 7, where Apple largely optimised existing features like camera and battery life. Scrum consequently becomes less helpful at these life cycle stages: The development team members are often no longer required to work together towards a shared goal in order to test an assumption or to deliver a piece of functionally. If, however, you decide to revitalise a maturing product and extend its life cycle, for instance, by taking it to a new market or unbundling a bigger feature, you usually face a significant amount of uncertainty and change. In the picture above, the life cycle extension is shown by the arrow that reverses the ageing process of the product and takes it back into the growth stage. In this case, Scrum becomes very helpful again!

If you are in doubt if you should use Scrum or not, consider how much uncertainty is present in your product. Do you understand how to address the market needs and solve the users’ problem? Do you know how to develop, market, and sell the product? And more specifically, can the users confidently tell you which functionality they require and which aspects of the product need to be improved? Do you mainly provide incremental enhancements or bug fixes? Are the architecture and technologies fit for purpose and stable? Are you regularly struggling to agree on a shared, meaningful sprint goal? If the answer to these questions is yes, then Scrum is probably not the best framework for your product. To gain more clarity, use the next sprint retrospective to investigate if your process is still helpful, or if you should switch to an alternative.

What’s the Alternative?

Once your product no longer exhibits a significant amount of uncertainty and risk, is growing steadily, or has started to mature, a Kanban-based process may be the right choice, as the following picture illustrates.

Unlike Scrum, Kanban does not regard protected, goal-driven iterations as mandatory. You can use it to implement an agile process with the flexibility to work on different items and release them individually at different times. This is particularly handy for incremental enhancements and bug fixes and to quickly test smaller ideas.

I therefore suggest that process follows product: You should choose the process that is best suited to provide a successful product—a product that does a great job at creating value for the users and for the business. There is no one right way, no silver bullet. Neither Scrum nor any other framework is always the best fit. As a consequence, you may well have to adjust and change your process across over time. Use the retrospectives to regularly enquire if your current process is fit for purpose and adapt and change it as appropriate.

Mix and Match

The picture above seems to suggest that you face a stark choice—either Scrum or Kanban. But that’s just a simplification to help you choose your primary process. You can, of course, combine Scrum and Kanban. You may decide, for example, to apply Scrum to develop new features and Kanban to fix bugs, as I describe in my post Succeeding with Innovation and Maintenance.

You can also use Kanban for product discovery and strategy validation activities, as I recommend in my book Strategize. These activities may overlap with the Scrum-based development, for instance, when you intend to extend the life cycle of your product.

Learn More

You can learn more about when Scrum is most helpful for you as a product manager and product owner by:

• Attending my Certified Scrum Product Owner training course;
• Reading my book Strategize: Product Strategy and Product Roadmap Practices for the Digital Age. The book discusses the product life cycle model with its impact on product strategy and it shows how Kanban can be used for strategy validation.

Title picture by Charlotte Coneybeer, published on Unsplash, licensed under Creative Commons Zero.

Product

What is a product? It might be tempting to say, something we can market or sell. But when it comes to digital products, this definition has only limited applicability. Take the search function on your company’s website. Is that a product? Or is the entire website the product? And how would others, including people from development, marketing, and sales, answer this question?

I view a product as something that creates specific value for a group of people, the customers and users, and to the organisation that develops and provides it, as the picture below shows. The former is achieved by solving a problem—think of Google Search or Bing that address the challenge of finding information on the Internet—or by providing a benefit—take Facebook that allows people to stay in touch with family and friends.

Creating value for the business is accomplished by directly generating revenue, like Microsoft Office and Adobe Illustrator do, helping sell another product or service, as in the case of iTunes and Google Chrome, or increasing productivity and reducing cost, as in-house developed IT applications do.

Finding a problem that’s worth solving—or a benefit that people would not want to miss once they’ve experienced it—and discovering a viable business model are two key prerequisites for successfully offering a product.

Products go through different life cycle stages: they are created and launched; they develop, grow, mature; and eventually, they die. Some digital products exist for many years and even decades. One of my clients, a company specialised in digital engineering products, offers a products that contains 30 year old code, for instance. This distinguishes products from projects.

Product vs. Project

A project delivers a product release—think of Windows 10 or iOS 9.3—and it is a temporary endeavour: The project is finished when the new release becomes available. But products have a different life cycle and typically exist for longer. The ancestor of Windows 10, Windows NT, was launched in 1993, and iOS was introduced with the first iPhone in 2007, for example.

Similarly, products have different success criteria compared to projects. A project is successful if the new release is deployed on time and budget, and if it delivers the agreed scope. A product, however, achieves success if it meets it business goals. Revenue-generating products typically become profitable when they have achieved product-market fit and start to grow. This may be months, and in some cases, years after the initial development project was finished.

A product manager’s (or owner’s) job is therefore different from a project manager’s: product people are in it for the long run—assuming that the product prospers and grows.

Features and Components

If an asset does not create value for its customers and users and for the company, then I don’t regard it as a product. Take an e-commerce site like Amazon.com or JohnLewis.com. Both offer search and check-out capabilities so that customers can find and buy goods. While these are important steps in the user journey and may require a complex technical solution involving third-party systems, I would argue that they are not products but features: they do not provide any distinct value to the customer. I don’t go to Amazon or John Lewis to search or checkout. I want to buy the right product at the right price with minimum hassle. A feature is therefore a product capability people can interact with—a part of the product that users can use. But it does not address a need or solve a problem on its own. Instead, several features have to interact to create the desired value for the customers and users.

Similarly, a user-interface layer or a (micro) service that talks to a payment gateway are not products but components, or more accurately, architecture building blocks—even if they are developed by a dedicated team. Both building blocks may offer a benefit to a group of people—the developers of other components and services—but they don’t create any measurable value for the company.

If you manage a feature or component, then that’s perfectly fine. But I don’t think you should be called a product manager or product owner. The terms feature owner or component owner describe your role more accurately: they clearly communicate your responsibilities and avoid confusion and unrealistic expectations. (See my post The Agile Product Owner Responsibilities for more information on how distinguishing between products, features, and components helps you define the right roles and responsibilities.)

Web vs. Mobile

Digital products are often provided in different forms. Google Search and Facebook are both available as a website and mobile app, for example, and the mobile apps are offered on all major mobile operating systems, including Android, iOS and Windows Phone. Does this mean that the mobile version is a product in its own right? And similarly, are the Android, iOS and Windows Phone apps separate products?

My answer to both questions is no. Here is why: The assets don’t differ in the value they create for their customers and users and for the company that provides them. They may consist of separate code bases developed by different teams and the mobile version may provide less functionality, as in the case of Facebook. But the core value proposition is the same—just like a book is offered in print and in an electronic format but its contents stay the same. I therefore view the mobile versions of a product as different product variants, variations of the same product.

Unbundling Features and Product Bundles

Interestingly, features and components can become products in their own right. Take the Facebook Messenger app for example. The messenger feature used to be part of the main Facebook app until it was unbundled in April 2014. This streamlined the main Facebook app and it allowed Facebook to evolve the Messenger app by adding new features, such as sending money to friends, communicating directly with businesses, and using chatbots.

If we take a look at Facebook.com, then we see that messenger functionality is still offered alongside newsfeed and other features. I therefore regard the Facebook website as a product bundle—a collection of related products, including newsfeed, messenger, and games apps. While some products evolve into bundles, as Facebook arguably did, others are intentionally bundled together in order to provide value to the customers and users and/or increase sales. Microsoft, for instance, decided in the late 1980ies to bundle several apps, including Word, Excel, and PowerPoint, into Microsoft Office.

The following image shows the relationship between product bundle, product, feature, and component. A product bundle contains several products, and a product has one or more features and components.

User Experience

The user experience, finally, arises when people interact with a product. It is therefore not the product. While the look-and-feel and the functionality of the product can trigger a specific experience—think of slow loading web sites, complex menus, or cryptic error messages that can test our patience or leave us confused—it is important to recognise that the experience people have is equally determined by their state of mind.

If I am stressed, upset, or angry, I get much more worked up when experiencing a slow loading site, for instance, than when I am my normal self. We should do everything we can to offer a great, pleasant user experience, but we cannot make people experience the product in one specific way. The picture below illustrates the difference between the user experience and the product.

The Matrix Reloaded

The product portfolio matrix, also called growth–share and BCG matrix, wants to help you achieve the right blend of young and established products in order to maximise the overall value a portfolio creates. The matrix categorises products as question marks, stars, cash cows, and pets (also known as dogs). The picture below shows the grid with its four quadrants and product types; cash cows are represented by the dollar sign and pets by a cross.

Question marks are products with high growth that don’t yet deliver significant business benefits—be it generating revenue, selling other products or services, enhancing the brand equity, or saving money. [1] Stars show high growth and deliver the desired benefits. Cash cows are products characterised by low growth, but they offer plenty of business benefits. Pets, finally, exhibit low growth and offer few benefits. A sample question mark might be Google Translate and Apple Watch, a star Microsoft Surface, a cash cow Google Search and Microsoft Windows, and a pet the iPod family.

When you apply the product portfolio matrix to the offerings in an established company, you’d like to see a healthy, balanced portfolio with enough question marks and stars that have the potential to become cash cows. You also need sufficient cash cows that generate the desired business benefits at a comparatively low cost and are therefore able to help fund the development of new products, question marks, and stars. Finally, you’d like to minimise the number of pets, as they incur cost but deliver only limited benefits.

From Question Mark to Cash Cow

The quadrants of the portfolio matrix form an interesting relationship: Products start out as question marks. If they are to become successful, they must develop into stars and then morph into cash cows. Both development steps require effort, time, and money. You may have to change or enhance the features, user experience, and architecture of the product; you may have to adjust the business model and opt for different marketing and sales strategies; and some products require a pivot—think of Youtube, which started out as a dating website, and Flickr, which was an online game before it became a photo-sharing website.

Once a product has become a cash cow, it is able to offer the desired business benefits at comparatively low cost, as existing features are largely incrementally enhanced. A revenue-generating product is now most profitable (hence the term cash cow). Eventually, though, cash cows will lose their ability to provide business benefits and become pets. These products provide few benefits but still consume money to maintain them. The following picture shows the desired development sequence from question mark to pet.

As every successful product will become a pet and eventually die, it is crucial that you are able to replace ageing cash cows with stars and stars with question marks. At the same token, you must invest enough in new product development initiatives to generate new question marks—assuming that you want to grow organically.

Your product portfolio therefore requires regular adjustments, and portfolio management should be a common activity. As a rule of thumb, review your product portfolio once per quarter and initiate the necessary changes.

Product Portfolio Matrix and Product Life Cycle

As you may have noticed, the development sequence discussed above is correlated with the product life cycle: Question marks tend to be products in the introduction stage; stars are products in growth; cash cows are mature offerings; and pets are declining products. The picture below illustrates this relationship.

Note that the picture above does not account for life cycle extensions—prolonging the life expectancy of a product by adding new features, optimising existing ones, creating variants, or taking it to a new market or market segment, for instance. Such a measure extends the product’s status as a star and prevents it from prematurely becoming a cash cow.

Avoiding Common Mistakes

In theory, the development from question mark to pet and retirement should be straight forward and result in a healthy portfolio. But in practice, I see companies make three common portfolio management mistakes: focussing too much on stars and cash cows, not retiring pets, and clinging on to unsuccessful question marks.

Don’t Focus too much on Stars and Cash Cows

The first mistake is focussing too much on cash cows and stars and neglecting question marks and new product development initiatives, something particularly bigger companies are prone to in my experience. This is due to their tendency to optimise structures and processes for managing existing, successful assets, which makes it hard to deal with the amount of innovation and risk present in new and young products. But focusing too much on stars and cash cows leads to an unbalanced, ageing portfolio that stifles future growth, as shown in the picture below.

To prevent such a portfolio, invest 25% of your budget in brand-new products and question marks, and ensure that the teams have the right environment to quickly experiment, fail, and learn. [2]

Don’t Keep Pets for too Long

The second mistake is clinging on to pets even if their benefits are rapidly declining. You should, of course, do the opposite: retire products that are no longer sufficiently beneficial. Take the iPod Classic, Apple’s original and iconic MP3 player. The product was rightly discontinued in 2014 after it had experienced a continued decline in sales.

Don’t Cling to Question Marks

The third mistake, finally, is to over-invest in question marks and to hold on to them for too long: Not every question marks will become a star. Some just die prematurely. Take, for example, Google Wave, a product that combined e-mail, instant messaging, and wikis. Wave was discontinued about a year after its launch in 2009. It never experienced stardom and died as a question mark.

The following picture shows that retirement is not the only exit point in the portfolio matrix but that products may have to be discontinued as question marks.

To avoid over-investing in your question marks, ensure that all products in your portfolio have clear business goals and use the right KPIs to track product performance. If the latter stays flattish even though you have made significant changes to your product, then pivot or discontinue it early like Google did with Wave.

Notes

[1] I have tweaked the original product portfolio matrix by using business benefits instead of market share on the horizontal axis. When Bruce D. Henderson developed the matrix in 1970, he focused on revenue-generating products; digital products, as we know them today, did not exist. But many digital offerings do not directly generate revenue—take, for example, Amazon Kindle and Google Chrome. Instead, they provide different types of benefits to their companies, such as, help sell another product or service (Kindle books), collect data to learn more about user behaviour and build new products (Chrome), and tie the user into the company’s ecosystem (both products). Substituting market share with benefits makes the product portfolio matrix applicable to all digital products.

[2] Bansi Nangji and Geoff Tuff recommend in their article “Managing Your Innovation Portfolio” that companies should invest about 10% in disruptive or transformational initiatives and about 20% in incremental or adjacent ones. As a life cycle extension counts as an adjacent innovation, 25% makes a good rule of thumb for new development initiatives and question marks in my opinion.

How much product discovery work is necessary? While I find it impossible to give a general, precise, and accurate answer, there is one factor that has a big influence on the time and effort necessary to create a valid product strategy: the product’s lifecycle stage.

The younger a product is, the more discovery work it requires. A new product development effort may spend several weeks carrying out necessary prep work such as creating an initial product strategy and iteratively testing and correcting it. Contrast this with incremental enhancements of a mature product that may require little or no discovery work, as the following picture shows.

Please note that the line representing the discovery effort is in the picture above is only a rough approximation. In reality, the discovery effort may be higher or lower, and it may fall later or sooner.

The picture also assumes that the product moves from growth into maturity and decline, when it is eventually retired. Be aware, though, that when you extend the life cycle of your product, for example, by creating a variant for a new market (segment), unbundling one or more features, or changing the business model, you will have to carry out a significant amount of discovery and strategising work, as the picture below illustrates.

When determining the discovery effort, don’t make the mistake of skipping or shortcutting the necessary work. Don’t start the actual development work without a valid product strategy in place, without having nailed the value proposition, market, differentiators, and business goals of the new or changed product. Consider showing the necessary discovery work on your product roadmap, particularly when you make bigger changes to an existing product.

At the same token, avoid overdoing the discovery work. There is no way to guarantee that the product strategy is correct, that the new product or next version will be a success. Your goal should therefore be to get a good enough product out as fast as possible, and then adapt it to the market feedback.

[This post was updated on 6 October 2017.]

Bring the Right People Together

Product discovery is a team sport. You should therefore involve the right people in the discovery work and secure enough of their time. I find it helpful to form a product discovery team that consists of:

• Development team members: user experience (UX) designer, developer, tester;
• Key stakeholders, for example, people from marketing, sales, and support;
• A ScrumMaster or agile coach.

Involving others in the discovery work allows you to leverage their knowledge and expertise, builds rapport, and creates support for key product decisions including the selection of a specific market segment and stand-out features.

A UX designer, for example, might help you observe and interview users; and a developer and tester might advise you on technical feasibility, identify technical risks, and build prototypes; a sales rep might get you in touch with target users and help you with competitor research; a ScrumMaster might facilitate collaboration and advise on process issues—for instance, which process and tools should be best used to visualize and track the discovery work. (I prefer to use a Kanban-based process and a Kanban board, as I discuss in my book Strategize in more detail.)

Focus on Problem Validation, not Solution Building

Your product discovery work should focus on nailing the value proposition, target group, business goals, business model, and stand-out features of the product—not on writing user stories, designing the user interface, or building the actual solution. Your goal should be to mitigate the risk of building a product nobody wants and needs, not to figure out the product details.

Having said that, it’s ok to address key UX and technology risks and evaluate important user interaction and architecture options as part of the discovery work. But the bulk of the UX design, user story writing, and technology work should be done after you have successfully validated the problem.

To get your focus right, consider using a tool like my Product Vision Board to capture your idea, and identify assumptions and risks.

Do Just-Enough Product Discovery Work

Minimise the amount of time you spend on product discovery in order to accelerate time-to-market. You should aim to get a good enough product out as fast as possible, and then adapt it to the market feedback. There is no way to guarantee that the product strategy and business model are spot on, and that the new product or next version will be a success.

But don’t rush the necessary work, and resist the temptation to jump start building the actual product. Explore the key assumptions and risks in your product strategy and business model by systematically testing and addressing them in an iterative fashion using, for example, observations, interviews, surveys, and prototypes.

If you can’t confidently state why people are going to use your product, who those individuals are, what makes your product stand out from the crowd, and why it’s worthwhile for your business to develop and provide the product, then you are not in a position to build the actual solution. Instead, continue the discovery work (persevere or pivot), or stop and move on to another product idea.

Talk to the Users

With all the product discovery work that needs to happen, it can be easy to lose sight of the most important success factor—the people who are going to use the product. There is no point in coming up with a smart business model and sophisticated user interactions, if you don’t know who the users are, what they may be struggling with, and what works well for them, and what doesn’t. If the users don’t need and like your product, you will find it hard to monetise it and achieve product success.

Therefore, get out of the building (as Steve Blank says) and meet target users face-to-face as part of the discovery work. I know that’s not always easy. But to succeed with product discovery, I find it paramount that you—the person in charge of the product—carry out user research yourself and develop a deep understanding of the user needs.

When talking to users, take a genuine interest in the people you meet. Have an open mind and let go of preconceived notions about the problem you think the users have or the solution you believe they need. This allows you to discover what people really want and need thereby maximising the chances of creating a successful product.

Don’t Handoff Product Discovery Work

The people involved in product discovery should also participate in building the actual solution. The UX designer, developer, tester should work on the development team. The stakeholders should regularly attend product strategy and roadmap reviews, as well as sprint review meetings. This speeds up the product innovation process, creates a smooth transition from discovery to delivery activities, and mitigates the risk of loss of knowledge.

Handing off the discovery work is ineffective and wasteful: It requires detailing the knowledge acquired in form reports and other artefacts. This is time-consuming, and it is likely to lead to misunderstandings and loss of knowledge—it is hard to precisely capture the discovery learnings, and written information is open to misinterpretation.

Therefore, refrain from using separate discovery and delivery teams. I find it is usually better to involve more people from the development team rather than opting for two distinct teams. Remember that quickly learning what to do (and what not) and quickly delivering the right solution are more important to product success than efficiency and saving money—at least in the early life cycle stages.

Consider Timeboxing the Product Discovery Activities

Knowing upfront how much time and effort will be required to carry out the necessary discovery work is tricky. New risks and work items often emerge as part of the validation work. Luckily, there is a straightforward solution: timebox your product discovery work. This technique is particularly useful when you work on a new product or when you make a bigger change to an existing one, for example, to take the product to a new market in order to extend its life cycle.

A time box is a fixed period of time, such as one week, that cannot be extended. At the end of the time box, the work stops, and you reflect on what has been achieved. If the work has not been completed, and your product strategy and business model still contain significant risks, you have two options: add another time box—and possibly pivot—or stop the work.

Consider holding weekly review meetings that involve the people carrying out the validation work as well as the management sponsor. Use the meetings to reflect on the risks that are being addressed and the learnings that you have achieved; consider the risks that still exist in your product strategy and business model; and decide if and how to continue.

Don’t Limit Product Discovery to New Products

While the traditional usage of the term suggests that product discovery is the first stage in a new-product development process (see Cooper’s Stage-Gate process), it would be a mistake to limit product discovery to new products.

As your product grows and matures, its value proposition, market, stand-out features, and business model will change. To make and keep your product successful, it is paramount that you proactively review and adjust your product strategy, roadmap, and business model. These adjustments sometimes require little or no product discovery work.

But when bigger changes are required, such as, taking your product to a new market or adding features and redesigning the user experience to sustain growth, you’ll likely have to carry out specific discovery work, as the picture below shows. If that’s the case, then I recommend anticipating the work and stating it on your product roadmap.

Modern product discovery is hence best understood as a set of activities rather than a clear-cut phase that is separated by a milestone or gate from building the actual solution.

The post Product Discovery Tips appeared first on Roman Pichler.

The Minimum Viable Product

The minimum viable product (MVP), as originally defined by Eric Ries, is a learning vehicle. It allows you to test an idea by exposing an early version of your product to the target users and customers, to collect the relevant data, and to learn from it. For instance, to test the viability of using ads as the major revenue source, you could release an early product increment with fake ads, and measure if and how often people click on them.

As lack of knowledge, uncertainty, and risk are closely related, you can view the MVP as a risk reduction tool. In the example above, the MVP addresses the risk of developing a product that is not economically viable. Since the MVP is about learning, it’s no surprise that it plays a key part in Lean Startup’s build-measure-learn cycle, as the following picture shows:

The MVP is called minimum, as you should spend as little time and effort to create it as possible. But this does not mean that it has to be quick and dirty. But try to keep it as small as possible to accelerate learning and avoid the possibility of wasting time and money, as your idea may turn out to be wrong!

While the MVP should facilitate validated learning, I find it perfectly OK to work with MVPs such as paper prototypes and clickable mockups that do not generate quantitative but qualitative data, as long as they help to test the idea and to acquire the relevant knowledge.

The Minimal Marketable Product

Another concept that encourages you to create a minimal offering is the minimal marketable product (MMP). It is based on the idea that less is more: The MMP describes the product with the smallest possible feature set that addresses the needs of the initial users (innovators and early adopters), and can hence be marketed and/or sold. The MMP is a tool to reduce time-to-market: It can be launched more quickly than a fat, feature-rich one.

Creating a product with just the right amount of features sounds like common sense. Why would we offer more features than necessary? Sadly, I have seen many organisations develop over-engineered products with lots of shiny features that provided little value to the users, but cluttered the product and increased its maintenance cost. And it’s not just the others: I am constantly tempted to add just another cool feature to a product, or to write a few extra lines in a blog post. Using the concept of an MMP helps me focus on what really matters, and remove unnecessary features (and lines).

A great example of an MMP is Apple’s original iPhone launched in 2007. I understand that the first iPhone was a complex product, and that many people worked incredibly hard on it. But I find it amazing how many features the phone did not provide compared to its competitors: no copy-and-paste, no video, and no POP email integration, to name just a few. Nevertheless the phone was still a staggering success. How come?

The key to creating a successful MMP is to “develop the product for the few, not the many,” as Steve Blank puts it, and to focus on those features that make a real difference to the users. To discover the right features, the aforementioned MVP is a fantastic tool.

Combining the Two Concepts

To combine the two concepts, develop one or more MVPs to test your ideas and to acquire the relevant knowledge. This is typically done as part of your product discovery activities. Then use your new insights to create and launch the MMP – a simple product with the right user experience and feature set.

Note that a minimal marketable product differs from a viable one: It is complete enough to be ready for general release, as indicated by the gift wrapping in the picture above. What’s more, launch preparation activities have to take place for an MMP, for instance, creating advertising campaigns, or gaining certification. Some of your MVPs are likely to be throwaway prototypes that only serve to acquire the necessary knowledge; others are reusable product increments that morph into a marketable product.

Post Scriptum 2 November 2017

Since I wrote this post, the meaning of the term minimum viable product has started to change. People like Ash Maurya view it as the smallest offering that can be launched, which essentially equates the MVP with the minimal marketable product.

Whichever definition you prefer, aim to launch the smallest possible product that is still good enough to serve its early market. Then inspect and adapt to achieve product-market fit and growth. This may require smaller changes like adding or optimising features, adjusting the business model, and enhancing the user experience. But it might also require a pivot, a drastic change. Flickr, for example, was launched as an online role-playing game and changed to a photo-sharing website; YouTube evolved from a video-dating site to a video-sharing product.

The post The Minimum Viable Product and the Minimal Marketable Product appeared first on Roman Pichler.

What Maturity Means

A product is mature if it has stopped growing: The benefits it creates no longer rise. Instead, they have started to stagnate. In terms of the product life cycle model, the product has left the growth stage and entered maturity, as the following picture shows.

To find out if your product is mature, you should track its performance. To do so, you must be clear on the value it creates for the users and business. A tool like my Product Vision Board can help you with this. Next, select the right key performance indicators (KPIs). These might include revenue, cost, profit, market share, engagement, net promoter score, and cancellation rate, for instance. Then measure how much value your product creates. If the data shows a largely flat performance over the last few months, then the product is likely to be mature.

Ideally, you should continuously track the product performance and regularly review the product strategy—at least once per quarter as a rule of thumb. You should therefore become quickly aware of the fact that the product performance is stagnating and your product is entering the maturity stage—which I regard as an important strategic inflection point. This enables you to be proactive and thoughtfully respond to the change. Note that eventually every product enters maturity; no product can continue to grow forever. The only question is when this will happen.

Option 1: Extend the Product Life Cycle

Once your product has entered maturity, your first option is to move the product back into the growth stage thereby extending its life cycle, as the following picture shows.

A number of techniques can help you make an ageing product attractive again including enhancing its capabilities and adding new features. Take the iPhone as an example. Apple has made considerable changes to the products throughout its life: it introduced apps, increased its size, improved the camera, and added face recognition, to name just a few.

Sometimes, though, the opposite strategy is more appropriate. Instead of adding more features, you may want to remove some and declutter your product. Take Microsoft Word for example. Microsoft has made significant efforts to simplify the application in recent years, thereby making it easier for people to use the product.

Another way to stimulate growth is to take your product to a new market or market segment. Think of YouTube Red, a variant of YouTube, for example. At the time of writing, the product offers advertising-free online and offline viewing of YouTube videos, as well as access to Google Play Music and YouTube Red Original series and films. (At the same time, the move has enabled Google to compete with companies like Netflix.)

Finally, you might consider bundling your product with other offerings to increase its attractiveness. For instance, iOS and Android bundle a mobile operating system with a number of pre-installed apps including a web browser, email client, and maps.

Is Option 1 Right for Your Product?

While rejuvenating the product and moving it back into growth may sound attractive, it is not necessarily the right thing to do for your product. If you should choose this option depends on a number of factors:

• The category the product belongs to continues to be attractive.
• You don’t want the product to turn into a cash cow.
• You are able to invest the time and money required to extend the life cycle.
• The product is not too deep into maturity; its performance has fairly recently stagnated.
• The product health including its code quality is reasonable.

If the product category your asset belongs to has lost its attractiveness, then revitalising the product will be difficult. Take MP3 players, for example. The product category has lost its sparkle; fewer and fewer people own dedicated MP3 players; and most of us use our phones to listen to music on the go. If say Apple wanted to revitalise its iPods, then this would be hard to achieve (unless the company marketed them as niche products similar to turntables).

Additionally, rejuvenating your product only makes sense when you don’t want or need it to become a cash cow. As its name suggests, a cash cow is a product that offers plenty of business benefits while it requires a comparatively low investment. Any product portfolio should contain a healthy mix of younger and older products. It can therefore be advantageous to accept maturity and let your product age gracefully, as I discuss in option 2 below.

Extending the product life cycle also requires time and money: You may have to carry out market, user, and competitor research; you may have to develop new features; and you may have to evaluate new technologies and integrate them into the product, resulting in a significant product discovery effort.

What’s more, the longer your product stays in maturity, the bigger the effort is likely to be: Chances are that the market has moved on while you’ve played a defensive game, doing only what is necessary to secure your product’s current position. Shifting gears, embracing an entrepreneurial mindset, and innovating the product can then be challenging.

Finally, consider the product’s health. How high is its refactoring potential and code complexity? How soft or brittle is the software? How easy or difficult will it be to make the necessary changes? While poor product health is not necessarily a show stopper, it will make a life cycle extension harder and more expensive.

Option 2: Keep the Product in Maturity

The second option is to accept your product’s trajectory, let it continue to mature, and keep it at this stage for as long as possible, as the picture below illustrates.

Accepting maturity means adopting a more conservative mindset and playing a defensive game: You typically want to protect your product’s position without investing too much time and money. This often results in incremental enhancements and bug fixes rather than bigger changes like adding brand-new features.

This approach allows you to turn the product into a cash cow—a product that creates plenty of business benefits while requiring a moderate to low investment. But to be able milk it for an extended period and prevent early decline, you must not become complacent and neglect your product.

Keep an eye on market developments including changes in user behaviour, moves by competitors, and new trends that may affect your product. Continue to track the product performance and regularly check if the current strategy is working. And invest the money required to keep the product beneficial for its users.

Should You Choose Option 2?

The second option is right for you if you don’t need to or if you can’t rejuvenate the product: New products are in the pipeline that can eventually replace your product, which are also referred to as question marks and stars, or you are able to secure new products through an acquisition.

Alternatively, the effort to extend the lifecycle is just too big. This may be due to the product category losing its attractiveness, the product having been in maturity for too long, and / or poor code quality.

At the same time, you are happy to turn the product into a cash cow maximising the value it creates for the business while carefully managing the investment required.

The post Strategic Options for Mature Products appeared first on Roman Pichler.

Why Technical Debt Matters for Product People

As the person in charge of the product, you may not be terribly concerned about how clean and well-structured the code is. But the quality of your product matters: It directly impacts your ability to achieve strategic product goals and make your products successful: Technical debt makes it hard to experiment with new ideas, release new features, and quickly respond to user feedback. [1]

The messier the code and the less modular the architecture is, the longer it takes and the more expensive it is to change your product. In the worst case, you have to go through a rewriting exercise where some parts or even the entire product are being redeveloped. This is similar to financial debt: When the debt is not paid back, the interest payments can multiply and eventually cripple the business.

Technical Debt and Your Product

To understand if and to what extent your product is affected by technical debt, talk to the development team, for example, in the next sprint retrospective. I find that development team members usually have a good understanding where issues in the architecture and code are.

Additionally, consider asking the team to collect data that shows how much technical debt there is, where it is located, and how bad it is, for example, by using code complexity, dependencies, duplication, and test coverage as indicators. There are a number of code analysis tools available that collect the appropriate data and show how adaptable the architecture and how clean the code is. [2]

Once you understand the amount and severity of tech debt in your product, analyse its impact on meeting the product goals and achieving product success together with the development team. Take into account the cost of delay, the cost of not addressing the technical debt now but delaying it to a future point in time. Should you, for example, continue adding new features to the product for the next six months and plan in bigger technical improvement work afterwards? Or would it be better to address the worst debt now?

Furthermore, consider the life cycle stage of your product. Technical debt is particularly bad for new and young products: If your product has a closely-coupled architecture with lots of dependencies, if it lacks (automated) tests and documentation, or if it is full of spaghetti code, then experimenting with new ideas and adapting the product to user feedback and new trends will be difficult and time-consuming. Similarly, if you want to extend its product life cycle, you may have to first remove (some of) the technical debt before you can make the necessary changes and add new features or create a variant.

Having said that, it is a valid strategy to launch a minimum viable product (MVP) whose architecture, technology, and code has been intentionally compromised in order to reduce time to market—as long as the quality is good enough to adapt the product to feedback from the early market. But apply this strategy with caution: You will have to spend time addressing the technical debt incurred and putting your product on solid technical foundations. This should be done before reaching product-market fit, as you will otherwise struggle to scale up and keep your product growing.

If, however, your product is in maturity—or even decline—and you do not intend to extend its life cycle but focus on maximising the business benefits it generates, you probably want to do as little debt removal work as possible.

Options for Removing Technical Debt

Once you’ve established how much tech debt there is and how soon it needs to be addressed, you face two choices: You can either make time for a focused effort and dedicate a period of time to removing the debt, or you can carry out the work in parallel to enhancing your product and adding new functionality.

Whenever you face a significant amount of tech debt that constitutes a barrier to innovation, you should opt for a dedicated period to remove it. Apple did this with Mac OS X Snow Leopard, which was released in 2009 after nearly two years of work. While Snow Leopard didn’t provide any new functionality, it created the foundation for future releases by improving performance and reducing the memory footprint of the operating system, for example.

I am not suggesting that you should necessarily spend a year or more refactoring your product, as Apple did. But it can be more effective to make a concentrated effort and invest a few months, or at least a sprint or two, in cleaning up the software, as opposed to doing it in drips and drops across several releases. You intentionally slow down, so to speak, to go faster afterwards.

If a refactoring release is the right approach for you, then your product roadmap should reflect this: It should show a release dedicated to future-proofing the product and making the necessary technical changes.

But if the technical debt is not as significant and does not need to be addressed as urgently, then plan in time for removing some debt in every sprint while continuing to improve the user experience and add or enhance features. You can do this by adding tech debt remedial items to the product backlog. This makes the necessary work visible and allows you to track it across sprints and releases. Make sure, though, that the necessary work is actually carried out and requests for more functionality don’t prevent the removal of technical debt. (My article “Succeeding with Innovation and Maintenance” discusses how you can fix bugs and add new features at the same time.)

Preventing Technical Debt

Intentionally compromising the code quality to get a release out and accepting technical debt is all good and well as long as you actually remove the debt afterwards. Often, however, technical debt is created unintentionally in my experience.

Digital products require ongoing attention to their architecture and code. Otherwise, the product quality will deteriorate, which leads to an increase in technical debt. This is very much like maintaining your bicycle on a regular basis, ideally after every ride. And the more you rely on your bike, the more you should care about it, clean it, and fix or replace faulty parts. The challenge is to make time for the necessary clean-up and maintenance work and view it as part of the bike riding experience, rather than a chore.

The same is true for digital products: Some teams feel so rushed and pressured that they repeatedly cut corners and don’t apply good software craftsmanship practices like evolutionary architecture, test-driven development, pair programming, and continuous integration. But these practices do not only help create an adaptable architecture and clean code base. Used properly, they will speed up development and allow you to release new features and functionality faster, not slower—the latter being a common misconception amongst product people in my experience. The opposite is also true: If development teams don’t apply the right practices and tools, then the software is likely to be brittle, not soft and malleable.

If you want to prevent future technical debt, then give your development team the time to learn, apply, and improve the right development practices. In fact, you should expect that the development team creates product increments with the right quality. A great way to do this is to employ a Definition of Done that states code complexity limits and test coverage targets, and to only accept work results that fulfil this definition.

Notes

[1] Technical debt is a concept originally suggested by Ward Cunningham and nicely explained by Martin Fowler. Thanks to Yves Hanoulle for encouraging me to write about it.

[2] I recommend that you add software quality to your KPIs and routinely track it. Quality is leading indicator: If it is decreasing, then you know that changing the product will become more and more difficult unless you do something about it. Knowing if and how much technical debt is building up helps you be proactive and avoid nasty surprises.

The post Technical Debt and Product Success appeared first on Roman Pichler.

See the Rewriting Effort as an Opportunity to Innovate

A digital product is commonly redeveloped for two reasons: It has accumulated too much technical debt or its technologies are outdated, but the product is still needed—be it to generate revenue, support other revenue-generating products, or automate business processes and increase productivity. Consequently, rewriting efforts are often focused on replacing like-for-like: The users get the same product dressed up in new technologies.

While this approach works, I wastes the opportunity to innovate and create more value for the users and business. Wouldn’t it be great to make the product better, improve the user experience and add brand-new features? Take Microsoft Office as an example. The company enhanced its productivity suite in recent years by decluttering the user interface and adding new features like collaboration and Skype integration, not just by replacing existing code.

Start with Product Discovery

But before you start compiling a product backlog with the new features the product should provide, take a step back and find out who actually uses your product, why people employ it, which user journeys they carry out, and which existing features they mainly use. This requires some user research and product discovery work, for example, observing users and conducting problem interviews, as well as analysing any analytics data you may have available.

A great way to leverage the data you’ve collected and discover improvement opportunities is to create a consumption map. Such a map visualises the steps users take and any issues they encounter like waiting,  delays, and errors (as I explain in more detail in my book Strategize). For revenue-generating products, you should also investigate if the product is still effectively differentiated: Do users have a compelling reason to choose it over competitors’ offerings? A great way to answer this question is to create a Strategy Canvas, as I describe in my article “Make Your Product Stand Out with the Strategy Canvas“.

Additionally, give the development team members the opportunity to carry out some technology exploration to ensure that the redeveloped product will be built in the right way. Would a micro services-based architecture or machine learning be beneficial, for example?

Finally, capture your insights and describe the product’s current strategy: the people it serves, the value it creates for the users and business, and its key features, for instance, by using my Product Vision Board.

If you find it hard to justify carrying out the necessary discovery work, then look at the inaction risk, the risk of not making the necessary changes and providing a carbon copy of your product: Which benefits would you lose, such as increasing user satisfaction by simplifying the product and saving maintenance cost by removing features? Then try to quantify these benefits and compare them to the discovery investment required.

Explore Your Strategic Options

Next, examine the options to move your product forward: Should you continue to provide one, cohesive offering? If so, can you remove some features or lean them out? It’s not uncommon in my experience that over time, features are added to a product in order to accommodate requests from powerful stakeholders—not necessarily because they benefit the majority of the users. These are prime candidates for removal. Additionally, consider if you can add or enhance features to make your product stand out, and if you can improve the user journeys, for example, by eliminating steps, improving touch points, and reducing delays.

If, however, the user base has evolved into a larger, heterogenous group, consider creating different product variants to address the subgroups—think of Microsoft Visio Standard and Professional as examples for variants of the same product. Alternatively, you may want to unbundle one or more features into a new product, as Facebook did with Messenger in 2014 when the company released the messaging feature as a stand-alone app.

Capture your decisions and document the new strategy for your product, for instance by creating a new, forward-looking Product Vision Board. Before you proceed, carefully investigate your board for any major risks and assumptions. If you find some, take the time to validate them. Otherwise you risk implementing an unvalidated and potentially incorrect strategy.

Incrementally Replace the Product

Chances are that the existing product has grown over many years. Replacing it in one go may require a significant amount of time and money and it carries the risk of discovering issues late in the process. Incrementally replacing your product, for example, by using bimonthly releases that progressively enhance the product, avoids these issues. What’s more, it allows you to collect user feedback and data and discover issues and opportunities at an early stage. But it also means that you have to keep the old product working until the new one is ready to substitute it.

If you decide to create variants or unbundle features, determine which variant you will offer first or which product, the original or the new one, you are going to initially develop—unless you are able to create both in parallel. And if you look after a commercial product, you may have to find a small group of customers who are willing to be innovators/early adopters of the redeveloped product in exchange for the ability to influence its development.

Once you have identified the right way forward, capture your decisions in a product roadmap like my GO Product Roadmap. You should now be in a good position to stock the product backlog and create the right user stories.

Invest in Quality and Proactively Manage Your Portfolio

Several years ago, I worked on a new telco product that was destined to replace its predecessor. The new offering, built with cutting-edge technologies, was intended to have a superior user experience and significantly reduced maintenance cost. Unfortunately, the development effort took longer than expected. To avoid further delays, management decided that the development teams should do whatever they could to get new features out as fast as possible; development practices such as test-driven development, pair programming, and continuous integration were seen as unnecessary and went out of the window. Sadly, the new product’s code ended up being as messy and buggy as the old one thereby invalidating a major reason for developing it.

While this story may sound extreme, rushing out product replacements is not uncommon in my experience. Organisations sometimes procrastinate the redevelopment effort for so long that quickly having the new product available becomes absolutely mandatory. To avoid this mistake, make sure you are aware of the technical debt in your product and start a re-writing effort early enough.

Additionally, you should do what you can to ensure that the new product has the right architecture and a clean code base, that it is easy to extend and maintain. Use a Definition of Done, only accept work results that comply to this definition, and encourage the development team(s) to apply agile development practices.

Finally, establish a portfolio management process and track your products’s life cycle stage. Pay close attention to your cash cows and pets (formerly known as dogs) and make sure that you invest early enough in new products to replace them and avoid having to rush out their replacements. This makes it considerably easier to carry out the necessary discovery and strategizing work and develop a product with the right quality.

The post Tips for Rewriting a Digital Product appeared first on Roman Pichler.

Before You Start Prioritising …

Before you order the roadmap items, double-check that you have a validated product strategy in place. You should be able to confidently say why users would want to use your product and why it is worthwhile for your company to invest in it. In other words, you should have valid answers to the following questions:

• Which user problem will the product solve, or which benefit will it provide?
• How will it create value for the business? For example, will the product directly generate revenue, help market and sell another product or service, reduce cost, or develop the brand?

If you haven’t nailed the answers, then do not continue the roadmapping effort. Instead, carry out the necessary product discovery and strategizing work. Otherwise, your roadmap may be built on false assumptions. Getting the prioritisation right will then be virtually impossible.

Create a Compelling Narrative

To prioritise the product roadmap, consider in which life cycle stage your product is. As long as it hasn’t reached maturity, a product has to constantly move forward: initially to get to launch, then to reach product-market fit, and finally to sustain growth.

At these life cycle stages, your product roadmap should tell a convincing story about the likely development of your product; it should describe the journey you want to take it on in order to create the desired value for the users and business. To get the prioritisation right, take the following steps:

• Determine how you can meet the user and business goals stated in your product strategy. What is the best way to achieve them? How can you break them down into smaller, intermediate goals?
• Order the newly created goals so that each one is a logical progression, a further step towards the overall user and business goals, considering any dependencies between the goals.

For a brand-new product, this might mean that you start with user acquisition followed by activation, retention, and finally revenue generation, depending on your product’s underlying business model. For a product in the growth stage, you might find that you first have to remove technical debt before you can enhance the user experience and increase conversion.

If there are items that were on the product roadmap prior to the prioritisation, then check if they help you reach any of the newly created goals. If that’s the case, then assign them to the appropriate objective. Otherwise, either discard the item or investigate if changing the goals to accommodate the items would be beneficial. A cost-benefit analysis might help you with this.

Whatever you do, make sure that your roadmap tells a cohesive, meaningful story that clearly communicates how the product will create value.

Determine the Cost of Delay

Once your product has entered the maturity stage, you usually don’t want to take it on another big journey, unless you decide to extend its life cycle. Instead, you stay where you are, protect your product’s position, and maximise the return it generates.

Consequently, there are often smaller, unconnected goals that need to be addressed, like sustaining engagement or preventing churn by offering incremental enhancements or bug fixes. But these objectives often lack clear connections, and they don’t form a logical sequence or narrative.

Faced with such a challenge, I recommend using cost of delay to get the prioritisation right. To put it simple, ask yourself how big the loss or severe the disadvantage is likely to be when you delay each item. For example, if you are unsure whether you should first enhance the user experience to sustain engagement or fix bugs to prevent churn, then identify the impact of delaying each goal.

Once you’ve determined the cost of postponing the items, address the one with the biggest cost of delay first, then the item with the second biggest cost, and so forth. This should give you the right prioritisation.

Don’t Let Powerful Stakeholders Dictate the Prioritisation

The two approaches described above assume that the user and business needs together with the product’s life cycle stage determine the prioritisation of your product roadmap—not the HIPPO, the highest paid person’s opinion.

Don’t get me wrong: I am a big advocate collaborative product roadmapping. Do actively involve the key stakeholders and development team members, encourage people to share their ideas and concerns, attentively listen to them, and build shared agreement, as much as possible.

But if you are faced with individuals requesting or even demanding that their interests must be first addressed, then do not simply give in. Don’t appease them and don’t avoid a difficult conversation. Instead, patiently listen to them and thank them for telling you about their idea. Then invite them to the next product roadmapping workshop so they can share their request with the other stakeholders and jointly decide if and when it can be addressed. And if the matter is urgent, get everyone together as soon as possible.

Being a product professional means making difficult choices, and prioritisation entails saying no. This is an important part of our job, whether we like it or not.

The post Product Roadmap Prioritisation appeared first on Roman Pichler.

A Tale of Two Products

I once worked with a telco company that was developing a brand-new commercial product. Product management and development were located at separate sites in different countries. But this didn’t seem to matter much as everybody was in great spirits and had high hopes for the new product. What’s more, the product people would occasionally visit the development site, and development group members would travel to product management from time to time.

Unfortunately, things didn’t go to plan. The technical complexities were greater than anticipated and the development progress was slower than forecasted. As trust was low between product management and development, a blaming game quickly started. Instead of working through the issues together and supporting each other, the product people assigned fault to development, and the development teams blamed the product people. Unsurprisingly, the product failed to become the success everybody had hoped for. Would things have been different if product management and development had been at least initially collocated? While it would not have guaranteed product success, it would have led to stronger and more trustful connections that would have made it more likely to resolve the challenges encountered.

Compare this example with a different one: I was working for a large technology company, tasked with helping develop a new digital product. Despite its focus on reducing travel expenses, most people involved the development effort were collocated at one site in the US. I was one of the few individuals who stayed at their home site. But regularly traveled to the main site and stayed there for several weeks at a time. This allowed me to build strong connections with the other team members and work more effectively with them from my base in the UK. While the development effort was not all plain sailing, the product became a great success: The trustful connections people had developed helped us successfully work through the challenges.

To Collocate or Not

We live and work in a globalised world, and there are usually good reasons for having teams and individuals located at another site. For instance, the team might be part of a recent acquisition; the skills required might not be available locally; people might not be able to relocate; or you might have to partner with a supplier in another country. But as the initial story above shows, working with remote teams is not always conducive to achieving product success: When you work on a product that has not yet reached product-market fit or when you are planning to extend the life cycle of an existing offering, you should at least initially collocate the development team and key stakeholders. Similarly, whenever you work with a new team, collocate everyone at least for the first two to three sprints, assuming that you use biweekly iterations.

In other words, whenever you face a significant amount of innovation or the level of trust between the people involved is weak, you should bring people together, as the following pictures shows.

The matrix above suggests that unless the individuals involved in the development effort know and trust each other and the degree of innovation is low, you should at least partially collocate them. This includes initially working together at one location for a few weeks, as described above, and regularly spending time together onsite, as I explain in more detail below.

The Office

“I suppose I’ve created an atmosphere where I’m a friend first and a boss second. Probably an entertainer third,” says David Brent in the original Office series. While I admit that working in the same office can have a number of drawbacks, including getting side-tracked by meetings and office politics, being at least temporarily collocated offers the following three benefits to your product:

First, it allows you to collaborate on product discovery and strategy validation thereby leveraging the collective knowledge and creativity of the individuals, creating a shared understanding of the users, needs, competitors, and business goals, and securing strong support by involving the stakeholders and team members in strategic product decisions. Ideally, you want to select a site that is as close to the target users and customers as possible when developing a new product or taking an existing one to a new market. This makes it easier to carry out collaborative market and user research work like observing and interviewing target users.

Secondly, being collocated makes it easier for people to get to know each other and build trust. It’s more difficult to establish rapport and jell as a group when you can’t have coffee or lunch together and only see each other in video calls. But without sufficient mutual trust and understanding, working together will be difficult and costly: You are likely to require more and longer meetings and you will experience weaker buy-in to product decisions; people tend to be more defensive and less open to change, as they lack the necessary psychological safety.

Thirdly, working in the same office, at least for some time, helps with developing initial norms and standards. This includes the following:

• Agreeing on roles and responsibilities and how they are filled;
• Determining which tools you should use to capture product strategy and product roadmap decisions, collect user data, store product backlog items; and measure product quality;
• Making process decisions, such as how product discovery work is planned and tracked, how sprint review meetings are run, and how the development progress is measured.

Get Back

It’s wonderful to established trust amongst the people involved in developing the product. But if people return to their home sites and work in a distributed or dispersed fashion, then bring them back together from time to time, at least as long as the level of innovation is high. This allows people to reconnect and deepen their relationship, and it counteracts them-and-us thinking, something I have often encountered when working with distributed teams. The following practices will help you with this:

• Quarterly onsite meetings: Meet at one of the sites every quarter and carry out joint discovery/strategy and development work. For instance, have a joint strategy review workshop taking into account product performance, competition, and trends, and hold a shared sprint review meeting inspecting the latest product increment. Don’t forget to regularly rotate sites. This ensures that people get to know the different locations and avoids that one site is seen as being preferred or better.
• Ambassadors: Ask the development teams to rotate team members. For example, if you have two teams in two different locations, ask each team to find a member who is willing to work with the other team for the next three to four months. After this period, the individual joins her or his “home” team, and another team member plays the ambassador role.
• Site visits: Regularly visit the different sites as the person in charge of the product to connect with the local team members, stakeholders, and any local product people like a feature or component owner.

Don’t Accept a Distributed Setup as Sine Qua Non

If you believe that working with distributed or dispersed teams will make it hard to progress your product and achieve product success, then don’t accept it as something that cannot be changed. Instead, share your thoughts with the decision-makers in the organisation and suggest a more effective setup. Alternatively, consider if you realistically can be in charge of the product. While it’s easy for me to say this, nothing will change if you make do with an ineffective setup. Bear in mind, though, that creating teams that are collocated may take time.

In some cases, it may require site consolidation—transferring jobs from one site to another and forming collocated units of product management, development, and other key functions, even if that’s difficult for the individuals involved. But in the long run, it may be better for the people, product, and planet.

The post Collocation, Trust, and Distributed Teams appeared first on Roman Pichler.

What are Feature and Component Teams?

A feature team is a development team that implements end-user functionality end-to-end. Contrast this with a component team. Such a team owns an architecture building block, for example, a layer, a subsystem, or a collection of components or services, as figure 1 illustrates.

Figure 1 depicts a simple software architecture that consists of three layers: user interface, business logic, and data. Say that I want to develop an app that helps people eat healthily. A feature team might then develop the capability that allows users to see their eating trend, for instance. It would implement the feature as a vertical slice, from the user interface down to the data layer. A component team, however, might develop the business logic that calculates recommended calorie intake. The team would not touch any of the other layers but exclusively focus on the business logic.

Why Does this Matter to Product People?

When your product starts to attract more users, you typically require more development teams to sustain the growth, enhance features, and add new ones. This presents you with a choice: You can organise the teams primarily around features or architecture building blocks. This choice matters: It will affect your ability to progress your product and achieve its strategic goals, as I explain in more detail below.

Feature and component teams both come with benefits and drawbacks. The former have a strong end-user focus: They work on functionality that creates value for the end users. Feature teams can also consume items directly from the product backlog and turn them into working software. Additionally, they are loosely coupled and not dependent on the work of other feature teams. This has two benefits: First, it allows you to quickly test an idea and release a feature fake or early version of a feature, gather user feedback, and adapt it. Second, if one feature team fails to deliver, then you can usually still use the work of the other teams. But using feature teams can introduce user experience and architecture inconsistencies and it can lead to code duplication. In the worst case, each team creates its own user experience and user interface design, its own business logic, and its own data layer, to stay with the architecture example shown in figure 1.

Component teams avoid these drawbacks. As they are organised around architecture building blocks, they enforce architecture consistency. Additionally, it can be easier to staff component teams compared to feature teams. In figure 1, every feature team would need someone with the appropriate user interface design skills, for instance. On the downside, component teams often cannot consume items directly from the product backlog. The teams that own the business logic and data layer in figure 1 need technical requirements that describe the interfaces that should be created or enhanced. Translating end-user requirements into technical ones creates overhead and slows down development. What’s more, as component teams tend to build software for other development teams, they can lose sight of the end users and sub-optimise their building blocks: I have seen component teams who were more concerned about the performance of their components than the end-user experience.

When are Feature Teams Preferable and When are Component Teams Better?

I recommend that you prefer feature teams over component teams as long as your product experiences bigger changes. This is typically the case for brand-new products, products in the introduction stage, products that rapidly grow, and products whose life cycle is being extended, for example, by taking them to a new market or adding new features. But once your product is stable, once it has entered the maturity stage (and you don’t intend to extend its life cycle), then component teams tend to be a better choice, as figure 2 shows.

Features teams allow you to move fast, add new functionality, respond to user feedback, and adapt your product. This makes them better suited for coping with innovation, uncertainty, and change—challenges that are present at the early life cycle stages and a life cycle extension.

Component teams help you reduce cost and increase profitability by maximising reuse and ensuring architecture integrity. This is desirable for mature and declining products, where you typically focus on incremental enhancements and bug fixes, and cost reduction.

Consequently, it can be beneficial to change the team setup after a product has entered the maturity stage. But this should always be done with the agreement of the development teams: Telling teams that they will be disbanded and newly assembled conflicts with the idea of having empowered agile development teams.

What about a Mix and Match?

You can, of course, combine feature and component teams. But the advice above still holds true: Be clear on the team setup that benefits your product most. For instance, when managing a young product, you might find it beneficial to have one component team that looks after the data layer. But if that’s what you decide to do, make sure that there is a good reason for using a component team, and keep the number of component teams to a minimum at this stage. Similarly, when you need to make a bigger change to a mature product like a substantial feature enhancement, you might want to use a feature team to get the work done.

Don’t forget, though, that teams need time to gel. Team members have to learn to trust each other and build connections in order to be able to effectively work together. Frequently changing the team setup is therefore undesirable.

The post Are Feature Teams or Component Teams Right for Your Product? appeared first on Roman Pichler.