Replace Your Product Roadmap

A product roadmap is a list of tasks and mile stones. It's generally built with a destination in mind. The destination isn't always clear and more importantly why it's the destination isn't clear.

It covers up the where you're heading with tasks. Sometimes, the destination isn't even considered when putting the map together. This leaves people to guess about the destination.

The destination, could also be called the goal. Or the why. Or the context.

Let's take the analogy further and see how roadmaps hurt productivity.

A roadmap

• Take I-70 west to Grand Junction
• Continue on I-70 to I-15 in Utah
• Take I-15 south to Las Vegas
• Continue on I-15 to 210
• Take 210 west to 605
• Take 605 south to 10
• Take 10 west to the Los Angeles Union Station

This tells us how to get to the Los Angeles Union Station. Los Angeles Union Station must be the goal, since it's the last milestone. We're starting somewhere east of Grand Junction. We're probably taking a car.

• Why are we going there?
• Why are we going by car?
• Why are we using that route?
• Where are we starting?
• What if a road along the way is closed?

When something goes wrong the team has to go ask what to do next. They can't adjust on the fly and make the best decision to move forward. They are stuck. Road blocked.

Context

We are moving from Denver to Los Angeles. Using a U-haul. To start a new job on June 1st. Dropping the U-haul off next to the Los Angeles Union Station.

With this context...

It's clear going by car (or U-haul) makes sense. We don't know what route, but since we have a deadline we can figure out the best route.

Maybe we have time to go further south and see the Grand Canyon? Or stop at Zion National Park?

If we hit a road block it's easy to navigate around it. We need to be there before June 1st.

With context is the roadmap needed?

Nope. It can be useful to others who are not going on the trip. The team making the trip should create it. And they should also be able to change it as needed.

Okay, but does this work for software development?

Absolutely. Businesses exist to solve problems for customers. Being very clear on the why, the context, gives teams the information they need to solve problems.

Teams with context can plan the best route and adjust to road blocks. They are motivated and invested in the goal.

You do need a team that is capable of achieving the goal. And then you need to trust them.

The example above wouldn't be suitable for a team that couldn't drive. Or one that can't read a map.

If that's the case you need to teach them those skills or replace them with a team that has those skills.

What is context?

• Context is the problem being solved
• Why the problem is being solved
• Who the problem is being solved for
• Why it makes sense to solve this problem

Updating multiple WordPress sites is time consuming. Updating WordPress is important for the security and performance of the website. Developers and agencies have many WordPress sites to keep updated. WordPress is the number one technology for building websites making it a target for attacks and a viable market for a solution.

If this example is interesting, check out CommandWP.

What's missing from that context is the How. The how is better decided by the team creating the solution. If you know exactly how to do it, you are coping an existing solution and that should be explicit in the context.

Give your teams the why. Make sure they are capable. Trust them to do what they do.

Try it on a smaller project. But make sure you give it a full try. Be careful of letting your existing processes influence the experiment.

---

Photo by GeoJango Maps on Unsplash