Prioritizing for Profit (Part 3 of 3)

In my last two posts, I outlined many reasons why prioritizing a product backlog for ROI doesn't work and suggested a core set of prioritization attributes that Agile Product Managers should use to prioritize their backlog. In this last post of my three part set, I'll describe the core processes that an Agile Product Manager should use to prioritize their backlog starting with the processes associated with gathering the data needed to value customer attributes. Note: This series is a precursor to my talk Converting Business Value into Actual Money at the Agile-08 conference on Tue Aug 5th.

---

Setting Prioritization Data

Prioritizing against the three sets of attributes I outlined in my last post means that Agile Product Managers must identify stakeholder preferences, understand which backlog items align to corporate strategy, and demonstrate which backlog items drive profit. Each of these involves gathering a unique set of data.

Gathering Stakeholder Preferences

The ideal way to gather internal and external stakeholder preferences is to collaborate with them to get their perspective on backlog items. The kind of collaboration we advocate requires product managers to move beyond many forms traditional forms of market research (which, as outlined in my first post, may take too long or cost to much) and embrace new thinking and new tools.

One approach that we've pioneered at Enthiosys is to leverage preference weightings and collaborative gaming to enable continuous collaboration on the prioritization of backlog items. Focusing on collaborative gaming, Agile Product Managers leverage in-person or online tools to collaborate with groups of stakeholders to gather requirements.

For example, a product manager might use the in-person version of the Innovation Game® 20/20 Vision to rank-order the benefits that a small group of customers (typically 8-30 lead customers) want in the next release and the online version of the Innovation Game® Buy a Feature to gather direct feedback from an arbitrarily large number of customers (or other stakeholders, such as channel partners) on the backlog items that represent the features that create these benefits. Using _Buy a Feature_ online, they could gather and compare external stakeholder results with the results of various groups of internal stakeholders. These collaborative approaches compliment and extend the personas that astute product managers create to drive success of their products. As you can expect, the highest priority backlog items will be preferred by both internal and external stakeholders.

This process can inadvertently prevent Agile teams from prioritizing architectural or system level enhancements into a release. I know, because I’ve made that mistake. To compensate for this, recall that we anthropomorphize the system architecture to capture necessary architectural changes from the roadmap, with the technical architect representing the “voice of the system”. Thus, even though no other internal or external customer cares about refactoring or improving your architecture, it can still be prioritized high on your list because your system cares. As a result, our experience is that every backlog item should correlate to at least one stakeholder preference.

Aligning to Corporate Strategy

Aligning your backlog to your corporate strategy is simple; provided you know your corporate strategy! Assuming you do, simply associate corporate strategy attributes to backlog items, identify which backlog items directly support that corporate strategy, and demonstrate that at least some of these backlog items are contained within your release. For example, one of our client's 2009 strategies is focused on developing solutions that are mobile, global, and social. An Agile Product Manager at this client would therefore seek to show which of their backlog items directly align with at least one of these strategic initiatives. Our experience is that not every backlog item will align to corporate strategy, which is OK (sometimes a bug fix is just a bug fix).

Product managers who find it difficult or impossible to align their backlogs to their corporate strategy need to tackle some potentially serious problems. When the root cause is an unclear corporate strategy, it is the product manager's responsibility to suggest their best possible interpretation and encourage senior leaders to extend and improve the same.  (At Enthiosys, we call this Leading with A Point of View and it is baked into our corporate culture). When the root cause is a backlog that is challenging to align with the strategy, we naturally suggest exploring a change in the backlog or a change in the strategy. The former is appropriate when the backlog was developed without awareness of the strategy or when the backlog was developed under the context of a previous strategy. In this case, the backlog should be refreshed under the context of the current strategy, which is likely to motivate a new round of market research.

There are times, however, when a product manager is faced with solid market research and an associated backlog that justifies a change in strategy. In this case, the product manager should negotiate with senior leaders to explain their evidence, demonstrate how the backlog aligns with a modified strategy, and make the case for the updated strategy. Sometimes the right approach is to indeed change the strategy.

Driving Profit

Stakeholders, and especially existing customers, may want (value) a large number of backlog items that they expect "for free" because most software companies have conditioned their markets to expect continuous improvements to products and services as part of existing business models. While implementing these may improve customer satisfaction, they may not drive profit. Similarly, a product manager at our client who can demonstrate that a backlog item aligns to the corporate strategy of providing a mobile solution may be hard-pressed to identify how this solution will drive profit. Again, this may be OK, as there may be larger corporate goals served by developing a mobile solution in a given product even though that particular product may not be able to directly monetize that profit.

Eventually, though, a product needs to contribute an appropriate profit to the firm, and it is the product manager's responsibility to demonstrate which backlog items are expected to drive profit. For example, suppose that you’re managing a hosted service and have some backlog items motivated from your operations team that identify ways in which you could reduce operational costs. These items serve to drive profit. And yes, I know that because computing the NPV/ROI for these items is relatively straightforward you’ll be tempted to do the same. Go ahead, if you must, but remember: prioritizing your backlog solely on ROI is not your goal because you’ll not be able to compute the ROI on every backlog item.

A more realistic (and therefore, complex) example occurs when your market data (qualitative market research, win/loss analysis, competitive offerings, etc.) results in backlog items that you believe will enable you to sell more of your software, perhaps to existing customers or perhaps to a new market segment, but lacks the necessary rigor or completeness to support a defensible NPV/ROI analysis. In this case, you’ll want to identify they key ways in which this backlog item will drive increasing profit. And, if you’re working in a truly agile company, you can also provide some broad insight into how much revenue you’ll make.

