Don’t Be Afraid to Make a Good Product

With literally hundreds of new ventures being born each day, it’s easy to think that building a startup’s just about slinging together some code and hoping.

Throw enough ideas at the wall, and some of them’ll stick.

If you are not embarrassed by the first version of your product, you’ve launched too late.

Reid Hoffman

And there’s no denying that worked really well. But markets (and consumers) are becoming more picky. So should we all still be following Reid’s advice? Is it really the right thing to do?

A Sound Idea

The idea behind launching super early is that you get to find out if people really want what you’re building before you’ve even finished building it. That way you waste less time developing something nobody wants, and more time iterating to something that people need.

And as an idea, it’s pretty sound. If people are willing to put up with a terrible first version of your product, you’re clearly helping people with a huge need.

So it seems pretty sane to just bootstrap yourself to a Minimum Viable Product (MVP) as quickly as possible, then start selling it as fast as you can.

Who cares if your users churn right away? You can deal with that later. For now, it only matters if they sign up and pay you in the first place. That way you know for sure it’s at least a problem worth solving.

The Real Problem

So you’ve built your product. It kinda works. Sometimes. But users also kinda hate it. And now a competitor comes along with a good product, and they all churn.

There’s the rub.

If you’re building a product that solves a need big enough that people will flock to it even though you’re execution’s bad, you’re probably not the only one who’s thought of it. And there’ll certainly be people willing to rip you off soon enough.

If you’re product’s not sticky enough, and you’re not iterating really fast, you can’t build a great business.

Build Something People Want

I don’t know about you, but to me, building a terrible product and just hoping it’ll work out in the end seems like a crummy idea.

There’s a better way.

Don’t build a product that everyone hates, solves just enough of a problem to be useful, and constantly breaks. Instead, build a product that solves a simple problem really well.

Your MVP should be a skateboard, not a wheel.

I’d much rather pay for a beautifully designed product that promises to make my life 10% better, than a fugly one that promises 100%.

Give me the skateboard any day.

Y Combinator (and of course Paul Graham) popularized the notion that we should make something people want. And what consumers want right now is great looking products.

Need an example? Check out Stripe Atlas. They’re dealing with super boring problems like incorporation and banking, and making it look beautiful. I’d use them at twice the price, because the experience is great.

Build Something You Want

The most critical gut check that it’s all too easy to skip, is to build something that you really want.

It’s OK to be embarrassed by the first version of your software like Reid says. But better if that’s embarrassment in retrospect, not at the time. If your gut tells you not to launch something because it’s just too bad, maybe take a second to listen to it.

From experience, I’ve launched some terrible software in the past, because I totally bought into the whole ‘launch before you’re ready’ philosophy.

Every time, that’s been a mistake.

Our early customers all churned almost immediately.

And that’s kinda disheartening. To be honest, it sucks.

So this time, with HelpDocs, we’re doing things differently. Our knowledge base product is still really young, but it looks beautiful, and it’s super robust. It works all the time.

Because why should people trust a new product if it looks like crap and breaks all the time?

Just think “would I use this product?”. No? Don’t ship it.

So what should you do?

In the end, don’t sweat it. If you build a product a ton of people want, that looks and performs well, then get it in front of those people, you’ll do great.

It’s a harder path, for sure, and it might take some more Engineering hours, but the end result will be a way better startup.