“Several distinct problems manifest themselves as delays in launching: working too slowly; not truly understanding the problem; fear of having to deal with users; fear of being judged; working on too many different things; excessive perfectionism. Fortunately you can combat all of them by the simple expedient of forcing yourself to launch something fairly quickly.” —-Paul Graham, The 18 Mistakes that Kill Startups

When you’re going through Y Combinator, one piece of advice you receive is to “ship early” — to launch well before you think you’re ready.

At my startup, we didn’t just follow this advice. We imbued it to an almost absurd degree in everything we did. In fact, shipping early and often is now our most cherished company behavior. It’s an ethos that I believe has been instrumental to our growth, and one that most every company can benefit from adopting.

Here, I’d like to share a bit of tactical advice on what this means, and how to do it:

Why shipping early matters

The virtues of shipping a product are hopefully clear to everyone. Without shipping, you have no growth — and by definition, you are not a startup.

The problem is, we all tend to ship too late and too infrequently. A number of psychological factors collude to stop you from shipping: pride, perfectionism, scope creep, fear of criticism, fear of rejection.

I learned this the hard way. In retrospect, the very early product development at our company was hilariously bad. We spent months working on something that had no users at all, based on the misguided belief that there was some set of features we could develop that would switch on growth.

Once we joined YC, it became unavoidable that the product we had built just wasn’t working.¹ If we wanted to survive, we needed to toss out our first grand vision and try something else.

Work toward a v0, not a v1

We started releasing a series of fledgling products, with an increasing focus on efficiency. Every time we launched something that failed to find any users, we’d go back, work on it, and launch something a bit different. Each time we discarded a product, we’d chastise ourselves for the amount of time we spent on it, and spend less time on the next go-round.

Our MVP gestation time kept shrinking, from three months, to one week, to one day, down to a few hours. In the end it was our most minimal release, a single page that submitted a file and an email address to our inbox, that got us the most traction.

We started to call this release the “v0.” The v0 is the first step on the road to building the full vision of something, and the most minimal, just-about-fit-for-purpose version of what you are aiming to do. It’s a given that your v0 will be missing lots of obvious stuff, and that’s fine, as long as what you build includes the pre-requisites you’ll need to eventually create those things.

The v0 is the least amount of work possible to say “Hey, this is what I’m creating. What do you think?”

Shipping v0 features

A new product has many unknowns: You do not know which features will be important, and you do not know what design or implementation is going to work. Therefore, just as shipping early is essential to finding product/market fit, releasing new features early is also essential to product/feature fit.

Sometimes our features were so ridiculously basic that as soon as we released them, everyone complained about the lack of functionality. However, this was great: We’d wasted zero effort, and quickly knew that customers wanted that feature.

With careful design and Wizard of Oz techniques you can often disguise minimal functionality while preserving time and engineering resources, some of your most valuable assets as a startup.

The main downside to this approach is that your product will feel less mature and polished than it could. But the feedback, data, and learning you get from releasing v0 features far outweighs the minor early reputation damage you may incur.

Mini-demos

We took this concept of v0 features one step further with something we call “internal mini-demos.”

When anyone is working on a new feature at our company, they should share an absurdly early version of it. We do this on a projector in the middle of the office. Anyone who is free sits around the giant screen, observes, and discusses.

This usually means that you demo a new feature after one day or less of working on it. This could be a new piece of an interface, or even an obscure technical feature (“I click this one button and all our infrastructure rebuilds it self, isn’t that rad?”) Mini-demos are not just for the start of a larger piece of work: They happen constantly, whenever there is something new to show.

These mini-demos are incredibly useful, for a number of reasons. Mini-demos:

• Point people in the right direction before they’ve travelled any significant distance. It’s easy for someone to be a bit off-track at the start of a project.
• Pool together the combined experience of our team, feeding a diverse range of viewpoints and needs into each feature’s design.
• Provide a regular drip feed of progress, and help everyone understand what others are working on.
• Bring together people who are remote or traveling.
• Prevent people from doing unnecessary work when it comes to presenting ideas (e.g. building a powerpoint deck instead of just writing some bullet points.)
• Provide a forcing-function to get stuff started and working.
• Make each day feel successful and exciting.

It’s important the discussion around mini-demos is productive. The most helpful comments are specific and rooted in data or past experience (e.g. “Last time we released an icon-only interface a lot of customers needed a lot of help to work out what the buttons did”, “Our sales team spends their entire day in that one screen, could we make it remember their preferences?”) Beware of bike-shedding — don’t allow the conversation to get into the weeds with petty debates or critiques.

Just as founders initially struggle to ship early, everyone finds giving mini-demos awkward at first. Sharing a scruffy, half-baked piece of work with a room of people you want to impress might feel counter-intuitive, particularly for new employees who have just joined the team. However, with gentle encouragement and regular participation, I’ve found that almost everyone grows to love this way of working.

It goes beyond tech

Shipping early is not just for engineers. Based on the success of mini-demos for technical features, we adopted this practice within all of our teams. People jump on the projector and share their new lead-qualification spreadsheet, their new customer help article, their hiring pipeline, their latest Zapier integration. Absolutely any kind of work can and does turn up as a mini-demo.

To make sure the mini-demo process itself does not become bogged down with dogma or rules, we keep them flexible. Mini-demos are not relegated to a certain format: We jokingly call very small changes “micro-demos,” and sometimes there are larger-scale “macro-demos.” They can happen at any time: Often, during lunch a quick succession of people will hop up on the projector for a few minutes and share the progress they’ve made on something that morning. Before we ship a feature live, we hold a final “any last concerns” mini-demo. The key is to keep it entertaining and productive for everyone.

Shipping everything early and often is our best company practice. Thanks to mini-demos we create better work faster. We hope others find this practice as beneficial as we have.

David Mack is the co-founder and CTO of SketchDeck (YC W14), the service that provides designs on demand by allowing businesses to outsource their presentations to professional designers. He earned a BA in Computer Science from the University of Cambridge, and an MSci in Mathematics and Computer Science from the University of Oxford. You can read more of his writing here.

Notes 1 When in doubt about traction, three months with no distinct user growth is a reasonable warning flag that it’s time to try something else.↩