Back To Blog
Launch Broken But Not Too Broken

This is a phrase I use quite a bit and one that seems to resonate with startups. It encapsulates what I view is a pretty critical aspect of product management so let me break down the phrase.

"Launch Broken"
This is the first part of the phase -- so what's the significance of launching broken? A lot of my sensibility around product was heavily influenced by my time at I joined when it was still growing very rapidly, but already a big company. In fact, I often described it as a small company that wanted to be a big company (in the sense that it was already accumulating a lot of big company practices that I thought were bad.)

One of the problems with big companies is that they're often very risk averse. The classic example I would give is there are a lot of companies where products are primarily measured against their performance against plan. So the keys here are 1) did the product launch when it was said to launch? and 2) did the product perform against the metrics it said it would do?

This is crazy to me. In my case, *I* was the one devising both (1) and (2) so for people to care about these made no sense to me. In fact, I would often have conversations where people would say to me something to the effect of, "We think this is a good idea but your projections are too low. We think we can get it resourced if you moved up your projections." Again, this makes no sense. I would argue that my projections were generally quite realistic but at the core of it, the argument is over something that is *unknowable*. We don't know what the metrics will turn out to be. The projections are just guidelines to help us understand if it's a good or bad idea and where there are problem areas. Why not instead spend time figuring out if this is actually a good or bad idea and stack rank them against other ideas -- rather than let sandbagged metrics determine where resources should go?

So what does "launch broken" have to do with this? Well, if you can imagine this is the response to things like this -- you can imagine what the response would be to a product that needs some work. However, it's *really hard* to get a product out the door. I would argue it's actually harder to do so in a big company than in a small company because of all the executive and cross-functional touchpoints and approval processes. This type of internal reward system basically stifles speed and makes people paranoid to make sure every i is dotted and every t is crossed. 

Even in startups, slowness manifests itself just by virtue of the personality of the CEO or product manager. Maybe they're a perfectionist by nature and wants things to work perfectly. I would say 80% of the time, I push startups to launch sooner because they fall into this category. Here's why. On the day of your launch, you'll have 100+ bugs. You'll then think, "Wow, this is really screwed up. I can't launch this. I'll delay it a week and work on the bugs." The next week, you'll have 100+ bugs. You'll always have 100+ bugs on the day of your launch. So get it out sooner and use it as a forcing function to get a product that is acceptable into the market because that means you can then improve it, iterate on it, and get a v2, v3, etc. that will be worlds better than what you can possibly hope to plan and polish in a vacuum.

This, however, leads to the second part of the phrase, "but not too broken." This is where judgement comes into play -- judgement in knowing when a product is really broken. I told this to a startup once after a major release and they asked me, "Was it too broken?" My response? "I wouldn't have launched it."

It's a subjective thing -- and you have to not necessarily "know", but more importantly, have a strong opinion on what you think is an acceptable level of design, features, and bugs. Is there real value to your customers with the current product? Is it so unworkable that it's frustrating beyond all belief? Does your company have a history of just being really slow that to get it out the door, even in a really broken form, means everyone will rally around improving all the processes to get it better as soon as possible?

Each situation is different but the tension here is clear -- get it out as fast as possible but no faster. It's sort of like John Wooden's saying, "Be quick but don't hurry." Be comfortable with an acceptable level of things being screwed up -- because there is an acceptable level and that level is not 0. The value of launching and iterating is too high to make that level 0.

I mention this and sometimes people go, "What about Apple? They're perfect across the board." True. But not completely.

1) Look at the history of the iPod. The second version was a massive improvement over the first version (the first version didn't even have a click wheel) and each successive version got better in terms of design, fit and finish, etc. They can't get to the 4th version of the iPod without launching the 1st. That's the point. Launch the 1st.

2) Apple has $60 billion in cash. Apple is a massive company. Basically, Apple has the resources, intelligence, and the world's best product manager in Steve Jobs to be able to launch fast and as close to perfect as possible. Startups don't have these benefits. It's nice to aim high, but also be realistic. (and it's ok that your startup isn't Apple tomorrow!)

Before I close this posting, I want to add one more thing. I met with both a startup and nonprofit yesterday and mentioned this phrase. Both of them are (in my opinion) experiencing a variant of launching too slowly in the sense that they're planning too rigorously. Will there be a market for this? Will this be effective? Can we get biz dev partnerships with these companies etc.? Part of launching broken, is launching broken. It's building in manual processes when ideally, there are automated processes. Why is this good? Because then you start selling tomorrow! And if you get so much business that you need to make an automated process -- that's a good thing! I say don't plan for the absolute, ideal world where everything you do, you crush. Just plan on getting something out the door -- be smart about it and make sensible decisions -- but get it out there and get market feedback as soon as possible. Don't try to solve every problem before they exist. The market will tell you what you need to know.