The problem with ‘roadmap first’ teams

Whether your team is using an agile, waterfall, or some other development method, it is very likely that you have a roadmap.

Roadmaps are a great tool for team members to answer some very important questions, such as what they should work on, how much time do they have to complete it, and what’s next for them and the team. They’re also a great communication and sync channel between the all the team members.

This is how a roadmap usually looks like:

For a single member, an accomplishment means to complete a task and move on to the next task. Completed tasks are good signs for progress, both for the ones in charge of it and the entire organization.

The problem starts when the roadmap, and not the users, becomes the thing that drives the team. I call it a ‘roadmap first team’. In a roadmap first team, the development cycle looks like this:

It is great for team spirit, as there are many tasks and the end-of-the-year checklist would show we’ve done a lot. But it tells nothing about user satisfaction, and even after 50 completed tasks there’s still a high chance that the users are not happy at all. For example, the core feature could be buggy, the UX could be inconsistent, or the site could take too much to load.

When that happens, roadmap driven teams won’t just say ‘hold it guys, our product loads really slow and many users get frustrated. Let’s take the next two months to improve our past releases’. Instead, if there is no easy fix, they move to the next task and continue the development process as planned... They would say ‘It’s not perfect, but it works. Right now we have more important things — we have to deliver feature A by December’. New features will keep coming all the time, and this kind of team would keep chasing them. Their products will usually end up being fully functional products that nobody likes to use.

In a roadmap first team, the missing link is Iterations.

Iterations are crucial to improve solutions that were not good enough. They come after collecting feedback, and allow the team to improve. In a ‘user first team’, the next thing to work on would actually be determined by this question: ‘What can we do next to make the users most satisfied?’. Many times, it is not necessarily to develop something completely new, but actually improving the existing.

Therefore, the roadmap becomes more flexible. Tasks can always be added, moved or removed, and they’re sorted by calculating the cost & value that each task brings.

Great products are born only when the core features are the team’s main focus, and iterations and improvements are part of the team’s culture. The key is adding value, and not just marking more items in the checklist as ‘done’.

This story is published in The Startup, Medium’s leading publication for entrepreneurs and startups.

Join +12,417 people who get the top stories here.