Why Spreadsheets Suck for Prioritizing

The Goal

As a company executive, you want confidence that your product team (which includes all the people, from all departments, responsible for product success) has a sound basis for deciding which items are on the product roadmap. You also want confidence the team is prioritizing the items in a smart way.

What Should We Prioritize?

The items the team prioritizes could be features, user stories, epics, market problems, themes, or experiments. Melissa Perri makes an excellent case for a “problem roadmap”, and, in general, I recommend focusing on the latter types of items. However, the topic of what types of items you should prioritize — and in what situations — is interesting and important but beyond the scope of this blog entry.

A Sad but Familiar Story

If there is significant controversy about priorities, then almost inevitably, a product manager or other member of the team decides to put together The Spreadsheet.

I’ve done it. Some of the most respected names in product management have done it:

• Quick Prioritization, by Steve Johnson
• How to Use a Scorecard to Prioritize Features, by Daniel Elizalde
• How to Build Roadmaps that Stick, by Bruce McCarthy

The Spreadsheet is a list of all the ideas for the product roadmap or “backlog”, along with columns for every factor imaginable that might affect the priority of the items.

Columns in The Spreadsheet might include:

• Man-hours to implement
• Tool and other expenses required to implement
• Potential revenue
• Number of customer requests
• Number of lost deals due to absence of feature
• Alignment with quarterly or annual corporate strategic priorities

Someone creates a “magic formula” in the final column of the sheet that combines and weighs the various factors in the other columns and computes a “score”. Then the product manager or team and you all get in a room and fill in the sheet. The group proceeds to debate the finer points of, for example, assigning a “5” or a “6” rating to the “potential revenue” column for a particular feature idea.

Halfway through the multi-hour exercise, you and the team are fatigued and decide to pick it up another day. Whether or not this follow-up meeting ever happens, the team ignores much of the priorities that result from the effort, and few if any updates ever occur to The Spreadsheet.

Why “The Spreadsheet” Sucks

The Spreadsheet approach to prioritization has at least three fatal flaws:

1. Organizational dysfunction. It attempts to address organizational dysfunction with formulas and analysis that ignore human factors.
2. Product strategy void. It indicates team members lack a shared understanding of the product strategy.
3. Distraction from unique value proposition. It distracts from your product’s value proposition or from the target audience that derives the value from your product.

Let’s examine each of these flaws in more detail.

Organizational Dysfunction

Step back and consider why one or more people on the team thought The Spreadsheet was a good idea. In all likelihood, it was due to difficulty determining or agreeing on priorities.

At some point, you may have asked your product manager, “Why aren’t we working on feature Y instead of feature X? What data do you have to back up your decision?” Or members of the sales team bypass the product manager, talk directly to developers, and tell them how the next big deal will happen if only they would implement a killer feature. Or multiple product managers are competing for development resources and employ passive aggressive tactics to divert those resources to work on their products.

By now, you recognize the recurring theme: dysfunctional interactions among team members. The hope is that The Spreadsheet causes everyone to set aside their distrust and passive aggression and become “objective”. If we just focus on the numbers and let the “magic formula” compute the score, all these dysfunctional interactions will go away, and we’ll get on the same page.

Once you recognize the context (dysfunctional team interactions) and the proposed solution (objective analysis of priorities), it becomes obvious to anyone with a modicum of human sensibility that the proposed solution misses the mark.

Product Strategy Void

Why does this distrust and passive aggression exist in the first place? Or if no such dysfunctional behavior is occurring, why is it nevertheless so hard to get on the same page? It could be due to personalities and culture, or it could be that the team simply doesn’t have a shared understanding of the product strategy.

One model of product management is that the product manager or product owner (The All-Knowing One or The Decider, as Teresa Torres might say in jest) knows best, prioritizes a backlog, and doles out the work to designers and developers. “I’ve prioritized it for you; just design and implement it.”

This approach works fine when the product manager or owner is, in fact, all knowing, has the time to meticulously specify and prioritize every user story in the backlog, and when the designers and developers are machines that do exactly what they’re told. Good luck with that.

What happens in the real world? The All-Knowing One is swamped, she has no time to talk to prospects and customers, and designers and developers keep pestering her with questions. When the product manager is wrong or has no sound basis for her answers, she loses credibility.

