RICE plus a little politics

Prioritization is a Political Problem as Much as an Analytical Problem

Most of our tools and processes around product/feature prioritization are heads-down analytical: RICE, opportunity trees, Kano, weighted 16-column spreadsheets, WSJF, Eisenhower, whatever. Our (hidden) assumption is that choosing the objectively best work is hard, but getting organizational buy-in is not so hard. That once we have a brilliant answer, we can walk internal stakeholders through our logic and they will agree — bowing to our superior tools and intellect and data.

At least in the B2B software product world, I haven’t found that to be true. Rather the reverse: regardless of how we rank alternatives or sequence work or match roadmap items to corporate initiatives, no matter what analytical method we apply, we [product managers] get similar reactions from the go-to-market side of the house: “I only see 1 of my 5 critical items” and “we have to do more” and “your process gets in the way of the commitments we need to make.”

At the leadership level, I see a fundamental disconnect between the folks defining/building software products and the folks marketing/selling them:

This back-and-forth happens in so many organizations: a go-to-market team with an inclusive ( expansive) view of ever more products and features and opportunities — facing a builder team juggling too many commitments and doing CPR on existing under-invested products. More than just language, this is IMO a fundamentally different worldview.

Things I frequently hear from B2B field/sales organizations:

Across the aisle on the development side, I hear:

One side’s solutions are the other side’s problems.

Approaches That I Have Not Found Helpful:

[A] Asking exec teams to collectively prioritize long lists of things

It’s understandable that product leaders throw up their hands in frustration, and want to give the prioritization problem back to the rest of the exec team. It seems simpler to bring a list of 32 (or 57 or 133) requests into the weekly E-Staff meeting and let the group vote. IMHO reasons why this doesn’t work:

Eventually, the CEO gives up… and decides that we’ll choose projects with the highest current-quarter-revenue ROI. Sales gets to pick, and we go another quarter without addressing fragile systems or architectural debt or instrumentation or product sprawl.

[B] Lectures about algorithms, development processes, and staffing shortages

As product leaders, we can fall into explaining philosophies or frameworks. “That’s not how agile works.” “Let me walk you through my roadmapping algorithm.” “Hiring great engineers is hard.” “This didn’t get a RICE score above 162.” Go-to-market-side folks find this infuriating. They don’t care about ticketing systems or sprint lengths or test harnesses or hiring challenges. What they (correctly) hear is that they won’t get what they need.

Especially if they’re used to IT Services organizations that do exactly (and only) what’s been spec’d by business stakeholders, they interpret this as unwillingness: Which means that pushing product/engineering harder will get us to YES. Inspecting every developer’s to-do list will uncover massive waste. Finding one-time project money for outside contractors is a solution. Prioritization means we get most of what we need.

[C] Expecting spreadsheets to prioritize for us

Technologists have an unstated but deeply held belief that better algorithms will solve prioritization issues. More columns, better weightings, finer-grained estimates. Displaying 8 significant digits instead of 2.

But the error bars on our guesstimates are huge. We squint for differences between 4.10835 and 4.10977 when both are +/- 3. I find that numeric sorts are handy for choosing 12 candidates for my 6 open slots — so that we can ignore items 13 through 972 — but less handy for deciding #1 vs #2 vs #3. Engineering estimates are notoriously inaccurate/optimistic, and revenue estimates are worse. Our semi-arbitrary inputs don’t improve much with ever-deeper analysis.

And items in our backlogs have different criteria/units. Creating revenue estimates for usability or validation experiments or dashboards is mostly IMO wasted effort. (Can we really estimate churn reduction from fixing this data export feature? How much incremental sales from a smoother login process?) So forcing everything into one stack-ranked computation isn’t effective.

Some Approaches That I’ve Found Helpful

Each of these helps share the pain of hard choices across the organization, rather than bashing Product for unilaterally making unpopular choices.

[1] Set an explicit top-down allocation of effort across a few broad categories

Technical investments come in a few broad categories, so it’s useful to make some strategic allocation decisions before sorting individual tickets.

