I was taking another look at VTS’ 4Q17 product roadmap today and it (along with having to check some salespeople making promises that were a little too confident) sent me down memory lane today.
This is our fourth incarnation of a true, external product roadmap at VTS. Now that I’ve rolled these out four times, I thought back on the first time I did this at VTS and the challenges roadmaps present for organizations.
There’s tons of articles on product roadmaps. I wouldn’t be a true product marketer if I didn’t have my own rant about product roadmaps. My rant is best encapsulated by the email accompanying me releasing VTS’ first product roadmap. I’ve copied & pasted it below. Have a read & let me know your thoughts!
Roadmaps are evil
Sooooo here’s the deal. PMM public service announcement: PMM hates sharing roadmaps. Product roadmaps are complicated, ever-evolving boards or lists of specific things (we think) we’re building next or by X date. The problem? They shift. All the time.
Why does PMM hate sharing roadmaps? David Hansson (the guy who created Ruby on Rails and founded 37Signals) said it best.
Customers do not forget your promises — especially not the ones that were won over specifically because of the promises of a road map.
What PMM does like sharing is what I refer to as “product focus areas.”
What’s the difference between a “roadmap” and a document that shows our “product focus areas”?
In a word? Detail.
Roadmaps are detailed lists of specific features that we’re going to build. When shared externally, they create problems.
Why? Because they change rapidly, all the time. As we plan farther into the future, the confidence interval and probability that we will actually develop an item declines. We may reprioritize other critical items over it, decide we don’t actually need it or pivot towards another direction altogether and abandon it. So if we promise a customer that we will deliver this “super special feature” by X date and we don’t, they get upset.
Even worse than mismatched expectations, though, is the slippery slope of selling tomorrow over today.
BUT…if we allude to areas of focus instead of specifics, we 1) answer customer questions about what we’re building next without making false promises or setting ourselves up for dissatisfaction, and 2) give ourselves enough room to make changes without impacting promises or upsetting customers.
It’s better to turn customers away than to placate their instincts and lure them in with vague promises. It’s incredibly rare that a single feature will truly make or break your chance with a customer. If your software is a good enough fit, most people can make do without that one or two things that they’d like to see.
Real life examples
VTS/Salesperson shares roadmap
VTS: “We’re building feature X, Y and Z by 9/31/16.”
(Roadmap changes the following week)
Customer, 10/1/16: “Where is feature X, Y and Z?”
VTS: …..
Customer: “#&%$ you.”
VTS/Salesperson alludes to product focus areas
VTS: “I know robust tools for asset management are important to you as a landlord. Over the rest of 2016, we’re focusing on building and improving tools to let you manage your tenants more effectively and approve deals faster.”
Customer: “That’s awesome and good to know!”
(We release some new features relating to the above without having promised them specifically)
Customer: “Oh wow! Look at these sweet new features! I’m surprised and delighted!”
VTS: “Cash money and happy customers, yo.” #winning
So, without further adieu, I give you VTS’ product focus areas for the rest of 2016.
This was shared in the all-hands meeting a few weeks ago, so it shouldn’t be new. Notice how the items listed are broad focus areas and not a list of specific features. Preach our areas of focus to customers, not false promises for specific features. They’ll be just as happy, and even more happy when we surprise & delight them with new stuff. 
(roadmap image went here)