A public roadmap sounds like a good idea. Except it isn’t.
Prospects and existing customers want to know what’s coming and when. Typically via the Sales team or the Directors, the Product Manager is tasked with publishing a roadmap.
The aspiring PM creates a solid public roadmap with features, themes and release dates. It might have looked something like this:
It’s well received. Grumpy customers are quelled. New customers have signed up. Everyone is happy.
And it’s all downhill from here.
The Improved Billing Algorithm is more complex than you thought, and the date slips. Then slips again.
The New Shopping Cart ships on time. Except it misses the mark. Turns out it isn’t fit for purpose and receives poor feedback. Adoption is low and you’re now caught between two poor choices:
a) Going back and re-working it; and delaying your next feature
b) Moving on and leaving this turd out in the wild
Centralised User Management was rushed out to hit the deadline. Whilst a good concept, it was full of bugs which ended up blowing up your support desk.
Email Campaigns were supposed to be a home run. Marketing were desperate to recover from the past few releases and planned an entire multi-channel campaign on launch day.
However it just didn’t sell.
It was a feature launch with no proof it worked, no case studies and likely poor training and support.
After this poor run of releases, your customers now raise an eyebrow to your roadmaps. Your reputation for delivering value on time has taken a beating.
It didn’t have to be this way.
Customers don’t actually want a roadmap. Roadmaps are a means to an end. A classic case of over-promising and under-delivering.
They want products that serve functional, emotional and/or social needs.
So what can you do instead?
Zoom in on your current features, and zoom out on your upcoming features.
Zooming in involves measuring feature adoption across your user base. Often decent features you’ve already built aren’t being used properly, due to a miscommunication of value (“why should I use it”) or lack of customer education (“I don’t know how to use it”).
Find out which segments of users aren’t engaging and why. Then empower Customer Success and Support to target and educate those groups.
Helping your customers get more value out of what you’ve already built increases ROI.
Zooming out on your roadmap means removing all specifics, like features and dates, from the roadmap. Instead you could discuss themes.
This approach could roll up into a customer-facing statement like this:
“This quarter we have a big focus on business outcomes. We’ll be releasing a series of webinars educating users how to use our reporting engine to drive operational success. We’re also developing new features aimed at driving your sales engine.”
You could visualise this in a number of ways. Here’s one take:
This may not be the roadmap your customers wanted, but it’s the roadmap they need.
You’ve now created the black-box space to work with customers that are willing to be design partners or a beta group.
Through them you can test ideas and early iterations. Features may take weeks or months of tweaks before you do a big marketing push and rollout.
When you do this, you increase the odds of success by a magnitude. You have proof the feature works, polished training content, experienced customer support, the feature is bug free, customer testimonials, and vetted pricing plans.
Then you’ll have moved from broken promises to customer delight.
So ditch the public roadmap. Focus instead on creating power users, development themes and iterating with your design group.
Why You Should Run Your Business Without Roadmaps. (2019). Seeking Wisdom. [podcast] Available at: https://soundcloud.com/seekingwisdom/no-roadmaps [Accessed 5 Jan. 2019]