Product portfolio

…a complex multi-product endeavor.

✣  ✣  ✣

Overview and clear strategic goals aligns forces and eases planning on all levels.

A product portfolio and its corresponding management:

1. maximizes value creation, thereby increasing ROI (reducing cost, increasing effectiveness and efficiency, creating more value);
2. aligns company strategy;
3. reduces the overall risk level and concurrent, often competing, activities by bringing focus.

Therefore:

Maintain a product portfolio.

✣  ✣  ✣

✣  ✣  ✣

In general, a comprehensive product portfolio boosts your unfair sustainable competitive advantage.

In more detail, a product portfolio:

• has been shown both in theory and practice that it helps scaling agile development;
• shortens time to market due to less thrashing;
• focuses and aligns all forces;
• makes prioritization clear;
• moves the organization from a handover mindset to a “let's optimize the flow of value creation” mindset;
• structures the way of starting initiatives and new product development;
• shows a clear, broad, and visible overview of all ongoing activities, currently and in the foreseeable future;
• eliminates the struggle to complete projects within schedule;
• avoids the competition over resources (budget, people);
• causes smaller projects to be managed as part of the portfolio;
• homogenizes the type of projects included in the portfolio; more harmonization, less waste;
• increases or unveils the amount of product developers' time allocated to real product development;
• reduces the effort spent on resource allocation, and may even be eliminated when properly implemented;
• provides the right amount and level of progress data;
• helps the organization to make more informed overall decisions, considering the whole portfolio and synchronized with team decision making;
• avoids teams making up priorities due to the lack of a absolute prioritized list of requirements;
• guides and direct teams' activities to align with program level;
• aids proxy product owners in making the right decisions;
• properly synchronizes (software) system interfaces across teams and minimizes dependancies in code;
• helps coordinating the work of multiple scrum teams;
• manages cross-team risks and dependencies, especially when developing large (software) systems;
• enacts the company vision;
• handles the silos of knowledge and skills (if not already tackled by communities of practice);
• defines investment themes that drive resource allocation (also consider buy a feature and perpetual multi-voting);
• deals with “competing backlogs”;
• can be effectively carried out by merging the backlogs of different product offerings into a single backlog, and then perform backlog management on that single backlog (one backlog to rule them all);
• uses epic-scale initiatives to express the portfolio vision in practice to guide forthcoming product releases;
• delivers minimal marketable features in a steady flow;
• resolves the tension between short-term and long-term planning;
• leverages the earlier estimation and planning experiences of skilled program managers;
• prefers the cultivation of dedicated stable teams over resource sharing and strongly reduces costly task switching;
• encourages seasonal demonstration for a larger audience, including interested customers;
  • often received with great interest by customers;
  • allows customers to really see the changes and makes them feel they can truly have influence on the program outcome;
• improves the accuracy of the program outcome (i.e. how accurately it fits customer needs);
• makes people feel more productive and increases the subjective feeling of quality;
• addresses the costly and slow traditional process of requirements freeze and change management;

Forces:

• visual management provides clear understanding to all stakeholders;
• unclear and shifting priorities from sales and marketing lead to a handover mentality and the congestion of the product development pipeline and disconnects business from development; (use a value stream map to make this disfunction painfully visible);
• congestion of the development pipeline results in a long time-to-market or time-to-value;
• monolithic architectures slow everything down and foster component teams; component teams are known for their disfunction (see persona team and persona obeya for their resolution);
• the effort for giving visibility to the work and helping in planning is small compared to the situation of not having a product portfolio;
• forecasts get more uncertain as complexity grows due to:
  • number of teams;
  • new technology;
  • architectural complexity;
  • technical debt;

You might call it the “product portfolio backlog” (mvs—there must be a better name for it).

