Roadmapping doesn’t have to be a solitary affair for product managers. Get stakeholders involved in the action by using some of these interactive activities:
Get Sticky With It
One of the best visual product roadmap tools is something simple you probably already have at hand: sticky notes.
Find a room with a big, empty wall. Get a whole bunch of sticky notes in different colors and some bold black markers. Segment the wall into the timeline for your roadmap and the different release “buckets” along with two additional buckets (one for “The Parking Lot” and one for “Out of Scope”). Every enhancement gets a sticky; start sticking them on the wall in different buckets and let the fun begin (yes, some of us organizational nuts think of this as fun).
This is the time-honored tradition for mapping out what should get built in many organizations; it’s better than a whiteboard because nothing gets accidentally erased (just make sure you don’t get Chickenscratch Charlie to do the writing). Here are a couple of wrinkles you can add to get some new perspectives and insights during the process:
One at a time
Each stakeholder comes in the room and has to place each sticky note in one of the buckets (with a predetermined limit on how many sticky notes can go in each release). You’re there to answer questions, but otherwise it’s all up to the stakeholder to make their decisions and tradeoffs themselves. When they’re done, take a picture or otherwise document this particular arrangement (or cover it up if you have enough wall space for everyone), then remove all of the sticky notes and let the next stakeholder have a turn.
After everyone’s had their turn, you’ll have a number of individual opinions on what’s most important. Find the areas of consensus and then probe the outliers.
At Gov.UK, the team had three strategic goals from their business plan that they were trying to achieve, and they wanted to ensure their product roadmap adequately reflected all of them relatively evenly. So, as they would tape up each potential enhancement into “Now,” “Next,” or “Later” buckets, they used a tape color that matched which strategic goal that feature supported.
“A quick glance at the coloured tape on the wall reveals the spread of features in support of each goal, and how that changes over time,” says Gov.UK’s Neil Williams. “And while teams take the lead on identifying priorities within their missions, the coloured tape also acts as a constraint to make sure features always relate back to business goals (if it doesn’t support a goal, there’s no tape to stick it up with!)”
Ranking and rating is a tried and true roadmapping tactic. Here are a couple of different spins you can put on it:
Only Rate The Product Features You Know
When your roadmapping process includes a ratings session where all of the stakeholders decide how important or how hard something is by assigning a numerical value, you are throwing out the individual expertise each person brings to the table and instead turning your process into a popularity contest.
While engineers might have great opinions on how marketable a feature is or a sales exec could understand how difficult an enhancement might be to support, there’s no reason to ask their opinions about these subjects. Instead, let everyone simply rank each item based on their own part of the process.
“The benefit of this blind rating, done only in one’s area of focus, is that no one is influenced by the others’ numbers. Groupthink becomes negligible, and features which might otherwise overlap on a feature/value matrix begin to come into stark contrast with one another,” says Andy Parsons, founder and CTO of KONTOR. “When we reassembled to look at the features and their ratings as a group, it was clear something remarkable was happening. We’d cleared away all the extraneous debate and laid bare the priorities our collective brain deemed most critical to work on.”
Put Some Money on It
There is only so much a team can accomplish during any period — time is money. At Pandora, CTO Tom Conrad turned to Monopoly money to help stakeholders really put the focus on getting the most bang for their buck with each cycle.
Each person in the prioritization process would get $5 for each available block of a developer’s time. They would then allocate their funds to the projects they valued the most. Having limited “dollars” to devote to the host of possible enhancements made them really focus on what was most important.
At Pandora, CTO Tom Conrad turned to Monopoly money to help stakeholders really put the focus on getting the most bang for their buck with each cycle.
“This is incredible, because someone very smart at one point thought, ‘We would be absolutely stupid not to do this thing.’ But really, when viewed in context of all the opportunities for the business, half of the things people thought were important immediately fall away,” says Conrad. “You get into this collaborative consolidation, re-scoping with a little bit of horse-trading.”
Product management consultant Steve Johnson often employs the same trick, only using jelly beans instead of faux dollars. “Ideally you want to create a prioritization scheme that makes sense to both colleagues and customers, and one that doesn’t rely on too much technology.”
Give It the Silent Treatment
Roadmap meetings can devolve into endless debates about the importance of feature X vs. feature Y or how many scrum points a certain initiative will take. Eliminating ALL talking (from at least part of the meetings) can avoid these rathole discourses and get you that much closer to actually setting priorities.
Before the roadmap meeting starts, write each item on a flash card, then tell the group to (without talking) arrange the cards into three piles (large, medium, small) based on the effort required to finish them.
“They should do this without talking unless they have questions about what something is. They might react to this ‘silence’ thing with doubt—just tell them to trust you here. Allow any member of the group to override someone else’s decision by moving a card,” says Aaron Schildkrout, co-CEO of HowAboutWe.com. “If they move a card that someone else placed, they should put a yellow sticker on the card. That’s a card which is in contention. It’s fine—in fact, it’s good… The primary goal of this step is to get everyone familiar with all the options and to set yourselves up for the next step.”
This process can also be performed (or repeated) to prioritize features. The key is that you’re able to reach a partial consensus without a ton of unnecessary discussion and the conversation can focus on the actual disputes between members of the group.
The key is that you’re able to reach a partial consensus without a ton of unnecessary discussion and the conversation.
“Be sure everyone understands that the priority order listed won’t necessarily be the priority order in which things are actually built (given the complexity of product development timelines),” Schildkrout continues, “but will only act as a guide to basic priorities.”
Make It a Bigger Party
If you feel like the core team is getting stale or you just want to get a broader set of opinions, you can always include more people in the process.
“The old model of strategy as an exclusive club where senior managers only are invited is dead,” says Rick Freedman, author of The IT Consultant. “The core values of agile teach us that innovation requires collaboration and self-direction; this doesn’t apply only at the tactical, methodological level but at the vision and strategy level as well. Invite the IT teams, the developers, the rank-and-file business ‘do-ers’ to the table, and develop strategies that actually resonate team-wide and have enthusiasm and commitment behind them.”
Get Users Involved
While users shouldn’t be setting your company goals, they can play a role in helping form your roadmap. There are multiple ways to incorporate user feedback into roadmap meetings.
If you have a large enough and dedicated enough base of user, leverage their real-world expertise in the roadmapping process. By holding a roadmap planning meeting with a user group (or inviting a user group to one of your meetings), you are going to get a whole new perspective on what’s important to the people who actually use your product.
“User group feedback is not arbitrary; you have to be willing to take at least some of it on board,” says Hans Constandt, CEO of DISQOVER, who also emphasized that you shouldn’t be blind-sided by their input. “Make sure you already have a good understanding of the concerns of your users. If you’re completely surprised by some of the suggestions, than you haven’t been in touch with your users well enough. The outcome should not be a complete overhaul of your product, but rather incremental updates.”
Make Your Product Roadmap Public
While it would be unruly chaos to open up your actual meetings to the public, you can still incorporate a far broader array of opinions into your process by posting your roadmap documents in public forums.
“It’s accessible to the public, it’s laid out in a simple way that the public can follow,” says Garry Newman of Facepunch Studios. “This means that we can communicate directly with our community – they can see exactly what we’re doing. Each issue or feature is kind of like a mini blog.”
Seeing how the masses react to each iteration can inform the next meeting and prompt discussions driven by user/customer input.
Once a feature is implemented, your team’s work isn’t done, as it now must be supported, maintained, upgraded and considered whenever you build anything else. In short, every feature is a burden.
Of course, human nature is to assume that once something is built it’s there forever, but the savvy product manager knows that all you’re doing by keeping every feature around forever is limiting innovation by siphoning off more resources to support the old stuff (we recently published an article on balancing innovation with technical debt that addresses this issue). So turn your roadmapping on its head with some “anti-roadmapping” and make your meeting all about deciding what you should be removing from your roadmap.
“The goal of this exercise is to identify features that are used by a small fraction of users and aren’t critical for those users,” says Harshjit Sethi, who employed this tactic during his time at Dropbox. “This exercise was eye-opening the first time I did it. From the conversations that followed, I learned that having a list of features on the chopping block often tees up a more thoughtful, opinionated and broader discussion on how a product should evolve than a typical product roadmap.”
“Turn your roadmapping on its head with some ‘anti-roadmapping’ and make your meeting all about deciding what you should be removing from your roadmap.”
Of course, it would be hard to employ all of these activities at every roadmapping meeting, so experiment with the ones that might fit. If too many end up working to use each cycle, create a rotation to keep things fresh.