How Roadmaps Can Help Your Agile Team

We recently read an article on 37signals that claimed building out a product roadmap wasn’t necessary because it often leads to user disappointment, mismatched expectations between what your customers want and what they’ll get, and it pushes a future product rather than the one that exists in the present.

While we agree with many of the points made, the Testomato team believes that if done right – a roadmap is a great way to make sure your product development follows a logical and chronological path.

In today’s post, we’ll go over the what and how of product roadmaps and how they can help strengthen the web strategy of an agile development team.

Testomato is agile

Here at Testomato, we apply Agile concepts and methods in our development processes. This means, among other things, that our team functions in an environment that promotes team flexibility to problems and change, as well as adaptive planning throughout our development and delivery cycles.

However, while we regularly employ Agile development as a methodology, we also work hard to make sure our protocols do not overshadow the core values of Agile: collaboration, self-direction, and individual accountability. Respecting and following daily practices is extremely important to us, but it is equally significant that we balance them with Testomato’s strategy and future “vision”.

And, this is why we use a roadmap.

So, what is a roadmap?

Over time, as Agile has gained popularity, the community has enthusiastically embraced the “roadmap”.

Simply put:

A roadmap is a document that outlines the release and introduction of new features and improvements for your product. 

It’s good to keep in mind that while a roadmap helps you plot your future web projects, the things on your list should not be things that you wish to add. Rather, it should be used to list the things that you are definitely going to develop and add.

Additionally, your roadmap should be prioritized. This means that items that are listed at the top are those that warrant the earliest implementation and will be completed first.

Here are a few more things to remember before you start putting together your roadmap:

1. Projects should be realistic and concrete to-dos – things that you are planning.
2. Always prioritize your projects.
3. It’s important to describe projects in detail, but don’t go overboard. Spec out the project when you reach it on the roadmap.
4. Make sure to keep it flexible and avoid hard deadlines to avoid locking in a project which doesn’t allow you easily add or remove things.
5. Keep it Agile! A lightweight roadmap is easier to navigate. The heavier the detail, the harder it is for your to edit and change it.

Roadmaps are for more than just product managers and stakeholders.

Roadmaps are important for your whole team. Although typically seen as a tool for product managers and external/internal stakeholders, this is something that is great for everyone on the team as a whole, especially in startup environments where teams tend to be smaller and more compact.

A roadmap can serve several purposes:

• It ensures that everyone is on the same page, and provides a long-term vision of release schedules and capabilities.
• It is a great way to communicate  your entire product strategy in a cohesive way to both team and your users.
• It’s a great tool for your product managers to see an overall outline of your product strategy on a timeline.

Tools to help you out

There’s really no right or wrong tools to use to create a document. For example, we use Google Docs for our roadmap as it’s easy to edit and accessible to everyone on our team. It’s important to remember that the definition of what a roadmap should look like is fairly loose. You should create a roadmap in a format that fits the needs of your team,

However, we suggest checking out tools like Trello if you are looking for something a little more visual. Or, you can even make your own with paper and Post-it notes. Try to break up your roadmap into color-oriented streams or sections so that it’s clear which areas are assigned to what aspect of your project.

You might also find it helpful to set business objectives or conduct S.W.O.T analyses of your product as an entire team. This will help you create a list of things you’d like to build into your project. Once you have this “wishlist”, you can decide what lines up with your long-term objectives and add these to your roadmap. Remember, the only things that go on a roadmap are points that you are going to build. 

A few final thoughts…

Be inclusive. Planning a roadmap should include your entire team. Throw away the traditional idea that roadmaps are for upper management or an exclusive team. Invite everyone and get their ideas! Innovation is rarely spurred along by playing the rules, so make sure you really embrace the Agile values of creative collaboration and self-direction.

Predict, don’t write it in stone. Don’t forget that the roadmap is a strategy tool, so make sure you treat it that way. Define where you’d like to go, but try to keep the specifics for things that are relativity close to the present. Having vague ideas of direction is great, but detailing future plans with an iron-fist leave no room for flexibility to changing priorities.

Be brutal when you prioritize. Priorities shouldn’t just be about ranking what’s on your roadmap. It should be decided on a variety of other factors, including a realistic timeline, energy, resources, and commitment. If that means picking a small number of projects for a better impact, then so be it. Your whole team will thank you in the end.

Connect. Be sure your roadmap makes sense in relation to your overall strategic plan and vision. Try not to make important decisions on an ad-hoc basis. Without a product development that matches up with your overall strategy, you run the risk of investing time and money into the wrong things at the wrong time.

Does your team use a roadmap? Why or why not?

 Share your thoughts here or on Facebook. Or, tweet us directly @testomatocom.