Business transformation, meet product portfolio management..

Business transformation is a much bandied term these days and in practice is often used to cover business change activities. This article is to make some comparisons between the goals & activities of transformation against those of a product portfolio planning and management process.

First, a reasonable definition of product portfolio management (PPM):

The process by which business strategy is converted into a product roadmap which delivers corporate goals and optimally utilises the business’ product making and marketing abilities in relation to the market opportunity.

Next, a couple of definitions for business transformation (BT):

Business transformation is about making fundamental changes in how business is conducted in order to help cope with a shift in market environment.
Business Transformation is a change management strategy which has the aim to align People, Process and Technology initiatives of a company more closely with its business strategy and vision.

In summary then, business transformation is an external market and business strategy driven process with the goal of creating change in the organisation to enable it to execute the business strategy and align it to compete in the new market reality. This is now sounding rather like the definition for product portfolio management…

So, are there any real differences between business transformation & PPM?

Transformation scope covers situations where major cultural change is required
PPM builds upon reasonably well working functional processes. Functional competence needs to be in good enough order for PPM e.g. functional capacity planning
PPM has built-in “closed loop” feedback to adapt and sustain in the face of continued change as opposed to transformation which is about initiating & driving a big change
PPM generates risk/return options for business decision e.g. between long and short term gain and taking technology risk or market risk or a balance of both.

PPM vs. business transformation

If we were to try and make an analogy of personal health to these two approaches then business transformation “treatment” might be required in the most extreme situations to shock the patient to help them survive and then guide them toward a more healthy way of living. By contrast, PPM might be seen as a combined exercise and dietary approach which avoids the risk of extreme intervention and helps the person achieve their best health and fitness.

Personal reflection

In my own experience of working for a large corporate (Nokia) over many years, I have seen both transformations in action and then also contributed toward the formalisation of product portfolio management. My perception would be:

The transformations galvanised the organisation into “change mode” and caused for example the creation of new business units with unique missions
Whilst the initial phases of the transformation mostly bore fruit in line with their mission, often the nature of the transformation challenge could make the timing of the first fruit quite unpredictable
Real value was only generated further through the transformation. This might be partly attributed to the benefits of the learning curve but the main value transition was co-incident with product portfolio management practices becoming bedded in
The big value add of PPM was in its ability to hedge both technology risk through different delivery paths to market and market risk through an offering of mainstream and niche/discovery products.

I am interested to hear other views from others on PPM vs. business transformation, but for today, I am an advocate for benefits of PPM and indeed our company offers the Portgenie PPM framework to those interested in learning more.

References

[1] https://en.wikipedia.org/wiki/Business_transformation

[2] https://rapidbi.com/what-is-business-transformation-3/

[3]”Leading Change, Why Transformations Efforts Fail”, John P. Kotter, Harvard business Review.

When two worlds collide: Integrated Business Planning & Product Portfolio management.

As a long term practitioner of Product Portfolio Management (PPM), I was really interested to analyse the principles of Integrated Business Planning and compare it to the practises which I was familiar with. In the first place I must declare that in my career rather than labelling practices and processes, the modus operandi was to extend existing ways of working to become more holistic and drive higher overall business value. When looking at Integrated Business Planning, or IBP, I quickly recognised business processes which I had been operating for in excess of a decade.

The same problem from two different ends

The origins of Product Portfolio Planning lie in the desire to transform company strategy into an executable roadmap to deliver the corporate goals. In simple terms, it is about understanding the market opportunity and making decisions which maximally utilise the company’s ability to develop and market products. On the other hand, IBP was born from the world of Sales and Operations Planning (S&OP) which originated with the goal of balancing product sales and product manufacturing delivering the mantra of ‘one set of numbers’ – in other words, delivering operational excellence.

The collision between these two process philosophies is therefore natural once each has developed excellence in its original field of application: product sales performance is key intelligence for Portfolio Management whilst driving change in the selection of products is a key extension for S&OP.

The term, “Integrated Business Planning”, was originally coined by the consultants Oliver Wright who have a foundation in advising on S&OP. The aim of IBP is the integration of more company functions than S&OP, of particular relevance finance and product development, into a single regular planning cycle. The result being very similar to the regular cycles advocated in the portfolio management context.

A personal reflection

At Nokia in 2007 we implemented an organisational change which was characterised as an ‘integrated company’, the aim of which was to bring sales and operations into the same planning and decision making processes as product development. In reality this change had already started to happen ten years previously as operational excellence had developed as well as more structured product line management. Working in an integrated way had already become a way of life with functional decision taking a supporting role to the over-arching process driven, cross functional structures.

