My roadmap failed. Now what?
The difference between thoughtfully invalidating a hypothesis and poor execution.
We hit over 300 subscribers this week! Thank you all for the support 🙏🏼. I write a new note on Product Management, Growth, and career every Friday. Share with your friends, subscribe to get them directly in your inbox and please send me feedback or suggestions on content you’d like to see!
Time commitment: 5 minute read
Your roadmap failed. You had a sound strategy and your team worked hard to deliver something, but it fell flat. Now you’re worried if your roadmap failing means that you failed. I’ve gone through this experience and had this thought a number of times. Over time, I’ve come to appreciate the intricacies of how to truly evaluate success or failure in the face of a roadmap flop.
To clarify, failure of a roadmap could mean many things. It might mean that the work that you and your team did didn’t drive the metrics you thought it would. Or that a feature you shipped had a low rate of adoption and/or a less than positive reaction from customers. As I mentioned above, the question behind this question is whether the functional leaders of the team (which usually includes the Product Manager) will be penalized for this 'failure.' The answer is a bit more nuanced than just a yes or no. I have learned that evaluating two key dimensions before answering this question is crucial: execution rigor and the quality of gathered learnings. The fact that certain bets don’t pan out is inevitable. It should be celebrated because it’s a sign that innovation is happening and taking bold swings is part of your culture. But if you believe, with a reasonable degree of certainty, that your team had missteps in execution and are confused as to why your roadmap failed (i.e., you have gathered limited learnings) — that’s a clear miss on you.
It’s important you understand the nuances of this post-mortem so that 1/ you can very clearly tell the story as it relates to your own performance, 2/ your leadership (as a proxy for your customers) remain confident in your ability to execute on the next roadmap you create and 3/ you can understand critical points of improvement for you and your team. Let’s dive in to the specifics:
Success vs. Failure when a roadmap fails
You can use the two dimensions from above to claim success or failure:
Success = roadmap didn’t land, but tons of learnings and flawless execution
Failure = roadmap didn’t land, gathered limited learnings and had poor execution
Did you learn?
The litmus test to know if you have gathered the right level of learnings from a failed roadmap is whether or not you’d be confident in your ability to exceed your roadmap goals the next cycle. The thought here is that, despite an initial failure, you’ve now learned enough to be able to double down on the right things and absolutely knock it out of the park the on the next go. If the answer is a very strong no, then you probably didn’t learn as much as you could’ve.
Did you execute well?
Whether or not your team had strong execution rigor is usually something you can answer pretty quickly. I’ve found that experienced product managers tend to just know if their team had strong execution over some period of time. Execution rigor and effectiveness can be measured a bunch of different ways, but I tend to gravitate towards looking at a team’s velocity, malleability, and quality of decision making.
Execution: Velocity
Did you move as fast as possible within the constraints you were operating in? Pretty self explanatory. There are a number of things that slow teams down. Staffing gaps, organizational changes, tops-down asks from leadership, etc. These will impact velocity, but they are known and not always within your control. What should never slow you down is poor planning, lack of escalating when needed (read: ask for help early if you’re struggling), and allowing misalignment to fester. Being quick is absolutely essential (read more here). If you have not done everything in your control to maintain high velocity, that’s a miss.
Execution: Malleability
Did you pivot and change direction as you gathered learnings? A team that starts with one understanding of a problem they are trying to solve and remains attached to that understanding is bound to fail. A product team is a living, breathing organism that is constantly evolving and changing its shape based on customer and market feedback, quantitative learnings, and new dots being connected across an organization. If your team was truly malleable, you were successful even if your roadmap was not.
Execution: Quality of Decision Making
Did you make good decisions when new data was presented to you? If you had open engineering capacity, what did you do with it? Did you sequence and prioritize the right way? When a customer told you X, did you make the right tweaks to the product experience? All of these questions and more relate to quality of decision making. To be clear, you can and will be wrong. But the overall quality of your decisions should net out to be high. When it is high, you are successful even if your roadmap doesn’t end up being.
Product Management (and generally all aspects of software product development) is hard. Sometimes the most well thought out plans fall flat and don’t work out. A subpar strategy will usually work itself out if you have extremely high execution rigor and are adapting that strategy based on rich learnings along the way. However, a failed roadmap due to poor execution and a failure to learn is a clear miss and should be avoided at all costs.
Other notes from Reflections of a PM: