Product roadmap planning is one of the trickier product management tasks. The product leader’s role is to balance all the different product roadmap pressure points and focus on maximizing the business outcome. The number of variables the PM needs to take into account are substantial. This makes the job that much more difficult especially as engineering resources tend to be constraint.
Some of the contributing factors influencing how product leaders will weigh priorities include:
- New customer acquisition vs. customer success focus. product investments targeting new customer acquisition will typically be somewhat different then investments targeting customer retention. Of course, you’d like to focus on areas which benefit both but that’s not always possible. For example, that new addition that really helps demo well and show instant value will not necessarily be important for longer term customer retention.
- Bugs and feature requests. Typically, these requests directly come from customers via the support or the technical field organizations and could fill up the whole roadmap for many years to come. Also known as “the bug tracking system”.
- Longer-term product vision and strategy. Typically, the CEO and other key leaders in the company have a long-term view for where the company needs to go to maximize market opportunity and outcome. Such investments will often be in conflict with short-term pressure points.
- Competitive dynamics. There are situations where competitive dynamics really come into play but often they are not the primary reason why the business isn’t growing faster. There is risk of thinking too much about competition although it can be important if you’re clearly and consistently losing to the competition on a very clear set of capabilities.
- Technical debt. No one except for the product people care about this category. But we all know that if ignored for too long, technical debt can lead to major velocity and longer-term customer satisfaction challenges.
- Large customer requirements. Often large customers take your product to new limits. As part of that there may be recurring asks from the largest of customers which are not as relevant to the broader customer base. These are often tricky requests and need to be weighed very carefully as they may require a lot of investment for a small set, yet high paying customers. Weighing opportunity cost against benefit is key.
- Broader market dynamics: The market is always shifting in new directions. Short-term such investments typically won’t pay off in revenue, but if you don’t get ready today you will be left behind. For example, companies who were proactive about Cloud vs. companies who were late and reactive and are now playing catch-up. Also known as getting stuck in the innovator’s dilemma.
- Expanding use-cases: There are often ways to make adaptations to the product that can broaden its applicability into new use-case scenarios. For example, when Splunk moved from being primarily an IT-centric log analytics engine to broadening the same technology to machine-generated data and tailoring it to additional non-IT use-cases e.g. sales & marketing metrics. This can fall into the longer-term product vision category but I think one that deserves a separate callout as it is often less about making a big technology investment but rather a minor investment plus repackaging and repositioning. The go-to-market impact may be a lot more significant.
And the list goes on… Needless to say product roadmap planning is a very challenging effort and needing to weigh the short and long-term effectively within the constraints of finite engineering resources is often the product leader’s biggest challenge.
There is one aspect of product roadmap planning which I feel many product leaders leave out but should not. That is matching up buyer personas with the product roadmap. For most products, there is not just one target persona. While not every persona is the decision maker it becomes critical that there be value for each influencing persona. Therefore, constantly weighing the product value by persona will also give the product leader a good idea of which personas are being well taken care of vs. others who may not perceive as much value in the offering. While many companies try and map out their target personas this is typically done in a very shallow way and ultimately is not used to truly weigh product value and roadmap investments. It tends to be used more in targeting exercises by marketing and sales enablement tools.
Some key things the PM should know about the target personas include:
- What flavor of titles they may have?
- What some of their characteristics are? Their background and thought process, what they care about, how they typically spend their time, what makes them look good in front of their bosses?
- What their key concerns are? What do they need to get done? what do they need to improve? what keeps them up at night?
- What is the value you currently offer to that target persona? If you are very honest with yourself, in a product which requires buy-in from multiple persons, you will never have every feature be valuable to every persona. It needs to be crystal clear how the product value intersects with their concerns and ensure that there’s perceived value there.
At Zend, the company I co-founded, we spent time mapping out the value per persona. Our PHP application server, Zend Server, has a number of personas that need to buy-in to the product. This includes the head of development, the production operations team and developers. We are a very developer-centric organization and have invested in developer tools for many years. However, as we went through such an exercise it became very clear that we had very strong value for the head of development who was constantly looking to further professionalize and streamline application delivery (our decision maker) and we had strong value for the production operations team thanks to strong management, security, compliance and DevOps capabilities.
But as we mapped our capabilities onto the developer it became clear to us that while we had huge value to production applications, we were a bit lighter on the “what’s in it for the developer?”. It was very interesting given developers are our #1 lead source due to the successful developer tools we deliver to the market. But Zend Server was not primarily designed as a development tool but rather a runtime capability to best support running business-critical applications.
With this learning and the fact that developers are extremely important to us we recast our 12-month product roadmap to prioritize value targeting the developer persona and reduced the amount of investment in enhancing our production features. While we did not reduce the production investments to zero, we significantly reduced them for a limited period of time in favor of developer value. With a very clear and immediate focus to add more developer-value and leveraging our deep technology expertise in the PHP runtime we designed, a new product capability called Z-Ray. Z-Ray’s goal is to change the game when it comes to developer productivity and code quality. Deliver in-context insights into developer’s code while they are developing it without requiring them to change how they work. We developed this capability in an agile manner with customers in the mix from a very early stage (alpha). The ongoing customer feedback made a good idea great, and within nine months we shipped the killer feature.
Z-Ray has made a big impact on our customers and the enthusiasm by the developer persona. In addition, we successfully tied the capability into the DevOps and production cycle so that it also adds value to the other target personas including head of development (benefit: team productivity and code quality increases), the DevOps role (benefit: reduce friction throughout the DevOps cycle by tackling errors early on in the development and testing stages) and the production ops role (benefit: Z-Ray has production capabilities and it also helps eliminate many errors going into production, hence, less nightly awakenings).
But this article is not about Z-Ray. It’s just one example of many on why weighing product value and product roadmap against the target personas is as important of an exercise as weighing against the many criteria listed above. Without clearly understanding the value delivered to each target persona, product leaders will not effectively balance product roadmap investments and will lead sales and marketing astray on how they communicate and engage prospects.
My previous article on the product marketing discipline emphasizes how important it is these days to ensure communications have the right level of depth and specificity to truly get attention in the market place. Getting the personas and delivered value right is a big part of making that happen!