So overall it does not matter if the change to integrate a company into a common decision-making, shared-goal oriented organisation comes from S&OP or the Product Portfolio management end. Fundamentally, it makes sense for a company to operate as a single team which was our goal at All about the Product when we created our “Portgenie” Product Portfolio Management process framework.

In the end, so what?

You might accuse me of some bias, but my strongly held opinion is that there is no greater opportunity for medium and large scale businesses, than to look at how to jointly maximise product making and marketing capabilities in relation to market opportunities. Thus, I am really interested to hear the experiences of others in utilising IBP or PPM based approaches to deliver this benefit.

When does Product Portfolio Management become relevant for a growing company?

In the start-up phase a new business typically searches for the one product which can initiate some business momentum. Allied to this, following lean start-up methodologies, the product is often limited to a ‘minimum viable product’ and little attention is paid to further products or the evolution of that product into something more complete.
As the business moves into a phase of growth, the initial product becomes more complete and further products may be added to the firm’s line-up – typically products are managed in the same way as in the start-up phase. It is in this period that some Product Portfolio Management discipline can become crucial to maximising the prospects of the business.
However the traditional form of Product Portfolio Management is seen as a process for big companies with lots of activities to keep relatively remote senior management in control. So the question is how can a business benefit from Product Portfolio Management without incurring the overhead of doing so?
In a sense the question returns to one which is very familiar to a start-up: what is the minimum viable method of Product Portfolio Management?

Critical Aspects

Essentially Portfolio Management is about optimising the overall solution rather than focussing totally on the atomic constituents. What this means that any minimum portfolio management method must:
• Consider the business opportunity as a whole and so develop holistic objectives/prioritisation.
• Identify conflicts on resources between products/projects and arbitrate on them.
If these two aspects are addressed then portfolio management is already up and running!
As the business develops and grows further aspects of Portfolio Management can be added such as linkage to formal strategy, defined communications policies, standardised reporting and planned reviews.

A roadmap for Product Portfolio Management

It is recommended that any growing company should implement the minimum viable Product Portfolio Management Solution, anything less does not represent a step forward compared to managing products individually. An example template of this is Portgenie-MVP from All about the Product Ltd.
The first step of Portfolio Management(MVP) is enough to manage the portfolio operationally with consolidated plans and roadmaps without a dedicated Portfolio office, without a significant documentation, reporting burden or process load.
Elements of Product Portfolio Management can be added to the MVP state as needed by the particular business; if the company is operating over several sites then communications may be next key element to add or if strategy is changing then a formal strategic link could be added.
In essence this way of considering Product Portfolio Management makes it modular built onto a minimum core.

Minimum Core

Statement of business priorities
Roadmap of product plan
Resourcing plan of the roadmap
Decision making and conflict resolution

Modular add-ons

Internal/external communications policies
Regularised reporting rules and formats
Portfolio planning projects on a annual/six month cycle
Formal steering and followup processes
Linkage to strategic planning processes
Defined linkage to go to market projects.

Why we created PORTGENIE

Successfully managing a Portfolio of Products is much more difficult than it seems from afar. Complexity builds as a Portfolio develops from a single product, driven by increasing levels of dependency between potential product options and the reality that neither markets nor technologies stand still. Learning to master these complexities is therefore a steep and long learning curve.
From our experience leading Product Portfolio activities we know of this learning curve only too well. We also realised there was very little support out there to help master the art of Product Portfolio Management. While there are number of frameworks out there to assist with Project Portfolio Management, the case where Strategy, Marketing, Sales and Operations need to be embedded in the process is missing. We therefore decided to distill our decades of experience managing global product portfolios into a product which we call PORTGENIE.

We developed PORTGENIE with several key aims which we had learned the hard way:

A Product Portfolio should be designed to deliver company strategy and not simply evolve.
Sufficient Portfolio space should be created to allow innovation to thrive.
A Product Portfolio needs to track change in the market, competition, technology and progress in its own product development – we have learned that two ‘gears’ are needed to do this tracking.
Ultimately good decisions are the lifeblood of good portfolio management. Good decisions require holistic clarity of the current state and likely future trends as well as good timing.
Organisational commitment is built on common ways of working across functions with clear aims.

At its core PORTGENIE enables a company to get better leverage of its business domain specific knowledge and experience without having to expend effort in learning some hard lessons in the art of Product Portfolio Management.

Why Implement Product Portfolio Management?

