Roadmap Planning in an Agile World

Posted by Kevin Steigerwald on Wed, Apr 20, 2016

This article is a guest post from Andre Theus, Director of Marketing at ProductPlan.

people-woman-coffee-meeting.jpg

What is an “agile product roadmap,” and is creating one a good idea?

To some product managers, the phrase itself might seem to be a contradiction in terms. After all, a roadmap suggests strategic planning and a long-term product vision. Agile development, by contrast, suggests short-term cycles and frequently shifting priorities. Can product managers develop successful roadmaps using agile development principles? And more importantly, should they?

Yes, and yes. Product roadmaps can benefit significantly from one of the unique advantages of agile development — the ability to correct course frequently based on real-world input, user analytics and other key metrics.

To illustrate how using agile development in conjunction with metrics can help you create more effective product roadmaps, let’s examine a few of the 12 agile principles.

Agile Principle 2: Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage.

At first, this principle might sound like it runs counter to the roadmap process. Once you’ve defined the roadmap and received buy-in from all stakeholders to move forward with your plan, that plan is set in stone, isn’t it?

Here’s where the agile process — and the ongoing input from relevant metrics that it allows — can be so valuable. Remember, the purpose of your roadmap is to define and communicate a high-level strategy for your product. But once you have that strategy in place, what is your primary goal in the development process? Is it to create the best product possible? Or to stick faithfully to the details of your execution plan?

Agile development places high value on iterations and feedback, which is why it can be so useful in managing your product roadmap. One critical component of creating a successful product is regular input from key constituencies — existing customers, new customers, prospects using your product’s free-trial version, etc.

Monitoring and analyzing how all of these users’ interact with your product, and gaining direct feedback from them through surveys, interviews or whatever method works for you, will be as essential to the success of your next release as the highest-priority feature or story you have on your current roadmap.

In a more traditional, waterfall-based roadmap process, a mandate to change focus or priorities in mid-development — even if it comes as a result of real feedback from the market — can be viewed as a setback or a failure. After all, it takes the team off of its agreed-upon roadmap path.

But in agile development, product managers will more accurately view such a course correction as an opportunity — a data-supported opportunity to improve the product.

In other words, using agile development and tracking key metrics in your roadmap gives you and your team ongoing opportunities throughout the development process to learn what’s working, what needs work and what will truly resonate with your constituencies.

Agile Principle 3: Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.

This concept follows closely from Principle 2. Agile philosophy favors breaking a product’s development into smaller components and “shipping” those components frequently — which allows for the all-important feedback and learnings that will inform and enhance the rest of the product’s development.

This allows you and your team to continually monitor user behavior and analyze real-world metrics from the market to improve your product as you’re developing it — rather than building it entirely in a silo and finding out only after you release it that it falls flat with your key personas and other constituencies.

Many product roadmaps, by contrast, default to the waterfall approach of building the entire product behind closed doors and shipping only when it’s done.

Using an agile approach, therefore — and building in more frequent mini-releases of your product, in stages — can be more effective in roadmap planning for several reasons.

First, it can speed the product’s overall development. That might seem counterintuitive, considering that these more frequent mini-releases will also mean more data and feedback to review, at each stage. But at the same time, this agile approach, with short-term development cycles of smaller portions of the product, results in less time spent drafting and poring over the large amounts of documentation that characterizes waterfall product development, where the entire product needs to be defined upfront.

Second — and the more important benefit for our discussion here — this frequent-release approach creates more opportunities for you and your teams to validate your product ideas and strategies from the qualified constituencies who see each new release.

Ultimately, this feedback will inform the next stage of your development, and the stages after that — and will result in a product that better meets the needs of your market than one you developed without such interim and ongoing feedback.

It is important to note, however, that your product will enjoy the full benefits of Principle 3 only if you judiciously track, analyze and apply the learnings from your key metrics at each stage. The real value of delivering working software more frequently to your market is that the market has more frequent opportunities to tell you what they like and do not like about each new release. Your product roadmap updates, therefore, not only track those metrics but also apply them.

Agile Principle 1: Our highest priority is to satisfy the customer through early and continuous delivery of valuable software

I held Principle 1 for the end of our discussion because it perfectly sums up not only the overarching philosophy of agile development itself, but also the value — even the necessity — of monitoring and analyzing relevant metrics throughout the process, and then using what you learn from the data to continually improve your product. The best ways to ensure you “satisfy the customer” and “continuously deliver valuable software” are to iterate frequently, ship frequently, and listen to your market frequently.

Users of Notion’s analytics tools certainly understand the importance of real-world intelligence for improving product quality and better meeting customer needs.

This approach should be applied to building and maintaining your product roadmap as well — building in a series of key metrics to follow, data to analyze and interpret, and key times to step back and investigate what that user information suggests about your priorities for the next iteration of your product.

One way to apply this agile approach, combined with metrics tracking, to your product roadmap is to develop and maintain the roadmap in a high-level, visual product roadmap tool that you can easily view, update and share with your various constituents across your organization.

~

About the Author
Andre Theus is the Director of Marketing at ProductPlan. He works closely with customers and prospects to build better product roadmap software. Andre has worked for disruptive technology companies for more than 10 years. Prior to ProductPlan, he was a member of marketing teams at RightScale, Sonos and Citrix. Andre received a master in computer science from the Cologne University of Applied Science in Germany.

Level up your team's impact on company growth. 

Learn the AARRRT KPIs of Product Metrics and become a PM Pirate. 

Download the guide now.