One of the essential functions a product manager at any level must perform is the creation of a product roadmap. This sets the direction of the product for all stakeholders involved. When clients ask if they can have ‘xyz’ feature, the product manager gets to say yes/no based on the roadmap. When sales asks what they should be focusing on in their pitches, the product manager points them to the roadmap. And when leadership asks where their next stream of revenue is coming from, you point them to the roadmap. It’s incredibly simple to understand the ‘what’ behind the task, but it’s an entirely different thing to understand the ‘how’. Let’s get into some different techniques I’ve seen used to create a roadmap, and you might just walk away with what you believe the best way to go about it is with your product.
Traditional Roadmapping
Pre silicon valley ideas influencing the market, roadmaps started from the top. Leadership would provide the vision and direction for a product, and engineers were tasked with building it out. The product manager role wasn’t a thing for much of the early development of the tech products you think of today. Now though, companies are recognizing that they are product companies, so it makes sense to have an individual who owns each product that the business offers. This marked the next evolution in product development, and the one I like to call the traditional method of developing a roadmap.
There is some good that came out of this shift to product managers being responsible for products, but it’s not perfect. On the good side, it provided an avenue for each product to get the attention required to make it great. No longer did clients have to communicate directly with company leadership in order to influence the direction of the product. Sales, marketing, consulting, engineering… Every stakeholder now had a way to make their voice heard, and good product managers listen. So the traditional thinking was to listen to stakeholders, condense the feedback into a well-defined problem, and add a solution to that problem to the roadmap. That is all well and good. The trouble is in this traditional method of roadmapping, the solution generated still had to be approved by leadership, making sure it met ‘business needs’. This type of thinking is where I see a lot of businesses struggle. They want to be a product-first company, but they define what they will and won’t develop by business priorities. They tell product managers they have the authority to set the direction for their product based on what problem’s their clients are facing, but they have metrics that must be met that influence the direction of the product. Ultimately, product managers are there to facilitate the direction of their product, but they don’t have the final say, even though it’s usually broadcast by leadership that they do. The result is a backlog of features that may or may not be providing value to the end user, but you spend the time and money to develop them because leadership says you should.
Alternative Methodology
As we saw, the traditional methodology for developing a roadmap has some good, but also some bad. It leaves companies in a place where they think they’re a product-first organization, but they’re really not. The business is the priority, and the product reflects that. It leaves them in a place where the roadmap has features that may or may not be addressing the exact issues that clients are facing. The time and money is spent to develop these features with little room to pivot when feedback from a client isn’t positive mid-development.
Marty Cagan in his book “Inspired: How to Create Tech Products Customers Love” outlines a different approach to building the product roadmap. He believes it’s important to acknowledge that “at least half of our product ideas are just not going to work.” AT LEAST HALF! Think about that for a second. An entire team of well-paid, intelligent product people and engineers end up creating something that doesn’t make an impact more than half the time. What are we doing wrong in this process that creates so much waste, and how do we fix it?
The first problem that needs to be solved is the commitment to hard deadlines. Many times, they aren’t necessary, and they’re used as a control mechanism to make sure the team is doing work. If that’s the case, leadership needs to hire individuals they can inherently trust to deliver a solid work effort routinely. Many projects don’t require a hard deadline, and will develop naturally at the pace the product team is moving at. There are instances though where deadlines have to be set for the business to function. Often though, the timing of those deadlines is off. Instead of setting them before the project kicks off, acknowledge there are many unknowns. Spend time investigating each individual feature of the project, and set deadlines for them when investigation has revealed many of the unknowns. Also, build in some time for iterating. It’s rare that a feature is delivered and solves the client’s problem immediately. If the business side can accept these challenges in product development, the end product will be better and deadlines will be met more often than not.
Another problem that must be solved is who is influencing the final decision for what goes on the roadmap. I mentioned in the traditional method, it’s typically the business leaders that are setting the direction. The problem with this is they aren’t the closest to the customer. They’re more concerned with financials and stock prices than creating great products that solve customer needs. The reality is, the roadmap needs to be driven by the product team, with influence from the business. It’s a partnership. The product team should be the expert on the problem domain. They understand their client’s pain points more than anyone else in the world. These problems and potential solutions need to be communicated to the business in a way that helps them understand what the highest value development items are. The business will always look at things through the lens of financials, but helping them see the value of the long-term fix that results in an industry leading product as opposed to the short-term fix that results in a quick cash inflow is the difficult part of a product manager’s role.
Wrapping It Up
I’ve only scratched the surface on ideas around creating a product roadmap. Hopefully it’s clear that there is always going to be tension between what the business wants and what the product team wants. Casting a vision for the product future is a vital part of the product manager’s job, one that takes experience and practice to cultivate. It’s ultimately a two-way street where both sides have to give and take a little, reminding each other that in the end, creating products that customers love is the ultimate goal. Let me know in the comments what successes and failures you’ve seen in the attempt to create great products!
