As a company starts to introduce variants of a product, moves into adjacent segments, acquires companies and their resulting products, a few cycles later it becomes very difficult to make even the most basic of decisions about the products that the company is producing. Is the product earning its shelf space? Is the product consuming engineering resources in excess of the product’s contributions to the company’s revenues? Should the product be retired and what would happen to the customers of that product?
No, software does not create portfolio discipline, although the right combination of software tools can make visible in good time the trade-offs between different actions with respect to a portfolio of products, and enable one to take decisions on the basis of that. But the wrong combination of software can make invisible in a great variety of different spreadsheets, which in turn only one person can understand, the very same information with respect to a portfolio of products that with the right software one can bring up in good time and decide on the basis of.
Fix the data model before choosing a platform
Most portfolio tool implementations fail on definitions rather than features. The definitions required to generate meaningful reports for a portfolio of products need to be embedded in the data model of the tooling, not in the front end reports that can change from release to release. To generate meaningful reports about a portfolio of products, you need to have a stable set of definitions about what each product is and what work has been done on each product.
The minimum viable hierarchy
Create a single product hierarchy with a stable identifier for each level. Map all downstream systems (e.g. Finance, engineering, sales) to this single hierarchy. For a portfolio of products three levels are usually sufficient to make the necessary portfolio decisions, Platform / Family, Product, Variants (e.g. Different configurations). Below this level complexity is typically handled in engineering systems and not in strategic reporting.
In addition to the 4 attributes (Complexity, Uncertainty, Incompatibility, Irreversibility) that make up the portfolio conversation, each product record should contain the 4 levels of definition (Platform / Family, Product, Variant) and the 4 stages of life cycle (New, Mature, Harvested, Abandoned) that the product is going through.
The tool categories that do distinct jobs
A portfolio tool can also fall into more than one of the above categories. Therefore, in the first place, a category must be chosen for the portfolio and then a tool must be searched for that can fulfill the needs for this category.
| Category | Primary job | Best fit when | Common failure mode |
| Product lifecycle management (PLM) | Engineering data, bills of material, change control, compliance records | Physical or regulated products with heavy variant complexity | Treated as a reporting layer it was never built to be |
| Portfolio and roadmap planning | Scenario comparison, capacity modeling, investment allocation across products | Multiple product lines competing for shared engineering capacity | Adopted as a roadmap presentation tool with no capacity data behind it |
| Product information management (PIM) | Commercial attributes, channel content, pricing structures | Wide catalogs sold through several channels | Confused with PLM, producing two competing sources of truth |
| Analytics and profitability modeling | Margin by product, cost allocation, cannibalization analysis | Margin varies widely and shared costs are material | Allocation assumptions never agreed with finance, so results are contested |
Where the categories overlap
PLM software contains the roadmap for current products in development. Market planning software contains the roadmap for current market products. Thus both categories of software can be used as input for the portfolio decision layer. For the question of whether a product is worth continuing to invest in relative to the alternatives, lean on dedicated product portfolio planning software. Thus, keep engineering truth in one system and investment logic in the other. Schedule a sync on a regular basis instead of manual re-entry.
Prioritization mechanics that survive review
A simple weighted scoring model can be set up very quickly to deliver any defensible ordered list of up to 20 initiatives. However, such an ordered list can vary greatly by a 10% change in a single weight. Therefore, scores should be input to a discussion rather than used to make decisions.
Constraints make better portfolio tools. By representing the fixed capacity in the scarcest resource(s) such as specialized engineering skills or approval pathways, such tools enable a ranking to be reverse tested against the constraint. This ensures that only the projects that fit within the available resources actually make the cut.
What to require from a scenario feature
- Model at least three funding scenarios side by side, with capacity consumption shown per scenario
- Show which committed work is displaced when a new item is added, not just what is added
- Retain the reasoning attached to each accepted and rejected item, so decisions can be revisited rather than relitigated
- Support partial funding, since most real decisions involve slowing something rather than stopping it
Making retirement a managed process
Ending life of products needs the same workflow and defined gates as launching new products. Same owners for end-of-life as for launch.
Triggers worth automating
- Revenue below a stated threshold for a set number of consecutive periods
- Support or warranty cost exceeding gross margin
- A successor product reaching a defined share of the shared customer base
- A dependency reaching its own end of support, for example a component or platform version
Decisions on portfolio products have to be taken by the review body whether or not an automated trigger has put a product under consideration.
Sequencing adoption
Start with setting up the hierarchy and attributes needed for your portfolio. Manually test out the analysis on a single product family. Finally, acquire the platform that removes the necessary manual efforts for you. Most teams get this in reverse order and thus spend the first year or so of using a portfolio tool to configure the software to represent the as yet undefined portfolio using the very same definitions that are in dispute.