• It's all fractal, so there are multiple levels of scale—theme, suite, product, epic, story, task.
  • So, there is a nested set of control loops, e.g. a portfolio loop, and a scrum loop. Since it can be multi-level, you may consider numbering the levels, the top level being number 1. The innermost loop is that of a single day, with the daily scrum as keystone event. Depending on the size of your product suite and organization, the innermost loop may be at level 3, 4, or 5. More than 5 levels are probably better suited for a split into a separate business unit, incorporated.
• Synchronize iterations for the whole the organization by using a season beat—use the season beat for your release train.
• Create a product roadmap as the public version of the product portfolio.
• Adopt an agile process for the whole organization.
• Prioritize the contents of every release (upgrades, new features) according to business value.
• Train sales and marketing in agile purpose, values, principles, planning and prioritizing.
• Adopt visual management and information radiators across the organization.
• Establish a clear babushka of value (a.k.a. admission criteria or column policy) at every membrane of the value stream map to ensure the ‘maturity’ of new “projects” entering the value stream.
• Only honor clearly visible and radical transparent initiatives that meet a minimum maturity level. If you do not make it transparent, people will understand it differently, reducing communication richness.
• Force everyone to deeply understand the forces at either side of a membrane in the value stream map.
• Reward initiatives that make membranes almost invisible or even disappear.
• Penalize any handover. Replace handovers by having any documentation be the meeting minutes of an collaborative conversation about discovery.
• Foster facilitation and brainstorming techniques and cultivate those who show talent for this—the art of hosting.
• Put work in progress limits on each cell of a value stream map. Limit the number of active initiatives to match capacity of the organization at large.
• Use a crack pull flow approach across the board.
• Structure a clearly defined and accepted, company-wide prioritization process based on work types—e.g. core activities, expand business, reduce risk—and make it radically transparent, even to your customers and users.
• Eliminate, even penalize rogue “business critical projects” and “pet projects” induced “under the hood” by some managers.
• Only include multiple similar projects to research alternatives, and only if you can afford it. Ask yourself “What are you prepared to throw away?“, and “What does that mean?”.
• Structure and formalize the resolution of problems that are dependent on resources outside the own department, preferably by cultivating relevant communities of practice, one for product owners might kick this off.
• Clarify any business needs, value, risks, dependancies, stakeholders and increase their visibility on a hoshin kanri.
• Track progress with a cumulative release flow diagram as an aggregation of multiple cumulative sprint flow diagrams.
• Establish a wisdom council that acts as e steering committee to make wise and timely decisions when new opportunity spaces open up or when the going gets tough.
• Base product proposals on templates that also function as checklists for presenting the value and planning the work.
• Put a face, name and number on any proposal or problem—visibility and motivation educe responsibility.
• Track and review the product portfolio every three to four weeks on an operational and tactical level and every season on a tactical and strategic level. Adjust it according to reality and better steer what is happening in teams by continuous planning (seems like everything is
• Perform triage on initiative competing for scarce capacity (time, budget, people, machinery).
• Replace the practice of resource management by cultivating stable teams and feed them with the right mix of work items that reflect current priorities. Eliminate the need of resource management completely. Resource management is obsolete, a waste of time. This requires that your stable teams are multi-disciplinary both inter-team and intra-team! Ultimately team members can take over from each other, as can teams. So you teams will eat almost anything that you feed them. This will make your organization as a whole more agile, resilient, and sustainable.
• Reward anyone that blocks a request that is not connected to the shallow hierarchy of business goals that in turn drive the shallow hierarchy of product goals. Escalate when needed.
• Review the shallow hierarchy of business goals and shallow hierarchy of product goals every season.
• Cultivate a sharp, focused, nimble and highly productive stable teams of six plus or minus one that thrive on work flows inward.
• Develop a training package for management and leadership—both top and middle management—to help them better understand the value, impact and outcome of adopting agile portfolio management.
• Set up, institutionalize and uphold an agile policy, stewarded by the agile steering council.

Sources

• SlideShare » Thomas Jeffrey Anderson, Alexis Hui, Taimur Mohammad » Enterprise Portfolio Kanban
• HBR » Brad Power » How the Software Industry Redefines Product Management

---