Whenever you require more than a single development team to progress your product, you have to consider how to organise the teams. One choice is to use feature and component teams. This article explains why this distinction matters for product people, and it shares my advice on when feature teams are right for your product and when component teams might be better suited.
Getting the product roadmap prioritisation right is a common challenge. Which items should be addressed first? Which ones can be delayed? This article answers these questions and helps you effectively prioritise your product roadmap.
Rewriting an existing product is often a cost and technology-centric exercise that can feel like a joyless necessity. But instead of replacing like-for-like and providing a carbon-copy of the old product, you should see the rewriting effort as an opportunity to innovate, to create more value for the users and the business, as I explain in this article.
Similar to a company experiencing financial debt, products can incur “technical debt”: This happens when wrong or suboptimal architecture, technology, and coding decisions are taken. Consequently, the architecture may not be as loosely coupled as it should be, and the code may be messy rather than clean. This article explains why product people should care about technical debt and it offers strategies for addressing it.
Product strategy does not only matter for new and young products; it is equally important for older ones. This article discusses two main choices for mature products: extending the life cycle and revitalising the product, or leveraging maturity and turning the product into a cash cow.
Product strategizing refers to the activities required to determine if and why a product should be developed. Carrying out this work makes it more likely to create a product that users want and need. In this article, I share my recommendations to help you improve your product strategy work.
The product portfolio matrix is a handy tool that helps you make the right product portfolio decisions. This post explains how you can effectively apply it to manage a portfolio of digital products.
Scrum offers a powerful way to develop products. In fact, it is often seen as the standard way to create digital products, and I have met more than one company where the product managers were suddenly told to be agile and do Scrum. But like every process, Scrum has its benefits and limitations. Is it the right approach to develop and grow your product? Or would you be better off using an alternative?
As product professionals, we create a product strategy and product roadmap; we manage the product backlog; we release minimum viable products and product increments; and we are responsible for achieving product success. But what is a product? While it might seem a trivial question, it is surprisingly hard to answer for many organisations. But a poor understanding of this fundamental concept can lead to unclear roles and responsibilities and result in ineffective product management practices. This article offers my definition of what a digital product is and how it differs from features, components, projects, and the user experience.
The product backlog is a great tool. But using it effectively can be difficult. One of the challenges is to get the level of detail right. An overly detailed backlog is unwieldy and hard to manage. But a product backlog that is too coarse-grained is also not helpful: It provides too little guidance for the development team. This post helps you strike the right balance between too much and too little detail. It shows you how determine the right amount of detail for your product backlog.
