Roadmaps make stakeholders, contributors, and users feel safe. They give everyone this false sense that the product team has their shit together because they've thought ahead and have a release schedule.
In reality, roadmaps are insanely expensive. The whole team is required to make a huge upfront time investment in order to make roadmaps work.
In the above example, a team might have 3 development tracks and each milestone is represented by a letter. Now imagine if starting the "L" milestone depends on completing milestone "K". That might sound like a good idea on paper but that means Milestones "B, D, F, H, and K" all need to be delivered without a hitch. That isn't likely to happen. If any milestone isn't delivered on time, the whole system gets thrown out of whack.
Other common pitfalls
Agreement - Everyone has to agree on what should be on the roadmap in the first place. Sounds easy but this can divide teams and get people working against each other.
Planning - Meticulous planning is required to break large milestones down into smaller chunks of work. Overlooking a single detail can throw everything off.
Estimation - The team needs to come to an agreement on how long each chunk of work will take. Story estimation is not an easy problem. Even the most thoughtful estimates can be very inaccurate.
Why are we doing this?
Is it really that important to be able to predict that some random feature will be available on a given date? I don't believe the benefit is generally worth the cost. But I hear the same arguments over and over.
Marketing - Teams want to be ready to market a hot new feature the minute it comes out of the oven. I think this is generally a waste of marketing dollars. It's better to soft launch a new feature, get feedback, iterate, and promote the thing once it's actually solving real user problems.
Communication - Teams want to be able to communicate internally and externally what'll be released in the coming months. This one is more of a valid argument. Building anticipation and transparency are good things. It's good to make users feel like you are addressing their needs. But I believe you can accomplish this without a roadmap.
So far, I've talked about some of the major challenges teams face when building things using roadmaps. Now let's take all that and imagine a better system. Here are a few things I believe should be taken into account:
1) Cheaper to operate - A startup shouldn't need dedicated managers and require contributors to invest a significant amount of time estimating stories in order to get things done.
2) Happier contributors - As a contributor trying to figure out how I can maximize my skills and energy to help drive a product forward, I find a predetermined list of things to do demoralizing. We need a system that doesn't treat people like resources.
3) More efficient - Instead of optimizing for predictability, we should be optimizing for figuring out the right thing to build and actually building it.
4) Adaptable - Roadmaps lack flexibility. We need a system that doesn't lock us into a 5 year plan when we learn something that changes everything 1 month into the execution.
I've talked about some of the roadmap drawbacks and made a short list of potential improvements. Now let's talk about how things work at Hacker Noon.
We've adopted a product funnel to replace the traditional roadmap.
Think about the lifecycle of how a concept goes from idea to production. You can think about the stages of the lifecycle as stages in a funnel.
At the top of the funnel, we've got a big cloud of things we can do. This is a mix of user feature requests, bug reports, and ideas from the team. We have a big pool of raw ideas that represent opportunities to build a better product.
At this stage there is no expectation for when or even if an idea will get to production. We really need to think about all the opportunities in this pool of possibility and decide what to pursue.
If an idea is fuzzy and seems like it has potential but the implementation isn't obvious then it goes into the discovery track. This is a space for things we might pursue. At this stage, the goal is to rapidly prototype a concept and get more clarity on the value of an idea. Once we have a functional prototype, we should get validation from users and the team to decide if the concept is ready for the next stage of the funnel.
Once a concept is well defined and we've validated the value, it moves to the delivery track. At this stage, we have things we plan to pursue. There is still no guarantee when the improvement will get into production. But the probability that the thing will be available soon goes up substantially.
At the bottom of the funnel, we have a small list of things we're actively pursuing. Things in this list are expected to make it to production, generally within a few days.
That's about it! No need for some fancy flowchart or a gantt-like chart to show swim lanes for every contributor or team. Just start with a bucket of ideas. Use the discovery track to vet ideas if needed. Invest your time delivering the most impactful concepts. Reassess daily if possible or weekly if necessary.
At Hacker Noon, we use Slack, our Discourse forum, email, and social media to capture ideas at the top of the funnel. It's important to treat feedback with respect at this stage. You might have a negative first impression when someone presents an idea but try and think about the underlying problem. Often times the proposed approach might be off but the pain a user is feeling is real.
We use Asana for the Discovery & Delivery Tracks, and for tracking what's in progress. Each track has a project listing associated tasks. By default every task should be unassigned. We assess priorities daily and self-assign tasks based on what is most important. When a task is self-assigned, it is considered "In Progress". Each contributor should only have a few in progress tasks at any time. This is what our Delivery track currently looks like.
When a task finally makes it through the gauntlet and into production, we celebrate by writing a short description of our accomplishment in a Slack channel called #progress. This gives everyone a heads up when something changes and an opportunity to use their favorite slack emoji. So far there have been 1,483 emojis given in our #progress channel. This is one KPI I'd like to keep tabs on.
What we've learned so far...
1) Organizing our work into a funnel instead of a roadmap makes us much more flexible and productive. We've accomplished so much in the last 8 months with a really small team.
2) We require very little project management in order to make progress.
3) Trusting and giving contributors autonomy to work on what they believe in is almost always better than top-down management. Developers and designers occasionally get side tracked but that usually means the team is neglecting to have quality conversations about the product and what's important.
4) Communicating our progress and setting expectations in an environment that is inherently more chaotic and less predictable than a roadmap is challenging. But with more transparency, we can get there.
5) We still need to get better at addressing critical tasks such as bugs that break core functionality. It's always a challenge to balance competing needs. Sometimes it's more important to address short term problems (we use the #critical tag on Slack and Asana for those cases), and sometimes it's ok to say "No, this issue can wait."
6) I believe it's important to use KPIs to decide what to work on next, which we need to get much better at. But it's also really important to encourage people to advocate for ideas. This naturally happens at the top of the funnel because people tell us daily how important it is to change X, Y, or Z. But advocating for ideas near the finish line is something we need to improve on.
7) Planning and prioritization isn't a bad thing. It's good to have a vision. Just realize that your future self is smarter than your current self. So let your future self solve future problems and focus more on the task at hand.
We still have a lot to learn. But the team seems to be happy so far. Here is a quote from Austin Pocus, our Lead Developer.
The problem with a roadmap is that it tells you exactly where to go and how to get there, with no consideration for anything that might come up and change where you should go. The funnel system is much more flexible, and frankly, enjoyable to work with. We're still working out the kinks, but it feels like I'm a part of that process, as opposed to a roadmap system. I can't imagine going back to a roadmap after this.
I plan to write a few follow up stories on topics I've covered here that deserve a deeper dive. I could go over computing the cost of running a roadmap or talk about some of the communication challenges. Please leave a comment if you have any questions or ideas.
P.S. If you'd like to add a product idea to our funnel, start a thread in the product community forum.