Fucking Ship It Already: Just Not to Everyone At Once

There is a pretty common fear that people have. They’re concerned that if they ship something that isn’t ready, they’ll get hammered and lose all their customers. Startups who have spent many painstaking months acquiring a small group of loyal customers are hesitant to lose those customers by shipping something bad.

I get it. It’s scary. Sorry, cupcake. Do it anyway.

First, your early adopters tend to be much more forgiving of a few misfires. They’re used to it. They’re early adopters. Yours is likely not the first product they’ve adopted early. If you’re feeling uncomfortable, go to the Way Back Machine and look at some first versions of products you use every day. When your eyes stop bleeding, come back and finish this post. I’ll wait.

Still nervous? That’s ok. The lucky thing is that you don’t have to ship your ridiculous first draft of a feature to absolutely everybody at once. Let’s look at a few strategies you can use to reduce the risk.

The Interactive Mockup

A prototype is the lowest risk way you can get your big change, new feature, or possible pivot in front of real users without ruining your existing product. And you’d be surprised at how often it helps you find easy to fix problems before you ever write a line of “real code.”

If you don’t want to build an entire interactive prototype, trying showing mockups, sketches, or wireframes of what you’re considering. The trick is that you have to show it to your real, current users.

Get on a screen share with some users and let them poke around the prototype. Whatever you do, never tell them why you made the changes or what the feature is supposed to be for or how awesome it is. You want the experience to be as close as possible to what it would be if you just released the feature into the wild and let the users discover it for themselves.

If your product involves any sort of user generated content, taking the time to include some of the tester’s own content can be extremely helpful. For example, if it’s a marketplace where you can buy and sell handmade stuff, having the user’s own items can make a mockup seem more familiar and orient the user more quickly.

Of course, if there’s sensitive financial data or anything private, make sure to get the user’s permission BEFORE you include that info in their interactive prototype. Otherwise, it’s just creepy.

The Opt In

Another method that works well is the Opt In. While early adopters tend to be somewhat forgiving of changes or new features, people who opt in to those changes are even more so.

Allowing people to opt in to new features means that you have a whole group of people who are not only accepting of change but actively seeking it out. That’s great for getting very early feedback while avoiding the occasional freakout from the small percentage of people who just enjoy screaming, “Things were better before!”

Here’s a fun thing you can learn from your opt in group: If people who explicitly ask to see your new feature hate your new feature, your new feature probably sucks.

The Opt Out

Of course, you don’t only want to test your new features or changes with people who are excited about change. You also want to test them with people who hate change, since they’re the ones who are going to scream loudest.

Once you’re pretty sure that your feature doesn’t suck, you can share it with more people. Just make sure to let them go back to the old way, and then measure the number of people who actually do switch back.

Is it a very vocal 1% that is voting with their opt out? You’re probably ok. Is half of your user base switching back in disgust? You may not have nailed that whole “making it not suck” thing.

The n% Rollout

Even with an opt out, if you’ve got a big enough user base, you can still limit the percentage of users who see the change. In fact, you really should be split testing this thing 50/50, but if you want to start with just 10% to make sure that you don’t have any major surprises, that’s a totally reasonable thing to do.

When you roll a new feature out to a small percentage of your users, just make sure that you know what sorts of things you’re looking for. This is a great strategy for seeing if your servers are going to keel over, for example.

It’s also nice for seeing if that small, randomly selected cohort behaves any differently from the group that doesn’t have the new feature. Is that cohort more likely to make a purchase? Are they more likely to set fire to their computers and swear never to use your terrible product ever again? These are both good things to know.

Do remember, however, that people on the internet talk about things. Kind of a lot. If you have any way at all for your users to be in contact with one another, people will find out that their friends are seeing something different. This can work for or against you. Just figure out who’s whining the loudest about being jealous of the other group, and you’ll know whether to continue the rollout. What you want to hear is, “Why don’t I have New New New New New Thing, yet?” and not “Just be thankful that they haven’t forced the hideous abomination on you. Then you will have to set your computer on fire.”

The New User Rollout

Of course, if you’re absolutely terrified of your current user base (and you’d be surprised at how many startups seem to be), you can always release the change only to new users.

This is nice, because you get two completely fresh cohorts where the only difference is whether or not they’ve seen the change. It’s a great way to do A/B testing.

On the other hand, if it’s something that’s supposed to improve things for retained users or users with lots of data, it can take a really long time to get enough information from this. After all, you need those new cohorts to turn into retained users before seeing any actual results, and that can take months.

Also, whether or not new users love your changes doesn’t always predict whether your old users will complain. Your power users may have invested a lot of time and energy into setting up your product just the way they want it, and making major changes that are better for new folks doesn’t always make them very happy.

In the end, you need to make the decision whether you’ll have enough happy new users to offset the possibly angry old ones. But you’ll probably need to make that decision about a million more times in the life of your startup, so get used to it.

So, are you ready to fucking ship it, already? Yes. Yes, you are. Just don't ship it to everybody all it once.

Now, follow me on Twitter.

Fucking Ship It Already: Prototype Testing Can Save You Time

