The back story
In 2019, we had wrapped up a massive project that was rolled out in 10 phases over 12 months and our product team was facing the major question of, “What’s next??”
Of course, we had endless logs of ideas and requests for what could be next, clear company priorities for what should be next, and new client needs arising every day… but, really, what would actually be next?
After a full year of being almost singularly focused, we ended up in a totally different place than where we had started: our team had doubled in size, more than half of us hadn’t worked under any other system, and across all teams, we were used to knowing the answer to “When can we tackle XXX?” was undoubtedly, “After August!”.
We had produced a shiny new version of our platform, but we had lost some of our gumption and good practices of proposing our ideas and thinking about better solutions.
Following a clear process for such a long time made for a huge shock when we went from months and months of working like a well oiled machine, to staring into the great blank abyss of the future! We needed a plan, and fast.
At the time we were closing Q3 and drafting all of our ambitious goals for the end of the year. We knew we had to organize ourselves to get shit done, and more importantly, get it done in the right order.
Oh, and small detail, neither I, nor anyone else on the team, had ever created a Product Roadmap before. I’m not a product manager by training, and like every startup ever we’re always learning on the go over here.
So here’s what I wanted to accomplish with the Product Roadmap
A crystal clear, totally prioritized list of product projects that the entire team helped to create, that anyone could reference and understand, and that was aligned with our company OKRs. (Objective Key Results, a system used by Google and tons of other companies to measure success.)
Why these things, though?
- Clarity: at Bridge everyone (whether from sales, marketing, tech, or operations) depends on our product in some way or another to do their jobs. The roadmap needed to be totally clear and easily understandable so that anyone could see exactly what would be done before the end of the year.
- Prioritization: like at most startups, every day we face the challenge of balancing unlimited needs and limited resources. We’re constantly talking about priorities, considering importance vs. urgency, and seeing how our time is best spent. But how do you apply that to a list of hundreds of detailed requests? We needed the true priorities of the big picture projects in order to act.
- Transparency and Collaboration: at Bridge we use a TEAL management system for transparency in the entire team and shared decision making power. We seek advice, avoid making unilateral decisions without input from others, and ensure buy-in before moving forward. I wanted the process to be collaborative because of this, but also so that everyone understood the needs of the entire company and not just their own teams.
- Alignment: for about a year now we’ve been wrestling with Objective Key Results and finding the best formula for how it applies to us. This quarter we’ve finally ( ??) arrived at OKRs that help us to organize around company goals and not get stuck in siloed team objectives, so also having the product plan in sync with these OKRs was essential.
Alright, great. Now how did I make it actually happen? Here’s the full debrief in 7 steps.
(Buckle up, we’re gonna get into the nitty gritty here…)
Step 1: Choose the tool
Time and resources were tight so learning about, setting up, and paying for a fancy Product Roadmap software wasn’t an option this time. I decided to rely on our good friend, Trello.
We use Trello for tons of things from onboarding, to weekly sprints, to project planning. Why not transform it into our product roadmap tool? Our team knows it and we could use labels, lists, and cards to deal with categories, priorities, and moving projects as they got done. Added bonus, it could even be made public for our users to see, if we wanted to!
Step 2: Clean the backlog
I spent 2ish hours digging into the loooong backlog of requests, fixes, and ideas that we had accumulated. This wasn’t glamorous work, but it was really needed to weed through the things that were too granular. Here, I made some executive decisions about things that would be left out.
I started to (1) label what I saw into categories we could work with to be our ‘north stars’ in the big picture of our roadmap, and (2) grouped them under drafted priorities levels:
- Urgent
- Really needed
- Needed
- Needed/wanted
- Wanted
- Nice to have (actually, these cards didn’t even make the cut)
Step 3: Sync-Up
Before digging in deep with each team, I used 20 minutes of one of our alignment meetings (a weekly meeting where one representative from each team attends) to agree at a high level about the “must have” projects and dividing them into priority levels. It’s key here that these were just 20-30 broad themes and not the detailed tasks.
Step 4: Choose and prep the format for the Product Roadmap
Step 4: Choose and prep the format for the Product RoadmapThis part didn’t have much science to it – I relied heavily on common sense and past experiences. I’m a fan of design thinking style workshops, but only so far as they actually contribute to the goal.
In this case, there were a few key factors that made me choose this style: I wanted the process to be fun, engaging, and collaborative; there were hundreds of requests to sort through and bring priority to; the requests had been proposed by the exact teams I was trying to involve, so they had an interest in their requests, but not much awareness of the others they didn’t propose.
Organization
In the end I brought the whole process offline – for context, we do almost all of our work online with ? of our team working remotely – into interactive workshops per team. (Aside: a strong argument could be made for doing the workshop together as one entire team, but I chose to divide into smaller groups for two reasons.
First, because we were at a point where we actually needed basic alignment even within our teams let alone across teams. Second, because I needed to hear detailed discussions about the priorities per team, and this would have been really difficult, if not impossible, with 10 people in the room and 6 online.)
Method
I converted the online lists into squares of paper, each one with a task written on it. (Again, a bit of a time commitment, but it was worth it!) Let’s say we ended with 75 paper squares categorized into the five groups pictured above. Each of the groups were color coded and laid out on tables. Then, per group, each person in the room got a marker and responded (silently!) to the following:
- If we could only do five things before the end of the year, which ones would they be? Vote to keep a task by marking the paper with a dot.
- Which two things do you not care at all about right now? Vote to eliminate a task by marking the paper with an X.
Then every paper was separated into groups:
- Tasks with dots
- Tasks with Xs
- Unmarked tasks
From there the team had to agree on and order every single task into a true priority list from 1-75.
Why this way?
- Forced prioritization: The point was never that we would follow the exact priority order that the teams determined (and I stated it at the top of each workshop)… but I wanted to force decision making and discussion, get everyone to see the full picture of what was “on the table” (figuratively, turned literally), and hear for myself the deeper perspectives of each person on why something seemed important to them or not.
- Voting for tasks without speaking: this is a typical design thinking strategy to make sure everyone has a voice and to visualize people’s opinions. It shows raw opinions, maps the ‘distance’ between the people in the room, and brings unpopular items (that might not have otherwise gotten attention) to the conversation.
- Sorting marked tasks into groups: this can be done any way you want, I just broke it down like this to facilitate the prioritization and go by chunks. We didn’t follow this strictly, but it was helpful to discuss, say, “cards that have 3, 4, 5 dots on them” in one group and prioritize those and then move on to the next level. (Note: there were times when a card that only had one or two dots got bumped up to the top in the discussion round, so this shouldn’t be followed strictly – it has to be considered in context.)
- Marking tasks that aren’t important: this is key for eliminating things that shouldn’t be “on the table” and it actually brought key discussions forward when a task had a dot and an X.
Step 5: Run the Product Roadmap workshops!
Following the method above I did three workshops (~1 to 2 hours each, depending on the size of the team). We did one of them following the same format, but online with a digital whiteboard.
Each time, I started with an intro to the idea, the context, and explained how it would work. As we went, I had to do a few things to nudge us forward. Things like getting clear agreement about priorities 1, 2 and 3, and then removing them from the table completely in order to move on quickly.
At some points I would separate a group of cards and ask “Of these six, what’s the priority order? Why?” Then after it was answered, ask “Is there anything else on the table that is at a similar priority level as these?” All of this was very free flow – do what works for you and your team.
The point is, you have to do small things to force decisions, but should also allow for “breaking the rules”. It doesn’t always work out that a card that had the most votes is the most important, or that a card that had no votes is less important than one that had two votes.
Another important part is visibility of the cards, so we needed a fair amount of space in order to see the order and keep challenging it. However, at some point, once we could see a clear break-off point of “these cards are more important than those ones” I would “close” the ones that were already prioritized to keep the focus and move forward. Sometimes a few new tasks were brought to the table that we hadn’t been considering. Anytime this happened, we made a new card and brought it into the mix.
“You have to do small things to force decisions, but should also allow for “breaking the rules””
Step 6: Turn the results into an actual Product roadmap
So, again, a bit of work on my part, but after the workshops I had to take the learnings to our actual Product Roadmap. I already had all of the cards on the board in a proposed order, but the learnings from the workshops really turned some things around.
For starters, I ended with new guiding categories that were totally aligned with our company OKRs: convert, engage, automate, reduce support, close paths, and improve customer experience.
Each card had to be labelled according to the OKR category it touched. Then I used the teams’ inputs, these new labels, and some other more technical cost considerations to come up with a new detailed Product Roadmap that looked a bit like this:
I also translated this detailed roadmap into a much cleaner, time bound Product Roadmap to help the broader team see the big picture and to be able to bring the Product team’s focus back to the guiding needs rather than only seeing the step by step details.
Step 7.0: Present to the team, Finalize, Celebrate, and Start using it ?
All four parts of this actually matter: once the roadmap is ready, you’ll want to present it to the team for final adjustments. But the process doesn’t end here. After learning about the Dragon Dreaming methodology, our team recognized that we’re so busy doing, we don’t stop to celebrate enough. So this time we made sure to acknowledge all the hard work we put into this Product Roadmap, and celebrated with a round of applause during our weekly general meeting.
As for “start using it”… we consider our roadmap a living tool that can and should change. Even though it’s not static, having the basic structure set and all the teams engaged in its creation has been fundamental to how we do things.
When setting our weekly product and tech sprint work, we pull directly from this list and the deep learnings behind it. A month and a half later, the board has a DONE and DOING column and the URGENT column is totally cleared. We’ve added about 5 cards since the initial meetings and we slightly readjust the priorities every week, especially based on customer feedback and user needs.
So, what do I think in retrospect?
Even though it was a time commitment across teams, it was worth the effort. I experimented with this concept of forced prioritization and now I’m a big believer in its value: it made us think critically from different perspectives, pushed us to discuss the “importance” of tasks and the complex factors that play into this, and helped us achieve collaborative decision making.
Everyone better understood the company’s needs as a whole and not just their own. One of the best things to come from building the roadmap this way is that we broke the wall between people blindly submitting requests and actually understanding the bigger puzzle of product work.
