How I Built a Product Roadmap from Scratch - with little time and $0 budget
A few months ago at Bridge for Billions we wrapped up a massive project that was rolled out in 10 phases over 12 months and our product team was faced with 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 so used to knowing the answer to “When can we tackle XXX?” was undoubtedly, “After August!!!”.
“We had a produced 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.”
We were following a clear process for such a long time that it was a huge shock to go 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 facing the end of Q3 and 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 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 — a post on our journey to adopting the system is coming soon).
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. We live and breathe prioritization — out of necessity — but how do you apply that to a list of hundreds of requests? We needed the true priorities of each and every project (and sub-project!) compared to one another in order to act.
- Transparency and Collaboration: we use a TEAL management system that embraces transparency for 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.
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 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 was used to it, it has labels, lists, and cards to deal with categories, and cards could be moved as they got done. And, 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 over the year prior. This wasn’t glamorous work, but it was needed to get started and make sure we were covering our bases.
Here, I made some executive decisions about things that would be left out. For example:
And started to label what I saw into categories we could work with:
And grouped them under drafted priorities levels:
→ URGENT
→ REALLY NEEDED
→ NEEDED
→ NEEDED/WANTED
→ WANTED
→ NICE TO HAVE (actually, these cards were just eliminated)
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 and work that would come next.
Step 4: Choose and prep the format
This 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 lean toward this style: I wanted the process to be fun, engaging, and collaborative; I had hundreds of requests to sort through and bring priority to; those 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.
Organization
In the end I brought the whole process offline into interactive workshops per team — normally, we do almost all of our work online with ⅓ of our team working remotely.
(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. And second, because we needed to get into detailed discussions about the priorities 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, color coded by the give categories mentioned above. (Again, a bit of a time commitment, but it was worth it!) Say we ended with 75 paper squares separated into the five categories. The cards from each category were laid out on tables. Then, per category, each person in the room would get 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 if they don’t get done? Vote to eliminate a task by marking the paper with an X.
Then every paper would be separated into groups:
→ tasks with dots
→ tasks with Xs
→ tasks with nothing
From there the team would have 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 they determined (and this was stated at the top of each workshop). But I wanted to push decision making and discussion, get everyone to really see the full picture of everything that was “on the table” (figuratively, turned literally), and hear for myself the deeper perspectives of each person on why something seemed important or not.
- Voting for tasks without speaking: this is a typical design thinking strategy to make sure everyone has a voice and to visualize opinions. I like starting this way because it shows raw opinions, maps the ‘distance’ between the people in the room, and brings unpopular items to the conversation that might not have otherwise gotten attention.
- Marking tasks that aren’t important: this is key for eliminating things that shouldn’t be “on the table” and it actually brought some important discussion when a task had both a dot and an X.
- Sorting marked tasks into groups: it can be done however 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 on it was bumped up to the top in the discussion round, so this shouldn’t be treated like a rule — it has to be considered in context.)
Step 5: Run the 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 what we were trying to do, the context, and explained how it would work. As we went, I had to do a few things to nudge the group forward. Things like getting clear agreement about priorities 1, 2 and 3, and then removing them from the table completely.
At some points I would separate a group of cards our 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?” This part was very free flow and depended a lot on context.
What I mean 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.
Another key part was 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 keep moving.
You have to do small things to force decisions, but should also allow for “breaking the rules”.
Another thing that happened is that a few new tasks were brought up that we hadn’t been considering. Anytime this happened, we made a new card and put it into the mix.
Step 6: Turn the results into an actual roadmap
So, again, a bit of work on my part, but after the workshops I had to take the learnings to our actual roadmap. If you remember, I already had all of the cards on the Trello board in a proposed order, but the learnings from the workshops really turned some things around. (Which was the point!)
For starters, I ended with new categories that were totally aligned with our company OKRs:
→ convert
→ engage
→ automate
→ reduce support
→ close paths
→ improve CX (customer experience)
Each card had to be labeled according to the OKR category it touched on. To come up with a newly prioritized roadmap I used the teams’ inputs, the OKR labels which themselves which gave priority levels, and some other more technical cost considerations to create this:
Step 7.0: Present, 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 even put into this roadmap, and celebrate with a round of applause during our weekly general meeting — And decided to write this post ;)
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’re pulling directly from this list. 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.
What do I think in retrospect?
Even though it was a time commitment across teams, it was totally worth the effort. I was experimenting 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 “importance” of tasks and the complex factors that play into this, and helped us achieve collaborative decision making.
After the workshops everyone better understood the company’s needs as a whole and not just their own. They were also able to see clearly why their requests or needs fell where they fell. One of the best things that came 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.
