

If you aren’t embarrassed by v1.0 you didn’t release it early enough (2007) - profquail
http://successfulsoftware.net/2007/08/07/if-you-arent-embarrassed-by-v10-you-didnt-release-it-early-enough/

======
matt1
I'm working on an app at the moment and despite my intention of releasing
early, I find myself adding additional features for the initial release.

Here's my logic; tell me if I'm out of line:

1) As a user of my own product, I have a pretty good idea of what the first
set of features users are going to ask for. I could release a simpler version,
but since I know some additional features are important, I feel like I might
as well implement them prior to the launch.

2) You tend to get a big spike in traffic right after launch. The better the
site, the better that initial feedback is going to be and the more people who
will convert. Why waste that large influx of traffic? Counterpoint: the people
that make up that large spike of traffic are largely tech-geeks, who are not
my target audience anyway so it doesn't matter.

~~~
ryanwaggoner
I think this is pretty typical of developers scratching their own itch, but I
would launch now:

1) You may not be scratching the itch you think you are. Users may love your
software or they may hate it, but both might occur for reasons you never even
thought about, because your users are different from you and may use it
completely differently.

2) Don't launch. Seriously, a big launch event with PR and hype is overrated.
Put it out there, get feedback, iterate based on that feedback, and do
marketing and PR later. Here's a much better post on the subject:

[http://www.startuplessonslearned.com/2009/03/dont-
launch.htm...](http://www.startuplessonslearned.com/2009/03/dont-launch.html)

~~~
matt1
Ryan, great points.

I have mixed feelings about listening to users. On one hand, I'd like to think
that my vision for the app should lead me and that users are there to keep me
on track. On the other hand, what good is a vision if your users don't like
where you're headed? Put another way: as the developer, am I there to
implement the users' collective vision or are they there to guide mine?

I think there's got to be some sort of healthy balance. You can't (and
shouldn't) do everything your users want, but you need to listen to their
feedback because in the end what good is business without any customers?

~~~
cantastoria
Agreed.

I'm often shocked how obsessed everyone is with "getting user feedback so you
can iterate".

In my experience, users have no idea what they want and the ones that do are
usually just trying to get you to implement their pet piece of functionality
that will make their lives easier (usually at everyone else's expense).

User feedback is good for validating your design and feature choices not
driving them.

~~~
kristiandupont
They may not be very good at telling you _how_ they want to do something, but
they are usually pretty good at telling you _what_ they want to be able to do.

------
ryanelkins
I think most people commenting so far perhaps didn't read the article
entirely. I find the headline a little misleading - it does not advocate
shipping buggy software, but simply a minimal feature set to get the idea out
there, start seeing what features people use, what features people want, etc.
Sounds pretty familiar to me.

------
vaporstun
Counterpoint: <http://www.cuil.com/>

Embarrassment ruined them and few will ever give Cuil an honest second look,
regardless of their future additions/improvements.

~~~
warfangle
Cuil was also hyped a lot before its initial release. I think if it had
stealth-released, done some research and refined, they might have done better.

Or at least realized the concept was something the market simply didn't want
(alternatively: hasn't wanted yet).

------
SandB0x
Is anyone else tired of this aphorism plus wild generalization format?

------
cantastoria
Can we please stop giving out this bullshit piece of advice?

People expect polished applications that are better than what they already
have. If you're not proud of your product wait until you are to release it.
Believe me, it will make standing in front of a room full of investors or
potential users a much more pleasant experience and you'll be able to sleep at
night.

~~~
ryanwaggoner
Completely disagree. The biggest risks for almost any piece of software done
as an entrepreneurial project:

    
    
      1) The developer never ships it
      2) When they finally do, no one cares
    

Shipping early even with flaws and bugs solves #1, and if #2 is a problem, you
find out a lot faster and can move on to the next thing. The truth is that
early adopters expect bugs and flaws, which is why they're early adopters.
Most people are surprisingly forgiving of new software [1], provided the
developer engages and regularly addresses their concerns with bug fixes, new
features, etc.

1\. Obviously, this depends on what market you're in. Developers of avionics,
for example, probably shouldn't follow this advice.

~~~
eru
Yes. And you can just call it version 0.1 instead of 1.0, if you are cautious.

------
dmn
On a semi related note, Intype is an example of a great piece of software that
should have been released as v1.0 already.

If it were to be released, I personally would pay for it and know many others
who would also (in order to feed their development). But in its current
(development) state I opt for something with backing assured.

------
bitwize
Macintosh System 1.0 was AWESOME.

Even Mac OS X doesn't match it in terms of usability.

If you're not willing to put polish on your 1.0 product, YOU FAIL IT.

~~~
ryanwaggoner
Counterpoint: Microsoft's (and Google's) products are hardly perfect when
released, and has a bigger market cap than Apple (and Google is close).

And to take it even further, you're cherry-picking. Apple's products are
usually polished, but not always. MobileMe? Or their first product:

[http://www.landsnail.com/apple/local/design/images/computers...](http://www.landsnail.com/apple/local/design/images/computers/apple1.GIF)

