No matter how small a product starts – over time it will get bigger and fatter. The seemingly canonical growth paradime enforces the continuous extension of the product portfolio. Needs of existing customers should be satisfied even better and new customer groups should be cracked in parallel as well. There are only a few organizations capable of not following this logic. 37 signals is such an exception. Or also Apple where the re-joining Steve Jobs dramatically cut product diversity (just compare the number of different smartphones offered in comparison to Samsung). All other product managers know the result: However fast or slowly an organization is actually growing, the current backlog of committed initiatives will easily fill the roadmap for the next 2-3 years. Projects and corresponding expectations pile up. Without active management the queue will get longer and longer, since the required effort to maintain and develop the product portfolio will increase with every new feature.
For agile product management this queue proofs to be a serious problem (see also our blog post “Wasted potentials of agile product development“). Agile learning means iterative improvement of products based on rapid user feedback. Such a heuristic method is time consuming and not really predictable. Organizations driven by growth usually do not have the required time for this. Whenever a MMP has barely hit the market, the next project is already waiting for implementation. So, even when customer feedback is gathered, there is no time to react on it. Over time a product portfolio of incomplete initiatives sums up. But at the same time customers and stakeholders need to wait for promised products longer and longer. Companies get lost in self-made mediocrity and ever increasing entropy. The self-enforced growth imperative will turn into a growth-trap.
Stepping into the growth-trap is easy. Getting out of it or – even better – not falling for it right from the start, is hard and requires counter measures.
Most importantly: Agile product management only works with a clear focus. Especially in the online-world options are (seemingly) endless. However, no individual can draw up and prioritize a list of all ideas and options of a company based on objective criteria. In addition, costs for new products are only low at first sight. Such a view does not calculate with a full economic model including opportunity costs and costs of delay. As Don Reinertsen says “Counting peas is great, but you need to make sure to count all the peas!”. So, a strategy needs to be in place to narrow down the solution space before ideas are generated in order to keep the product portfolio manageable. This always implies a radical and often painful selection of just a very few topics that are really important. Such a focus needs to set a wide and at the same time close enough strategic framework. Question like “Where should our company aim at and why?”, “What is now the most important thing and why?”, “Who are our customers?” and „Which services and products do we offer?“ can’t be left unanswered at any time (see also überproduct’s blog post “The way out of the enterprise jungle”).
One instrument that complements this strategic focus is the definition of bandwidths per strategic bucket. Similar to a WIP-Limit this enables a rough and iterative planning of the overall capacity spending per topic. Important: All things with a significant capacity demand need to be on the table. This includes a segment for fixing bugs for example. Only this will enable a realistic view on bandwidths that is required for a true portfolio discussion. And then, still, it is hard to keep up the discipline across the company to say ‘No’ to many seemingly great opportunities that may not be in the absolute core of the focus.
Fighting self-made time crunches also means keeping MVPs and MMPs really “minimal”. Often they are way too big so that all patience with a project is used up already when learning is just about to start. Those who are not capable of learning right from the start will have an even tougher time to implement any insight later on. A heuristic: Every minimum can be 10 times smaller than initially thought.
How much time for learning is really required per product is hard to answer. A crucial point is reached when the area of diminishing learning returns is hit or the company decides that a sufficient information level has been reached. Helpful in defining either threshold is a learning-diary where all closed and still open hypotheses are summarized to document the real state of a product. But also the life-cycle model, which is often criticized as being over simplistic, can provide a valuable framework for taking such difficult arbitrary decisions.
Photo by Rev Stan on flickr under CC License