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

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, andInfrastructure/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 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 comment below with your best practices. I’d love to hear from you!

(Cross-posted on the Mfly Blog)

Deepak Jeevan Kumar of General Catalyst Partners wrote a pretty good overview piece on TechCrunch describing his point of view of how to launch a F500-focused enterprise software company. Many parts of it ring true based on our experiences at Mediafly and my previous experiences:

CIO offices in Fortune 500 companies are trained to play it safe. Many companies stick to Oracle, VMWare, EMC and Cisco not because their products are the best in the world, but because no one got fired for selecting one of them.

That’s so very true. Often this is driven by their own experiences, but just as often it’s driven by internal politics. We heard recently from a customer (who was discussing another part of their business, thankfully) “if we don’t go with Microsoft for [terrible product A], our prices will go up on [pretty good product B used somewhere else], and we can’t have that.”

Do not use unpaid PoCs even if you have to wait one to two months to get a paid PoC.

This is very important. Customers that don’t put money behind a proof of concept simply don’t have enough skin in the game. We’ve been on the wrong end of this story before:

• Prospect says “well, if you have feature X, I’ll be willing to buy then.”
• You spend days/weeks/months building feature X, in hopes of securing their business
• You show feature X to prospect
• Prospect says “Great! Now, if you have feature Y, I’ll be willing to buy then.”
• Repeat

Customers who are not willing to engage in a paid proof of concept are not worth it, no matter how large.

Some parts of Deepak’s perspectives don’t seem right:

Second, power and influence in the early days can come from public silence for enterprise startups (unlike consumer startups). Your competitors, the media and your customers like a game of treasure hunt to find out what you are doing.

In reality, as a “stealth startup”, no one really cares what you are doing. And the last thing customers want to do is to spend time trying to dig to learn your secrets. They are usually too busy running their business.

As you are selling to a select group of Fortune 500 customers, there is no point in announcing to your powerful enterprise tech competitors (e.g Cisco, Oracle, IBM, HP) what you are up to. Convince your design customers first before you open up the kimono.

Again, even if your largest competitors figure out what you are up to, it’s highly unlikely that they will try to usurp your untested, unproven ideas. They are busy running their businesses and executing on their product and company vision, to bother trying to knock you out. Of course, all this changes when you start to generate real traction and, more importantly, win deals from under their nose. But you are not at this stage yet, pre-customer startup.

That being said, I do agree with the general premise that you shouldn’t spend time talking about the product too publicly. But for these reasons. I believe that’s the case because you should be 100% focused on executing on delivering your product to these large companies that are taking a chance on you. Spending time engaging in PR is a waste of your time, as you haven’t proven anything yet.

Overall, this article is definitely worth a read for anyone starting down this road.