Sunday, December 30, 2012

Multi-Product Portfolio Planning


One question I hear often is "How does product planning change in a multi-product environment?". While all of the key tenets of Product Management and Product Marketing continue to apply to ensure that you are building the right individual products, and taking them to market effectively, there are fundamental differences.

When faced with multiple products, the first factor to consider is that they all fit within the corporate vision and strategy. If products don't fit into the established strategy, you need to ask some very hard questions - while these businesses bring in revenue, they may prevent achieving the established goals and vision by distraction, consuming resources, and confusing customers.

When considering a portfolio, I often like to ask everyone "Should we build Ferraris?" - and the answer is a universal "NO - building Ferraris does not fit into our established strategy".  But this question and answer establishs that there is a line of what the organization should and should not be building (and that there is a strategy) - and you can zero in closer to establish where the line actually exists.

Assuming all products fit into the established strategy, the next big task is to allocated resources (R&D, marketing, go-to-market) based on product/market potential, and not on current revenues. One of the most erroneous statements ever made by a Product Manager is "my product is profitable so I am untouchable". Companies need not just profitable products, but products with high growth potential.

All companies have limited resources to invest and too many fall into the trap of allocating based upon product revenue or relative profitability e.g, let's take a look at a XYZ Corps revenue for a diverse product portfolio.




The above chart would lead many companies to make similar resource allocations - as we know, P&L is the common management mechanism in large companies and headcount is allocated based upon the product revenue and forecast growth.  However, resource allocation should be based on overall market opportunity and product managers often fail to make difficult decisions to prioritize investments effectively across multiple products.

There are numerous tools to help make these prioritization decisions, but they all acknowledge that  there are many factors that need to be considered, such as annual growth, market share, competitive landscape, route to markets, core competency, product maturity, etc.  One of the commonly used tools is the BCG Matrix, applying a scatter graph to rank the products on the basis of their relative market shares and growth rates, with sales revenue shown by the size of the bubble e.g: XYZ Corp product portfolio yields the following results:




Using this analysis we can start to pose some very interesting questions?


  • Should be investing more in Product 3? We have a great market share and high growth potential.
  • Is Product 2 viable?  Can we do better here? 
  • How much investment should we make in Product 1? We already have a great market share with lots of revenue.
  • Should we exit Product 4?

The BCG uses four terms to describe each of the quadrants:

  1. Stars are products with high market share in rapidly growing markets.  These businesses are often going to need additional resources to capitalize on their early success and are not yet profitable.
  2. Cash Cows have high market share in slow growing markets.  Look very closely at investment levels here and only do what is needed to maintain the business.  Over-investment in Cash-Cows is a huge problem that Product Managers must address, but this can be a very difficult and emotional process.
  3. Dogs have low market share in slow growing markets, and often break even, but should likely be sold off. Again, this can be a difficult and emotional process.
  4. Question Marks typically have low market share in markets growing rapidly.  They have the potential to become stars and ultimately Cash Cows.

One of the points made with BCG planning is that any successful company has a combination of Stars, Cash Cows, and Question Marks - you probably have some Dogs too, and they should be sold off if possible.  But the point is that not every product can be a Star, and all products go through different quadrants as they mature through the product lifecycle i.e. they start out Question Marks, become Stars, and then end up Cash Cows.

How to calculate product market share in another interesting topic, and many companies use PPH or PPPH analysis, where:
  • P = Product Line Coverage - what % of  market does the product target?
  • P = Presence - what % of the time do we get to propose our product?
  • P = Preference - what is the % share of market within our own channel partners?
  • H = Hit Rate - how often do we win the sale (%)?

P x P x P x H = MS

Multiplying PxPxPxH gives us a "market share" factor that can be used to evaluate the effect of different market strategies on the market share.

The BCG Matrix is just a tool, and like any tool, has positive and negative points. You can use many different methods the point is that you consider all the relevant factors when making portfolio decisions, and move investments to maximize overall returns.

The final dimension here is that successful portfolio planning relies heavily on effective relationships across product groups and a healthy dose of pragmatism. Here is where the organization with the best relationships between products teams is going to win - and the organization with the most silo-ed approach will likely fail. Nobody likes their product to be called a cash cow or a question mark - everyone wants to be the star - but we need to be realistic and look beyond our own products and work together to do what is best for the complete portfolio and entire company.

Sunday, July 1, 2012

Post-PC - Companies that don't evolve will be gone over the next 10 years.


The term " Post-PC" is everywhere and nobody is doubting that we've entered the next phase of computing.  But do we really understand the effect that this is having on our industry today, and how it will shape the future?  I think not.

