Jugglin’
I don’t really differentiate between backlogs and roadmaps.
It is all a spectrum: high level, low level, sooner, later, certain, uncertain, designed to learn, designed to act on learning, strategy, tactics, etc.
Depending on the day, you might be looking at an ordered list, map, mockup, casual relationship diagram, network graph, charts and data, kanban board, timeline, canvas, one-pager, or brief. The underlying data remains consistent, but the chosen view for that particular day, person, team, or meeting is context dependent.
As a Product Manager, you will always be juggling context. As I’ve mentioned before, this is really, really hard. You’ll never be doing it exactly right:
Go low level, and someone will ask for the Big Picture. Talk Big Picture, and they’ll ask for the details. Talk why, they’ll ask about how. Talk how, they’ll ask for what. Frame the work as experiments, and they’ll ask for concrete solutions. Talk solutions, and they’ll challenge your assumptions.Get used to having to switch gears!
Anti-Patterns
That said, there are some things that are universally bad.
Anything that…
- Triggers premature convergence, planning, etc.
- Adds unnecessary commitments, constraints, or dependencies
- Encourages feature bloat, and adding unnecessary complexity
- Communicates stale information
- Limits meaningful conversations
- Fails to expose (or glosses over) assumptions
- Obscures the relationships between items (e.g. nesting, sequencing, experiments/hypotheses, etc.)
- Restricts the team’s ability to come up with creative solutions
- Obscures the Why and the problem to solve …is bad. Change your tactics when you run into these problems.
The major issue with product backlogs (and roadmaps), is that folks tend to fill them for the sake of filling them. Instead of looking at the outcomes/impacts we hope to generate, we prematurely solution (aka “guess”). The org gets fixated on the solutions, and forgets why the items were actually added in the first place. You might rename these:
Guesslog, Wishing Well, Spec-In-Disguise, Require-LogThe team always needs to be asking “can we deliver the desired outcome with LESS complexity?”
Get Tactical/Specific Late
In the last couple years, I have trended towards using story maps, experiment canvases, mission canvases, feedback repositories, and outcomes-based roadmaps, more than lists of stories (aka product backlog). There’s a time and place to get super specific, but I try to do this as late as possible in the process. I prefer to use tools like Evernote or Trello to capture ideas, reminders, and research… and leave “the tool” (aka Jira) for pure tactical work decomposition and tasking. Of course…the team has access to everything.
The basic idea…bind as late as humanely possible. Don’t turn the 100-page specs of the past, into a mess of 1,000 Jira tickets. I prefer to keep backlogs VERY short, with only a few specific items decomposed at any particular time.
Let’s Get Cleaning
Go through your backlog and look for these familiar items. Do a bit of house cleaning.
1. Soul Sappers
You know, we really should ____________ . It bugs the whole team, and really sucks!The danger here is that failing to act will take a toll on the team. It’s like a psychic tax. Consider doing the work (very) soon.
Managers often worry that responding quickly to these items will lead to a culture of gold-plating (adding layers of perfection on top of something that works). I think people know the difference. One feels shitty: people tend to not get terribly agitated about gold-plating, whereas with soul sappers, the pain is acute AND lingers.
DO THIS: Commit a block of time in the near future to address the issue
2. Potential Solutions
Well ____________ is one way we could solve that problem . There are other ways we could go about that.You frequently stumble on “good ideas” in the backlog. But it is important to consider whether there are even better ideas out there. Make sure you have a placeholder for the actual problem, and then link this item to that placeholder. Don’t leave it dangling without context.
Make sure that anyone looking at this item will know that it is one of many potentially good ways to solve the problem. Also, make sure to be realistic about your knowledge of the problem. If the problem itself is a hunch, be diligent about documenting that.
DO THIS: Add as sub-item under the actual problem
3. Guess?
How do we know that ____________ is important? Did we just make this up? Sounds like we should discuss this.In the same vein, you need to indicate the research/data/insights behind the item. Teams tend to decouple the research from the “ticket”. This is dangerous because someone looking at the ticket may be left with nagging doubt. Similarly, teams will have unaltered requests from customers/internal stakeholders sitting in their backlog…with no context or research.
DO THIS: Link ticket to research/insights on Wiki
4. Awesome Ideas
Wouldn’t it be awesome if we ____________ ?You have to tap this energy! It is rare for people to use words like awesome, so you want to figure out how to channel that. There’s value in doing things just because they’re awesome (fun, creative, delightful to customers, etc.), and it isn’t always easy to quantify. There are many ways to play this. The first instinct is to do something like 10% time, hack days, reserve sprint capacity, or force people to do business cases. I prefer to say something like “hey, anything under a couple days that you want to try because it looks promising…go for it!” I’ve found that people take that responsibility seriously, and tend not to abused the freedom.
DO THIS: Discuss some “awesome idea” guidelines with the team.
5. Broken Stuff
The ____________ is broken. If we don’t fix it soon we ____________ .If something is broken, it’s broken. Unless you’re working on something that is more broken, there are few excuses why the item shouldn’t be worked on immediately, or put in a Next Up state. If you delay, you’re liable to lose context, and a sense of urgency. You might get lucky and nothing explodes, in which case you’ll persuade yourself it isn’t that broken (the mind plays tricks in this regard).
Just do it! Some teams have become numb to stuff being broken. Broken stuff is everywhere. This is a different (but super important) problem.
DO THIS: Fix it immediately. Skimped quality rarely pays.
6. Reminders
When we get to ____________ , we should remember to ____________ .I often see backlogs that are littered with reminders. There’s no sense of priority, value, or severity. There’s no story. There’s no goal, actor, or impacts. The item is basically a note-to-self. Reminders are fine, but somehow they all just sink to the bottom of the backlog because they lack context. It is far better to collect these as notes inside a larger container story. In what context will this reminder become valuable?
DO THIS: Fold these into larger stories where the reminder will be relevant.
7. Committed
Oh ____________ ? Well, we’ve kind of committed to do that.That is pretty darn important. There is a big difference between ideas/potential solutions/experiments, and things that have been promised. And there’s a pesky difference between items that have been promised, and items that “we’ll try to get to if we have time.” What you tend to see is that someone — often the PO — has churned out some stories. The team sees those stories and assumes that they’re committed, when they aren’t (or vice versa). The lesson: clearly describe the promise involved with the work item.
DO THIS: Clearly label things that have been promised. Link items that have been jointly promised.
8. Parts of a Whole
Without ____________ , that other thing we have in progress will be of no value.This item is basically committed. Teams should be encouraged to decompose their work. Small is good. In the process of making things small, we tend to accept some dependencies (they run counter to the Independent in INVEST) in exchange for the beauty of small stories. This is OK, but it is important to indicate that a relationship DOES exist. “No Value” can be a bit misleading. Releasing a small (but incomplete) item into product — behind a feature flag, perhaps — can provide valuable learnings. There’s no beating this game, and it’s a balance between the scope of the item, and big picture cohesiveness.
DO THIS: Link the item to its dependencies. Also, make sure to have a holder for the cohesive bit of customer/user value.
9. Huh?
What does ____________ even mean? This makes no sense.If no one knows, kill it immediately. You’ll never figure it out.
DO THIS: Kill
10. Stale
Oh ____________ ?! That is like three years old.Kill it. There’s a reason why you haven’t worked on it, and highly unlikely that the information in the story will still make sense.
DO THIS: Kill
Hope this helps. I’ve run out of time for the day. Cheers!