A couple of years ago, I was engaged with a team involved in the migration of an e-commerce platform. Based on a budget, the cost of ownership, and an implementation deadline, the executive team selected a medium level e-commerce platform provider over other premium vendors and custom coding. Soon we realized that each and every implementation of the chosen vendor’s e-commerce platform was a customized version of its core product and framework.
For some enterprise clients, the custom version of the e-commerce platform had additional features and extra modules (different types of billing channels, promotional engines, analytics, etc.) not present in the core product while for other mostly smaller clients, the vendor did a scaled-back implementation of the core product feature set. This process of having multiple different versions of a single product running simultaneously usually works well if you have a limited set of versions and a limited set of customers and users.
However this strategy becomes increasingly difficult to manage and scale with multiple different product versions having disparate feature sets running at different client locations. New version upgrades, feature introductions, or any changes made under the conditions I detailed above can be a nightmare for a product management team. Looking forward, the product management team may think of creating multiple different flavors of product and market them (for example, a silver, gold, and platinum branding) for different customer bases. However, doing custom implementations on top of each of these versions could ruin the management team’s potential to scale and manage a stable portfolio.
I have seen similar scenarios happen over and over across the industry spectrum, from medium and large telecom billing and customer care (BaCC) product implementations to large-scale educational software products as well as major operating systems. Microsoft Windows is a classic example of how delays in major launches can occur when a significant amount of time is spent by the product group to consolidate feature sets from existing versions. Based on such experiences over the decade or so, I tried to isolate some patterns (or anti-patterns) about why product managers and product teams have a hard time managing their portfolios. I expect few of the traits to be familiar to the readers while others may be not that apparent.
Inaction of Under-performing Products and Projects
A lot of product managers, especially those in large companies, are more concerned about new products and well-performing products rather than ones that are not doing so well. They might expect that those poorly performing products will die a natural death and no one will need to worry about them. However, this inaction on part of the portfolio managers will affect the portfolio bottom-line.
Large banks—or any other multi-billion dollar enterprise—have a predetermined life span for most IT products and applications. However, due to organizational bureaucracy, age-old budgeting processes, and a consistent lack of sufficient and accurate data, the life span is always twice as large the preset limit; remember that Internet Explorer Six is still a preferred browser for some US-based financial organizations.
Surprisingly enough, smart, market-responsive digital media companies suffer from the same symptoms, albeit for different reasons. The product divisions of such market-savvy organizations can end up carpet bombing the market with multiple products and product lines. As a result, these product divisions are unable to figure out when is the right time to pull the plug on any one of them and focus on just the strategic few. For example, a digital division of one large publishing company that I worked with managed an annual portfolio of thirty or more market-facing apps and sites and had a difficult time identifying the ones that actually made strategic sense.
Product Teams Tend to Avoid Financial Messiness
Surprisingly, many portfolio managers do not like to get into financially messy predicaments, and they rely on a lot of hand waving with respect to the ROI calculations for any given product. Because of insufficient and unreliable data, there is always the risk of miscalculating the net present value (NPV) for new innovative products that are not yet launched. Even the more stable, established product lines need financial wizardry to calculate the true total cost of ownership (TCO), and the product owners often do not have enough time of the day to focus on that. In this case, the product managers often take a shortcut and they match the NPV to the internal limit required for the development and marketing budget to be approved. Behavioral scientists frequently use the term ostrich effect to highlight the human tendency of avoiding apparently risky financial situations by pretending they do not exist.
For any given product, the business model is critical to success, and a key part of the business model is making decent financial calculations. The lack of financial prudence can lead to unstructured decision making in terms of portfolio management, which can result in utter disasters. In 2010, the United States Department of Energy (DoE) provided a $535 million loan guarantee to the thin-film solar cell manufacturer Solyndra in order to build a new 28,000 square meter plant without properly investigating the true cost of producing the innovative cylindrical solar panels. The DoE expected Solyndra’s fabrication plant to produce almost seven gigawatts worth of these solar cells in its lifetime, producing roughly 110 megawatts per year. Instead, Solyndra produced only 500,000 panels before closing down. It so happened that the cost of producing a solar panel by Solyandra was estimated at more than $3 per watt (as per SEC filings) while competitors were producing similar grade panels for $1.20 per watt due to a fall in prices of the necessary raw materials.
Insufficient Available Data
A few years ago, the Harvard Business Review Blog Network published the outputs of a Babson Executive Education study of innovation team leaders at twenty-one science and engineering-based companies (http://blogs.hbr.org/research/2010/02/innovation-teams-lack-data.html) Only six respondents reported that their innovation teams make decisions in a structured and data-driven way, while eighteen reported that their organization-wide innovation process—a stage gate or a drug pipeline, for example—tends to be much more disciplined and data driven. Though the sample size is remarkably small, this shows that most small teams and start-ups do not always have sufficient data to make structured decisions.
Portfolio managers are taught in schools to spend an inordinate amount of valuable time collecting and maintaining data before they delve into scope analysis or an ROI calculation. However, with the high frequency of new technologies, products, and competitors hitting the market, there always seems to be a case where enough data points are not available to make intelligent decisions. The lack of relevant data substitutes fact-based decision making with gut-fueled instincts that may often lead to an imbalance in the portfolio.
Unreliability of Available Data
The unreliability of available data is another paramount cause of error in portfolio planning. The lack of a quality data metric that’s clear to understand and provides information that can be analyzed can force the PMs to make high-risk decisions that do not always pay off. This can occur, for example, when marketing and sales teams submit product win and loss reports to the product managers without providing a detailed analysis of the why a particular product didn’t sell and how they think the sell could have gone better. This can force PMs to rely on their judgment rather than solid metrics and factual feedback.
A Lack of Roadmap for Critical Themes
It’s critical to create a roadmap, however short it may be, for market-focused products. Lots of organizations do not have the rigor to create and maintain one. Without the roadmap, the stakeholders are in no position to prioritize and decide on parallel versus sequential streams of work to address multiple market demands and business goals.
While the new world of social media presents innumerable opportunities for the portfolio managers to exploit new channels and drive and measure sales, service and marketing yet not having a roadmap for determining the direction(s) to go for based on organizational drivers can leave the PMs with multiple costly campaigns and not enough return on the dollar spend. A lack of a roadmap also leads engineering divisions to undermine capacity planning, which results in a sloppy and risk-laden execution followed by potential launch delays.
Consider Google, which infamously closed a few of its new products like Google Health, Google Gears, Google Buzz, and others. Many individuals and companies who were using these products were taken by surprise as the overarching Google App roadmap was never created or shared. This forced many enterprise businesses to take a close look at Google’s overall roadmap with new products as Google can decide to kill any of its products based on its own adoption numbers. These businesses are questioning Google’s reliability as an enterprise platform partner, primarily for socially relevant sectors like education.
Mismatched Resourcing Results in Late Products
Most large enterprises are divided into silos, thereby resulting in the separation of duties and responsibilities. The product management divisions have either no or limited power and influence to determine the staffing and resourcing plans for the engineering units. This can result in poor planning of infrastructure, technology and skill-set needed by the engineering units for maintaining and extending the current portfolio.
I recently got a chance to work with the digital marketing division of a large financial company that wanted to create a rich, media-driven Web 2.0-enabled website to reach out to its customers. While the product owner team from the marketing division had good intentions for the product and worked hard to prepare a roadmap, it had no power to influence the key factors needed to define, design, build, and test the product. The tools used for the product development and testing were not appropriate for the product development work, and the people identified to do the work didn’t have the right set of skills resulting in inordinate delays of the launch.
A Lack of Objective Prioritization of Product Lines
Objective, data driven prioritization is a critical element that aligns the portfolio with the organizational strategy and divisional goals. More often than all, especially in large enterprises, the prioritization depends on which stakeholder shouts the loudest rather than the alignment of the product with the organizational goals. All the above factors (insufficient data, inaccurate data, and unreliable data) contribute to this behavior and the PM is rarely able to make objective decisions on critical product issues.
Here is a sample set of questions to ask while prioritizing a product or project in a portfolio
- What is the business value for the product?
- Will the new product allow the stakeholders to reach and exploit new marketing geographies?
- Does the new product provide a distinct competitive advantage in the marketplace?
- Is the new product going to help launch or promote any new or emerging lines of business?
- Is this new product playing catch-up with rest of the players in the market?
- What happens if we do not build this product and invest the budget elsewhere? Who will get affected? Will this be a potential market share issue?
- Is the new feature considered a legal obligation for the market?
- Is there a partner obligation for the product launch schedule?
- How much can the proposed product leverage the newly created infrastructure?
- Does this product address the most demanding stakeholder group in the company?
Resourcing and Cost:
- Are all necessary resources available for the product to be implemented?
- How much will it cost to launch the new product?
- Do we have talent in-house to make this product? What is the lead time to ramp up a team?
- Do we have data to prove that we can produce a quality product on time?
- Is there a need to build follow-up modules to the product?
While it’s easy to point out how your portfolio planning is in shambles and why you will not reach the success you are aiming for, it’s harder to do course correction and put it back on the right direction. That requires courage and conviction. There is a huge trove of online literature of successful case studies, interviews of successful product managers for understanding the golden rules of portfolio management. Along with that knowledge and the attitude to question every assumptions made during a critical decision making process you will be definitely on the path to avoid dumb mistakes while planning your portfolio.