Post-PC is really an incorrect term - the PC (Intel/Microsoft) is not going anywhere and will continue to be a valid and viable choice for many industries and consumers (I'm writing this blog on a Windows 7 PC).  The real change is that the PC will no longer dominate - the future does not belong to any single device - rather it will be a heterogeneous mix of PCs, Macs, Tablets, Smartphones, Chromebooks, Android, iOS, Intel, AMD, and devices that have yet to be invented.

The velocity of device innovation is accelerating, and trends such as BYOD (Bring Your Own Device) have forever changed the face of enterprise computing. Surprisingly, even regulated industries such as Healthcare, Finance and Government see the rise of BYOD as inevitable.  Even if these organizations try to (mostly) standardize on a single device, they admit that BYOD in just one organizational pocket dramatically increases complexity. The enterprise application and data delivery landscape is going to be multi-device and multi-platform.When CIOs ask what will be "the new PC", they are (falsely) applying thinking that has developed over the last 30 years and deduce that there will be single device that dominates - that just isn't the case. 

The face of Enterprise computing is forever changing and there is no going back to the 'simplicity' of a single device - the Wintel PC.  Just as 30 years ago there was no going back to the minicomputer.  The minicomputer was born in the 60's and ruled until the mid 80's, when PCs started to trickle into the workplace.  The PC emerged from the new low cost microprocessor, and succeeded in business due to factors such as the lower cost, Local Area Networking delivered sharing, and freeing users from relatively inflexible IT departments.

Ironically, many of the issues leading to the demise of the minicomputer are also drivers to the Post-PC Era - IT departments are seen as not being flexible or rapid enough to provide users what they want/need, and the new devices are much cheaper.  The same core drivers around cost and flexibility continue to affect change. None of the minicomputer vendors survive today, and there was not a technology problem, as PCs were much easier to build and sell than minicomputers.  These companies were unable to shift their business models from one era to another, and the only exceptions were those who broke the rules.  IBM created a PC in under a year using off the shelf CPU and parts (even the operating system). From http://www.economist.com/node/7226000:

The IBM Personal Computer running DOS 1.0 In many ways, the PC triumphed due to the very un-IBM way in which it was developed. When IBM's previous attempts at a PC failed to sell, being too expensive, a “skunk works” team of engineers was convened in Boca Raton, Florida. The team did not report through IBM's stifling bureaucracy, but directly to the top of the company. It was given a year to devise a low-cost machine. 


“The people doing that work weren't talking about it, there weren't any business cases done, there wasn't any annual budget review,” explains Lewis Branscomb, IBM's chief scientist from 1972 to 1986. “IBM did a lot of radical things—and that proved to be very successful.”


To meet its ambitious goals, the team bucked two IBM traditions. First, instead of using only IBM parts, the team chose off-the-shelf components. Second, rather than keep the design a secret, the team made the specifications open, so that independent software developers could flourish. When the PC finally launched, IBM expected to sell 250,000 units in five years. In the event, it had sold nearly 1m by 1985.


Anyone working at a company delivering enterprise products today must deeply understand the change to the Post-PC Era. Analyze reasons for the ultimate demise of the minicomputer market - the same lesson has played out in hundreds of industries and there are plenty of great examples. Help your organizations understand that a huge change has started and product/technology is just part of the solution. Once your colleagues understand the ramifications of this shift, they'll be more likely to evolve to meet this new environment.  Companies that don't evolve will be gone over the next 10 years.

Monday, April 9, 2012

Does your Product have Safety Guards?


One important aspect of Product Design is ensuring that your product includes what I call "safety guards".  Safety Guards prevent any product from being used in a way that causes damage to the operator - and exist commonly in shop machinery.  Safety Guards prevent the operator from either deliberately or accidentally doing something that can cause them damage, without reducing or limiting functionality.

Software products are no different - expect that instead of causing physical damage to the operator we need to guard against doing damage to the technology environment - such as data center, network, end device, and so on.


Many products forget this part of design and testing, and we end up with solutions that accidentally or through deliberate misuse create havoc with our customers or business.  Customers may try to use your solution in a way that it was not designed, and then demand support and product modifications to fit their unsupported use case. 


While startups and early stage products may seek every viable use case in a search for a viable product and market, mature products need to guard against being pulled into fringe markets where there is not sufficient available market to sustain the product, or being pulled in a planned direction too  early. Don't arbitrarily install safety guards either - look for active situations you want/need to avoid, rather that grossly limit the product - you don't want to restrict customers from finding genuine use cases that had never been considered.


The easiest way to resolve this potential problem is to consider ways that the product could be misused, and design the interface to gracefully prevent these situations. Monitor sales and support calls and look for patterns where you are being pulled into directions that don't make sense. Design the safety guards just like those of machinery - don't limit the functionality, be simple, and just guard against things where the operator may cause damage to themselves.