Whenever you require more than a single development team to progress your product, you have choice: You can organise the teams around features or components. This article explains why this decision matters for product people, and it shares my advice on when feature teams are right for your product and when component teams are 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 discovery 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 users actually want and need. In this article, I share my recommendations to help you reflect on and improve your product discovery 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 managers and product owners, the products we look after are fundamental to our work: they shape our day-to-day activities and determine our responsibilities. We create a product strategy and product roadmap; we manage the product backlog and use minimum viable products and product increments. But what is a product? While this seems a trivial question, I have met several organisations with a understanding of what a digital product is. This can cause confusion, lead to unclear roles and responsibilities, and result in applying the wrong product management practices. This post discusses what a product really is and how it differs from features, components, bundles, 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.