I have been a software developer for a good chunk of my life. And as I have progressed in my career and started working for bigger companies - trying to tackle bigger challenges - one thing that sprung into my world was roadmaps.
In the past I was one of the people who would always ask for and on some degree even advocate on getting a roadmap. Main reason was to understand what work was coming up - and often would get back a plan for next 12 months. Sometimes even longer.
First - myself and the team would get excited - there is clarity,a plan - and sooo much work to do and so many challenges to face.
However about 2 months down the line it becomes apparent that the roadmap is hardly fit for purpose anymore - the world has moved on - priorities have changed.
This often would lead to very frustrated teams - which somehow made it feel a lot more annoying and a lot worse that it really was.
These days I am not a big fan of roadmaps anymore. I believe if you want to be quite competitive and do the right thing - you cannot plan too far ahead. Just focus on the next most important thing.
You may be wondering how then the team aligns then on priorities - and I would suggest that team mission would serve you better than any roadmap.
At the end of each sprint/feature/goal - reflect on what you learn and see what is the next most important thing.
In my opinion it is because majority of them are just Gantt charts under a mask. A lot of them have dates and expectations - and reality is that as soon as you slot something else in - all of your dates go out of the window.
Unfortunately the dates are never truly meaningful and things get pushed back further and further.
In more extreme cases you also end up moving your whole roadmap to your ticketing system and pollute backlog with stories that will never get implemented - or create a backlog that would take the team year(s) to complete. That in turn creates even more waste of time for the teams.
When I brought this subject up with colleagues and in my network - although few voices shared my concerns, one person has suggested to use something called "Now, Next, Later".
As simple as it is named, the principles for what they are can be summarised in the following way:
Tasks that need your attention right now. There may be quite a few items here, maybe a scope of larger feature spanning a number of weeks - but one thing sure - you have to work on it right now.
Tasks that may need some final refinement before they are ready to be move to the Now area.
Refined ideas and requirements that come from user and market research that you will be working on whenever things in Now are done. Or just think of these as tasks that need some final touches before they require immediate attention.
This may be fresh ideas that need a lot more refinement - think of a fresh idea that needs some validation beforehand, maybe some research done ahead of time. Maybe they will never even make it to the Next bucket.
And that is it. It creates a wonderful flow that should be constantly changing.
One of the things that I been reminder recently is that different people may learn new information better if it is presented in a different format. So here is a short video I found explaining the concept:
In conversation with my fellow colleagues a good point came up around dates and roadmaps that I thought is definitely worth sharing.
You might need a roadmap for things that you MUST do at a certain point such as:
- legal requirements (example: cookie banner, GDPR changes)
- maybe a feature is crucial to reach market before some big promotion for season sales
- I struggle to think of more examples but hopefully you get the gist.
If you see or learn some amazing opportunity for your product - take it and run with it.
The software and product landscape is changing rapidly - you have to be able to move fast too.
The post originally published on my personal blog: Digital Roast - My view on Roadmaps