Hacker News new | past | comments | ask | show | jobs | submit login
How not to launch your company (mutlicorp.com)
156 points by chrislloyd on Oct 8, 2012 | hide | past | favorite | 41 comments



You seem to place a lot of weight on hitting the HN homepage. What is your expectation for would have happened had you jumped to the top slot and stayed there for several hours?

Would you have signed thousands of new paying users? Ignited a media firestorm and suddenly found yourselves on the cover of Inc magazine? Would you be rolling in millions today?

Or would you have had 10,000 visits to your homepage, a small handful of signups, a few dozen comments on the HN thread (half snarkilly dismissing it, the other half arguing about some completely separate issue that the first person to comment happened to mention in passing), and a traffic spike for a day or so followed by a return to your normal levels.

Having occupied that top slot a few times, I'm sorry to inform you that it looks a lot more like the latter case. You still need to build and grow your business from square one, and a year later you'd have been exactly where you are today. A few Techcrunchings and HackerNewsings really aren't going to make a difference in the outcome of your thing.

The real difference is made by the things you did on the other 364 days between then and now. Here's hoping you executed well.


I agree. HN certainly isn't the worst place for a Minecraft-related venture, but I bet reddit.com/r/minecraft would have been a lot better for business, and would have practically guaranteed a top position regardless of other news. They could have even targeted ads at that specific sub-reddit.


The next 48 hours were spent fixing hundreds of bugs in all sorts of places we never expected things to go wrong.

Launching quickly # Launching prematurely.

I think that it takes this kind of suffering to fully appreciate the fine line between launching too early vs. too late. Sure, we're all in a rush with too much to do, but everyone should do themselves a huge favor and slow down long enough to come up with a good test plan, before, during, and after development.

I went through the same thing once and will never let it happen again. It was so bad, I actually considered becoming a cook instead. In the long run, it's just not worth it, to your customers, and mostly, to yourselves.


If you spend too much time planning you run the risk of never launching. I can sit here and refine my product forever, but at a certain point you just need to pull the trigger and launch the damned thing.


I don't think edw519 said anything about "refine[ing] my product forever."

But having a thorough test plan better be a part of your project roll-out. No one wants to go through the rabbit holes of corporatized QA team B.S. but product refinement is a different topic entirely than the point of his comment, which was testing that product before launching it to the masses.

If you think your product won't be seen by many customers, well OK. Set it free. If you have a major push behind it, however, and know 100's of thousands of people are going to be mashing it to death in the first few hours or days, adding a time buffer for testing beyond your close family and friends is wise advice. It will save you money in the long run, too.

The alternative is to become buried under an avalanche of crash reports, bad reviews and ratings. And, conversations like, "If only we'd had more time to test this thing."


But there will always be something that might be the next bug, but perhaps not really keeps people from using your product as well. There is a fine line there. And I agree with 'aytekin' below, probably having more features in a product leads to more bugs and thus difficult launches.


You are correct, but also if you spot "hundreds of bugs" it seems fair to say the trigger was pulled prematurely.


Having too many features on the first version is probably the real problem. 'Release quickly' only works if your releases are small increments.


Yes, having so many bugs -- they must either be awful at programming, or tried to release too many features with not enough testing. Reducing features probably would have helped a lot.


Unless you are Blizzard, you can't have a SaaS with a catastrophic launch and still have people think of you as a bunch of swell guys and gals at the end of the day.


If no one sees your first launch and/or it fails -- just launch it again. Seriously -- the vast majority of people will never notice or know.

I dont get this BS about depending on a singular date as a defining 'launch'. Its a good internal goal to have, but not the ideal way you want to reach your market.


If you are launching an app, you get a tangible benefit from a marketing launch, which probably derives from Apple's DNA.

On the App Store, if you do zero marketing, you will likely have your most total downloads the day after your app is approved. The first day, you likely only get a half day, and you have to wait for full propagation on iTunes. Also, the rankings are a moving, weighted average, so unless you have a terrific spike, you need to wait for your average to start kicking in before you move up the charts.

Day 2 or 3, you will peak, then rapidly decline. So, it makes a lot of sense to time your marketing boom for the day after your approval, or rather the first full day of being live on the store. Marketing tends to be multiplicative.

People make the mistake of thinking app rankings get you sales over the long haul - it's more the other way around. But at the beginning, you get a bump, and you should use it. This bump derives from several sources:

* new list on App Store

* lots of robotic websites and Twitter accounts spamming about new apps

* the press cares about "news"

* energy from your team on a specific launch - people tell their friends and social outlets, and actual planned outreach by the company

* Apple featuring you in category or on home page of iTunes


I have made quite a different experience with my own app. Since the day it was approved, I have seen a very constant number of sales. I didn't make a big deal about the launch and I didn't post on HN. People just found my app by searching on the App Store (it is a utility app that quite a lot of people need, and it was the only of its kind when I launched).

Over the course of the first year, I saw a gradual increase in sales, presumably due to the page rank of my website increasing, or maybe because adoption of the Mac App Store increased. Now there are slight fluctuations in sales numbers, but they are more or less constant.

So I didn't get that bump, but I was lucky I made an app that was in demand.


I had the same experience with a StopWatch app I make actually, also a utility. It has gradually increased overtime. Mostly I see a pop though.


This process sounds perfect for launching an app with a soft launch, while holding a launch event a few days later.


Unless you're apple, don't count on a big launch full of pomp and circumstance, because no one cares. For startups, "launch" should be a continuous process, not a singular date.


> Second mistake: don’t launch when somebody famous is in ill health.

If you did that, you'd never launch.


I found that "don't launch when somebody famous is in ill health" -- as well as the lesson about simply copying Apple's launch dates/times -- could best be summed up by something a bit broader. Namely, do your market research before your launch.

Market research means knowing your customers, as inside and out as you possibly can. And, if HN users represent a significant chunk of who you expect to be your early adopters, then you should make it your business to keep abreast of everything happening in the HN world. The world of stories of potential interest to HN is direct competition to your launch announcement. If you want to be newsworthy, know what news you're going up against -- especially as relates to your specific audience.

(In fairness, I don't think anyone in their shoes could have predicted Steve Jobs's death, down to the day and time. But even still, there could have been a hundred other big-attention topics that would have buried them, had they not been paying attention. Such as another major product launch, or what have you -- things that would have been slightly more predictable.)


Yeah. I might have gone with "Number 2: Have a plan B in case the day you launch something very significant happens in the tech world to drown out any chance you have of getting attention"


Yes! And let's not forget don't be fully depending on one marketing channel to get your first launch.


  There wasn’t anything we could do about the poor reception on HN, 
  but we’d been working on this for three months 
  expecting it to be a smash hit as soon as we launched.
If you're working on something new repeat after me: "It wont be a smash hit"

That way you can make a plan that will actually fit reality and create your own growth.


Maybe it's the mobile version of the post but feels like some of these simple lessons about posting to HN could benefit your engagement rate from this post:

http://www.meetingburner.com/blog/2012/10/05/a-story-of-two-...

Eg - talk about what your service actually is in the post, link to it, and lay out a call to action so you turn some of the HN traffic into actual users vs browsers . . .


"Don’t launch when somebody famous is in ill health." Is this intended to be actual advice? I think the real issue is a shabby product, especially after seeing "make sure your service can sustain more than a couple of people at a time" and "the next 48 hours were spent fixing hundreds of bugs".

Looking at the website I am impressed you at least have an SSL certificate, cause it doesn't look like much more effort went into it. I'm even more confused looking at the about page, it lists David as being a rockstar programmer who enjoys working on difficult scaling problems, yet he didn't plan for more than a couple of users?

If you want to make your service succeed put an embedded Minecraft applet on there and have it link to some of your public servers, maybe even let the user select from a few of them. Just do the same things as http://minecraft.net/demo. Add some color to your site, your target audience isn't a bootstrapped web developer, it's a highschool kid who wants a Minecraft server. Add a big old buy now button on that homepage. And why does the Sign Up page not have the pricing options?


>Second mistake: don’t launch when somebody famous is in ill health.

Is this a joke? Steve Jobs was, more or less, in ill health for years and there are enough famous people to make this advice "don't launch ever."

Somehow I don't think I've ever heard of Minefold. Sounds like something I would have been interested when I was still playing. Two years ago, I dumped a few hundred hours into Minecraft though and got pretty burnt out.


I am pretty sure it was tongue-in-cheek.


Ah, wasn't sure since the other highlighted mistakes were definitely legitimate.


In my opinion, launching is just a PR stunt. If you don't already have users (hopefully paying users!) prior to launch, you're doing it wrong. In my opinion, a launch is really just a media event which you do to get free advertising - that is, you're product should already be well tested and validated through real users and the launch is a publicity thing.


Now that you've hit HN front page, wouldn't it be good to actually have a link to your product in that post? I know there's a link in the header on the desktop version, and an image with the URL midway through, but on the mobile version there's nada.


I'm a big fan of Minefold.

Also, being no stranger to... "problematic" launches, I can totally sympathize here.

Can't wait to see what you guys have in store with the new update, and as long as Cook or Schiller doesn't suddenly kick the bucket, I think you'll be fine with this one :-)


When you are wondering what value the "suit" should bring to a partnership, it is experience in what not to do in cases like this and how to recover when you do run into them. Better yet, a good "suit" will make sure that your business success isn't determined by a singular launch event (which is almost always a bad idea for startups).

Sometimes you can recover without that (great job on the recovery!), sometimes you can't. If you choose your "suit" right, your chances of recovery will be better.


Minefold is of interest to me and I guess inevitably the answer will be "we're doing great!" but if you can say more than that... how is Minefold doing?


We're doing great! But seriously… we went through a hard time after YC trying to figure out where to focus our time. However, it's been growing steadily (almost at 60,000 players) and we've done some great work in the last few months which I can't wait to release :) I don't like taking this long between releases but we've had to re-think a lot of our internal systems (blog posts coming). We've fixed most of the things that people didn't like about Minefold and hopefully added some cool extras too.


60k players? That's awesome, congrats.


Third mistake: make sure your service can sustain more than a couple of people at a time.

As I am thinking to launch an app sometime in the future, how do you test for this? This is something that has been bogging me a lot. I can't find easy to understand info on how you do this, especially running on a virtual server (so how much ram? how much bandwidth? etc.).


Low-level tools that just spam requests at your webserver will give you a pleasingly high number (hopefully), but are unlikely to be an accurate picture of how many 'users' you can concurrently sustain.

Try to come up with some automated test or script that exercises the full set of features you'd expect an actual user to be interacting with over the course of a session.

Then, build a harness that slightly randomises those activities, and fires off a large number of 'virtual users' against your service. Running from geographically diverse hosts will ensure you're closest to what an actual user would experience.

Actually determining what mix of operations constitutes an 'average session' is relatively difficult, but there are tools that can record sessions from actual users (look at the HAR dump in chrome, or Selenium[1] testing framework)

All of your test clients should be recording response latencies + errors, which you can later analyse to see what slows down at scale, or which critical features with unacceptable performance you need to target first.

Another thing to consider, especially during release, is that lots of users signing up and playing around is likely to be a completely different workload to regular users using it for day-to-day activities.

You need to make sure things like your transactional email notifications ('your account has been created, verify your email address, ...') can handle peak demand as well.

[1] http://seleniumhq.org/


This was very detailed and useful, thanks. I ll be looking more into selenium, I knew of its existance, but I never looked deeper into that.


Personally, I recommend running a "friends and family" test prior to the launch. Get some people you know to come in (perhaps bring their laptops) and all log on and use the system for an hour. Ask them to try to crash it. It won't simulate 100 users (unless you have LOTS of friends), but it WILL catch some things that load-test scripts won't catch.


Launching early is the first step for testing your assumptions in the real world. You don't learn unless you launch. Don't worry about timing.Just launch.

Lot of first time entrepreneurs learn by launching a product and getting feedback. I think there is no better way to learn than by getting the feedback from an unknown stranger.


Upvote because I feel a little bad -- hope you can get the attention you deserve now


Thanks for the article and reminder. Good luck.


www.iceboxpro.com




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: