Assess the Product Portfolio

Flickr image source: http://tinyurl.com/nl2c4vh

After recognizing that our development team would remain inundated with far too many product requests, I decided to examine our entire collection of products with an eye toward slowing or reversing ongoing product investments.

Like any Product team, we are never in short supply of feature requests, product suggestions, looming technical debt, must-have components, urgent customer pain points, etc. And we do our best to stay on top of the things, trying to keep all parties happy-ish. But over the past few months, I had started to see important product enhancements slipping from each release and was able to attribute those slips to other competing product priorities.

Because there are quite a few moving parts in a typical software development shop, there are any number of places you could start the analysis. Our problems could be related to bad grooming practices, poor scoping efforts, or even an understaffed engineering team. But I know the problems we were having were not limited to a single product or any one PM. It was simply proving too difficult to keep all our balls in the air.

We had launched a generous number of products over the past decade but poking around at the ground level was likely to be an unproductive exercise. I needed a model to help me and our team evaluate decisions across our entire portfolio.

What drove this decision

I was getting anxious about the number of product-related discussions the Management team was having and becoming convinced that they had lost some perspective on what we had already committed to. In fact, there were signs that the company's entire product strategy might be in need of a refresh so I scheduled a mid-year strategy meeting with the management team to do just that. But I felt there was a need to connect the day-to-day challenges we were having with each product release to the product discussions that were happening (at an increasing rate) at the executive level.

I needed to create a backdrop for our high-level product investment decisions that would also drive real benefits at the troop level.

The decision: Create a model for evaluating current and future product portfolio decisions

Over the past decade or so, we had made decisions to create new products and not all of them turned out to be winners - no real surprise I guess. The bigger problem was that we had managed to sell each product to some subset of our customer base so we had an obligation to support it through troubleshooting, bug fixing and occasionally, even enhancement-ing. This obligation grew non-linearly with each new product. 

I knew the customer usage patterns were irregular and more importantly, the revenue we derived per product was inconsistent and unpredictable. Despite this, we had no plans to sunset any of the products thus perpetuating our dilemma indefinitely.

I needed to spark some productive conversation. I needed to shed some light on the impact of our past decisions and try to head off some questionable proposals that were brewing in the company.

Plan of attack

The diagram that I built only needed to be as complex as the audience I was targeting. I felt I could communicate a great deal with coarse-grained data elements, where conclusions could be drawn (no pun intended) by counting boxes or showing the relative size or positioning of boxes. I ended up with something along these lines (pun fully intended):  

View fullsize

Simplified Product Portfolio Model

1 - Plot the products on a simple graph based on revenue vs. customer use

I strongly recommend that you organize your graphs so that the most desirable position is in the top right corner. Both X and Y axes should go from low to high, least to most, etc.

I started by placing each product on the chart based on how much customers were using it and how much revenue it generated. In using these axes, I was hoping my products would be stacked up and to the right. If plotted accurately, it should be easy to defend ongoing and future product investment decisions with this simple graph.

In an attempt to communicate more information with fewer charts, I decided to use the relative size of the product "boxes" as an indicator of our current investments. Without aiming for exactness, I was able to quickly explain where our resources are being deployed. A slightly more complex approach would have been to use other graphical elements to break down the current investment by Product, Engineering, Operations and Support.

2 - Clarify the ratio of Products to Product Resources

Our company currently has more than 15 products in our portfolio and I'm sad to report, not nearly enough Engineers and PMs to manage a portfolio of that size. We have found ourselves in this situation after years of adding new products because at the time, we believed they were crucial to our company's success.

But like many eager, young software companies, we never seem to plan well for the long-term maintenance and support of each new product. I can't help but make the comparison to the decision of adding a new baby to your family.  Everyone thinks it a wonderful idea at first but after spending a number of grueling months bringing it into the world, you find yourself responsible for taking care of another living thing for the rest of your life (or your life at the company at least).

With a few, carefully placed text overlays, I listed on the diagram, the relative sizes of our current teams which revealed the stark truth about our current staffing situation. This helped set the stage for a productive conversation about acquiring more Product/Engineering resources or reducing the size of the product portfolio or both.

3 - Future investment and product goals

I used the same model to spell out some of our short and long term product strategy. With the boxes already arranged on the chart, I added arrows to indicate where we would expect to see movement in the months ahead. Specifically, I predicted the movement of various products over the next 6-12 months in terms of increased/decreased usage and increased/decreased revenue.

By adding a few crude marks over some of the product boxes, I was able to show which products in which I intended to reduce our investment and even more, which I thought we should retire in the months ahead. 

