Anatomy of a roadmap planning fail

I went through a roadmap planning cycle where I learned a valuable lesson about how to present a vision to the team in a way which allows them to see the real value which will be provided to the end user. A reassessment in how I was presenting potential roadmap items triggered a night and day shift in the reaction of the team.

Every quarter or so my team will get together for a series of roadmap planning meetings. The management, the senior development team and I will sit together for a few hours in an effort to distill a rough plan of what we should work on in the next 3 to 6 months and put it on a roadmap while following our roadmapping principles.

I prepared for the most recent cycle by meeting customers and stakeholders and preparing a list of potential features we could work on in order to bring value to the customers and to the business.

Sometimes I unblur it when I show it to the team :-)

In the weeks leading up to the planning meetings, I worked with some of the developers individually to analyze our strategy and brainstorm solutions to customer problems. Together we divided larger features into chunks of work which are not huge but will provide incremental value for the users, even if the value is small in isolation.

I like to avoid taking on huge chunks of work with long development cycles. Anything larger than 2 months is too big in my book. The goal of these individual meetings was to come up with features which wouldn't send the team down a rabbit hole and could be released quickly in order to get value to the users so we could get feedback and iterate.

There were three broad categories of features:

1. Work which helps us increase scale such as enabling horizontal scaling or reducing pressure on the database at the core of the product.
2. Work which helps us make the application easier to understand during development. Internal complexity was hurting development velocity.
3. Work which made the product easier for our customers to use.

Planning Meetings

The roadmap planning meetings happened over two days. One hour each day.

The first meeting covered the first two categories: scale and ease of development. We talked through the expected growth of the application, the main scaling bottlenecks and the technical debt that had built up in the codebase. The engineers were enthusiastic. They thought these were high-value work items.

The second meeting was about user-facing features. I ran through each of the potential epics explaining the pain point for the users and the effect it had on their workflows. This meeting was more muted in its response. Each of the three features I proposed was picked apart for not adding enough value for the users.

During this process, I was conscious that I was straying into specifying how the problems would be solved. Not so far that I was talking about how they would be implemented at the code level, but far enough that I was saying "we would add xyz" or "the user would be able to do xyz". I thought that this was ok because I had worked with the engineers individually to design the features and ensure they were technically viable.

Here's a concrete example, imagine my product is Digital Ocean (in reality it's a similar product so it serves as a good example). Digital Ocean lets you create virtual machines in their cloud using a command line interface.

The commands to do that can look like this:

doctl compute droplet create my-virtual-machine --size 512mb --amount 100 --ssh-keys-id 89734 --image-id i8345

In the command above I'm saying that I want Digital Ocean to create 100 virtual machines for me and I want each one to have half a GB of RAM, contain the ssh-key with the ID 89734 and use the VM image i8345.

Works great but that's a lot of stuff copy/paste and type out manually. To avoid the extra typing, our users had stored all the IDs and the amount in a database and wrapped a script around the command to pull the data out of the database.

I suggested that we should be interfacing with this database directly. This would reduce the command our end users have to type to:

doctl compute droplet create my-virtual-machine

Much simpler and more automated. Automation is, after all, one of my desired attributes of good deployment tools.

This idea faced a rather muted response. The response from the engineers was: "sure, we could do that, but they're getting on ok without it and we're only moving logic from one place to another".

The other feature ideas were similar and were met with similar responses. I found this response tough to rebut. I knew the back of my head somewhere that there were good reasons to do this work but I couldn't articulate it.

Back to the drawing board

After some serious thought, I realized that I'd made a serious mistake. I was pitching features. That's the wrong way to approach it.

I knew that this individual feature could combine with others to change the way our users experienced the tools we provide but all I was articulating was a shorter command. I wasn't laying out the vision for the team in a way which let them buy into it. By going straight to the features I short-circuited the WHY of what we were doing. I didn't tie them all together to share the problems our users faced because of the intricate commands they were required to type. Each idea or feature or problem in isolation seems to deliver little value but that's because they are stepping stones to a place where there is a lot of value.

Instead of pitching features, I needed to work on setting the stage in these planning meetings. I needed to point out certain trends that are happening in the business (general growth and so on) and then point out the problems that I want to tackle. This keeps me further out of the solution space and lets the engineers take that over.

Next time I came armed with visuals representation of the problems that the users faced because of these complex commands. I showed the excessive work they did to maintain all these scripts, to run the database and keep it updated. I showed how the fact that we didn't access the information in the database prevented us from tackling key scaling challenges and I showed how close we were to causing production issues because of mistyped commands.

The response from the team was completely different. By exposing them to the customer's problems they were much more enthusiastic about solving them.

Lessons Learned

• Take time at the start of any roadmap planning session to set the context and put the user's problems in focus.
• Breaking large features into incremental value is good but be sure to tie them back to the overall vision when you talk about them.
• Supplying context can turn a no into a yes in a way I previously didn't think possible.