

How We Fooled Ourselves Into Waiting Too Long To Launch - vacanti
http://viniciusvacanti.com/2012/04/02/how-we-fooled-ourselves-into-delaying-our-startups-launch/

======
patio11
There exist many, many businesses where V1.0 of the product can be the CEO
scrambling with a cell phone, Gmail, and a spreadsheet. This is especially
true for business process innovation type businesses like e.g. ZeroCater
(which actually started out pretty much exactly like that). After you learn
exactly where the painful bits are you can code to prevent them rather than
coding for problems which may not ever be experienced by any human ever.

To this day, there's a couple of things where my workflow is "SSH into the box
and run commands against the Rails console" because those tasks were never
common/important/etc enough to justify even an hour writing up a tool to
automate them.

~~~
NameNickHN
_[...] those tasks were never common/important/etc enough to justify even an
hour writing up a tool to automate them._

I can't agree more. It took me a while to get there but in the end it's
exactly what everybody should do.

As of right now I'm manually creating the accounts of new customers (has
something to do with creating new database tables which is done half-
automatically). Right now there is only a trickle of new customers (due to the
lack of marketing) and it's not worth it (yet) to program a fully automated
registration process which would require a registration form, payment
processing and above mentioned account creation.

~~~
patio11
A major "aha!" moment for me was 37Signals writing "If you have a 30 day trial
anyhow, launching with billing code written means you've swapped something
customers actually will notice today for something they won't." I don't
endorse that specific advice (because you should probably auth cards on launch
day) but the kinda relentless scope-cutting it implies has been a major win
for me.

~~~
wulczer
We launched with billing code, but did not have code to actually do something
with accounts that did not pay until they were into their 35th day of a 30 day
trial (a slight estimation error, you know how software development works).

"Hey, you lucky guys, we're extending your trial period by five days! Ain't
that cool?"

------
padobson
_The best way I’ve come up with is to think of a startup as an experiment, not
as a business._

This is the key take away.

If you're doing an experiment, you're doing it to learn something and prove
some hypothesis. The only thing that should delay you from launching is, "If
we launch now, we won't be able to collect that data we need to test our
hypothesis".

Learn and learn fast. That's it. You can't learn if you're not making contact
with your customer. A 25 SLOC splash page that learns something is better than
2500 SLOC that just sit in your GitHub account.

------
alexkearns
I never thought that I would be hit by launch fear. Over the past couple of
years, I have conceived and finished a number of reasonably big projects -
www.gambolio.com, www.musicgames.co, www.casualgirlgamer.com and www.tiki-
toki.com - and for each I launched as soon as I thought the software/site was
polished enough. I had no hesitation or doubt. But for some reason, with my
latest project - www.peopleplotr.com - I just can't seem to launch it. It is
not that I am constantly tinkering with it. I haven't touched it since it was
completed a couple of months back. It's ready to be launched at a moment's
notice. I even posted about it on Hacker news to get pre-launch feedback. But,
for reasons I am not 100% sure of, I just can't conjure up the energy to write
a few press releases and send them out to some blogs and publications.

I am not sure exactly why this is. Am I fearful of it being a failure or am I
fearful of all the work I'll have to do when users start giving feedback.
Perhaps it is not so much launch fear as launch fatigue.

~~~
vidar
Stop thinking and launch. There has been enough thinking on this project
already it seems!

------
joeag
We launched a "netflix for action sports" dvds back in 2004 and the first day
we shipped all the dvds (about 30) by hand. We hand picked from inventory what
each customer wanted and then made mailing labels on the laser printer, licked
the envelopes and mailed them out. Once we found out that there was a rental
market for action sports DVD's we built the back end to use bar coding of
dvds, automated envelope printing, etc. We did build the credit card gateway
upfront though, both because we were offering free 30 day trials that involved
shipping customers our inventory and also because we wanted to capture the CC
info for recurring billing upfront.

------
alain94040
So true. Now, if all entrepreneurs could just _stop_ reading this advice and
actually _apply_ it to their projects, that would be amazing. As the article
pointed out in the introduction, they knew to launch early. They were told to
launch early. And they still didn't. I'm guilty of the same mistake. Why is
this cognitive dissonance still haunting all of us?

~~~
jamroom
Maybe if everyone did follow the advice and "launch early" then some of us
would realize we really DID launch too early and the popular idea of launching
early would lose some of it's appeal?

