

Why sharing your product roadmap is a bad idea - faramarz
http://www.freshbooks.com/blog/2008/11/11/5-reasons-why-sharing-your-product-roadmap-is-a-bad-idea/

======
rm-rf
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.

------
enjo
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._

------
Groxx
> _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.

------
7402
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.

------
billturner
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.

------
JonM
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?

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

I think a good way of combating that is to get a page up for feedback
submission. Anytime you have users like that, ready to make a decision based
on your answer or lack of one, you direct them to that page and gently ask
them to leave their suggestions for the team.

At the end of the day you need to be honest with your users, but do so without
revealign what you'll be doing. Instead say that feedback and feature
suggestion is crucial, but we can only support the most popular ideas for now.
Which is the truth. If adding a feature is requested by 60% of your base, you
know you're going create value by giving it to them.

Goodluck

~~~
JonM
Thanks for the advice. We do have a GetSatisfaction page setup but alot of our
user base refuse to use it (I don't want to pay the extra monthly fee to
integrate with our login system).

I think it boils down to a communication problem, support / request are
fragmented between phone, get satisfaction and our own support ticket system.
We also don't have a good way of sending out information.

Perhaps if we had a regularly updated blog and a single support and feature
reqeusts system it would eliminate the cause of the problem.

But that's more coding for me!

------
10ren
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.

~~~
Hoff
In short, you're leveraging your product and your business credibility on your
beta and your plans and your customer engagement.

High-risk, but it can pay.

Miss large on product or roadmap or customer requirements, and you're in deep
sneakers. Few places have the revenue stream to manage to maintain a rubbish-
n-roadmaps strategy sustainable after a sufficiently large miss.

~~~
10ren
Good point, and _rubbish-n-roadmaps_ is very apt (and google says it's
original.)

But I did cover myself on this: if you do solve an unsolved problem, all is
forgiven. Getting it out into a closed beta can tell you about a large miss
earlier, with less investment, and less reputation risk. Of course, it would
always be better to do everything right in the first place, if you can afford
it. Rubbish-n-roadmaps is the worst approach except for the others.

