SaaS Roadmap Planning in an Agile Environment

I’m often asked if there’s anything different about managing a roadmap in an agile environment. I don’t think so; since agile is (just) a methodology for delivering software, I don’t think having a roadmap and being agile are mutually exclusive. Let me know if you disagree.

Over the past few quarters, we’ve refined how we manage our marketing automation platform’s product roadmap (which we develop using agile methodologies).  As of today the platform has 525 Users, so the volume of feedback and demands is rapidly increasing.

Here are a few things we’ve found about managing a roadmap in this type of environment:

1. Creating a detailed roadmap for more than 1 quarter at a time seems to be a waste of effort. Perhaps this is not true for every SaaS platform, but in our environment our knowledge of the market evolves so quickly (as we intake user feedback called “oxygen“), that it is almost pointless to create a detailed 1-year roadmap. It seems to be obsolete within a few months.

Instead, we’ve taken to creating a roadmap that gives direction and clarity for the next 3 months. We’ve found that for us, 3 months is about right.

Sprint Planning Meeting: Where the rubber meets the Roadmap

2. With a quarterly roadmap, sprint grooming and planning gets easier — and much more focused. Every other week, I met with our chief software architect, and we engage in a very enjoyable “grooming” session (I know, it sounds funny). I’ll describe this process in another post — but the point of the session is to review items in the backlog, do a quick assessment of how much work is required, and loosely schedule the items (if necessary). With a 3-month roadmap in view, it is easier to make an assessment of what needs to be done relative to the big picture.  This makes our preparatory work much easier in advance of each Sprint Meeting.

Roadmap Training Session: Getting everyone aligned

3. Communicating the roadmap is difficult. We post the roadmap as a Google doc for everyone to see, review it at our monthly all-hands meeting, and refer to it often in discussions. Even though we do this, there are still team members who don’t know what’s on the roadmap. I’m still looking for better ways to communicate the roadmap and keep everyone aligned.  (For example: yesterday we experimented with an all-day team training session, which was designed to orient everyone towards our roadmap and objectives.  We’ll see how that does for us.)  More likely than not, you’ll find yourself constantly communicating the roadmap and the direction (which is a good thing).

4. We publish a version of the roadmap for our Clients to see. This is helpful for our team if Clients have a question about our engineering plans.  It also cuts down on questions like “When is such-and-such going to be available?“.  If something’s not on the roadmap, we give Clients an idea forum for voting on features.  Even if something isn’t in the idea forum, we’ll still consider it if the volume and importance of the item is sufficient.  Put another way, if something is uber-important to your Users, you’ll hear about it one way or another — and you’ll get the point.

5. We manage the backlog and roadmap in one Google Doc. I usually spend at least a few hours per week reviewing and refining the backlog, updating items as new data are available, and grooming “next up” items. Whenever I have an idea, or someone on the team comes up with a great suggestion, we’ll add it to the backlog so that we don’t forget about it.  The Google Doc is shared and available for everyone to look at.

6. Instead of allocating all available time to roadmap items, we try to allocate roughly 50% for bugs and other features that come up through our hand-to-hand work with Clients. This means that the roadmap generally contains only a handful of major user stories.  You have to resist the urge to try and do too much, especially as you’re still finding your product-market fit.  I think you have to give yourself room to remain nimble, as you’re going to discover valuable information along the way that requires an agile response.

For example, we had 10 items on our Q4-2012 roadmap. 5 were completed, 2 were partially completed (they’re going to roll forward into Q1-2013), and 3 were not started (also rolling forward). In addition to these roadmap features, we had a number of enhancements that were “discovered” through the course of working with Clients. Often, we find these are the most exciting features, as they enable large chunks of our user base to move forward in a major way.

What about you? What have you found helpful in managing a product roadmap in an agile environment?