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 lifecycle 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.
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 lifecycle model, you have to define the business benefits your product delivers and then track them over time. For revenue-generating products, for example, revenue is commonly used. 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, 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 optimized existing features like cameras 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 revitalize a maturing product and extend its lifecycle, 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 lifecycle extension is shown by the arrow that reverses the aging 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.
Therefore, I 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.