How I Built our Product Roadmap from scratch… with little time and $0 budget

Share on facebook
Share on whatsapp
Share on twitter
Share on linkedin

How do you build a product roadmap from scratch when you have little time and $0 budget? Read the testimonial of Allie, Product Manager, and get actionnable tips on how to prioritize efficiently everything in your backlog.

A few months ago 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.

  • 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 having the product plan in sync with these OKRs too 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 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, we could use labels, lists, and cards to deal with categories, priorities, and moving cards 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 really 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.

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 didn’t even make the cut and were 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 – 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. And second, because we needed to get into a detailed discussion 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. (Again, a bit of a time commitment, but it was worth it!) Say we ended with 75 paper squares categorized into the five groups I mentioned above. Each of the groups were color coded and laid out on tables. Then, per group, 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 the teams determined (and this was stated at the top of each workshop!). But I wanted to force 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 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. I like starting like this because 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 on it was 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 some key discussion when a task had a dot and an X.

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 the idea of 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 us 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.

The point is, you have to do small things to force decisions, but should also allow for “breaking the rules”. What I mean is, 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 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 breakoff 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 forward. Another thing that happened in the workshops is that 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 roadmap

So, again, a bit of work on my part, but after the workshops I had to take the learnings to our actual 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 categories that were totally aligned with our company OKRs: convert, engage, automate, reduce support, closing paths, and improve customer experience.

Each card had to be labeled according to the OKR category it touched on. Then I used the teams’ inputs, the OKR labels which themselves which have priority levels, and some other more technical cost considerations to come up with a new roadmap that looked a bit like this:

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 ajustements. But the process doesn’t end here. After learning about the Dragon Dreaming methodology, we all 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.

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.

So 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 and was 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.


Written by Allie Whitefleet, Product Manager at Bridge for Billions

Are you ready to build your own roadmap and get clarity on the next steps to kick-start your project?

Maëlle Lafond

Maëlle Lafond

Leave a Replay

About Bridge for Billions

We build entrepreneurship programs that bring together all key players to support early-stage entrepreneurs.

Recent Posts

Sign up for our Newsletter

Each month you’ll receive The Bridge, our newsletter full to the brim with the latest news from the startup world and updates from our partners!

Keep me up to date.

%d bloggers like this: