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.
[...] 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.
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.
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?"
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.
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.
It's reasonable to want to be in good shape when you put something out there. If you can't be responsive to users, you'll lose 'em.
My tip: go someplace quiet, warm, and pleasant for a couple of weeks. Read novels. Sleep late. Have a beer on the beach early in the afternoon. Go for long walks and maybe some long runs. Your love for what you do will return after a while.
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.
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?
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.
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.
Thanks for this. Reading all this stuff about people releasing stuff after 2 nights of work I was starting to wonder if I was crazy having my closed beta planned after 3 months development. I've been working damn hard part-time on the core technology of my project. Time adds up slowly when you're working part-time, and surely sometimes a new idea really does require a fair bit of work before it's ready for customer feedback?
Then I saw your comment about iterating on real customer feedback and I realised there's no difference between "releasing early" and "release a beta [early and get feedback early]", and obviously the time to release a beta varies depending on the product. If you think about Google or Shazaam or any technology-based service, the core algorithms took time to develop to a point where a beta made sense because access to the technology was the product. Or am I missing something?)
Instead, what I think happens is that people learn to launch smaller. A big public launch is, in my view, pretty late to start getting feedback. A fairly polished product is necessary for mainstream users, but if you have something truly valuable you probably can start with something much rougher for people on the early side of the crossing-the-chasm model. Once you have something for the other side of the chasm, you can go after the big public launch.
Agreed entirely about iterating based on real customer feedback, though.
I think the author nailed it with his "excuse he didn't admit to" paragraph, i.e. it he was afraid it would fail. As long as you haven't actually failed, you can still fantasize about retiring a billionaire in two years time.
It takes a lot of courage to burst your own bubble at the earliest possible opportunity.
I am working on a start up in my spare time myself. My partner and I know very well that we need to launch and iterate. For me, there's a fear that if we launch too early, there may be too many issues that will turn users away. When we will finally be "ready" (as much as we could be), those users will not want to come back and try our service. It's all about first impressions.
Having said that, I STILL believe in launching early. I interpret it, though, as stripping as many parts of the product as possible and then gradually adding them in
How many users will you turn away? Do you think it will be a significant portion of your potential users? To be clear, don't you think it's worth having .05% of your total possible user base turned away so that you can understand what the other 99.95% want?
well, it's a tough one... Intellectually, I agree with you, but it's sort of a gut feeling. The issue is that as a start-up you are limited in resources. So how many campaigns can we run? How many friends can we nag to use our service time and time again? etc. You don't want to exhaust your resources at the beginning.
Of course we will launch and iterate, but this is just a fear. Is it rational? Maybe not. I hope not :-)
LinkedIn's founder Reid Hoffman once said: "If you are not embarrassed by your first release, you've launched too late!"
If you want to try stuff out early, also consider in-person guerrilla user testing, running ad-driven tests on a fake brand, buying low-cost traffic, and asking fellow entrepreneurs to try things out. For more on this, the Lean Startup Circle mailing list has a lot of good ideas.
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.
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.
Just curious, what was it about alpha and beta that don't stick as opposed to now? Have you stuck some users in the mean time?
I also get stuck on the question of how many features is 'enough' that users won't immediately leave, which is when you can begin testing your business assumptions
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.
We launched early, asked for money right away [...]
You have no idea how I like reading this. I'm sick of all those new websites that offer their service for free, hoping to figure out how to monetize later.
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.
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.
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.
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.
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.
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?
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!
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.
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.
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.
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.
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?
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.
There are news shows and newspapers in multiple languages available in countries like Belgium or Switzerland that have two or more official languages. It's no big deal.
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.
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?
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.
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!
The daily deal business can make a lot of money and consumers (particularly women) love it.
However as Groupon has proven they are typically very dependent on expensive marketing channels in order to achieve growth. Over the last year or so the market has become really saturated with daily deals sites and so the competition for customers is fierce. I think as Groupon's woes become increasingly apparent, the daily deals bubble will start to implode (if it hasn't begun to already)...
Well, I guess that is pretty much what I'm thinking. The barrier to entry is low, but that just means the barrier to having your userbase taken by Groupon or LivingSocial is equally low.
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.
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.