Product managers have to balance the demands of many stakeholder domains. The most important are the customers and prospects, of course. While direct interviews with them are the best input to roadmapping and prioritization, very often we have to rely on departments like sales, marketing, professional services, and support to be proxies for the market. I hit upon this technique and found it not only to be a good way to gather input for prioritization, but also to make a broad array of people feel truly involved in product development. And, to my surprise, it resulted in a newfound consensus across functional areas.
Six Stakeholders
Your general manager
A take charge kinda guy… knows what he wants, knows how to get it.
- This week: more power to the phasers
- Next week: a gritty reboot of the series
Your VP of Client Success
Communicates most directly with existing customers. Great barometer for renewals.
- This week: bug fixes
- Next week: more bug fixes
Your VP of sales
Emotionally engaged, with his finger on the pulse of the market. Responsible for much of the food on your table.
- This week: "Bluer uniforms would demo better."
- Next week: "Y'know, a cure for Rigellian shingles—I could sell the @#$! outta that!"
Your biz dev guy
Takes a rational approach to partnerships and channel sales.
- This week: integration with Klingon Warbirds
- Next week: compatibility with whatever it is the Tholians fly
Your engineering lead
Underpromises and overdelivers (except when he doesn't).
- This week: replatforming
- Next week: replatforming
The enthusiastic PdM
At any given time, could be you or a teammate.
- This week: let's finally add video to the communicators… I mean, c'mon, this is the 23rd century already.
- Next week: just please, let's have a consistent vision.
Every one of these stakeholders is an idea factory and an important proxy for some part of your market. (Well, except maybe for the engineer… but they're vital too!)
The exercise
First off, what is stack ranking?
For those who haven't done it (or use a different name for it), stack ranking is just taking a bucket of feature requests
(or roadmap themes) and putting them in priority order. It's an extremely simple concept—but given that your dev team will only be working
on one to three things in parallel, it can be very effective for forcing perspective, cutting through recency bias,
and getting rid of feature fetishes.
What you're left with is a firm grasp of what to do next, without losing sight of lower-priority items, and that's essential for planning.
Recipe for the team exercise
The collaborative stack ranking event is also easy to understand and execute. Here's what you'll need:
1) A prepared online spreadsheet
I use Google Sheets, but you can use any spreadsheet that supports live collaboration. Have a look at my example (http://bit.ly/1qQtqks). If you are using Google Drive, you should be able to copy and paste it into a new spreadsheet. (Google may not paste in the conditional formatting so you'll have to recreate it following the example below.)
This is how I made my spreadsheet:
- Add the list of features or themes in the first column, and each participant's name in the top row.
- Add an instructional comment to the first cell.
-
Add a column for the average and another for the standard deviation, which can act as a measure of disagreement.
The formulas will look like
=median($D2:$Z2)and=STDEV($D2:$Z2)respectively. Then, hide these columns until you're ready to do the discussion. - Lock the first three columns to prevent inadvertent edits.
- Be nice and freeze the first row and first column—some people will be scrolled pretty far to the right.
-
Use conditional formatting to create a heat map effect. This will make it easy to instantly analyze the results and
know whom to call on during the discussion phase. You may want different "breakpoints", but these create a
nice bell curve:
- If your items require a little bit of clarification, you can add a comment to pop an explanation up when the cell is hovered over.
2) Around 15 items for ranking
The rankables can be individual feature requests or epics, but it's generally better to keep them roughly the same level of difficulty. If that's not feasible, or if you want to rank heterogeneous items (there are good reasons to sometimes do so), add something to the item name to indicate its scope.
I find 15 items is a nice rule-of-thumb number. Above a certain limit, entering the rankings can get confusing. But, tailor it according to your needs and the allotted time. Expect discussion time to increase geometrically with each additional item.
3) A room full of folks
There's no hard and fast rule on how to choose participants, but you definitely want to include as many functional roles as possible. In some cases, you may want to limit yours to the director- or VP-level, but for smaller companies or business units, you may be able to involve almost everyone.
Doing the exercise
Once you've got all the ingredients assembled, take a moment to review the items in your list with the group and check that everyone is clear on what they are; then, you're off to the races. There will be a little quiet time as people do their work. Once all the votes are cast, you can start an open-ended discussion. This is where your heat map comes in handy, along with the hidden average and “controversy” columns.
Scan each row and see what the background colors tell you. For instance, if one row is mostly gray (low priority) but a couple of responses are red, call individually on the dissidents and ask why. If you've got enough participants, you almost certainly won't have a total lack of controversy, and this will give you plenty to discuss.
A surprising outcome
Naturally, I expected this exercise to give me some valuable insights as well as deepen the feeling that everyone is a contributor to product priorities. But what I didn't expect was the feeling of consensus that came after. Salespeople understood the reasons underlying tech support's different perception of needs; engineers saw where the business people were coming from; marketing got a sense of what the customer success team was seeing; and so forth. Teams—especially small ones—need to pull together, and I found that even though each individual might not change how they advocate for any given roadmap item, we came away with a greater shared awareness of the myriad forces that drive a product and company.
Conclusion
It took you longer to read this than it will to prepare a collaborative stack rank session. Go ahead and try it. I think you'll find it a painless, maybe even enjoyable way to involve a wide variety of teammates in contributing to and deepening their understanding of your roadmap.