Nortrup in Development

Roadmap

Manipulating the Sorted Backlog

I’ve written recent guides to creating a backlog from scratch and sorting your backlog by value and effort. As part of building and sorting the ideas and initiatives on your roadmap you will start to show that roadmap to other people. When you do people will have opinions about the order that you have sorted things in. In most cases their opinion will either be agreement, or more commonly, they would like the thing that is important to them to be higher on the list. These differing opinions are good, this is why we build a roadmap. It is better to have those discussions when we are thinking about building things then after we have spent time building something.

#Roadmap | #Product Management | #WSJF | #Prioritization

Quick Prioritization of a Backlog

There is a lot of complexity in Product Management, but at the very heart of it what we look to do is order all of the things we could be doing to produce the most value possible. To do that we have to carefully weight the balance of value to effort in order to properly sequence the infinite set of work that we could be doing.

Estimating is a tricky and messy business, and I’m frequently skeptical of. But when you are trying to prioritize multiple potential projects as a product manager, having some basic numbers can really help things along. This is a system I’ve used multiple times to quickly establish baseline value and effort estimates. I like it because it is fast and avoids a lot of hemming and hawing. The goal of this system is to get things in mostly the right order and avoid making big mistakes.

#Roadmap | #Product Management | #WSJF

Roadmaps From Scratch

Very rarely will you build a roadmap from absolute scratch. But the technique is helpful because you can apply the process to help rationalize or refit an existing roadmap. I’m a strong believer that you should be able to connect all the work you are doing from top to bottom of the company. A developer should be able to look at any task and put it into the context of the larger solution they are building, the problem it solves for the customer, and the business objective that it supports.

#Roadmap | #Product Management | #Cost of Delay | #WSJF

Outcome First Roadmaps

I’m sure if you’ve talked to me recently you’ve heard my song and dance on outcomes based road mapping. As I’ve been talking about it over the past few weeks something really clicked for me on why it’s so important to identify the outcomes early in the definition of an idea.

When you are trying to get work prioritized and on the road map, it’s straightforward to start with a name for the solution that conveys meaning and then find supporters who also like the sound of the idea. An easy default is to talk about the solution you are proposing to fix a problem. They go together to help form a narrative story that works well in a meeting. We have this problem, and here is the solution!

While this is really appealing, it also leaves us some challenges on the backend. If we prioritize problems with a measurement of what we are going to achieve better alignment on why we are trying to solve this problem, and allow ourselves more freedom to discover the right solution.

#Product Management | #Roadmap