Separating new features and customer initiatives from infrastructure and -ilities lets us compare similar items with similar objectives. It reduces our tendency to apply a simple “current quarter revenue-only ROI” metric to a complex mix of short-term and long-term investments. [See Product Spending or Sales-Led Roadmaps.]
Then we can ask more nuanced questions like “which 2 of these 8 short-term revenue proposals are likely to deliver the best short-term ROI?” separate from “how will we scale up our platform for 6x volume next year?” separate from “have we done enough validation and discovery to confidently bet on International market expansion?”

And a top-level allocation keeps us from zeroing out any category. We can have heated arguments about revenue boosters relative to each other without accidentally defunding the entire infrastructure budget. IMO, shifting 100% to any single slice is a going-out-of-business approach.

[2] Push every exec-level stakeholder to provide a very short, fully ordered list of their group’s needs

There’s a tendency for execs to cascade down prioritization requests, then merge all responses into a huge set of requests (e.g. top 10 things from NorthEast Sales, top 8 each from SouthEast, 13 from LatinAm Sales and AsiaPac, a dozen from the Alliances team… ). But product leaders with support from the CEO can limit each exec to 3 or 4 things rather than 25 or 38 or 92 items. And these must be absolutely force-ranked: only a single #1 priority and a single #2. That lets product/engineering share the pain of real-world scarcity with the selling side of the house.

It also gives much better visibility to those top items. If the head of Customer Success can whittle down that group’s most critical needs to 3, we can discuss that short list in depth. Product/engineering can rough-size 3 projects and match them against strategic objectives. Marketing and Sales may have strong support for one versus another. We can all read 3 product briefs outlining what would be in/out of an implementation. As an executive team, we can start to make hard choices. A manageable set of options lets us understand them.

[3] Briefly recap top 3–4 products or projects every week

When I get a great new idea, it tends to push everything else out of my head. Similarly, I see organizations constantly proposing new initiatives or opportunities — without remembering what’s already underway. Call it “roadmap amnesia.”

Our excitement and optimism around this minute’s hot new topic reinforces our AND assumption: this would be great, so there must be room for it somewhere. Let’s get started right away! Here’s draft copy for the product announcement and a few slides to show our best customers…

Quickly reviewing what’s already committed and underway (every week) can be tedious or frustrating. Can’t we do more? Why does building software take so much longer than I want it to? Delayed again? But it repeatedly frames the right issue: here is what we thought our absolute priorities were last week. [See The Software Deli Counter] Has something changed? There’s no excess time or talent, so we have to pair adds with deletes.

[4] Use Now/Next/Never to frame upcoming choices

It’s not expensive to change our minds about what’s next in the development queue. (But very expensive to swap projects already underway.) So a Now/Next/Later/Never structure helps move the discussion from “cancel something partially finished” to “what’s next when we finish X.” Proposing what should be next gives us something real to argue about, and sets a bar for alternatives: “Is Y more valuable/urgent than Z which is currently up next?” highlights a specific trade-off (EXCLUSIVE OR instead of AND).

[5] Define in advance what kinds of work can be realistically outsourced, and actively recruit external partners

Contrary to 50 years of industry experience, it’s easy to think that we can rent short-term talent to build long-term product success. If a customer will pay us for some custom work, we can just hire a team in Buenos Aires or Riga… build from their specs, drop it into our codeline, and celebrate. Architecture, ongoing support and product strategy be damned.

But there are some situations where this can work if we think them through before our enterprise account team urgently escalates a deal to the CEO. If this is a viable product, we have work to do — and exec-level agreements to make.

But each of these takes time/money/design/engineering/thought/ongoing work. Infinitely flexible systems are unusable — or never ship. So negotiating a few dimensions for “canned” customizations or extensions is essential. Everything else goes back into our infinite backlog, likely deprioritized forever.

Note that each of these makes our trade-offs more obvious and shares some of the prioritization problem with non-product executives. We break up the problem, reduce the cognitive load, and get bits of buy-in on partial solutions.

Sound Byte

Prioritization is more than an analytical/intellectual exercise. It’s an organizational challenge with natural disagreements among stakeholders. Product leaders need to think about motivating the right kinds of participation and addressing the emotional issues that arise. Spreadsheets and models are necessary, but not sufficient.

Originally published at https://www.mironov.com on March 26, 2022.



Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store
Rich Mironov

Tech start-up veteran, smokejumper CPO/product management VP, writer, coach for product leaders, analogy wrangler, product camp founder.