I have always been fascinated by how product roadmaps are maintained. So much so that I feel it necessary to pen a bombastic screed on the topic.

(As an aside, when you talk to VC’s, they’ll ask, “What’s your {2-5} year roadmap?” I want to say, “Whatever needs to get built,” but I think better of it. Life Pro Tip: use words like, “disintermediate.”

I find there is little utility in years-long product roadmaps. Unless you ignore your users/customers. If you have a team conducting market research to determine what to build and then put it in a 2-year plan, then you’re ignoring your users. If you have a team advocating for your users and having hard conversations with engineering and sales, you are not ignoring your users.

This is why Gmail, 20 years later, still has the attachments at the bottom of the email instead of at the top, where they belong: the revenue team is filling the roadmap with better ways to sell your data. I digress.)

The three drivers of a company’s product roadmap are:

Things users want;

Things your sellers want;

Things your product team/engineers want.

They don’t overlap as often as you might think.

Your users want usability (and probably a ton of user-permissions stuff). They bought your product missing certain features, and they are OK with that. They primarily want your existing stuff to get better, easier to use, and easier to get data from.

Your sellers want new features. They usually want the best feature that your competitors already have.

Your product team is more complicated. Most teams want insane reliability, security, and speed. Teams run by CTO’s aspiring to wear black turtlenecks build their own UI framework from scratch so that the one thing the new thing does will be 1% better at something.

Where do they overlap?

1. Your Revenue Teams and Users overlap around UI and reporting. If it looks pretty and has cool reports, it will sell software (1).
2. Users and Engineering overlap in the desire for performance and reliability (2).
3. Development and Revenue overlap at shiny things (3). When you hear “Minimally Viable Product,” you’ve found it. When you hear “App Store”, or “I took some screenshots,” you’ve found it.
4. If you are wondering what happens when they all intersect, I don’t know. I can’t remember all three teams agreeing on a feature.

Your existing customers don’t care about shiny things. But you need to grow revenue, and the CTO is on board, so guess what gets built?

(I would like to say that building shiny things isn’t wholly a bad idea. You need to go for it every now and then. Sometimes, really cool stuff gets built. But, in my experience, that shiny MVP is going to the back of the update line the day it's shipped, and it will suck, forever. Related to this is why your “Admin” area is terrible. Don’t lie, you know it is.)

I have sat in so many board meetings where the CTO presents a roadmap, and the COO/Customer Leader freaks out. I was in an amazing one over a decade ago when the CTO’s priority was “voice enabling the product.”

Everyone blew a gasket.

If your customer falls in the woods, and no one is listening, do they make a sound?

If a user reports a bug or asks for a feature, if someone remembers to do it, it  will be manually logged in a drop-down menu in some silo. It’s also probably logged by someone who has no incentive other than to close the ticket as quickly as possible. In other words, if it gets logged, it will be stored somewhere that’s hard to get to, and no one will read it.

If a user is confused, or says something sucks, someone wraps the user in a warm blanket of apologies and moves on. In the worst case scenario, the user will get something like, “that’s actually how we intended it to work!”

(Once, in a design review, a UI team told me they hid a feature because they didn’t want the users to actually use it. It allowed people to opt in to having a paper check instead of a direct deposit. “How many support tickets did this cause last month?” No one knew.)

It takes hard work to know what the customer wants, or hates. It also requires honesty, and a bit of self-flagellation.

I ran into a CxO who wanted AI to “automatically write knowledge base articles.” I hear this as, “Our product is so confusing that we can’t manage the number of questions about how to use it.”

Get honest: fix the product. No one, ever, renewed because of an awesome knowledge base. Good products don’t need AI knowledge bases. They also don’t need churn prediction or quarterly business reviews, but that’s for another time.

To break this cycle, you must be rigorous about logging every feature request, bug, and UI issue. You’ll need to understand why customers are saying, “how do I do this?” and “that’s confusing.”

(Another data point: track when your people apologize. “What are we apologizing for?”)

How will you gather this brutal truth? You need to put someone in charge of collecting data from your 5-50 systems, organizing it by account, and attaching a cost-benefit analysis to each issue. Then put it in a spreadsheet and review it every week with the Revenue, Ops, Customer and Engineering teams. Soon everyone will develop a healthy anxiety about the quality of your product. Saying “no” to shiny things will get easier.

Do this and your customers will like you again.

End rant.

Do the hard things,

Steve

‍