This Product Roadmap Kerfluffle is Getting a Bit Silly

In case you’ve missed it, there’s a big Kerfluffle on right now over whether SaaS companies should share a product roadmap with customers or not. The charge against is led by Kashflow CEPO Duane Jackson, who says sharing your roadmap is flawed because:

- Reduces agility

- Creates expectations that make it harder to delight customers

- Introduces competitive risks

- Sets companies up for a fail if they have to change their roadmaps

Coming at it from the other corner is Dennis Howlett, who thinks it is “bonkers” not to share the roadmap and insists customers have a right to know and prudent customers will insist on knowing. In a third corner is Ben Kepes, who seems to have decided that while the arguments to share make sense, the success of KashFlow and others (37Signals to name one high profile example), and because he says as a small business owner, he knows it just isn’t that important because the decision cycles are so much shorter.

I’m coming down on the side of Dennis and sharing the roadmap

I’m on the side of sharing for multiple reasons.

First, the arguments against sound an awful lot like companies are afraid their customers will have too much control. Sorry, but that’s no way to partner with your customers, and I believe above all else that it is critical for you partner with your customers. That is the road to delighting them. Why live in fear of your customers when you could partner with them?

This all sounds so much like arguments I’ve heard from Product Managers against Social Product Innovation Sourcing (aka Ideastorms). It sounds like the arguments I’ve heard against Social CRM. ”We’re afraid of what our customers might say or the standards they might hold us to under the public spotlight.”

Hey guys, get used to it. The whole world now operates in that spotlight courtesy of the Internet and all the many ways it gives your customers to get the word out. You can’t just choose not to participate, especially if your competition is wholeheartedly embracing it.

Second, having worked with customers of all shapes and sizes, from small to gigantic Fortune 500, I’ve never had a problem of having a customer back me into a corner I couldn’t get out of. You’ve read all the advice about authenticity, honesty, and candor with Social Media? Guess what, the Social Media guys didn’t invent that stuff, it’s simply the right way to deal with your customers. If I don’t have a roadmap that’s baked well enough I can talk about it, shame on me. That means I’m waiting for some sort of Monkey-on-a-keyboard A/B testing to figure it out for me and that’s not going to happen. That’s a vision-less product organization and it is doomed to be inferior for a lot of more fundamental reasons than lack of a roadmap.

If I can’t have a well-reasoned conversation with a customer wherein I explain the business reasons why I have to change my roadmap and they don’t get it and can’t abide it, shame on both of us. Shame on me for being unable to sell it, and for not having delighted the customer enough elsewhere to get the benefit of a doubt. Shame on the customer for being so high maintenance and not understand that their best course is for me to be successful and that means satisfying more than just them. I will tell you in all honesty that’s never happened to me, despite having to break the news of roadmap changes more than once.

One of the best product managers I’ve worked with (Hi JP!) used to have a saying about this. There are no stupid features and no “No’s”. There is only prioritization, and that is fluid.

Third, let’s talk about the competition. Are they truly that clueless that they don’t have their own roadmap that’s pretty similar to your own? Particularly when it comes to things customers are asking you to sign in blood for? Don’t you think their customers are asking them for the same things? Of course they are. Those areas are not secrets and you’re kidding yourself if you think they are. On things that are truly visionary and innovative, precisely the kinds of things you don’t want the competitors to know about because they’re not thinking of them, who says you have to share the whole roadmap? There’s your opportunity to delight customers and confound the competition right there.

Things your audience is begging for are not plums waiting for you to pick and hold up for the adulation of the crowds. They’re cases you got blind sided and should’ve paid closer attention to. Fixing them is the elimination of a negative, not the creation of a positive. If you think otherwise, you are the man to be in charge of innovation at Microsoft, because that’s always been their problem.

Best Practices for Sharing Product Roadmap

Okay, so let’s get past the argument and talk about how best to share product roadmaps, because there are some important ingredients to maximizing the benefits of the practice.

1. Everyone does not get to share the roadmap and it isn’t public. As SVP Engineering/CTO, I have insisted that deep roadmap dives be presented by the CTO and/or Product Managers and not by Sales. Roadmap entries need a firewall separation from the negotiation and sales process. Getting to see the roadmap is a tightly vetted process. Only real serious customers who are also good customers get to see it. We will not drop it on leaflets out of airplanes to every lukewarm lead that comes along. The salesperson that wants a Roadmap Briefing for their customer has to make an impassioned plea for why that makes sense.

2. The roadmap is high level. It talks about areas of focus at the 20,000 foot level, and it calls out just a very few key features for each area of focus. Features you’re absolutely certain you must have as part of the area of focus, and are therefore unlikely to change unless the whole focus changes. It is not a detailed Market Requirement Document replete with UI mockups, giant bulleted feature lists, and all that stuff. It’s just enough so that if the customer says they need “X”, you can tell them when you will be focusing on that area, ask to understand the exact problem they’re trying to solve, and render an opinion on when you might (or frankly might not) attempt to solve the problem. The goal of such discussions is to assist the customer with the phasing of their own roadmaps, and to help them to understand whether the strategic direction they’re moving in matches your own direction. In other words, is this marriage going to get better, or are we really destined to go our separate ways?

3. We do not change the roadmap as part of a negotiation. We accept input that will be factored in, but we’re not going to talk about the outcome until post-sale. This is a strong ingredient in selling what we have, or at least what we’re firm we intent to build.

4. The roadmap is fluid. Get the disclaimer out there right up front. We’re not here to negotiate contractual obligations. We’re hear to share our best thinking, and that can change based on new information. We will promise not to act arbitrarily and capriciously, and to communicate well. But we will also promise to be good businessmen intent on maximizing overall customer satisfaction as best we can.

5. We do not talk much about how the features will work. Instead, we talk about the problems we intend to solve. Benefits, not feature roadmaps. These are not joint UI and Architecture design sessions.

6. We’re very honest about not doing something, and very diplomatic about how we say “No”. Product roadmap sessions are not the time to say “Yes” no matter what. They’re the time to get some cards on the table and understand the problem the customer is really trying to solve. If it’s a problem you think many of your customers have to solve, there is a strong business reason to tackle it, and you should say so. If you don’t you need to get that out front too. There are really a couple of different key “No’s” to be able to deliver:

- This doesn’t make good business sense for very many of our customers, so therefore we aren’t going to go there. If we hear more requests for it, we might revisit.

The subtext, particularly for smaller companies, is that the customer should want you to be successful by working on areas with the broadest demand. Discuss this candidly and you will have implicitly helped that customer to understand their problem better too. I have more than once seen a customer walk out of the discussion and wonder whether they might deep six the idea themselves if nobody else was doing it. Customers know when they’re being unreasonable. Those customers that know it and don’t care may not be the customers you want to divert your whole roadmap to satisfy anyway.

- This makes sense, but it can’t be done immediately. We’ll slot it into the roadmap, but it will be out there a ways.

Do not talk about your roadmap for more than 4 quarters out. Anything beyond that is baloney anyway. So the worst case answer is, “Yes, that makes sense, but it won’t be this year. We’ll keep you in the loop and work with you as our roadmap unfolds.”

More than one very smart person has said negotiations don’t start until you say “No”. Be honest with your “No’s” and your customers will respect your candor more so than the sucking up, even if they are handome and powerful men. You may scare the odd sales person along the way, but they’ll recover when the customer decides to trust because they’ve had a real conversation with you and buys as a result.

Follow those 6 Best Practices, and you and your customers will be very happy that you’ve chosen to share your roadmaps. Pray your competition decides not to share theirs. Guess which meetings will make the customer feel like they have a better partner?