The reality is that any business which has more than a single product implements some form of Product Portfolio management, but that implementation may not be formalised or even recognised as such. Product Portfolio Management is after all fundamentally about choosing which products to make, how to market/price them and when to stop selling them. So if a business can survive without formal Product Portfolio Management, why should anyone bother implementing it? To search for any answer to this question, it is first important to understand some of the factors which can make a product business successful such as:

It brings superior products to market.
It maximises business potential with a well-structured product range.
It can react to changes in the market faster than competition.
It can nurture and most importantly bring to market new innovations.

At the root of success of course are managers in the business who understand the market they are in, can anticipate its requirements and carry the organisation in the same direction with full force. In a business without a formalised portfolio management process, these key managers may struggle to get heard; struggle to create focus for the organisation and ultimately become very frustrated. Senior management may also become frustrated for slightly different reasons; their struggle is to get clear visibility of what the current state is in product development and then to have decisive levers to direct the business in the correct direction. Therefore in essence Product Portfolio Management is a framework which enables a business to get the best out of the management resources it has. So what are the key features of a Product Portfolio Management framework which can deliver these benefits?:

Provision of clear decision and review points which consider the totality of the product undertaking.
Direct linkage to company strategy which has been endorsed by the most senior management.
Bonding between the various stakeholder functions which means they all operate together in lock step.
Visibility into the current state in development and sales in a structured way.
By creating balance in the portfolio enabling innovation to bubble to the top as well as making incremental products.

These benefits seem pretty compelling but it remains that Product Portfolio Management is really a means to get the best out of the people who run the organisation. At the end of the day good decisions are needed and while the framework can potentially maximise the probability of making a good decision it does not substitute good market instincts or leadership qualities. So are there great costs implementing a Product Portfolio Management Framework? The fundamental answer is that the biggest part of the cost is the change needed to bring the organisation to a common way of working. A well designed Product Portfolio Management Framework will be customisable to a given organisational scenario to focus change only on those areas which need addressing. Once implemented the clarity and clear target setting it delivers will mean that the overall organisation can operate at a greater level of effectiveness. If the benefits are so clear then why doesn’t every business implement Product Portfolio Management in a formalised way? Well this is another story and the subject of my next blog post.

Missing the opportunity

Missing the opportunity: The under discovered benefits of Product Portfolio Management.

Product Portfolio Management is a discipline which can deliver great value for a business and ensure the firm gets the best return from its resources and opportunities. However, despite this clear benefit, many businesses either do not even have Product Portfolio Management as a recognisable process or have adopted an ad-hoc methodology.

At the root of this status quo are two factors:

Businesses can ‘survive’ without Product Portfolio Management.
Product Portfolio Management is very difficult to do well.

This paper explores these two factors.

Why it’s often not even implemented

It’s often overlooked

Product Portfolio Management is a task which is so deeply integrated into the overall operations of a business that it often is overlooked as a separate competence which needs to be developed and improved in order to make the overall business perform better. In many cases the decisions and choices which should be curated by a Product Portfolio Management function are instead driven by a dominant function (such as Development or Marketing) or alternatively handled without any joined-up ownership on a decision by decision basis.

Its benefits are seen more in the long and medium terms

The choices and decisions driven by portfolio management tend to derive value over some substantial period of time driven by the product development time to market. Therefore in a busy firm, there are always more pressing priorities – be it a product launch or sales firefighting – than to implement a well-structured process for managing the Product Portfolio.

It requires effort to implement well in an organisation

Product Portfolio Management is by its nature a cross functional undertaking requiring full buy-in from participating stakeholder functions. Therefore it is not in itself a new function but a very important process existing in the organisation. While the people tasked with running the process may be hosted by one function or another, it cannot be implemented by a single traditional business function alone.

A growing business does not realise the potential

A business starting out is usually small enough not experience any of the complexity which Product Portfolio Management sets out to clarify. However as business grows, products get added and the business opportunities become more sophisticated, there is a growing increase in complexity and potentially a loss of clear line of sight of on-going product operations. Rather like the metaphorical ‘boiling frog’, the business does not realise that adding structure and process would improve its business results.

‘We’re using Agile we don’t make long term plans’

The popularity of using Agile techniques for software development often creates questions whether any long term plans (such as a portfolio plan) can be made at all. However while Agile does address the issues of making sure a product is ‘about right’ before over-committing resources and not making unrealistic development predictions, there remains a need to allocate resources to different projects and set the overall aims of a product development if not the feature detail.

Why it’s hard to do well

