If you aren’t embarrassed by v1.0 you didn’t release it early enough (2007) | Hacker News Reader

If you aren’t embarrassed by v1.0 you didn’t release it early enough (2007)

successfulsoftware.net

11 pointsprofquail21 comments

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.

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

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?

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.

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.

This is one of the things we've struggled with the most. We're huge fans of customer development, but also started a company with a vision. Ultimately, I think part of it comes down to your motivations for starting the company and what you hope to accomplish.

[Shameless plug] You can read more about our battles with this exact issue here:

http://mightybrand.com/2010/01/got-customers-part-2-the-one-...

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.

Counterpoint: http://www.cuil.com/

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

If it's really the case that "no publicity is better than bad publicity", they can ditch the brand and relaunch under a different name.

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

Not true. There are bloggers out there trying to dig stuff up, and if Cuil suddenly became good, you can bet they'd love to report that story and you would've heard about it. You might've even heard about it from me, because for many months I would type stuff into Cuil just to see what I'd get.

But you never heard anything because they never did anything worth talking about (relative to the other players in the field of course...)

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

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.

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.

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

Polished != Has-every-feature-you'll-ever-want

You can come up with a small, polished product with a few well-designed features to start off with (v1.0), which will impress the investors and early users. That'll get your cashflow going, and you can add more features along the way.

I think people's tolerance of bugs and missing feature's has dropped to an all time low. It's not 1997 anymore. This "ship early, ship often" tactic may have worked at one point but expectations have changed. Especially if you are selling into an established market (which most of us are...)

Also building software for your early adopters is usually a bad move. Typically this gets you a product full of corner case features that these users weren't getting in existing products. Unless it's a huge market you're probably painting yourself into a corner.

People expect polished applications that are better than what they already have

Maybe they expect that, but what they want is to solve a problem.

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.

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.

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

Reply on news.ycombinator.com