For example, suppose you’re developing a content management system for patent data. This is a market that values data. Lots of data. The more data, the better the analysis. Suppose that your current offering manages data from the European and US patent offices. You’ve gotten some requests to manage data from the Japanese patent office, and you know that some prospects have listed a lack of Japanese patent data as a reason they didn’t buy your system in their win/loss analysis. In this case, you can legitimately claim that these backlog items are going to drive revenue through new sales even if you lack the data to complete a defensible ROI calculation (e.g., how many customers will pay the necessary amount to drive growth or how many customers will pay a data management upgrade fee to acquire this new data). If this backlog item further aligns with a corporate strategy of managing large amounts of patent data, you may have sufficient data to prioritize this backlog item into the release, provided you accept the risk that you didn’t justify your choice with a defensible ROI analysis.

In practice, we’ve found that backlog items that drive profit tend to be rather large amounts of work, often called epics, that are elaborated during release planning into many smaller backlog items each of which can completed in an iteration. That’s OK, because the benefit of enabling Agile teams to clearly define how they are driving profit through their backlog is more than having the team pick smaller-sized backlog items during release planning.

---

A Well-Prioritized Backlog Drives Profit

Now that we’ve identified core attributes, grouped them in sensible ways, and set their values, we can examine the results of our work to determine if the backlog items that have made it into the release are likely to drive profitable growth. Instead of prescribing more processes to follow, I’ll instead provide three simple tests that you can apply to your backlog to help you determine if you’ve done a good job (feel free to add your own).

Test 1: Stakeholder Balance

A stakeholder balanced release backlog has at least one backlog item for every stakeholder in the release. Yes, everyone. That’s because Agile Product Management is a political game, and you’re not going to succeed unless you manage the politics of the backlog. Which means you’re going to eventually have to prioritize your support team's request to improve the log files so that they can more effectively diagnose customer problems.

An unbalanced release is a release that starves one or more stakeholders. You can get away with starving a stakeholder every now and then, but consistently starving an external stakeholder will eventually lose you customers, partners, or your channel. Consistently starving your internal stakeholders means that you’ll lose the goodwill that results in sustained success. Your sales team may not push your product quite as hard, support may not support it quite as well, and so forth.

Strategic Alignment

A strategically aligned release backlog has at least one backlog item that can be directly correlated to the key elements of corporate strategy. Hopefully, I don’t need to elaborate the long term job prospects of a product manager who consistently ignores or is unaware of how their product’s evolution correlates to product strategy.

Profit

A release backlog that is driving profit has at least one backlog item that can be shown to be congruent with your Value Exchange Model and drive profit through your Profit Engine.

In summary, the key to prioritizing for profit is to:

• balance stakeholder demands
• align to corporate strategy
• drive your profit engine

See you at Agile-08!

Comments

[Erik Krause]

I'd like some insight into using the spreadsheet. What values go into the cells under the various stakeholders? Are all stake holders given a number of "votes" say- 100 and then are then asked to distributed them among the backlog? Does the same go for Strategic Alignment and Profit Alignment?
Or am I missing something?
Thanks- Erik

[Luke Hohmann]

Erik -
The values that go under the cells of the various stakeholders are the weightings that you ascribe to a given stakeholder. In the sample spreadsheet posted on the web site (available here: http://www.enthiosys.com/wp-content/uploads/2008/08/featurerankingspreadsheettemplate.xls), Judy, the persona of the owner of small business owner, is given a weighting that is more than twice as important as Frank, an employee of a small business. This means that your backlog will be most heavily weighted towards Judy's needs.

All stakeholders are encouraged to vote on all backlog items. I'd be concerned if you have more than 100 backlog items that you're actively trying to prioritize through this kind of spreadsheet. In this case, you might need to do some initial sorting of your backlog and try hard to avoid prioritizing large numbers of items that you know you simply can't get done.

The Product Manager is typically responsible for setting the values for backlog items relative to strategic alignment and profit alignment. A savvy product manager will review the weightings and values with others (especially their boss!) to ensure congruence with the needs of the larger corporation.

[Al]

Hi Luke,
thanks for the spreadsheet. What sort of values do you put in the content below the weights? Is it just a "1" if that cell applies to the feature and the stakeholder ? I've seen other charts like this where folks enter a rating value on scale of 1 to 10. But I've found this approach takes much time to fill in.

also, you're weighting equation simply sums the products of the weight and the value in the cell below. I'm more used to the weighted average formula that looks more like

x1* w1 + x2*w2 + x3*w3
-----------------------
w1 + w2 + w3

does the weighting algorithm matter?

Thanks!

[Al]

that's a big divided by line in my weighting equation above..sum of products divided by sum of weights.. sorry.. the comment entry unrwapped it.

[Luke Hohmann]

Al -
You want to restrict your entries in this model to either zero or one because of the weightings. If you allow people to enter in a number of than zero or one, they'll affect the weightings of their votes that you've established. Moreover, we've found that using zero or one makes the whole process go a lot faster.

The weighting algorithm does matter a lot, and I suggest you play around with different weights and a larger, more comprehensive backlog to help you get a sense of how you should be weighting items for your product.