So, I was talking to a company the other day, and they had just done a major redesign of their product. Unfortunately, as soon as they released it, they started getting customer complaints. They had removed a particular feature from the main part of the product, and paying customers started to scream.

They were already allowing people to use the previous design, which was a good thing, since folks started switching back immediately. Of course, they went into recovery mode. They started looking at customer feedback and planning a redesign of the redesign to reintegrate the feature they’d removed.

I asked what I thought was a reasonable question: Had they done any prototype testing with current users during the early phase of the major redesign?

Their response was, “We didn’t have time for prototype testing.”

Oh, really? That’s an interesting answer, because they sure has hell had time to do a fairly significant reboot of their redesign after launch to fix a problem that would have been prevented by showing some wireframes to current users.

After all, they already had mockups of the new designs. Showing those mockups to users would have taken a day of work at most.

Look, shipping fast is important. In fact, these days I’d say I do far fewer interactive prototypes than I did back in the days when we were still doing waterfall, mostly because engineers in a continuous deployment process can build, test, and iterate on something almost as fast as I can with an interactive prototype.

But major redesigns that touch all parts of the interface are exactly the kind of thing that you should make time to do prototype testing on. Because in this sort of scenario, more often than not, an interactive prototype, or even just a wireframe or sketch or mockup, can end up saving you a lot of time after launch. They help you get feedback from customers before you go to all the trouble of building something you have to roll back or redesign.

The most important thing to remember is that one of the biggest reasons for shipping fast is to learn as quickly as possible from your mistakes. If you can learn more quickly and efficiently from an interactive prototype, you should do that.

Going really fast in the wrong direction doesn’t actually end up saving you any time in the end. Sometimes glancing at a map before you leave gets you where you want to go faster.

Like the post? Follow me on Twitter.

Fucking Ship It Already: Limited Products vs Shitty Products

In our second installment of Fucking Ship It Already, we deal with a common problem for startups: shitty products.

Look, I know that building a product with one or two engineers and no money is tough. As an entrepreneur, you almost certainly have far more ideas than you have resources to create those ideas. And it doesn’t help that you have people like me screaming, “Ship it! Ship it!” before you’re really ready.

Who could possibly blame you for shipping a product that is, frankly, kind of shitty?

I could. Knock it off.

Let’s take a step back and try to understand the difference between a shitty product and a limited product.

One big difference is that I wholly endorse shipping a limited version of your product. I think it’s stupid to ship a shitty product. But what does that mean?

A limited product is something that may not do much, but what it does, it does well. It makes it clear to the user what it does and what they should do. It solves a serious problem, or perhaps a small part of a serious problem. It doesn’t crash relentlessly. It doesn’t have enormous usability problems.

It is not half a big product. It is a small but whole product.

Most importantly, a limited product is just big enough and good enough that you can learn something important from it.

But a limited product probably doesn’t do anything else. It doesn’t have bells and whistles. It doesn’t have “nice to have” features. It may only support the problems of a small subset of the market. It may only be released to beta users.

A shitty product, on the other hand, often tries to do too many things at once, and it doesn’t do any of those things particularly well.

You really don’t want a shitty product because, when people don’t use it, you have no idea if they aren’t using it because you have a bad idea or the wrong market, or if it’s just because your users are confused and turned off by your shitty product.

Shipping a shitty product is one of the best ways to get a false negative on your idea. People will use products that aren’t “polished.” They will abandon products that are just bad.

Here’s an example - remember when Amazon only sold books? If you were around in the ‘90s, the company that now sells fifteen different versions of everything on the planet only sold actual printed books.

And they did it really well. They made it pretty easy to find books. They had a large selection of books. They shipped the books to you reliably. They had nice descriptions of the books. They improved on the bookstore experience by offering me a giant bookstore in my own home.

In other words, they did one thing - sell books online - and they did it well. It wasn’t until years later that they even branched out into selling things similar to books. And it wasn’t until they were wildly profitable (and no longer a startup) that they started adding advanced features like eReaders, cloud storage, and a marketplace where other people could sell things.

What they didn’t do was do a half assed job of trying to sell you everything immediately. They didn’t promise to sell you toasters and jewelry and smoked salmon but then fail to actually ship any of that to your house or charge you three times for the same item. They figured out how to sell things to people online with one understandable market that they could learn from.

Other examples of products that started out doing one thing really well are Instagram, Google Search, and even Facebook. Remember, Facebook started out solving a single problem on a single college campus.

Now, I’m not saying it’s easy to build a product to sell books or share photos or search the web. It’s not. It’s incredibly hard, and it’s even harder to get right.

But that’s exactly the reason why you need to dramatically limit the scope of your initial product. Even building something that seems easy is hard to do well. Imagine how hard it is to build something really big!

So, when I’m yelling at you to Fucking Ship It Already, I don’t mean that you should ship something bad. I mean that you should ship something limited - something that is small enough to be shippable and usable in a very short amount of time.

And then I mean that you should immediately improve it and ship it again. Do this over and over again as many times as you can for as long as you can.

Eventually, you’ll build the product of your dreams. It will probably be quite different from what you originally imagined, but that’s a different blog post.