{"id":8658,"date":"2020-09-18T16:33:00","date_gmt":"2020-09-18T15:33:00","guid":{"rendered":"https:\/\/www.prodpad.com\/?p=8658"},"modified":"2025-01-13T16:26:47","modified_gmt":"2025-01-13T16:26:47","slug":"reframing-backlogs-and-roadmaps-for-good","status":"publish","type":"post","link":"https:\/\/www.prodpad.com\/blog\/reframing-backlogs-and-roadmaps-for-good\/","title":{"rendered":"Reframing Backlogs and Roadmaps for Good"},"content":{"rendered":"\n

Heavy backlogs and onerous roadmaps<\/a> 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\u2019s no inherent <\/em>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\u2019s beneficial to your business.<\/p>\n\n\n\n

Backlogs and roadmaps are filled with traps and tensions. If done badly, they hold back good product teams and cloud judgment. I\u2019ve 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.<\/p>\n\n\n\n

I can see why there\u2019s often a reaction to fully ditch <\/em>roadmaps and backlogs. This is the stance<\/a> that the folks at Basecamp take, and Marty Cagan as well<\/a>. But these approaches leave something to be desired, too. It leaves a hole where a reframed<\/em> roadmap and backlog approach would help.<\/p>\n\n\n\n

The ShapeUp methodology<\/a> 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 \u2018portfolio of options\u2019, with no promises, no list of things that will be done. I think \u2018portfolio of options\u2019 is a fine name for this, and the approach is sound.<\/p>\n\n\n\n

Reframing product roadmaps<\/h2>\n\n\n\n

It\u2019s very much in line with the lean roadmap format<\/a> we developed here at ProdPad. Like the ShapeUp method, a lean roadmap isn\u2019t a list of things to do, or promises being made. It\u2019s what you would call a \u2018prototype for your strategy<\/strong>\u2019.<\/p>\n\n\n\n

When you first conjure up an idea for a new feature or interface, you don\u2019t 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\u2019t in the paper, after all\u2026 the value was in the conversation that having the paper prototype enabled. <\/p>\n\n\n\n

Likewise, your roadmap itself isn\u2019t of value, and you should expect it to be thrown out and iterated upon. The value is in the conversations <\/em>you can have around it, once you use it to outline your assumptions.<\/p>\n\n\n\n

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\u2019s very good you had that conversation now and not months later.<\/p>\n\n\n\n

By collectively sharing assumptions about the strategic steps your product will take, and checking those with your team and customers, you\u2019re able to create a more robust version of your strategy\u2026. just as iterating many times on a paper prototype and getting lots of feedback will land you with a better design over time.<\/p>\n\n\n\n

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\u2019s resources and time to your advantage. <\/p>\n\n\n\n

\nhttps:\/\/twitter.com\/ashleymarinep\/status\/1306885083006205953\n<\/div><\/figure>\n\n\n\n

Your roadmap shouldn\u2019t 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\u2019re in.\u00a0<\/p>\n\n\n\n

The value isn\u2019t in the product roadmap itself. The value is in the roadmapping.<\/small><\/em><\/h3>\n\n\n\n

That doesn\u2019t mean not having a roadmap.<\/p>\n\n\n\n

The danger in saying \u2018No Roadmap\u2019 is that I\u2019ve 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 <\/em>level as you would on a roadmap.<\/p>\n\n\n\n

Reframing the roadmap is a powerful move, and it benefits the product manager. When we first launched our lean roadmap<\/a>, we weren\u2019t sure if we could or should still call it a \u2018roadmap\u2019. After all, it didn\u2019t look like any of the roadmaps we\u2019d ever seen before.\u00a0<\/p>\n\n\n\n

However, we stuck with it, and we realized something interesting: product people loved it because<\/em> it was called a roadmap. A legitimate online tool allowed them to build a \u2018roadmap\u2019 that, for the first time, didn\u2019t hold them back from focusing on the important parts of their product management job. They’re still doing a \u2018roadmap\u2019 like their boss had asked them to, it was just reframed into something more useful. They weren\u2019t forced into an uncomfortable situation where they had to make the case for giving a hard NO to a roadmap.\u00a0<\/p>\n\n\n\n

Years on, the lean Now-Next-Later format of the roadmap is so ubiquitous it\u2019s generally accepted by bosses as a legitimate roadmap format with no qualms.<\/p>\n\n\n\n

Reframing product backlogs<\/h2>\n\n\n\n

We\u2019ve done something similar with backlogs. This article started because of Jason Fried\u2019s \u2018NO backlogs\u2019 comment on Twitter<\/a>, and again, I get where he\u2019s coming from, but we take a different approach. <\/p>\n\n\n\n

Most backlogs suck. When you think of a backlog, you think of a vertigo-inducing pile of tickets that\u2019ll never get finished, most of which aren\u2019t even good<\/em> ideas, living under a bridge in Jira.\u00a0<\/p>\n\n\n\n

Where ShapeUp says NO backlogs<\/a>, we reframe it: Split your backlog<\/strong><\/p>\n\n\n\n

Jira, for example, isn\u2019t an inherently bad tool. It\u2019s just used for the wrong things. It\u2019s 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\u2019s a reason why every product manager I know hates Jira. But Jira\u2019s actually fine<\/em> if it\u2019s used for what it\u2019s meant for: managing a list of development tasks to be tackled. It\u2019s 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\u2019s not <\/em>a task to be done. This is your development backlog<\/strong>.\u00a0<\/p>\n\n\n\n

Your developers can decide for themselves how they work through this. Scrum. Kanban. Scrumban. Whatever. Ideally, short iterations so they don\u2019t disappear on you for months on end, but otherwise, they can be pretty self-led in this space.<\/p>\n\n\n\n

What about everything else? All the ideas, bets, experiments, etc. that haven\u2019t been prioritized or spec\u2019d. We call this the product backlog<\/strong> or idea backlog<\/strong>. Marty Cagan coined the phrase opportunity backlog<\/a>. This is a space for understanding all of the opportunities, potential solutions, and their connection to the problems that the business faces. And that\u2019s a really key point. The point of this backlog isn\u2019t to prioritize at the individual idea level. There is <\/em>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\u2019ve 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.\u00a0<\/p>\n\n\n\n

Instead, the roadmap is used to prioritize the problem level. Ideas surfaced to connect those problems as ways they might solve each.<\/p>\n\n\n\n

The ShapeUp way suggests that if your \u2018bet\u2019 or idea doesn\u2019t make it into the development cycle it\u2019s up to the person who suggested it to hold on to it and present it again if it\u2019s worth it in the future. This is where their no backlog concept comes from, but it\u2019s \u2018no backlog\u2019. It\u2019s just a bunch of other people\u2019s 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.\u00a0<\/p>\n\n\n\n

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, \u201cthe betting table gives the C-suite a \u201chands on the wheel\u201d feeling<\/em>\u201d – 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.<\/p>\n\n\n\n

The ProdPad way is to have a collaborative, helpful backlog that\u2019s transparent to the team. Why is this so powerful?<\/p>\n\n\n\n

Anyone in the team can add to the backlog, and see what else is in the backlog. Everyone\u2019s voice is heard and innovation isn\u2019t 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? <\/p>\n\n\n\n

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\u2019t. 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.<\/p>\n\n\n\n

This is not your old-school backlog where things go to die. Combined with the fact that it\u2019s collaborative and transparent by nature, the ProdPad backlog also has a ton of helpers built in to help the product team decipher what\u2019s in the backlog, and quickly pinpoint great opportunities that will solve the right problems.<\/p>\n\n\n\n

Automatic matching of customer problems to potential solutions<\/h3>\n\n\n\n

ProdPad\u2019s 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\u2019ll also catch your duplicates and help you link and merge similar ideas so your backlog never gets too hairy.<\/p>\n\n\n\n

\"ProdPad's
See customer feedback connected to ideas<\/a> in the ProdPad Sandbox<\/figcaption><\/figure>\n\n\n\n

Spot opportunities with the priority chart<\/h3>\n\n\n\n

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.<\/p>\n\n\n\n

\"The
See the idea chart view<\/a> in the ProdPad Sandbox<\/figcaption><\/figure>\n\n\n\n

Track opportunities in your backlog workflow view<\/h3>\n\n\n\n

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<\/a>) to do its thing, which is managing your development tasks, and ProdPad will be your window into development and across the entire product lifecycle. <\/p>\n\n\n\n

\"The
See the idea workflow view<\/a> in the ProdPad Sandbox<\/figcaption><\/figure>\n\n\n\n

Prioritize at the problem level, linked to OKRs on the roadmap<\/h3>\n\n\n\n

You won\u2019t find weighted scoring algorithms or stack ranking in ProdPad. Why? Because they don\u2019t 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\u2019s at the roadmap level that you outline and prioritize those problems. Roadmap initiatives in ProdPad are connected to Objectives and specific trackable Key Results<\/a>, and are connected to the ideas (or what I like to think of as experiments)<\/em> you\u2019ll try in order to solve each problem. <\/p>\n\n\n\n

\"The
See a roadmap card with ideas pipeline<\/a> in the ProdPad Sandbox.<\/figcaption><\/figure>\n\n\n\n

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. <\/p>\n\n\n\n

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: <\/p>\n\n\n\n

\n

Didn't "really" believe @jasonfried<\/a> & @rjs<\/a> when I first heard them speak of no #backlog<\/a>. Well crazy thing is: it's pretty much gone since we adopted Shape Up\ud83e\udd73

Still have a big feedback repository, of course. And ideas (@ProdPad<\/a>) & pitches. But no backlog that never slims down\ud83e\udd2a<\/p>— Massimo Arrigoni (@massiarri) September 17, 2020<\/a><\/blockquote>