August 2015

Product, Project, Technology, and IP Portfolios

In the 1990s, life was simple. Marketing, or Product Management, maintained the “product portfolio.” In the largest companies, there was perhaps also a technology portfolio. The “R” part of the R&D organization would work with marketing to plan future products based on the projected availability of technologies still in development.  Today, having both a technology and a product portfolio is considered the rock-bottom minimum regardless of company size. Just about all companies actively maintain these soft assets—only the degree of formality differs.

Over the past decade, these portfolios became more closely tied together with the advent and acceptance of roadmapping (which charts the path new technologies and products take as they evolve into commercial readiness). In between each and every portfolio snapshot in time, the roadmap provides guidance on the activities needed to reach the portfolio’s next incarnation.

It would be great if we could just call it a day with two portfolios and the roadmaps that tie them together. But that is no longer best practice. We now also need a project portfolio and an intellectual property (IP) portfolio to be a best-practices company.


Project Portfolio: The need for project portfolios has been partially driven by the tremendous growth in project managers and project management organizations. These now-large organizations need to prioritize and sequence their inventories. There are other equally important reasons.

IP Portfolio: The need for IP portfolios has been partially driven by the increasing ease of monetizing intellectual property as a commodity , in replacement of or in addition to including the IP in products for commercial sale.  There are other equally important reasons.

Product, Project, Technology, and IP Portfolios [Machine Design – August 2015] discusses the two newest portfolios, and some of their key attributes, that are necessary these days to be a best-practices company.

Measuring Project & Product Success

There are two fundamental categories of post-launch reviews.  The first we shall call “Team Self-Assessment Project Reviews.”  These reviews are primarily for product developers to explore their lessons learned from working together on a project that has just completed.  The second we shall call “Management Business Reviews of New Products.”  These reviews are primarily for management to explore the financial and marketplace results of the new product in both a relative and absolute sense, and to contrast the results to those that were promised when the project was approved.

Ideally, there is minimal overlap in the content of the two review categories. However, and this is especially true where the team that created the product stays together to enhance and service the product during its life cycle, much of what should be covered in structured Management reviews is often done in Team reviews.

Consider that management makes the business decisions. They could invest scarce R&D funds in many places. They choose to invest in certain projects because of the business plan that was presented to them, or sometimes just plain old gut feel.  If management does not involve themselves in a comparative analysis of promised vs. actual results, they diminish their capability to “see” similar or analogous estimating shortfalls in future business plans and decisions.  The learning loop does not get closed for management.

Manufacturing and operations professionals, in just about every company these days, have achieved closed-loop decision-making. The opportunity is still on the table for most engineering and product development operations and organizations to do this better.

In R&D, outcomes for the project are not always the same as the outcome for the product.  One could execute a great project, but the marketplace does not get excited about the resultant product(s).   Alternatively, one could execute a highly inefficient and prolonged project, but the resultant product(s) turns out to be a home run.  The important thing is to know about both the project and the product results, to position the organization to become ever better in the future.


As well, outcomes are not always clear.  Some times they are neither a success nor a failure, but are somewhere in between.

Reviewing Project & Product Success, published by Product Design & Development Magazine, discusses the importance of project, product, and portfolio reviews; and the importance of comparing results to the original estimates and promises that lead to the decisions to move forward.