The impact

There are more messages that can be highlighted and communicated in a chart like this. Seeing all the products intelligently placed next to each other on a single page inevitably invites more strategic conversations like:

• Why are we still supporting this product if the usage rate is that low? It's time to retire it.
• When is the last time we updated the technology behind those products? They're due for a refresh.
• How long has it been since we last sold this product? Let's try lowering the price.

Armed with this new model, I was able to drive a strong Product-focused agenda at the Strategy Summit and was even able to successfully head off some premature ideas that could have led us further down the wrong path.

Look for more reports from theProductPath around charts, product portfolios, and managing stakeholders here on PM Decisions.

More articles from our blog PM Decisions

Present a Product Roadmap to the Board using the 3 Horizons Model

Image source: https://www.flickr.com/photos/donkeyhotey/6143615821

In preparing to present the new Product Roadmap to the Board of Directors, I decided to employ a popular investment framework to organize our product decisions.

If your company has a Board of Directors or similar advisory group that helps guide the organization, chances are they will be curious about where the product is headed; however, more than the other stakeholders, this group is likely to view your ongoing product decisions as a series of investments. And, like any investment, yours are expected to deliver positive returns down the road.

As the head honcho for the Product team, you are responsible for crafting a rendering of the product roadmap that gives them the appropriate level of detail. There a number of ways you can organize your product investments to maximize both short term and long term opportunities but communicating that plan to “The Board” can be a challenge.

What drove this decision

In refreshing our roadmap, the Product team had established high-level themes to guide decision making but these tend to be more appropriate for filtering and prioritizing work and less useful for calling out specific product initiatives.

The 3 Horizons model was first published in The Alchemy of Growth by Merhdad Baghai, Stephen Coley, and David White in 1999 and made popular by the likes of McKinsey, Geoffrey Moore, and others.

I knew our Board members would not have the patience or the necessary product-level knowledge to absorb a thorough presentation of our detailed product roadmap, filled with epics and stories. Plus it can be difficult to get a good sense of the overall product direction when sitting that close.

For this particular audience, I needed to use broad strokes. Specifically, I wanted to explain exactly where the investments were being made and how we expect them to pay off in the next 6, 12, and 24 months.

I first ran into the 3 Horizons model in a wonderful presentation entitled 10 Roadmap Tools created by Radiant Minds (now part of Atlassian, makers of Jira). They recommended using this tool to communicate a high-level product roadmap as a set of investments that extended the current business but that also created viable options for the future.

The decision: Use the 3 Horizons Model to present the Product Roadmap to the Board of Directors and show how we would balance short and long term investment opportunities. 

I recommend exploring the Radiant Minds presentation and perhaps even reviewing the original source material for additional insights. I found this model to be convenient for speaking to our Board members - so that rather than try to impress them with impressive-sounding technical jargon, we were able to spend time talking through how we would leverage the technology to drive real, positive outcomes for the business.

The 3 Horizons model can help you organize your thoughts so that you continue to capitalize on the current customer opportunities while carving out appropriate cycles for favorable market conditions in the future.

Plan of attack

It would be impossible and also inappropriate to provide the full details of my company’s product roadmap here so I have obfuscated much of what follows. I have included a few examples that should help to illustrate the thought process I used in adopting the 3 Horizons model for our Roadmap presentation.

Horizon 1

The first horizon in the model shows how 70% of your investment should go into existing technology that you currently use and in an existing market that you currently serve. This best positions you to defend your current business and capitalize on your company's existing resources.

For our company, we used Horizon 1 to outline the scheduled work in the roadmap that would build on the technology components already present in our core platform. For example, we planned to develop a new mobile application for our customers based on feedback we had been gathering for the past few months. I explained to the Board that, because we had built front-end and back-end software like this several times before (and were quite good at it), the business risk for this new application was fairly low.

Horizon 2

In the second horizon, you describe how 20% of your product investment will utilize existing technology currently not in use in your company to address an existing market that you do not currently serve. Adopting proven technology lowers the risk for your company as you look to serve customers in the new market.

Internally, our teams had been researching an alternative to our outdated reporting infrastructure and, in the months ahead, we were planning on dedicating resources to the effort of overhauling our reporting engine. The new technology would allow us to better aggregate the information our platform collects and build helpful data-driven dashboards. As I explained to the Board, the Horizon 2 product investments would allow us to deliver an analytics offering to new and existing customers, opening up additional revenue opportunities outside of the markets we serve today.

Horizon 3

