Field Guide
ToolsButton Text
Product roadmap

Serial entrepreneur Jyoti Bansal details the most critical elements that product leaders must consider in building a product roadmap.

Tab 1
Tab 2
Tab 3
  • TL;DR
  • Ultimately, whatever you decide to build comes down to these four buckets, which are what any product leader should weigh when making tradeoffs and defining priorities for the product roadmap: Building functionality that enables sales to win new customers, making sure existing customers are happy, managing technical debt before product architecture becomes unwieldy, and Innovations and engineering toward future growth
  • It’s impossible to implement all ideas across all four lists at once. Instead, make sure that you are systematically adding the next 10% of your vision and going from 30% to 40% and 40% to 50% and 50% to 60% and so on until you reach your full product vision.
  • Unlike a social product where millions of users can give you instant feedback, you don’t get immediate feedback on enterprise products. It may take months to get the data points to understand if one of your new product features is effective or not.

List 1: What sales wants

The objective of List 1 is to build functionality that enables sales to win new customers. Sales is in the field on a daily basis fighting hand-to-hand combat. To product leaders, the message from sales is usually “if we just had X we could close this six-figure deal!” or "Every competitive situation could turn in our favor if we only had certain features."

At Harness, we call these “opportunity gaps.” If you want to stay competitive, you have to close those gaps. You may want to build some features quickly to compete in that same deal cycle. But for others features, you want to prioritize and build over the next three to six months, so you can keep winning against your competitors over the long term.

When you’re building out this list, ask yourself, “What do you need to win in this market?”

At Harness, we put in place a system for every opportunity in our pipeline and use a tool called Vivun (one of Unusual’s portfolio companies) to track these opportunity gaps. That gives us a dashboard where we can quantify how “expensive” each opportunity gap is for us. As an example, consider a scenario where one particular opportunity gap came up in five different opportunities in the pipeline and each of those opportunities is worth $1 million of pipeline.

Tracking gives us visibility into which product features would be just “nice-to-have” vs. massive costly gaps and allows us to prioritize based on dollar impact. The second trick we always use is the win-loss analysis. Every time we lose a deal to a competitor, we ask the prospective customer for the technical reasons that we lost or whether there were other reasons.

Gaps from the field help drive decisions on multiple dimensions. Revenue is a big one, but these gaps also help prioritize based on severity of need (i.e., will it cause the prospect not to buy vs. just cause friction in the deal?), the segment of the need (i.e., are we meeting the demands of our target market or are we being pulled in new verticals, geographies, company sizes?), and the competitive impact of the need (i.e., should we bolster areas against our top competition?). For example, your sales list will start to look different if you prioritize for moving into the enterprise, expanding internationally, or taking out a competitor.

Keeping track of product requests with List 1 from sales is incredibly important. But that’s only one consideration — or list — of product features that you (as the CTO, CEO, founder, or product leader) should be thinking about.

List 2: Existing customers

As product leaders, acquiring new customers and tracking the opportunity gaps are unfortunately not the only features that require consideration. If you focus only on closing gaps with competitors, you would neglect your existing customers and what they might need to continue to be successful. List 2 focuses on the users who already use your product and what’s important to them.

Oftentimes, existing customers discover they need certain features that they didn’t think of at all in the evaluation process. That’s because as they implement the product and go from being new users to power users over time, they start finding gaps in the product and begin asking for different capabilities. If you don’t listen and demonstrate an ability to offer those features that they need, those customers become dissatisfied and are less likely to renew. One example might be a customer that needs an integration that works with their internal user database, so they can pull in all their users. If you don’t build that feature, their adoption of your product would be limited to a small number of users and they would find decreasing value in your product over time.

The most important thing to consider for this list is being proactive and looking at customer usage and adoption as key metrics. That means examining the data on user engagement and seeing if a customer is becoming increasingly disengaged. You don’t want to wait until they churn, and ask them after the fact why they stopped using your product because by then, it’s too late. Instead, you want to collect product requests from existing customers before they churn and really seek to understand the reasons why customers are not using the product as much as they once did.

At Harness, for every account, one point person is responsible for putting together a list of three things that that customer needs to succeed and three things the customer needs to succeed even more. There are a number of tools that can help you track this. At Harness, we use Natero to keep track of these requests and score customers red, yellow, and green. (Red meaning they’re using our product very little, yellow meaning they’re using the product as expected, and green meaning they’re power users of the product.) We use this scoring system as the leading indicator to determine if our customers are happy and whether or not they’re likely to renew.

Once you have this information about customer satisfaction and requests, there may be several reference points you use to determine which product requests to take on. For instance, you might consider the ARR value of the account or whether the customer is in a strategic vertical you want to dominate. Or maybe it’s a small account, but the customer is really upset. (We refer to this as reading the “temperature” of the customer.) All these things might factor into your prioritization for new product features, but it’s hard to be formulaic about it. At the end of the day, you have to make a judgment call as product leaders.

Delighting customers is extremely important for any startup these days. Almost every successful company has really high metrics for customer retention. So that’s really the second list you have to start tracking and work toward.

List 3: Technical debt

List 3 is may be less exciting but is just as important as the other two lists we’ve described. As you quickly iterate and scale as a startup, you start accumulating what people call “ technical debt,” which you choose to take on as a tradeoff to build your product quickly. That technical debt may require you to re-architect a system at some point or slow down and work on test automation. These are not customer-facing features, so they don’t impact the sales or customers, but cleaning up technical debt is something you have to keep doing to maintain and/or improve product quality.

List 3 is where your engineers track any accumulating technical debt. This may mean pausing or slowing down while you make improvements. Other times, it may mean redesigning a certain feature or writing more unit tests. Working through technical debt can also mean cleaning up bad code that has been assembled for some time.