It’s like trying to hit a moving target

Product Portfolio Management is not about meeting the present day requirements of customers and competing against today’s competition rather is it about anticipating future customer requirements and battling against tomorrow’s competition. The longer the new product development cycle the longer the delay between specifying a product and it reaching the market place.

Since predicting the future is not normally a gift bestowed on most human beings, a great deal of effort is required to understand the possible future scenarios and make choices according to that understanding. The aim of Product Portfolio Management is to improve the probability of hitting the target when it is time to market the product.

Developments do not always go as expected

Not only does Product Portfolio Management need to cope with changes in the outside world, there are those changes arising from problems and delays in product development. The result may be that a product is missing attributes associated with its expected success or come to market so late its specification is no longer relevant.

Significant plan changes often precipitate the need to make tough decisions such as a project cancellation or significant re-direction. These are decisions which typically face significant resistance within the organisation and are often unpopular.

It’s often difficult to get functions to commit and co-operate

As a fundamentally cross functional process, success and failure is often tied up with the attitude present in the key contributing functions. It’s a reasonably normal situation than rivalries exist between functions or that hidden agendas exist which may not be aligned with the good of the business as a whole.

A key to success is therefore the ability to inspire stakeholder functions to commit to the common good of the business in an integrated plan.

Getting the balance right in the portfolio

While many aspects of a portfolio are clearly measurable, balance is one aspect which is perhaps more art than science. The term balance can be applied to several aspects of a portfolio design including: the balance between new product development and existing product engineering, the time balance of the portfolio in terms of when products are expected to come to market or the balance across different segments or price points.

At the end of the day, balance is really an informed management judgement which needs to be facilitated by the right information and informed views of the market; it is never a ‘black and white’ decision.

Conclusion

While there are multiple reasons a business does not adopt well defined Product Portfolio Management techniques, in many cases those businesses are missing out on creating a much clearer and strategy linked way to run their businesses. There is no doubt that Product Portfolio Management is a difficult discipline to master but the potential results far out-weigh the effort to implement it.

Prioritising development initiatives..part1

Part way through my career, I was asked to work on a change activity. One of its goals was to bring together the business priorities for a suite of about 100 software development initiatives which supported the end offering of products and platforms.

This was a great learning exercise, so part 1 of the post covers “what did I learn?”

Answer the “so what”?

Don’t invest too much time without first gaining a clear understanding of the purpose and intended outcomes from the exercise. Stakeholder contribution to this type of exercise is highly important and although I found stakeholders generally supportive, their main concerns were “What is going to happen in 1 week, 1 month or 6 months’ time as a result of this work?”

Be pragmatic

Projects and program briefs come in all shapes and sizes. Even with best intentions, the result is likely to be imperfect due to misunderstandings and the level of information available. By being pragmatic and giving fast feedback, the value obtained will track the 80/20 rule. As an example, it is very important to get the top 10 project rankings correct, but another thing entirely to try and fine tune project priorities lying in the 50^th to 60^th rankings.

Note, I am not suggesting there should be no clarifying dialogue between parties along the way, just that the act of providing the feedback ‘fast’ is a good way to flush out any major misunderstandings.

Decisions require preparation

It is hard to get time from senior stakeholders and harder still to sync their diaries to meet at the same time. A direct discussion of priorities is a challenge without having first developed the proper context. So, the approach for establishing priorities is likely to be an important point for the senior stakeholders along with the consequences of any decision options.

Therefore it is worth establishing a small core team to build and test a prioritisation framework and drive the significant ground work prior to any proposal. More on this in a later post.

Present versus future

“If we don’t secure today’s business then there is no tomorrow”. People tend to attribute higher value to items appearing in the immediate future rather than those slightly further away. This is natural and also a consequence of the time value of money or NPV. However, it is a bad sign when all risk and change gets pushed forward (delayed) further into the future. A balance is necessary and the core team should take care of the present vs. future investment balance according to the industry change clock cycle.

Prioritising development initiatives..part2

This was a historical exercise, but how might I approach matters now? With the benefit of hindsight, I would consider the approach:

Establish a core team
Map the projects to aid understanding
Interpret the strategy to build a framework
Make trial rankings and test result
Prepare for the senior stakeholder review

1. Core team considerations

Fair representation of the business. Functional area owners want to be consulted on matters that impact on their responsibility areas. If you require strong endorsement of the results, you will need representatives of these different functional owners to take part. Enough representation to build a “wide enough” business view, but not so much as to bring the impression of a fully democratic exercise. The functional representation is there to bring insight into relevant areas of the business, not necessarily to pass judgement on the whole spectrum of activities.

