Here’s a simple yet crucial insight about NPD Portfolio Management. And it points to a big problem every company must address.
Portfolio Management that oversees only projects in development reinforces a common misstep.
For many companies, portfolio management begins and ends with projects underway within their development practices. What happens before and after isn’t important. Their concern is getting the most from projects under development. If you need evidence, look at a few conference presentations or search the web to check it out for yourself. It’s a truth that’s hiding in plain sight.
Those new to product development might assume Portfolio Management is only about development projects following Agile, waterfall or a hybrid approach. But don’t let this fool you. Good NPD & R&D demands more. Shifting resources across projects under development is important, but it’s not enough.
What Matters Most
Here’s the portfolio management problem. It turns out the greatest influence on a portfolio’s value is the output of the Front-end. It’s the work and thinking before development that matters most. What happens in development is important. But the Front-end output is far more important. If you want to increase NPD and R&D productivity, you must consider the Front-end and its impact.
The following example helps explain the relationship between Front-end practices and Portfolio Management. Figure 1 below displays a four-project portfolio. Each project is at a different point in the development process (X-axis.) And each will launch at different times (Y-axis.) The bubble size represents the peak annual revenue the project should produce if it’s successful. The text next to the bubble tells the name of the project. Next to the name is each project’s likelihood of success.
The bar chart in Figure 2 displays the risk-adjusted peak annual revenue for the projects. This is like saying “we expect the sum of the projects that launch that year will have X million in peak revenue.”
The bar chart shows only one project will launch in the year 2019. Its risk-adjusted peak annual revenue is about $5 million. In 2020, three of the four products will have launched, and the summation of their risk-adjusted peak annual revenue is about $25 million. All four will have launched in 2021 with and expected peak annual launch value of about $32 million.
But the sloped line above the bars suggests the NPD financial goal is for more revenue than the portfolio will produce. There’s a gap between the launch value and the objective.
Filling the Gap
The gap presents a problem that’s common to NPD Portfolio Management. When you start new projects, you must assign resources to them. And starting new projects without ending older projects forces resources to spread thinner. The result is slower project speeds with lower success likelihoods.
If you slow down projects, bars in chart 2 will shift to the right. Decreasing success likelihood will lower the bars. In both cases the gap increases between the delivered value and the financial objective.
In response, management may shift resources to the two near-term projects. This resource shift moves the bars to the left, but it also widens the gap in future years. The move would trade off long-term results to meet short-term goals.
The difficulty for the fictional company is the nature of projects in their development portfolio. They don’t create enough revenue. The projects don’t target opportunities that are large enough. Management can shift resources across development projects as much as they like, but they’ll never meet the goal.
The solution calls for leadership to break the pattern. It’s shifting resources toward getting better projects out of the Front-end. The company’s management can’t fill the gap with the current projects. They must find other bigger or better projects. The key lesson is that without a productive Front-end, it’s unlikely this company will achieve its NPD objective.
Most organizations don’t have a proactive Front-end. Instead, potential projects come from the same sources as they have for many years: one-off projects from R&D, customers, marketing, the sales force, and even top management.
A problem arises when a Front-end keeps delivering the same project types. You may even be numb to this happening. You’ll notice it when projects have common characteristics. Sure, product ideas might be different. But you’ll see a similar opportunity size, a similar degree of newness, and similar competitive alternatives.
The problem is that portfolio management can’t do anything about the similarity. You can turn development projects on and off. Or you can shift the resources assigned to each. But portfolio management doesn’t create new projects.
But a default Front-end is seldom enough to drive a good NPD portfolio. From the vantage point of the bubble diagram above, you need a Front-end that delivers bigger, better bubbles. Good Portfolio Management will help development projects. But you must improve your Front-end investments if you want more. This is a proactive and deliberate choice that managers must make.
But here’s the kicker. Most proactive Front-end approaches don’t recognize the trade-off decisions needed in good portfolio management. They march to a different drummer. It’s one that sets a rhythm for the boldness of ideas and independent discovery. Funding, people count, and a strategy don’t matter as much to traditional Front-end management.
Front-end Freedom, Back-end Tilting
Front-end independence is empowering. But when a company deliberately shifts resources to the Front-end, you’ll see those resources come from development projects. And if the independence leads to projects that don’t match the portfolio, critical challenges will result. So, what’s the recourse to those challenges? It’s to move resources to tackle the challenges when the projects try to move through development.
Can you see the problem? First, shifting resources to a deliberately proactive front-end to create better development projects. Then shifting resources back into development to overcome problems stemming from Front-end independence. But shifting resources back to development projects undercuts the Front-end. This causes future problems in development. It’s what’s known as the tilting effect. And while a leading systems thinker at MIT pointed this out years ago[i], the solution has been elusive.
The original advice to overcome the tilting effect was to break the system. It’s to stop projects and move resources end masse to the Front-end. The approach, though, is excessively expensive and risky; especially if your Front-end operates independently.
But we’ve learned there is a better solution. It’s to direct the Front-end. It’s to target innovations to where you want them to lead. It’s to be purposeful, not independent and random. This demands creativity and strategic thinking. But this thinking is at the product line level with the goal of making powerful product moves. It’s not about pushing harder on one-off concept development.
Uniting the Approach
The work and thinking before development greatly impact the portfolio. And the work and thinking before the Front-end impact concept quality. That’s why a product line’s strategy and its roadmap are so important. It creates targets to drive productive Front-end work. It’s also the key to overcoming the tilting effect.
Figure 3 shows a better approach. It shows business strategy tied to product line strategy. The product line strategy then drives concept generation.
If you want a Front-end to create better development projects, your strategy practices must create superb innovation targets. And it’s each target’s impact on a strategy that’s most important. Conversely, keeping a Front end independent of a strategy will cause issues. You’ll see resource tilting undercut the Front-end. It’s a symptom of firefighting, not productive product development.
The challenge is two-fold. It’s to create the strategy and to carry it out. And carrying out the strategy falls to smart roadmapping. Such roadmap practices include front-end work, development projects, and in market management.
Product Line Strategy and Roadmap
Carrying out a strategy calls for sharp oversight and quick work adjustments. And when done well, the approach changes portfolio management’s goal. The old approach to maximize project throughput changes to one that seeks to carry out the roadmap successfully. It’s the strategy success that matters. And it’s the roadmap’s job to ensure the product line delivers maximum value.
Portfolio Management, to be effective, must include projects within the Front-end. And a Front-end must deliver a stream of superb opportunities. But to do this, you must resource your Front-end fully. Plus, you need to tie Front-end work to the strategy and its roadmap. This then connects it to portfolio management.
Portfolio Management and the Front-end must work in tandem. But for many it’s not clear how best to marry the two. Front-end projects differ from development projects. Time frames, task certainty, investment amounts are different. And this leads some managers to throw aside tying front end work with development projects.
Product line roadmaps enable these disparate worlds to unite. The key is to see the “investment objects” within the Front-end, and to place these strategy-driven investments on the roadmap. These are targets for innovations, not fully formed ideas. And such targets represent strategy moves to drive existing product lines or create new lines.
And that’s the key. It’s strategizing and roadmapping a product line that enables the front-end and portfolio management to unite. If you seek major NPD and R&D gains, you need a good product line strategy and a sharp roadmap. It works to overcome the Tilting Effect quagmire.
Want to learn more about how to tie Portfolio Management to a productive, strategy-driven Front-end? Please contact me. The gains are significant.
[i] "Understanding Firefighting in New Product Development." Repenning, Nelson P. Journal of Product Innovation Management Vol. 18, No. 5 (2001): 285-300.
Whitepaper– Good Product Line Strategy Matters.