May I suggest another approach?

Teams are most productive when they share a strategic vision and each team member can “fill in the blanks”. What if the product manager facilitated a shared understanding of the product strategy? Then each member of the team would feel confident making decisions without going back to The All-Knowing One. And the prioritizing that team members do on a daily, or even hourly, basis would flow naturally out of that strategy.

In the absence of a shared understanding of the product strategy, you, your product manager, and team members aren’t likely to agree on priorities. The Spreadsheet isn’t a strategy and is no substitute for a strategy. It won’t fill this fundamental void.

Distraction from the Unique Value Proposition

Let’s say you do have a product strategy and a shared team understanding of what it is. A fundamental part of your product strategy is the unique value proposition.

The unique value proposition is the value you envision your product uniquely delivering to a target market.

When the team chooses the product’s unique value proposition, it selects a singular, overarching theme that implicitly embodies the set of market problems it plans to solve with the product. It has largely selected the high-level priorities and deliberately set aside problems and features that don’t support the overarching theme.

For more information on unique value propositions and how to position your product relative to the competition, see this entry on competitive mindshare maps.

Imagine sales and customers bombard the team with requests for a “killer feature” that has little or nothing to do with the unique value proposition. How does the feature fare in The Spreadsheet?

Well, it scores well in the “number of customer requests” category. Perhaps it has great “revenue potential” as well, so bump up the score in that column, too. Sales claims it loses a lot of deals due to the lack of the feature. It looks like this feature might score very well indeed on The Spreadsheet.

But evaluating the feature through the lens of the unique value proposition might lead to a very different assessment of its priority. In fact, the feature might undermine, or be unrelated to, the unique value proposition.

Now, given the feedback you’ve gotten from customers and sales, you might want to consider whether to “pivot” and change the unique value proposition, and thereby the product strategy, for the product. Alternatively, you might consider spinning off another product or company with a fresh and separate set of product strategy hypotheses based on the new information.

But if you believe you already have a product strategy worth pursuing and testing, The Spreadsheet has led you astray. If you prioritize features without regard for the unique value proposition, you end up with a fractured product that distracts from — rather than delivers — its promised value. It may deliver bits and pieces of value, but those pieces have little relation to each other. They don’t coalesce around a central theme.

While the “potential revenue” rating might nonetheless seem to justify the high priority, it neglects the power of brand: the long-term impact on revenue of a cohesive product that delivers a clear value proposition.

How to Prioritize

At this point, you’re wondering how your team should prioritize, if not using The Spreadsheet.

I propose three primary questions to guide prioritization:

1. To what extent does this item (feature, user story, epic, market problem, theme, or experiment) support the unique value proposition?
2. What is the level of effort required to implement this item?
3. What will implementing this item enable us to learn?

(Heck, I might throw in a fourth one: how fun will it be to work on this item? It matters.)

The answers to these questions aren’t numbers team members plug into a formula. They form the basis for thought processes and conversations. Consider them holistically and always in the context of the unique value proposition. As Teresa Torres cautions, “If you use time-to-build to prioritize what to build next, you’ll end up with a product full of easy solutions.” Teresa rightly urges us to emphasize impact on a goal. I contend the goal is delivering the unique value proposition, as I wrote in 2013.

Accordingly, your product manager should lead the process of determining the product strategy (including the unique value proposition) and foster a shared understanding of it, and the reasons for it, among the entire team (across all departments). The product manager may also lead the process of conceiving experiments to continually test the riskier assumptions behind the product strategy hypotheses.

This high-level strategic baseline sets the stage for every member of the team to make common sense day-to-day prioritization decisions without resorting to numbers and formulas and without going back to The All-Knowing One for guidance. And when the product manager or team prioritizes one item over another, it will flow naturally out of the shared understanding of the product strategy. Steve Johnson calls it “empowering judgment with context”.

Healthy conversations about how my three considerations apply to an item should and will occur. But rarely will you need to ask for the “data” that justifies a prioritization decision. The Spreadsheet approach won’t appeal to anyone, except perhaps to the most hopelessly analytical members of the team. God bless ‘em.

Originally published at blog.cauvin.org on August 3, 2015.