I believe there is a growing number of startups that are realizing the
importance of launching with a (fairly) polished product. There's just a ton
of startups now, and standing out in the crowd is becoming more difficult.

When I hear "launch early" what I personally take it to mean is "iterate based
on _real_ customer feedback", with the intention being you'll minimize wasted
work. But this is how you should be running your business all the time - not
just at the MVP stage.

~~~
kenrikm
Great advice. Launch early does not mean throw crap at a wall at hope it
sticks. You do still need to make something that represents at least some of
the function of your initial vision. Really you should make simple version and
have a soft launch (not a ton of press) and when you actually "launch" it
won't matter that you were out there with a half finished product because no
one knew about you anyway. don't code locked in your basement make a demo and
then get out there and show it to people and get feedback.

------
sjayman
This is an awesome post. Thank you for this. Thinking about a start-up as an
experiment, not a business, until it succeeds is the biggest takeaway.

That said, there is some truth to the fact that you need to love it before you
can let others see it. It has to be clear to you why you yourself want to use
it. We have gone out on many launches. Alpha, Beta, and now launching to the
world on 17th April.

None of those early launches stuck! Why? Because it was still a Work-In-
Progress. And it felt that way to our early users. It felt like we had to make
excuses when presenting the product to friends and early adopters.

~~~
apenwarr
These early launches are not expected to "stick" - either that, or I've just
been terribly unlucky. The only value you need to extract is real-time
feedback about what you got right and what you got wrong. Then you tweak it
and launch again, and again, and again. And eventually, you reach "product-
market fit." And then it sticks. If you're lucky.

But the early product is _not_ expected to be scalable. It just helps you
avoid the problem of launching a _late_ product with all the same major flaws.

------
shawnc
We launched early, asked for money right away, and have been doing excellent
ever since. Now our problem is defining what makes a 'final, out of beta,
stable' version. Defining it, and then meeting it. We're constantly going
'this isn't good enough for a final release'. But hey, almost 300 paying users
right now is motivation to make it better for THEM, and not for us and our
imaginations of what is better. With those users who've paid for our product
(when it was barely a product) tell us what they need, it's far more valuable.

~~~
wpietri
Bravo! Why do you care about "final"? I can't imagine you'll stop iterating in
response to customer feedback, so isn't "final" an illusion?

~~~
shawnc
You're exactly right. I should restate I mean '1.0 final' so we can say we are
out of beta and anyone that buys it can know they're now getting something
that has no problems with it.

~~~
wpietri
In my view, that's more about the "Crossing the Chasm" transition from rabid
early adopters to the early mainstream market. In your shoes I'd interview
various potential customers to see what each group considers must-have
features, and listen carefully to any early mainstream people that have used
your current version.

~~~
shawnc
I know thisis a really late reply, but I wanted to say thank you for your
reply and input. Really appreciate it!

------
GBKS
My approach to avoid this is to not have a development or staging server. Just
a live site. That's what I work on at the beginning. It's always out there, so
there are no excuses. And it keeps your focus on the user experience.

~~~
wpietri
I'm sure this sounds crazy to some, but I wanted to add we do something
similar.

Every commit goes live as soon as the tests pass. We do have a staging server,
but it's running the same code as in production. We use it for manual putzing
around (so we don't mess up production data or clutter production logs), and
we eventually added feature toggles so that a feature can appear only on
staging.

That means we're releasing every few hours, which a) means we get feedback as
soon as possible, and b) production bugs are pretty easy to run down, because
you know just where to look.

------
NameNickHN
This is one of my biggest pet peeves. I've abandoned a project because my non-
tech partner constantly came up with new ideas why we couldn't launch and that
we needed more features before we launched. This resulted in me being highly
demotivated and frustrated.

~~~
Domenic_S
Not to sound trite, but that sounds like a lack of planning -- in the form of
a question, what's your MVP?

If you're clear on that, you point to the doc and say "how does this new
idea/feature help accomplish this?" and force a specific answer.

~~~
NameNickHN
It was all planned out and I myself had a clear path outlined but if your
partner is supposed to do the marketing and PR and simply refuses to start
with it, what are you going to do?

~~~
Domenic_S
That's the other big piece of any business: buy in. You can have the best
project roadmap in the world but if everyone else acts like it doesn't exist
it's not very helpful!

------
taskstrike
I launched early with a paid copy of our product, and people complained about
it a lot. This was good since I knew what to improve.

The best way to make people care about a product is get them to pay some money
for it first.

