Developing Attributes for Product Backlog Prioritization (Part 2 of 3)

In my last post I outlined many reasons why prioritizing a product backlog for ROI doesn't work. In this second post of a three part set, I'll explain how experienced Agile Product Managers select prioritization attributes that enable them to efficiently prioritize their backlog to produce the best near and long-term results. I'll put special emphasis on those attributes that enable a product team to prioritize for profit. Note: This series is a precursor to my talk Converting Business Value into Actual Money at the Agile-08 conference on Tue Aug 5th.

---

Backlog Prioritization Attributes

As I covered previously, to effectively prioritize a backlog a product manager must identify a set of attributes that will be associated with backlog items, assign the attribute a value, determine the degree of influence this attribute/value should have (the weighting) and then sort the list based on these results. The following represents attributes that Enthiosys has helped clients use to help prioritize their backlogs. Of course, not all attributes are used in any given project, and that the acquisition of data needed to support a given set of attributes is itself a cost that must be included in the overall analysis.

• Customer preferences as established through various market research methods;
• Cost-based financial attributes, which come "for free" as part of the various estimating processes used by Agile teams;
• Perceptions of internal stakeholders (sales, services, development);
• Corporate priorities, such as a preference to develop a new market or improve operational efficiency;
• Degree to which this backlog item is dependent upon external systems outside of the control of the development team (especially useful when more Agile teams are working with less Agile ("Waterfall") teams;
• Various kinds of risk attributes, such as market or technical risks;
• Attributes that drive the profit, which I'll cover in greater detail later in this post.

Most product teams create groups of related attributes, a sensible approach that enables the team to focus their attention on a "slice" of the problem without becoming overwhelmed.

I strongly recommend that before reading further you review the attributes you've developed to prioritize your backlog. How are they working for you?

---

Choosing Backlog Prioritization Attributes and Weightings

While the exact set of prioritization attributes and their associated influence (weighting) on the sort order of the backlog varies on a per-product, per-release basis, we've found that product managers work most efficiently when the backlog attributes are relatively stable while the weightings of these attributes are adjusted to reflect current thinking. As such, a product manager should select prioritization attributes that meet the following criteria:

1. They are valid across a few releases
2. Their value can be established in a timely and cost-effective manner
3. They support the politics of effective product management
4. They align the backlog to corporate and product goals

We've found that the following sets of attributes meet these criteria on every project:

1. Stakeholder Preferences
2. Strategic Alignment
3. Driving Profit

We also prefer market research that establishes direct customer preferences for backlog items, but, quite frankly, it is the rare product team who does this (see my last post for the reasons why). That's why the third set of prioritization attributes is so important, as these can help a product manager compensate for the lack of direct customer feedback.

Stakeholder Preferences

Stakeholders come in two primary forms -- internal and external stakeholders. Internal stakeholders refer to sales, marketing, professional services, and customer service. Their perspective on the backlog is critical for success, because all these groups must work well enough to create a successful project. A critical addition to this list of internal stakeholders is your "System". Here's why. Every system architecture, no matter how well-designed, must be maintained. This can be a challenge in agile teams who focus their attention on backlog items that are associated with top-line revenue growth and/or customer demands. To combat this tendency, we advocate anthropomorphizing the system. This enables the system to literally “have a voice” in its own “care and feeding” and helps encourage agile teams to make architectural investments that are every bit as important to the long-term needs of the business as various features are to other customers.

External stakeholders include customers, channel and marketing partners, integration and/or development partners, distributors, and quite possibly the general community that is associated with your product. In the ideal world you'd include their preferences directly through market research (Innovation Games®, Min-Max, conjoint analysis, Kano analysis, and so forth). In practice, most product managers include their preferences indirectly by interpreting their impressions of what customers want.

Strategic Alignment

The backlog must also support the larger corporate, divisional, and/or portfolio goals established by the executive team. This means that product managers work with the executive/business team to make certain the business priorities are clear and weighted according to the goals of the business.

To illustrate why this is critical, several years ago I was asked to help a product team adopting Agile find a way to manage their boss, who was inadvertently micro-managing the prioritization of the backlog. Specifically, after the product manager had established the backlog prioritization, he would inevitably change it, disempowering the product manager and dramatically slowing down the project. He didn't mean to disempower his product manager. Instead, he was frustrated by his inability to see how the backlog was prioritized relative to his larger divisional goals. Once we added attributes that captured the divisional strategy, he was able to see which backlog items explicitly supported the same.

Driving Profit

At Enthiosys we think of your business model as the system of inter-related choices that you make to drive profit. Two important components of this system are your value exchange model and your profit engine. Your Value Exchange Model is how you trade money for value in software. One example is a Time Based Access model, in which a customer pays you money to use your software for a period of time. Perpetual and annual licenses are the most common, with Adobe's Acrobat being an example of the former and many enterprise software offerings being an example of the latter. Another example is a Transactional model, such as the credit card industry's transaction processing models, Google's model for revenue based on advertising or Enthiosys' model for Innovation Games® online. (For a detailed exploration of Value Exchange Models, see my book Beyond Software Architecture).

Your Profit Engine is how you structure your relationship with your market to drive increasing exchanges of value. In Adobe's case, they make Acrobat reader free and ubiquitous, driving the growth of the writer. In the case of the credit card industry, they make their networks widely acceptable, drive common standards to lower certain kinds of costs (the shape of the card, the contents of the magnetic stripe, and card readers), and offer additional services to drive transactions (anti-fraud and sophisticated account management services).

Unlike ROI, every Agile Product Manager should be able to identify which backlog items contribute to driving profitable growth. For example, if your value exchange model is based on transactions, a backlog item submitted by your technical team to reduce transaction processing time by 10 ms per transaction drives profit by lowering operational costs. If your profit engine is based on selling add-ons or modules to a platform, you'll want to know which backlog items drive the growth of existing modules or create new ones.

A key distinction here is that these attributes are NOT designed to capture improvements to existing solutions. Instead, these attributes are designed solely to align backlog items with your those aspects of your business that drive profitable growth: lowering operational costs, driving top-line sales, motivating existing customer to purchase more of your total offering, and so forth.

Our experience is that successful Agile Product Managers have an almost natural, intuitive feel for prioritizing backlog items to drive profitable growth. Fortunately, this natural ability is greatly enhanced when they make the link between the backlog and their ability to drive profit explicit. As an aside, it is this set of attributes that most clearly distinguish the Scrum-centric role of a Product Owner with the full responsibilities of an Agile Product Manager.

In my final post of this three part series I'll explain how to put all of this together so that you can Prioritize for Profit and not "Business Value".

Comments

[Kent J. McDonald]

I would concur with the majority of you thoughts in this entry.

Good to see you mention strategic alignment. One aspect of that is having the strategy clearly defined enough so that the Product Manager, and frankly the whole team, has an appropriate understanding of it so they can apply the strategy to the decisions they make on a day to day basis when prioritizing the backlog or developing the product.

As for Driving Profit, would you include activities in that category that increase revenue as well as those that reduce cost? (Both of which have an impact on profit). Some would say that features that protect existing revenues could also have an impact on profit, which is in the case of a for profit business, what business value is all about.

[Luke Hohmann]

Kent, at Enthiosys we identify direct and indirect drivers of profit. The direct drivers of profit include increasing revenue and decreasing costs, in many different ways. The indirect driver of profit includes infrastructure, an investment of which enables a direct driver of profit (e.g., putting in a VPN infrastructure enables workers to work securely from remote locations often lowering costs, such as when they work from home; "Internationalizing" an architecture is an infrastructure investment that enables localization in multiple languages, often improving revenue).

"me-too" features that protect revenue are important in competitive situations and should be considered by a product manager in the set of attributes they consider for driving profit.

[Saeed Khan]

Luke,

The three attributes you list:

1. Stakeholder Preferences
2. Strategic Alignment
3. Driving Profit

are true when developing products, regardless of the development methodology. If one were to use a waterfall approach for product development, would the list be any different?

Probably not. So I'm curious if there is something specific about this list and Agile that I'm missing?

Saeed

[Luke Hohmann]

Saad -
Sorry for the slow reply -- I just missed it. Yeah, there is a huge difference: Waterfall approaches don't require ordinal rankings to be successful. Waterfall projects tend to prioritize on sets. Which lets Product Managers "slide" with a LOT of wiggle room. Agilists don't like the wiggle room. We like the fact that we agonize over which item in our backlog is #10 vs #18. And it is really hard work.

Let me say that again. It is MUCH harder to create a prioritized backlog than to simply say "Here are my 10 As, my 12 Bs, and my 14 Cc. I need all of my As and most of my Bs in this release". (Don't laugh -- I've seen lots of product managers do this). That's not helping your team.

Luke

[Using Innovation Games® to Ide]

[...] And they should do this, as I describe in my three-part blog series Prioritizing for Profit: 1, 2, [...]