Calibre of resources. The qualities of the resources could be summarized as: motivated, capable, respected, possessing a broad knowledge and impartiality. Do the best that you can in ‘borrowing’ resources.

2. Map and understand the projects

The objective here is to make more sense of the project portfolio prior to ranking. The value is in the discussion for the core team, building an understanding how the initiatives create value for the business, their timing, mutual relationships and how they impact across the business.

The precise approach taken will vary somewhat depending on the nature of the precise question being asked and the stakeholders involved e.g. involving the whole business vs. only the product related functions. Some thoughts on potential candidates to include in mapping:

Project Value

Project Investment

Market risk

Technology Risk

Current project timelines

Future projects pipeline

Independent projects

Projects with dependencies

Mutually exclusive project options

Project duration

Resources

involved

# Independent teams

involved

# New assets created

(or types of assets created)

Product type architecture e.g.

Market type architecture e.g.

Core plat-form

Messag-ing /CRM

Scale data support

Customised visualisations

Professional

Services

tools

Core product

platform

Customisation

enablers

EMEA

projects

APAC

projects

NAM Projects

A couple of project maps to show how visualisation can help understanding:

Value vs. Technology risk and Market risk map.

This is a good method to test the rationality and balance of the project approach against the market opportunity. It captures the business value of projects by the radius of the bubbles, so the most valuable projects stand out.

But it is sometimes hard to give every project a business value. An alternate view is to use project investment to scale the bubble radius.

Projects resource/investment vs. timeline map.

This is a good method for seeing the relative and cumulative project resource in use on deliveries now as well as the anticipated future commitments. It is a useful view for testing portfolio “options”, although with future project estimation a challenge, project categories or templates maybe necessary.

3. Interpret strategy to build a prioritisation framework

The business strategy should provide clear guidelines as to what is important to the business, both now and for a few years into the future. Thus for prioritisation of projects/initiatives, strategic alignment is a key criterion. However, strategy alignment can be captured through a variety of measures, so general guidelines for the prioritisation framework include:

Clear meaning for individual criteria	Readily understood by all of the core team
Independent criteria	Cover clearly separate issues
Criteria have different priorities	Some criteria clearly more important in prioritisation
Individual criterion has “values”	Enables ranking on 1 criterion (even if high/mid/low)
Enough elements as necessary	But as few as possible to avoid fatigue with large portfolio

It is especially important that core team members representing the business function stakeholders are fully understanding and supportive of the framework selected.

4. Issues in trial ranking of projects

Fatigue. Large portfolios take time to discuss and must be split over several sessions. Ideally this happens over consecutive days to maintain a consistent “mind set” for the work. Energy is needed to combat fatigue, so the project content should be ordered so that the most relevant (however judged) projects are dealt with first, creating high value and building confidence in the approach.

Maintaining Cadence. Within sessions, it can be useful to “time box” individual project discussions and place those projects that lack conclusion into an open category. If many projects keep getting put in the open category then this can be a sign of:

Low quality project descriptions
Too complex prioritisation framework
Too many people participating

The project lead can directly address the last two issues e.g. by opening up the framework or using a smaller size team to build the draft proposal & review with the wider core team.

Handling “open” category projects. The lead should judge if it is worth investing more time to clarify “open” projects/ priorities or to prepare to return such projects without overall priority but within some identifying category e.g.

Projects lacking in description/benefits
Projects lacking agreement on business priority

Rationality and balance of the result. The trial project rank result should appear to make sense logically. If there are some anomalies, then it is worth rechecking for consistency of prioritisation criteria. The other test which is less obvious is to look for balance using the earlier project mapping. If only the top 25% of projects are considered, what would the portfolio then look like when mapped? This approach picks up cases when there is not enough in effort anticipating future problems e.g. paying back technical debt.

5. Preparing for the senior stakeholder review

The ultimate approach taken for the review depends on the nature of the original question asked and therefore if any explicit decisions are required. The normal recommendations apply e.g. gaining feedback when possible from impacted functions, ensuring issues have solutions for mitigation and that the consequences for decisions are outlined.

It is important to be able to briefly show the “workings” how the team came to its proposal e.g.

This is the issue e.g. project portfolio load unsustainable
Here are the people / functions engaged in this activity to address the issue
Here is the prioritisation methodology used
And here are the conclusions & key decisions…

The visualisations built used for initially understanding the project portfolio are very valuable as a way of communicating the consequences of different options.