In terms of how you incorporate this into your sprints, many companies dedicate every third or fourth sprint to technical debt. Others prioritize a couple of items from this list in each sprint or allocate a fixed bandwidth in each sprint to technical debt. In any case, don’t go too long without working through your technical debt. If you don’t take care of your technical debt and to focus on building more features, eventually your product architecture gets so unwieldy that product quality suffers and it creates more serious problems in the long run. That’s why it’s critical to maintain this list and track it as you build out your product.

List 4: Innovations

The fourth and final list comes down to engineering toward future growth. It’s about building innovations that your customers are not yet asking for, but are designed to expand your total addressable market. In the Unusual Academy, we teach our founders to find their beachhead market and expand from there. That means constantly thinking about your next innovation.

Ask yourself, “What do I need to do to expand my total addressable market?”

You can’t depend on existing customers to source these innovations because they often aren’t the ideal customers for new features or product lines. They care about what they bought, not about what you don’t have yet.

For example, our first product at AppDynamics was Application Performance Monitoring (APM) for Java applications, and our customers who were Java programmers were asking for certain features. That was our beachhead market and we had to deliver against lists 1 and 2 to stay competitive and delight customers in that space. But at the same time, we had a playbook for expanding into .NET applications and had to build out this capability, which most of those existing customers were not requesting as they didn’t have any .NET applications.

Eventually, we built out our third product, End User Monitoring (EUM) and our fourth product, Synthetic Monitoring, as we continued innovating and expanding our market.

Essentially, you have to approach this fourth list by working backward from your revenue goals. Say you want your revenue to be $100 million ARR five years from now, $30 million ARR three years from now, etc. You have to have enough addressable market for your product, so you have to ask yourself what you need to do to keep expanding that market and hit those revenue numbers. That means you have to keep working on product expansion and innovations. Otherwise, your growth will slow down.

Balancing the 4 lists of a product roadmap — and making tradeoffs

Ultimately, whatever you decide to build comes down to those four buckets, which is what any product leader should be weighing when they make tradeoffs and define the priorities for the product roadmap. Some requests on the lists are lighter lifts and can be done immediately, like a bug that needs to be fixed. Others take a little more effort and can be accomplished in the medium-term, like slight product enhancements. Then there are the major product requests, which require building out completely new services and features for new customer adoption. There’s variation in the magnitude of requests that the product leader has to balance.

Whether you’re the head of engineering, product manager, CTO, CPO, or startup CEO (and wearing all those hats at the same time), tracking these four lists can help your team align and ensure they are focusing on the right things. But how exactly do you get the balance right between these four lists? It’s a very tricky balance to pull off and you will have to adjust the balance as business priorities change. That means that at any point, you may want to spend more time on one list over the others. Say you’re losing a lot of leads to competitors and are struggling to get revenue going. That means you probably need to put a lot of your focus on list 1 and make the conscious, deliberate decision to slow down on technical debt or innovations and market expansion.

Or maybe you’ve sold a lot of product, but your customers are unhappy or you are having quality issues and churning customers because you’re not keeping up with the things that customers are asking for. Then you may want to slow down on the other lists and spend your energy on list 2 and list 3. In an ideal world, you want all four lists to be executed extremely well at the same time. But in the world of startups — where time and resources are constrained — finding the right balance is key.

Structuring planning cycles in a product roadmap

One thing we’ve found helpful at Harness is putting in place a system wherein every three months, our team goes through what we want to achieve and creates a planning cycle based on that three-month timeframe. Then, the team does an additional mini planning cycle every two weeks. It might not perfectly match up with the three-month planning cycle, but it should align more or less with the broader three-month goals. Finally, we look at what we ship every day. By tracking those daily, two-week, and three-month sprints, we can see how we're making progress across the four lists.

Once a week, our CTO, Rishi Singh, will meet with our sales engineering team to go over the first list and what is important to buyers. Then, he meets weekly with the customer success team to understand the second list and what’s important to our existing customers. He also meets weekly with engineering managers and asks for their lists of technical debt. Once he’s accumulated the lists from key stakeholders, he and I talk about the product expansion and innovation list every few months. Then, he balances what goes into a two-week sprint. It’s impossible to implement all ideas across all four lists all at once. Instead, you want to make sure that you are systematically adding the next 10% of your vision and going from 30% to 40% and 40% to 50% and 50% to 60% and so on until you reach your full product vision.

Unfortunately, unlike like a social product where millions of users can give you instant feedback, you don’t get immediate feedback on the enterprise side. It may take months to get the data points to understand if one of your new product features is effective or not. That’s why there’s no exact science behind this process and why it becomes even more important to use the four lists to track high-level trends. If you’re systematic about capturing which requests recur most often across each list, you can get a sense pretty quickly for the most prominent high-impact product features, allowing you to prioritize your engineering and product roadmap.

Using the four lists process, you might wonder how the feedback loop works to update the company on the status of what product features were picked and how they were chosen. Sharing this framework/concept with everyone at the company gives everyone the important context that there are multiple requests to balance. At Harness, we have one wiki page in Confluence where everyone can see the lists and we mark progress in Salesforce using Vivun, so the sales team knows which new product features we’re working on and when each will be ready to roll out to customers.

Another thing to keep in mind is that as your company grows, this process changes as well. Usually, you start as a “single product” company and stay that way for the first few years or so. Once you have multiple products, you will likely need separate four lists for each of your products.

We recognize there are alternative methods to solving this challenge of product prioritization. We wanted to share this concept of “The Four Lists” approach because we’ve seen it work and we hope we can help every founder in some way. Enjoy the journey and good luck! Onward!

No items found.
TOC
Iterating to MVP