Why sharing your product roadmap is a bad idea

Sometimes sharing your product roadmap can be a really good idea. For instance:

I was the lead architect at Quickoffice for several years... at one point we were preparing for a big release. THE big release. It contained our first go at full editing/round-tripping for Word/Excel files. This was a big deal for our company as we moved from very hacky desktop-syncing solutions to full on-device mobile editing.

Our big competitor was behind and I'm pretty sure they knew it. We had been competing for some big business so we had some idea what the other was up to. About a month before our release, they issued a press release clearly laying out their roadmap... including their plans for full document round-tripping.

It was a genius move. It had a tremendous delaying effect among our shared customers (big phone OEM's primarily). They instantly negated our advantage as the decision makers and end-users both decided to take a wait and see approach rather than put their money into our software. It also took some steam away from our feature-set as people seemed to credit them with arriving at it first even if we were the first to actually deliver it.

I've seen this work in other cases. A competitor outlines their roadmap which forces their competitors to spin cycles trying to respond to it. It makes the product conversation about how they stack up against your hypothetical product, not what you're actually delivering today.

As with all things strategic, it's all about timing. All of those negatives in the article are valid and have to be weighed as well. In the end, however, it can be a tremendous competitive tool.

edit: god my grammar is truly terrible.

Steve Blank's idea (4 Steps) is that a roadmap enables you to ship a breathtakingly low quality product, because it is understood as the first installment in a bigger plan. Customers are really buying the vision, not the initial buggy, slow, undocumented, awkward, feature-missing piece of garbage you shipped in the first version (which is version 0.1, not 1.0)

But why are you shipping rubbish? It's part of getting going as quickly as possible, and iterating and learning. When real people start to use it for real tasks, you'll learn that the missing feature A that keeps you awake is not actually missed; but feature B that you didn't even think of is crucial. There are other advantages: if it truly is an unmet need, people will be so happy to solve some of it, that they won't care about the rest. water when you're dry etc. By shipping early, you'll also be building your market presence (for a new product, the first part of which isn't the quality of it, nor whether it works, but what is it).

The part about learning above is more crucial than you might think: knowledge of secondary user problems that no one else knows about (because they only become clear when people start using a solution) is a competitive advantage. The information is also precisely customized to your product, which makes it easier for you to absorb than for competitors with a different product and approach (which will have its own, slightly different, problems). You have a head start before other hear about these problems, and absorb them, so it's a time-limited competitive advantage. But in the meantime, you're learning the next thing.

The reason you're shipping rubbish is not because you aren't good enough to ship high quality; it's just that high-quality takes a lot longer. You need to have (or acquire) the ability to polish it - once you are sure you have something worth polishing. All that said, your product does need to do something useful; solve some problem (ideally that no one else solves; or no one else does it with some particular quality or tradeoff, that is valuable). It's crucial. With it you win; without it you lose. The quality and polish of other stuff is secondary.

>Purchase decisions get delayed

Absolutely agree. I do it too. Though that's partially because I've been "burned" by companies having X on their roadmap, and not coming out with it in a reasonable time-frame (ie, a couple years for what should be a very simple feature). Or, to pull from my favorite example, EverNote has utterly squat for exporting, literally to zero on OSX, despite repeated claims to support open formats for a few years now.

We've got this very badly wrong right now and are suffering the consequences. In short we are in the middle of a huge re-development of our core product. Unfortunately my co-founder (who isn't a developer) has been telling users various different "launch dates" (which have conflicted; and many of which we have now passed without the launch) on public and the pressure has really mounted on our public support forum.

The long and short of it is that I'm under enourmous pressure, because according to our users it's already behind schedule.

I don't want to break face by just saying that my co-founder has jumped the gun massively and was in no position to make the promises, so at the moment I'm just living with the embarassment and trying to keep my head down an get it out.

In his defense, there is a reason for this and I wonder what advice HN peeps would give.

Day-to-day senario......

User: Is feature xyz available? Company: No User: Will it be available in the future? Company: This does seem be a worthwile addition and we will discuss it in our next development meeting. User: When will this feature be added? Company: We don't have a launch date. User: Ok, when will this feature be available becuase I need to use it now? Company: We don't have a launch date available. User: When will it be available, I'm getting annoyed.

At this point my co-founder usually breaks cover and gives a vuage, fairly distant forward projection; "in a month".

Should we really just be saving "no" and keeping silent on good ideas even though we are developing them?

While reading their list, I kept thinking about the issues Wakemate have gone through. It looks like they would fail at all five of those points.

On the other hand, in enterprise-land, if a vendor doesn't show me their top secret, NDA-only roadmap, there is a pretty good chance that I'll be sufficiently impressed by their competitors top secret, NDA-only roadmap to consider a vendor switch.

For example - startup storage vendor shows me really cool stuff that will ship in less than a year. If really big incumbent storage vendor doesn't show me their roadmap, there is a fair chance that I'll be impressed enough with startup's gear to defer upgrade or replacement of incumbent's gear until startup's gear ships.

If incumbent is smart, they'll have something on the roadmap to share with me that keeps my seven figure annual business pointed their way.

It depends on the business. I worked at one company where we even kept roadmap information secret from the sales department, for fear that it would leak to customers and stall current sales to customers who might just wait for the newer product if they knew the details. I think the defining characteristic may have been that these were big-ticket items: if you buy one, you're not going to buy another for a few years. On the other hand, at another one of my employers, a company selling enterprise software, it was much more important to maintain an ongoing relationship and to establish trust. That required more openness about future plans, to customers who buy a product, buy maintenance contracts, and keep buying more products, once they decided that we were a company that they could do business with in the long term.