3 tips for agile roadmaps

2023-05-18T18:17:00+02:00

"Roadmapping is anti-agile. Instead, we should only have priorities."

This was a response to my product roadmaps article - discuss!

Are roadmaps anti-agile?
— Ant Murphy (@ant_murphy) May 17, 2023

My response: Product Roadmaps can be agile or not, it depends on how you use them.

The idea behind a roadmap is to deliver predictability to the business, but how does that work with also being able to respond to changes?

1. Update it regularly#

Once a year is too slow, and leaves no wiggle room for new insights or priorities throughout the year. But updating it too often makes it hard to use instead. I've seen quarterly updates work well for a 50 people company. Shorter for a smaller or younger company, longer for a bigger or more slow moving one.

2. Schedule broad areas/problems, not features#

Features change more often than problems, so putting problem areas in the roadmap works better for both delivering some predictability and leaving space for learning. The clearer you can be with what effect you are looking for, the more empowered the team can be in solving the problem.

3. Don’t make everything time bound#

If every item in the roadmap is time bound, then updating it regularly will be though. Put a time frame on the nearest items, that you know more about, so the business can plan. But don't worry about the ones longer in the future.

That's it, three quick tips to work with agile roadmaps. Sounds easy? It's not.

How to prioritize a feature list, the hard way

2023-06-08T07:53:00+02:00

What % of the top 10 [features that customers ask for] do you end up implementing typically?
— Jason Cohen (@asmartbear) June 7, 2022

Raw customer feedback is always too much about features, and too little about the problems customers are trying to solve.

So you need to rework the feedback to map to the problems customers have instead, merging and splitting feedback as you go. Hard work. Now you have transformed your list of features to a list of problems.

Can’t you just build things in this list in “most common problems” order? No. Because how often a problem occurs is not the same as how important it is.

Also, the type of user that has that problem is also very important.

In a B2B context, the buyer is much more important than the user. In B2C there are different kinds of users, which have wildly different priority.

And there are likely five other important factors too, all specific to your specific problem area, that we haven't even talked about yet.

Could you build a ranking system weighing these things together, and get a bottom up priority list?

You could, but it wouldn’t be at all as exact as it looks to be. It’s easy to fool yourself. Remember that the raw customer was very biased, is this something to build a solid mathematical model based on? I think not.

A better way is to not build a ranking model, and work from the list of common customer problems.

Instead, look at your company’s business goals, and start mapping customer problems to business goals.

Say some users have problems with the checkout flow. This maps directly to a revenue target.

Someone didn’t like the design of the site. Talking to them, you find that that leads to them not trusting you. Which indirectly leads to lost sales.

So maybe you put up “Increase customer trust” as a node in a tree and continue mapping. As you add more feedback, and more nodes, you get a much better picture of how things fit together.

Looking at the whole tree, you can now prioritize which customer problems to work on, based on business goal priority. This will make a lot more sense.

Because your job is not to build features, or even to solve customer problems. It’s to drive business outcomes.

And yes, you do that by solving customer problems, and building features. But that’s not where you start.

That’s how you prioritize a feature list, the hard way.

Friendly Bit - Web development blog

3 tips for agile roadmaps

1. Update it regularly#

2. Schedule broad areas/problems, not features#

3. Don’t make everything time bound#

How to prioritize a feature list, the hard way