Create a year-end Product progress report

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

In an attempt to summarize our collective accomplishments over the past 12 months, I decided to create a simple, 1-page chart that communicates the product advancements and highlights remaining product opportunities.

Many people look to the end of the calendar year as a good opportunity for reflection and this is as true in the professional world as it is in the personal one. Twelve consecutive months would seem to provide a sufficient review period for attempting to understand the overall impact of the team's more significant product decisions.

I have previously written here about why I feel the Product Manager has a more pronounced need to establish credibility than most other roles in the organization. It is easy to make grand, sweeping promises but ultimately, a PM and his/her team will be measured (continuously!) by the results they achieve. And even those small victories can be short-lived as the team is pushed to address the next round of challenges.

So, it seems fitting that I take a little time during the last week of the year to revisit those promises I had made and to fairly tally up the "scores".

What drove this decision

In the spirit of transparency, I wanted to conduct an honest assessment of how we did or did not advance the product portfolio and then share that with the entire company. I had established clear objectives at the beginning of the year and now felt an obligation to compare our actual results with those original goals.

I was also hoping to create a new artifact that might even help motivate the teams. Something that said, "Look how far we've come!"  If it turned out the way I thought it would, it could become a new collateral piece that gets the Sales all fired up, sending a clear message to them about how much easier it had become to tell and sell our story to customers.

Above all, I wanted to use this progress report as a reminder to the entire company that we have made great strides together along the very roadmap themes I laid out at the beginning of the year. It turned out that it was also useful for pointing out, even foreshadowing, where we'd likely be spending our time next year.

The decision: Use the familiar customer process as a backdrop for reporting finer-grained enhancements across the entire product suite.

View fullsize

Simplified customer business process

For the past few years, the Product team has been refining our understanding of our customers' core business process. We ultimately captured the process model in a single, clear diagram which we have been promoting and reinforcing with each major release so that, by now, everyone in the company was familiar with it.

This representation of the business process had been especially helpful in orienting the product team's efforts and now seemed to offer the ideal structure for lining up the various product initiatives from the past year. So I thought I would use it as the underlying structure for my progress report.

Plan of attack

Being a fan of 1-page artifacts, I set out to build a single chart that I could use to tell the story of the past year, one that would clearly illustrate our highs and our lows, our triumphs and defeats, our victories -- you get the picture.

Collapse the business process to create a familiar backdrop

View fullsize

Flatten the familiar process for context

I was confident that the process model we had been using for our own internal discussions - and which had been repeatedly validated by prospects and customers alike - would provide the right context for my new chart.

The original process diagram had filled the entire page. I tried to retain the familiar shape of the process but compressed it to fit in a much smaller vertical space. I removed the actor icons but kept the text labels for each step, moving them to the bottom of the new diagram to maintain the various transitions in the process.

Create a simple scale for relative comparisons

View fullsize

Horizontal lines set up a scale for comparisons

Next, I needed to create a way to compare the various product initiatives in a way that my audience could see the respective value of each project as it related to the customer's business process.

Ultimately I created a 3-point scale with the intentionally provocative labels "Poor", "Par", and "Premier." If I was going to use this chart to provide an honest report on how well we did over the past 12 months, I wanted to have a way to communicate where we had done well, where we had fallen flat, and where we were still struggling with mediocrity.

Plot trajectories for each product initiative

View fullsize

Plot each project as a trajectory

With these structural elements in place, I was now ready to add my data to the chart.

Instead of representing each initiative as single points on the graph, I chose to roll up the initiatives under more familiar customer-facing features and plot them as parallel vertical lines. Each feature had a bullet point to show where the feature would have been scored at the beginning of the year. I then extended an arrow from the bullet and the length of each line was meant to show how much we had improved the feature over the course of the past 12 months.

For some features, I stacked more than one arrow if we had taken several passes at it. Some features had no arrows which were meant to show a complete lack of improvement - even more meaningful when they appeared lower on the scale. It was absolutely my intention to highlight these features as ones that would require attention in the months ahead.

The impact

I had no prior experience creating a chart like this or even using a progress report to roll up the results of a year's worth of product roadmap initiatives. I will admit it that it was validating for me to see the results of our collective efforts captured in a single place though I recognize some obvious shortcomings with my approach:

• My chart only has upward pointing arrows - One might get the wrong impression that none of the work we did actually made things worse for our customers - ha!
• My chart ignores all the non-feature work - Anyone that did not work close with the Product or Tech teams might get the impression that this is all we accomplished when the truth is that so much more was done to support our growing customer base.
• My chart only exists because the story is mostly positive - I'm not sure I would have pursued this task if I thought it would have shown us in a bad light.

I'd like to think I'm not purposefully avoiding reporting on any negative outcomes but I knew that I would inevitably focus on those areas that made us look good. In the end, I think this is a fair report and have received similar confirmations from others in the company. I certainly achieved my goal of painting a clear picture for the company and my stakeholders around the improvements we've made from a year's worth of product investments.

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

More articles from our blog PM Decisions

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