It’s TRUE. Feature driven roadmaps fail. I’ve used them the vast majority of my career until recently so I am telling you from my experience of actual, authentic FAILURE. Here’s what we ALL know, but maybe aren’t really ready to admit to ourselves about our beloved but failed roadmaps.
#7 You move on after the MVP is done, never to return
We all say we won’t do this, but the reality is, most of us do. There is some sort of mental checkmark when the MVP goes out and then there is and then there is pressure to move to the next most important thing. We all say to ourselves and our team that we will come back to it, we will make it better and those short cuts in the UI and bugs are just temporary, but we don’t come back to it often EVER.
Why does this happen? The MVP moves the needle a little and often just enough to check it off the list and mark it as “done”. As many of us have experienced, this is SAD and DEMOTIVATING to you and the team. I’ve even been embarrassed when I think about these abandoned collection of features that could have been something great but become the thing that you are making excuses for when a new product person starts at the company and they start asking questions.
#6 You’ve sold a solution that isn’t your first pick anymore
While we live in an agile world with sprints and design thinking, often we find ourselves identifying and selling solutions (a.k.a. features) months in advance of when we actually get to them on our roadmap for execution, and, by the time we get to them we don’t think they make as much sense. Those of us developing annual or even 6-month long roadmaps are the most susceptible to finding ourselves painted into corners.
And, no wonder - we are dealing with markets changing, customer expectations changing, new and fierce competition, varying funding levels, employee comings and goings - NOTHING stays the same for very long, so it makes sense that our roadmap needs to evolve too.
However, getting to alignment on what’s on the roadmap in the first place takes a tremendous amount of negotiating and maneuvering. So, we have this tension between what we want to do now and our previous efforts. Since we worked so very hard to get to alignment on the original roadmap, moving stakeholders away from what we anchored them to months ago and onto the new idea is often impossible and not worth the time and effort. So, we build, and we build the thing that isn’t more important :(
At one company where I worked our customer’s expectations changed so quickly and considerably, that the features we eventually released were completely irrelevant. We executed beautifully (okay a bit behind schedule) but everything had changed over that 9-month period. A true fail!
#5 Once you get into the feature, you realize it’s WAY TOO BIG but now you’re stuck!
Yikes, it seemed in your t-shirt sizing exercise with engineering you had a good sense of how long the feature would take to develop. Marketing and sales are already promoting to new customers the feature that you committed to building. Now, you are in it and well, there are some issues. Maybe there are unanticipated architecture issues or you need to touch the old code to make it work or you have to re-work a whole section of the product to make the design hang together. Whatever it is - it is going to take much longer to deliver than what you thought it would take months ago when you created your roadmap.
The problem is that now you’ve committed and you have those blocks on your roadmap estimating time. While you and the team spend weeks or months developing, you are failing because you are way off your planned time to release.
#4 There’s a better way to solve the problem and it’s not new software development
Months ago you thought you’d need a custom build, but you figure out over time that there is a solution out there that you could use. It might be a white label solution or a tool that you already have like WalkMe, Zendesk or Hubspot. Or, if customer support would make a process change you wouldn’t even need the feature you committed to build. No matter the reason, you don’t think you should build it. Maybe you even make the case to remove it from your roadmap, but you then appear to be skirting the work or costing the company additional $$. It may be the right thing for the company, but it feels like a fail, something you and your team committed to and did’t deliver on. Even worse, most of the time that engineering budget saved gets absorbed into other projects that take longer than estimated.
#3 Good ol’ feature creep
It must be human nature, because it happens in all kinds of building efforts including home renovation. Feature creep is the, “well, we might as well fix this and redo that while we are in that code or that area of the product.” Gosh, it is so easy to slide into feature creeping - on a daily basis reminding myself to stay focused. Building to a feature lends itself to feature creep. Solving a customer problem instead of delivering a feature helps to focus the team and helps you manage feature creep.
#2 You can’t deliver all the features on your roadmap
Due to #7-#3 listed above, you are behind and it is just impossible to deliver on what you committed to moths ago. While you and the team have been working extra hard to deliver, it is just impossible and despite all the great work is just another FAIL! There is no path to success. But, what if your job was to OWN solving the customer problem…then things could be quite different.
#1 You don’t always solve the customer’s problems!!
This is by far the biggest issue that happens with a feature driven roadmap. Even if you have flawlessly executed on your roadmap you may still have not have solved your customer’s problems. Feature does not = solving a customer’s problem. In fact, we get so off track that what we ultimately deliver is combination of compromises and de-scoping with our features.
Aren’t we all here to solve our customer’s problem rather than deliver features?! We talk about “customer problems” all of the time, but when it comes time to roadmapping we forget solving the customer’s problem entirely and revert to features. What if we created a customer problem driven roadmap? What would happen then?