navigating the product roadmap

As is the case at many other startup/early growth phase companies, we at Mediafly haven’t hired a product manager. “Product management may be the one job that the organization would get along fine without”, and we’ve lived by that model for the past few years. Because of this, we operate lean and create our own best practices for the meaty parts of product management, most notably the product roadmap.

The product roadmap is necessary for any enterprise-focused SaaS company that is selling multi-year subscriptions to Global 2000 companies like we are. It’s used as a communication tool for:

    • Clients, both the ones signing the checks as well as the heaviest users/admins of your product. They want to understand (and influence) what is coming down the pipeline for your product
    • Product development team members, including designers, developers, QA, and infrastructure. They want to understand what they should be thinking about from a UI/UX/architecture perspective
    • Sales and marketing. They want to know what they can sell, how it should be marketed, and provide input from a client, competitive and market-driven standpoint

Defining the Roadmap

sample product roadmap

An Example of Mediafly’s Product Roadmap

It can be easy to let the roadmap balloon into a complex, time-sucking monster. The roadmap itself is housed in Google Sheets, and broken up by product category (for us, those are SalesKit, ProReview, Airship CMS, Interactives, Reporting, and Infrastructure/Security). We organize specific entries in the roadmap into five columns, with the following definitions:

  • Discovery: Ideas/features that are “baking.” We usually hear of these ideas from clients, prospects, users, or the market, and are looking to gather more information for these ideas before we move them to the next phase.
  • Evaluation: Once an idea has gathered sufficient input, it moves into the Evaluation phase. During this phase, we’re putting together benefits statements, wireframes, high-order engineering estimates, and public-facing selling documentation.
  • Plan: After we’ve committed to building an idea as a feature, we attach a delivery date (usually a quarter, sometimes a month), and move it to Plan. Here, we are working on detailed requirements, wireframes, and phasing. We are also conducting usability tests and starting to talk about the upcoming feature with our clients and prospects.
  • Build: Once the feature reaches our design and engineering teams, it is in Build.*
  • Release: Recently released features are moved here. At this point, we’re training our clients, updating documentation, and analyzing usage in preparation for improving our newly released feature.*

It’s All in the Details

Sample Details Document

Sample Mediafly Details Document

Some entries in the product roadmap will be hyperlinked to a Details Document, which is hosted in Google Docs alongside the roadmap itself. These documents will vary in structure, but often contain:

  1. Estimates
  2. Requirements
  3. Current and proposed approaches
  4. Discussion of tradeoffs and limitations
  5. Specific customer requests

Every 3-4 weeks, I will review the roadmap with our business leaders (currently, our CEO and EVP of Sales and Marketing). We focus on what’s changed since our last meeting and discuss new data that we’re seeing from clients, prospects, and the market. Then every 2 weeks, I will review the roadmap with the Product, Engineering and Customer Success teams. We focus on what’s coming up in the near future, and often will dive into the specific points to discuss better ways to solve specific problems.

Ad-hoc, I will be asked to present the roadmap to our customers. This is usually accompanied by a short presentation that explains what the roadmap is and how it works. Over the course of any week, I’ll spend about 1-2 hours reviewing and adjusting entries within the roadmap based on conversations, research, and incoming data.

We’ve managed to keep the product roadmap useful and relevant without too much overhead over the past few years by following this model. As we grow the entire Mediafly team through 2016 and beyond, this process will certainly evolve. I’m looking forward to that evolution, and will keep you up to date as it progresses.

If you’re involved in product management at your organization, please reach out or comment below with your best practices. I’d love to hear from you!

The product roadmap is one of the key areas you should ask about when vetting a cloud-based SaaS vendor. Download our cheat sheet for the specific questions you need to ask to find the best one for you!

SaaS vendor Cheat Sheet Download




Mediafly Executive TeamJason Shah
CTO
Jason Shah, a “Flyer” since 2010, is responsible for cutting-edge product development and engineering for the enterprise software company. His duties include overseeing all elements of product development, platform and integration engineering, platform security, customer delivery, and product marketing.

 

*I’ve seen some roadmaps that do not track movement through Build and Release. This happens at (typically larger) companies where engineering, customer support, and customer success are organizationally separate from product management. Once a feature has been spec’d out by product management, it’s thrown over the wall to engineering, and product management wipes their hands of the feature. 

I think this is a huge mistake. Oftentimes a hundred little tradeoffs need to take place during engineering, and if the product manager isn’t available, those decisions come down to engineers who may not have the appropriate user context to make those decisions.

By Jason Shah

November 12, 2015

Filed Under