The final horizon in the model is used to highlight the remaining 10% of your investment, which is where you target new technology with the intention of entering a new market. It is admittedly harder to aim for that third Horizon - which explains the proportional size of this set of investments.

Our team has set its sights on eventually moving away from relational databases entirely and the decisions we made in this iteration of the roadmap reflect that. We are looking to the next generation of database technologies to help our software platform scale that in turn could open up much larger customer opportunities. Over the next 12-24 months, we intend to incorporate new technology into the platform to better position the company to go up market and pursue larger customer opportunities. 

The impact

You will find that there are different audiences for your Product Roadmap and each audience may have different expectations - and different level of interest. Our Board responded positively to the overall roadmap presentation and was especially engaged in the investment-oriented nature of the product decisions based on the 3 Horizons model.

Look for more reports from theProductPath around product roadmaps, PM tools, and managing stakeholders here on PM Decisions.

More articles from our blog PM Decisions

Repave the road...map

Image source: https://www.flickr.com/photos/willemvanbergen/4498186500

After inheriting a weathered product roadmap whose years of wear and tear had been the source of chronic problems for our company, I decided to fortify its very foundation.   

Like many early stage companies, we had been struggling with product direction, with making and keeping promises to customers, and with overall Engineering churn. The source of many of these problems was a Product Roadmap that frequently over committed and that failed to adhere to any consistent vision.

What drove this decision

It's fair to say that no one expects every promise to come true. And that holds for product roadmaps as well. Roadmaps are simply a plan that drives towards some future state of your product and as Eisenhower famously said, "Plans are nothing, planning is everything".

Some Product Managers get into trouble when they get too specific about future plans and end up prematurely commit to features and dates in their roadmaps. This was a perpetual problem at my company and over the years, our credibility with customers and prospects as well as with internal sales & support teams had deteriorated.

The change in leadership on the Product team presented me with an opportunity to address the problem head on but that would require some real road(map) construction work.

Image source: https://www.flickr.com/photos/seattlemunicipalarchives/3749710569

The decision: Repair the roadmap infrastructure

There are quite a few good sources on the Internet that describe proven techniques for constructing sound product roadmaps and bolstering product planning efforts. Indeed, the tactics described here are not fundamentally revolutionary. What is novel perhaps, is how, with a few straightforward changes to how we built and socialized our product roadmap, we were able to directly address and ultimately improve the Product team's credibility.

Plan of attack

We identified and committed to three changes (at least in this first phase of construction) that would yield the most value for our stakeholders. They are not mutually dependent and could be done in any order.

Use 3/6/12 months increments

We immediately dropped the former convention of spelling out exact release dates in the roadmap. Instead of prematurely committing to specific monthly releases, for example, we create a 3/6/12 month plan. Because our confidence was much higher in the short term feature enhancements, we described these in more detail on the roadmap. And we decreased the level of detail around features as we moved into the six- and 12-month phases.

This change shifted the focus away from specific dates and to the prioritization and staging of the work itself.

“We use high-level themes because it makes communication simpler and allows us to keep uncertain details vague. It also helps to limit scope creep – if a request for a new feature doesn’t align with the agreed themes then it’s easy to push back. The use of themes, combined with broad delivery windows as we move into the future, helps us to be more confident that we can deliver what’s on the roadmap.”

— Roadmap issue of the Product Management Journal, vol 9, pg 7.

Create themes for prioritizing product decisions

Roadmaps that stretch out for months or years can be complicated and unwieldy for the newcomer. It is difficult to capture all the finer points of a Roadmap in a high-level, visual chart or to communicate all the thinking that went into developing it.

To make our Roadmap easier for others outside the Product team to consume, we introduced and described a few themes. These themes helped to visually connect different units of work so that the causal observer could find order in the abundance of features.

The themes helped our audience to better understand our decision process. For instance, we could show how when a particular feature on the roadmap aligned with multiple themes it was given higher priority over other features. 

Separate commitments from candidates

There is another simple technique that roadmappers can employ to avoid making explicit promises, especially when facing increased uncertainty about the ability to deliver features far down the road.

On any/all external facing versions of your roadmap, you include a graph that has two opposite endpoints: Commitments and Candidates. The features about which you feel more confident, likely the ones you will tackle sooner, will appear on the Commitment end of the graph. The features that are further out in the future will inevitably be designated as Candidates on the graph.

While this tactic might seem obvious to you and your Product team, it will help to set the proper expectations with your stakeholders and help you stave off unproductive conversations around future roadmap commitments. 

The impact

