A fellow product manager that’s working on a new product idea recently wrote to me:
“Common feedback I receive from our our engineers and executives is they don’t have a good grasp of the product vision. They say, “OK, that’s great, we can build that. But where are we going with this if we find the hypothesis to be true? What’s the long term vision for the product?” In essence, they’re asking what’s the end goal in 2-5 years, and if you show me that I’ll have a better sense of the architecture and tools I need to account for.”
This product manager is right at the very initial stages of their product idea, where he still needs to test the problem and solution hypotheses. But he’s already being asked for a long-term product roadmap! Sound familiar?
While the request seems perfectly reasonable, it’s misplaced at such an early stage. The question about architecture and tools seems perfectly reasonable on the surface, but it’s a scale question, and is not the right one to be focusing on before you even know if you’ve identified the right customer problem and have proof that your solution approach is viable to solving that problem. Execs are trying to assess the potential market opportunity, the underlying investment that will be needed, and the speed to achieving ROI. So naturally they want to see the long-term roadmap. Again, perfectly reasonable on the surface, but at such an early stage, you’re likely in no position to be able to answer the question.
Even at the conceptual stage, you likely have a list of potential features in your mind. You could prioritize them using one of the many scorecarding techniques written about by seasoned product practitioners. (See this, this, this, and this, to reference just a few.) These are all very valid techniques written by product folks who really know their stuff.
If you do that, though, you’ll be wasting your time. Creating a product roadmap is predicated on having a coherent product strategy, which is predicated on having a validated understanding of who are your customers, what are their pain points, and whether they’ll find your solution valuable. If you don’t even know if customers will buy your solution, what’s the point in having a roadmap?
So when do you develop a roadmap for a new product? I get this question a lot on my product help calls, so I thought I’d share my answer here.
For a startup product, the first step is always to identify the customer segment and customer problem. Quickly capture your product vision, formulate your customer, problem and solution hypotheses, and systematically test them. As you go along, you need to identify potential “innovator” customers and early adopters to whom you could deliver your solution — typically you build the product for these folks first. If practicable, test pricing at this stage as well.
Figure what you absolutely must deliver to these folks to solve their #1 problem, and work like hell to deliver it as quickly as possible. All other features get cut from scope and sit in the backlog. Again, with respect to pricing, what the customer is willing to pay to solve for takes clear precedence over anything else.
After delivering this, say, MVP, you need to actively gain feedback from these early customers. You’re using your delivered product to gain deeper insights into the customer’s problem, and you’re trying to understand what you need to improve in the product to (a) get these customers to stick, and (b) attract more new customers.
In addition, now that you have an initial set of engaged customers, you can also try to test their second level set of problems (or discover new ones). Understanding those problems may identify new enhancements/features. You’ll now be armed with a set of improvements, fixes and new ideas that you can put into the backlog.
If you have a sales force, and have armed them to sell your MVP, make sure you’re actively gathering feedback from them as well. Of course, not all their feedback may be feature-related — some may be about testing and evolving your sales messaging and positioning. However, as it relates to feature gaps, you put those into the backlog as well. I pay particular attention to feedback that’s preventing a customer sale.
You’ll have a pretty good backlog at this point, so you can now start building an initial roadmap. Start by prioritizing the backlog based on a reasonable customer-centric set of criteria that also help deliver on your company goals. I typically skew my priorities heavily toward voice of customer (VOC) feedback. While at any stage of the product lifecycle, features should solve tangible customer problems, it’s even more important at this early stage.
I also factor in the company’s strategic goals. For example, if the company’s focus is retention, features that create stickiness may carry more weight; if the focus is growth through customer acquisition, then sellable features may be more important; if it’s revenue through customer penetration, features that drive engagement and up-sells may take priority.
I also make some allowance for operational issues. I may not necessarily have a scale problem (yet), so these type of issues may not take precedence over VOC or driving revenue; however, I don’t want to completely ignore technical debt or reasonable operational fixes.
Once you have a prioritized list, socialize it. (Read this post by Bruce McCarthy on using “shuttle diplomacy” to get buy-in.) For the top priority items on the list, get t-shirt sizing from Engineering, and make a final call to sequence out the items based on customer value vs. LOE. Now you’ve got a validated product in the marketplace with a decent first-pass roadmap that you can build upon.