I also launched a free version of our product after. While this one has a lot
more users and is growing exponentially, the feedback is far sparser. People
care for things they pay for and that attention is great for shaping the
beginning of your startup.

------
EREFUNDO
Great article. Launching fast is always a good thing for any startup. The
challenge with our startup, PayGuard, is that we are a payments processing
service. Building the site is not the issue, the integration with financial
institutions are. We were able to build the Alpha version of the product with
all the key basic functionalities in 6 weeks but we could not test it yet to
actually transfer money. We began testing the key features using dummy data.

~~~
lusr
It's good to see somebody else building a complex product. People seem to
forget that not all projects can be launched overnight - if you're building a
WordPress plugin then, sure, you can launch and start selling it immediately,
and iterate new features thereafter. If you're building something that
effectively provides access to a complex technology (algorithm, integration
point, workflow, etc.) then the time-to-usefulness can be much longer.

~~~
EREFUNDO
That is why we're trying to figure out ways to test key functions that does
not require integration. We are currently focusing on user experience and
logic workflow.

------
john_flintstone
This is not just a software/startup problem. Every single web project /
eCommerce site / anything online that requires work, should be rolling out a
variation of an MVP.

I had a meeting with the brother earlier today. He runs an online wholesale
business (I do all the tech stuff). I've been leaning towards launching a
retail arm in our one EU country, and launching 3 new wholesale websites
translated into Dutch, French, and whatever they speak in Belgium.

We decided instead to translate just the landing page 3 times into 3
languages, to set up a retail site landing page, and to run 4 Google ad
campaigns for a couple of weeks, dropping a couple of hundred euro on each one
- to see what happens... impressions, clicks, etc.

Here's he point. On HN, we hear non-stop about MVPs, and because of the site
that's in it, it's all software or web services. But the reality is that
everything that points towards an MVP being a good idea for software and web
services, is also true for more traditional eCommerce and info sites.

~~~
NameNickHN
_whatever they speak in Belgium_

Dutch and French. :-)

~~~
john_flintstone
That doesn't help. If I listen to the 10 o'clock news in the Netherlands, do I
get a choice of languages? Newspapers in two languages? Parliamentary
questions and interviews in 2 languages? Seriously?

~~~
PanMan
The Netherlands only has one language, Dutch. Belgium has two: the top part
speaks Dutch, the bottom part French. And they don't really seem to like each
other. And, yes, official things are in both languages.

------
tnash
It's important to draw a line in the sand where you will launch, say, "when I
get X done, we will launch". Then make sure you stick to it. If you plan well,
and you know your customers, this should work.

It seems like the real problem here is just not knowing your customers. By all
means you should be beta testing with your friends and anyone else you can
guilt into helping you. Don't launch blind.

------
funkah
Strange that there is still so much daily-deal stuff being worked on. Is this
really fertile ground for a business? (Honest question.) Is everyone still
reacting to the Groupon IPO, even though that business has all sorts of
smells?

~~~
hkarthik
At this point, there are a couple of heavily funded daily deals sites that can
afford to hire armies of sales people to literally pester their way into
multiple local markets. My friends that work at one of these firms say there's
about 60 devs supporting 4,000 sales people. My friends that own local
restaurants constantly complain about the incessant daily deal sales reps that
won't leave them alone to sign up.

These larger firms make their data available to smaller sites via APIs,
allowing for firms like Yippit, Sqoot, etc to serve as aggregators. These
sites then skim off the top of the deal sales, sometimes getting 50% of the
commission on purchased deals.

The danger is that the larger sites that are the life blood of the system run
on enormous deficits to maintain those armies of sales reps.

As DHH put it, local deals is like finding oil on the moon: a valuable
resource that might ultimately prove too costly to extract.

~~~
creamyhorror
That's quite interesting. I'm in a non-US market where deals have
traditionally tended to be not that attractive, perhaps because of product
import costs and perhaps because of a captive-market situation, and I'm
wondering if the pestering-salesperson approach is the right one to induce
more businesses to open up to the possibility of offering good deals.

We have group-buying (Groupon-style) deals, which has opened up the way
somewhat, but I'm playing around with a more traditional deal-listing model
that doesn't push merchants as hard. Do you think salespeople is the only way
to keep merchants offering deals, for a listing model? It seems costly but
also the only way to keep merchants listing deals even when the revenue
outcomes of previous outings haven't been that spectacular.

I appreciate any thoughts you or anyone else might have on the issue - thanks!

