Reframing Backlogs and Roadmaps for Good
Heavy backlogs and onerous roadmaps have long been a weight that product managers have had to bear. Ask any product manager what they do with their time, and many will tell you about the hours they spend managing one or both of these artifacts. Problem is, there’s no inherent value in the backlog or the roadmap. They are just tools that may or may not be helping you get where you need to be as a product manager, which is, ideally, understanding the problems your customers face, and discovering ways to solve those problems in a way that’s beneficial to your business.
Backlogs and roadmaps are filled with traps and tensions. If done badly, they hold back good product teams and cloud judgment. I’ve seen product people spend more time shuffling things around their backlog or beautifying their product roadmap than talking to customers or diving into the problems they could be solving.
I can see why there’s often a reaction to fully ditch roadmaps and backlogs. This is the stance that the folks at Basecamp take, and Marty Cagan as well. But these approaches leave something to be desired, too. It leaves a hole where a reframed roadmap and backlog approach would help.
The ShapeUp methodology from Basecamp argues for no product roadmap. This is because a roadmap comes with expectations and we live in a world of uncertainty. Instead, it suggests that you have a ‘portfolio of options’, with no promises, no list of things that will be done. I think ‘portfolio of options’ is a fine name for this, and the approach is sound.
Reframing product roadmaps
It’s very much in line with the lean roadmap format we developed here at ProdPad. Like the ShapeUp method, a lean roadmap isn’t a list of things to do, or promises being made. It’s what you would call a ‘prototype for your strategy’.
When you first conjure up an idea for a new feature or interface, you don’t run straight to dev with a finished design. You start with a prototype. Perhaps even just some scribbles on a napkin or sheet of paper that you show to a customer or a teammate for feedback. You get feedback that your scribbled interface could be flipped like this or like that, or perhaps it needs some copy there. You throw out the piece of paper and start again, making a slightly better iteration of the same interface, based on the feedback you got. The value wasn’t in the paper, after all… the value was in the conversation that having the paper prototype enabled.
Likewise, your roadmap itself isn’t of value, and you should expect it to be thrown out and iterated upon. The value is in the conversations you can have around it, once you use it to outline your assumptions.
A roadmap is a place where you jot down your assumptions about problems, challenges, and opportunities that your business might face, and is used as a starting point for a conversation with others in your team. If you outline one version of your roadmap and share it with a colleague, and it turns out that they had a very different idea of what direction the product was going in, then it’s very good you had that conversation now and not months later.
By collectively sharing assumptions about the strategic steps your product will take, and checking those with your team and customers, you’re able to create a more robust version of your strategy…. just as iterating many times on a paper prototype and getting lots of feedback will land you with a better design over time.
Prioritizing at the problem level is powerful. Having a lean roadmap means you can identify problems long before they disrupt your business, and helps you wield your company’s resources and time to your advantage.
Your roadmap shouldn’t try to be a detailed plan capturing every last movement. It should be scrappy and flexible and linked to outcomes you want to see and experiments you might try, and be ready to be bashed apart as you learn more about the space you’re in.
The value isn’t in the product roadmap itself. The value is in the roadmapping.
That doesn’t mean not having a roadmap.
The danger in saying ‘No Roadmap’ is that I’ve seen teams take this literally, and actually operate without a roadmap of any sort. No way of laying out their options or checking their assumptions. No valuable conversations about whether they agree on the direction of the business. This leads to teams getting led by the noise in their backlog, prioritizing whatever seems easy, convenient, or important at the time, but never actually taking a step back to prioritize at the problem level as you would on a roadmap.
Reframing the roadmap is a powerful move, and it benefits the product manager. When we first launched our lean roadmap, we weren’t sure if we could or should still call it a ‘roadmap’. After all, it didn’t look like any of the roadmaps we’d ever seen before.
However, we stuck with it, and we realized something interesting: product people loved it because it was called a roadmap. A legitimate online tool allowed them to build a ‘roadmap’ that, for the first time, didn’t hold them back from focusing on the important parts of their product management job. They’re still doing a ‘roadmap’ like their boss had asked them to, it was just reframed into something more useful. They weren’t forced into an uncomfortable situation where they had to make the case for giving a hard NO to a roadmap.
Years on, the lean Now-Next-Later format of the roadmap is so ubiquitous it’s generally accepted by bosses as a legitimate roadmap format with no qualms.
Reframing product backlogs
We’ve done something similar with backlogs. This article started because of Jason Fried’s ‘NO backlogs’ comment on Twitter, and again, I get where he’s coming from, but we take a different approach.
Most backlogs suck. When you think of a backlog, you think of a vertigo-inducing pile of tickets that’ll never get finished, most of which aren’t even good ideas, living under a bridge in Jira.
Where ShapeUp says NO backlogs, we reframe it: Split your backlog
Jira, for example, isn’t an inherently bad tool. It’s just used for the wrong things. It’s been leaned upon to hold our every wish and story for the product, and it becomes this black hole where innovation goes to die. There’s a reason why every product manager I know hates Jira. But Jira’s actually fine if it’s used for what it’s meant for: managing a list of development tasks to be tackled. It’s a development project task tracker. Everything in Jira should be approved, ready to go, and have enough detail that any developer can pick up a ticket and start working on it. Nothing should be in Jira if it’s not a task to be done. This is your development backlog.
Your developers can decide for themselves how they work through this. Scrum. Kanban. Scrumban. Whatever. Ideally, short iterations so they don’t disappear on you for months on end, but otherwise, they can be pretty self-led in this space.
What about everything else? All the ideas, bets, experiments, etc. that haven’t been prioritized or spec’d. We call this the product backlog or idea backlog. Marty Cagan coined the phrase opportunity backlog. This is a space for understanding all of the opportunities, potential solutions, and their connection to the problems that the business faces. And that’s a really key point. The point of this backlog isn’t to prioritize at the individual idea level. There is no stack ranking or weighted score algorithm in the world that will tell you in what order you should build that list of things you’ve collectively thought up. One of the biggest mistakes that we see happen is trying to treat the product backlog like a simple list that can be prioritized.
Instead, the roadmap is used to prioritize the problem level. Ideas surfaced to connect those problems as ways they might solve each.
The ShapeUp way suggests that if your ‘bet’ or idea doesn’t make it into the development cycle it’s up to the person who suggested it to hold on to it and present it again if it’s worth it in the future. This is where their no backlog concept comes from, but it’s ‘no backlog’. It’s just a bunch of other people’s backlogs instead. It assumes that individuals have a way to keep tabs on bets they want to bring back to the table. Therefore, managing this personal backlog of ideas efficiently. They are removing the responsibility of the team to manage the backlog and putting it on the individual… with mixed results as some people will be able to organize better than others. Everyone will have their own system for how they keep tabs on the bets/ideas they have for the business.
This format of bringing pitches to the table also gives undue power to the loudest in the room. The concept of a meeting at a table where people pitch their bets and the strongest pitch wins lends itself to HiPPOs running the show. As they say in the ShapeUp book, “the betting table gives the C-suite a “hands on the wheel” feeling” – which might be magic in the right company with a certain make-up of leaders, but could easily lead to hard times in many others. After all, many product teams already struggle with wrestling control over product from well-meaning but often clueless C-suite and founders. The betting table runs the risk of excluding those who might feel shy or unempowered to speak up for their ideas versus their colleagues in a somewhat stressful environment. This is not an environment where the best product ideas are surfaced and is a diversity and inclusion nightmare.
The ProdPad way is to have a collaborative, helpful backlog that’s transparent to the team. Why is this so powerful?
Anyone in the team can add to the backlog, and see what else is in the backlog. Everyone’s voice is heard and innovation isn’t limited to those who have seats at the table. They can also see the backlog drivers. What are the top priority problems and objectives? Which ideas are most important to customers right now? Where have previous ideas ended up, and what makes for a successful idea?
This helps people in the team understand where ideas come from, and very importantly, where their ideas end up. It helps them build trust in the product management process, which was previously a black hole. They can see how and why certain ideas make it through to production and others don’t. It helps to demystify the product management process and allows the team to create and share a process by which problems are prioritized and ideas are selected to match.
This is not your old-school backlog where things go to die. Combined with the fact that it’s collaborative and transparent by nature, the ProdPad backlog also has a ton of helpers built in to help the product team decipher what’s in the backlog, and quickly pinpoint great opportunities that will solve the right problems.
Automatic matching of customer problems to potential solutions
ProdPad’s unique DotBot automatically spots ideas that might solve customer problems, or customer problems that might be related to ideas, and flags them up so the product team can join the dots. It’ll also catch your duplicates and help you link and merge similar ideas so your backlog never gets too hairy.
Spot opportunities with the priority chart
Backlogs can be overwhelming, but ProdPad’s priority chart lays it out and makes it easy to spot the best opportunities. Want to see your quick wins? Or spot ideas that might make you money or get you user growth? See your ideas on this unique priority chart and use the filters to quickly dig in where you need to.
Track opportunities in your backlog workflow view
Know what happens before, during, and after development, with the workflow view. Leave Jira (or Trello, or GitHub, or whichever development tool you want to integrate with) to do its thing, which is managing your development tasks, and ProdPad will be your window into development and across the entire product lifecycle.
Prioritize at the problem level, linked to OKRs on the roadmap
You won’t find weighted scoring algorithms or stack ranking in ProdPad. Why? Because they don’t work and they are doing your backlog a disservice. It is a source of knowledge to draw from when the time comes to solve problems. And it’s at the roadmap level that you outline and prioritize those problems. Roadmap initiatives in ProdPad are connected to Objectives and specific trackable Key Results, and are connected to the ideas (or what I like to think of as experiments) you’ll try in order to solve each problem.
All in all, the ProdPad way works really nicely with the approach that ShapeUp presents. Both come from the same place of rejecting heavy, onerous backlogs and roadmaps in exchange for something new. The key differences come down to semantics and how each approach positions the alternative.
As shown by this happy ProdPad customer, ProdPad can play a key role in helping your team take advantage of the best of the ShapeUp approach:
What about you? Are you team NO backlogs and roadmaps, team reframed backlogs and roadmaps, or something else altogether? Let us know in the comments 👇
Definitely, Lean Roadmaps rocks! And Discovery Backlogs are very useful to put and track activities between the Roadmap and the Delivery Backlog.
It’s kind of close to the Dual-Track Agile approach I think.
Hey Gabriel, you’re absolutely right! This way of working is ideal with teams who have some sort of dual-track agile approach 🤘