Product roadmap: 4 things to avoid

Managing an agile product roadmap is no easy task. You have to find the right balance between planning ahead and foreseeing trends and at the same time being flexible enough to adjust your course when new opportunities arise. It requires smart hiring in order to ensure that your team has an agile mindset and good internal and external communication skills. Today, let’s take a few minutes to look at some things that you might want to avoid in your product roadmap.

The ‘demo’ feature

You’ve been there. You want your product to not just be the best on the market for your customers, but you want to wow prospects at first sight. No matter how confident you are in your product, you feel the need to implement a certain feature because it would demo really well. Be careful. Resist the temptation to put something into your product for the wrong reasons. Critically assess the following:

• Is this feature really going to move the needle for your customers?
• Are your customers really going to have the resources and processes to use this feature?

A gimmicky feature can have several negative outcomes. For instance, your prospects might immediately catch on and question the soundness of your overall product roadmap. Or they might be excited about it, but once they’ve become a customer, they realize that the feature that “sold them” on your product isn’t really all that useful. Disappointment inevitably sets in. In addition, building a feature solely for the purpose of demos can be somewhat demoralizing for your developers, as they are committed to building the most helpful features, not necessarily the most “salesy” ones.

Build for a particular prospect

The following scenario is especially common in the startup world. You’re hungry for new customers in order to gain traction as quickly as possible. And here they are: a big fish prospect. Getting them onboard would be a game changer. But – there’s a but: The prospect is asking for a new feature. Hopefully, they make the commitment to purchase your system if you accommodate their request. Take a step back. There are very few instances in which this approach is advisable. Yes, there are cases in which the requested feature just makes a lot of sense, but veering from your roadmap in order to make individual customers happy can be treacherous and is not scalable as your product matures and your user base grows. Ask yourself:

• If and how the requested feature would fit into your overall roadmap
• What impact would this feature have on other parts of your system?
• Would this feature benefit the vast majority of your customers?
• Is the complexity of this feature going to prevent you from working on more impactful ones?

Copying the competition

In one of my previous posts, I talked about the futility of being overly concerned with your competitors. If you’re doing your homework, staying connected with your customers, and staying on top of emerging needs and trends, you shouldn’t have to spend too much time worrying about your competition. That being said, it always hurts to lose a deal to a direct competitor, and if your sales reps tell you that it was because you didn’t have feature X, it’s only natural to reflect whether it wouldn’t make sense to just go ahead and build your own version of said feature. Again, stop to think about the following:

• Is there a realistic use case for it? We’ve actually faced this situation several times with Hannon Hill’s flagship product, Cascade CMS. One of our competitors came out with a few features for which there really didn’t seem to be real world use case. Yet, they resonated with prospects during the demo process. We opted not to replicate the features and instead, to focus on the things that we identified to be more useful for our customers.
• What is the problem that this feature is intended to solve? It’s always best to first talk about the goals that a user is looking to achieve and the problem they’re trying to solve before implementing a new feature. Before you emulate what your competitor has built, think about the best ways to solve the problem you’ve identified.

Always keep in mind that every minute you spend copying your competition is a minute you could spend innovating.

Too much complexity without validation

Speaking of innovation, there’s also a risk in going overboard by building a highly complex feature that has not been vetted. Des Traynor, co-founder of Intercom, once used the analogy of building a cupcake before you build a wedding cake. This is very fitting when it comes to creating something brand-new without knowing if your customers will adopt it. When you’re trying out something highly innovative, start small, get frequent feedback, and adjust quickly. Don’t go down a rabbit hole. That being said, if your product is an enterprise system, this might present a challenge because your users likely expect very robust and complex functionality from your product.

What about you? What are some of the things that you avoid with regard to your product roadmap?