I published the updated Product Roadmap at the beginning of the year with these three improvements: 3/6/12 month timelines, high-level themes, and a commitment/candidate graph. And, while the changes were relatively simple, the outcome was significant. Product conversations with internal and external audiences were more focused. Our team spent less time explaining or defending our decisions and more time engaging stakeholders in productive dialogue about solving important customer challenges. 

Look for more reports from theProductPath around product roadmaps, roadmap planning, and managing stakeholders here on PM Decisions.

More articles from our blog PM Decisions

Campaign for early Product Roadmap support

Image source: https://www.flickr.com/photos/amycgx/3119640267

To increase the chances that the new Product Roadmap (and my first here) would win favor throughout the company, I decided to conduct a campaign to build early support for the Roadmap itself.

As the new guy now leading the Product team, I had my hands full getting up to speed in the first few weeks. My immediate concern was keeping the current Release on track but the greater challenge was creating a new Product Roadmap for the upcoming year and rapidly drumming up support within the company.

What drove this decision

Taking over a Product team at the beginning of a calendar year has some additional pressures as you might expect. Many internal and external parties are looking for clear indications of the overall product direction, the most concrete of which is the Product Roadmap.

Our company likes to kick off the new year with a rousing, all-hands pep rally for the entire company and one of the meeting's big agenda topics is the presentation of the refreshed Product Roadmap. A big reveal from me that early on would be risky as I hadn't built up sufficient credibility by that point. And with just a few weeks into this PM role, I really hadn’t hadn't been able to speak with as many departments as I had hoped. To pull this off, I needed to build a groundswell of support by having the various department weigh in on, or at least preview the Roadmap before I tried to broadcast it to the masses.

Image source: https://www.flickr.com/photos/israel-mfa/14616944000

The decision: Build support for the new Product Roadmap in stages

My ultimate goal was to present my new Product Roadmap to a room full of supporters. To improve my chances, I started a somewhat calculated crusade to win friends and influence people all around the company.

Plan of attack

There is no one, obvious way to plan a campaign like this but the strategy I recommend is to start small and with people whose opinions you value and push them to poke holes in your product strategy before moving to the next group. I have outlined the approach I took which proved successful.

Start with just the Product team

I began the exercise with my own Product team, perhaps the most empathetic of the groups I would encounter. These folks were the most patient and, because their future paths were most closely linked to the Roadmap, the most eager to engage. With this group's help, I was able to get my initial story straight, confirm the overall themes, and plug some minor gaps in the strategy.

run the roadmap past the Sales Engineers

The next audience I sought, though discretely, was with the Sales Engineers. I had worked closely with this team in the past and knew they would be supportive. I trust their general feedback but it was also important for me to vet out some of the key product decisions with someone who interacted more frequently and directly with our prospects and customers.

pitch to the Key Stakeholders

With my confidence growing, I moved on, skipping over the individual departments to gather all the stakeholders in a room. As you might expect, this group of department heads, their bosses and our senior leadership team is composed of a great number of strong personalities. But when invited to sit alongside their peers, even the feistiest individuals will often tamp down their protests, yielding to and general supporting the views of the larger group. I found this to be the case with my Roadmap presentation and used the inferred approval from the group to launch into the home stretch.

present to Individual Departments

With support from the top, I proceeded to set up separate meetings with each major department including Engineering, Operations, QA, and Customer Support. In each meeting, I tried to highlight those parts of the Roadmap that I thought would appeal most to each group. This proved valuable later, in the larger setting when I was able to direct different topics to specific members of the audience, with the effect of making it seem as though they had already endorsed the individual ideas.

Announce to the Entire company

The final stop in the campaign of dreams was pitching the Roadmap to the entire company. At that point of course, through all my previous efforts, I had eliminated the element of surprise. I had effectively planted sympathetic individuals in the crowd who consciously or not, were giving me the nods of support I needed.

And, while there was no thunderous applause at the end of my presentation, I did get relatively high marks for a "new guy". In fact, a number of people approached me afterwards with positive feedback and great suggestions about how to further socialize the Roadmap internally. For example, we decided to start using the many monitors hung on the walls throughout our office to track our Roadmap progress over the coming weeks & months. 

The impact

When I look back, it is obvious to me that this kind of approach to build internal support takes more cycles than one big reveal. Meeting with each team, one at a time and reviewing the Roadmap over and over was certainly more work in the short term but has paid off. I still have to demonstrate that we can achieve what was promised but I should not be spending as many cycles defending the Roadmap itself.

Look for more reports from theProductPath around product roadmaps, promoting product ideas and working with stakeholders here on PM Decisions.  

More articles from our blog PM Decisions