Users demand delightful experiences (see: Pinterest, Square, Path), but at what point does polish get in the way of finding product market fit?

The first versions of Facebook and Twitter weren't pretty and users flows probably weren't great, yet their products were inherently compelling. There was an underlying addictiveness to the experiences they offered their users.

So when should a startup ship their product? If the fully-realized app has four main components, should the startup only build one or two of those components with the finest attention to detail. Or should they bust out all four in a semi-embarrassing way?

Ship early, ship often, fail fast, and track. Repeat.

I used to keep a folder of screen shots of v1. of products, partially to track the evolution of the products, and partially to remind me on what v1. was. The journey only really starts when your product actually intersects with real people, ie: users. So I believe you have to ship before you want to, we named it betaworks because we believe that beta's, work. There is always more that you want to put into your v1. product, I always have this queazy feeling that its not enough. But you dont really know if your hunch, your instinct about a product actually makes sense for people / users until you ship.

Re: the second question. If an app has four parts I would ship them one by one. Focus on the hook -- the core problem each of them solves. Ship one, learn from it and then ship the next.

some questions are good enough to have no perfect or right answer. reminds me of thinking as a kid where does the universe end.

i think this group everyone understands the wait forever for something perfect thing is off.

but i guess there are some measures you could use to analyze after the launch if you were too early:

- did users get what was in your mind, were they excited about it? was the piece itself enough to get solid/great press and to get people excited about where you are going?
- did the system hold up so that people could actually use it?
- were the failures that were revealed by launch interesting and revealing and informing or were they things you already knew but launched anyway?

This all sounds like great advice. But how do you know if something is a launch blocker or not?

Specifically, we are thinking of launching Branch without Discovery. That is, you won't be able to view any branches except your own, even though discovering interesting content on Branch will inevitably be a compelling use case.

On one hand, you can argue that this is the right decision. If nobody wants to start branches then who cares about discovering them!

On the other hand, you could argue that most people are lurkers not creators, and surfacing interesting content will compel users to start their own branches.

What do you think? Is Discovery a launch blocker?

For most of the products I've worked on the test has come down to: Is this the thing we need right now to make me delighted by the product. If there's something that's keeping you and the folks building it from being delighted enough to use the product all the time, that's probably a launch blocked. If it's more "this would make it better" that's something you can find out the prioritization over time and with feedback from outside users.

Before it's launched, you are the user. So you've gotta make sure you're building something that delights you.

@goldman - That's really well put. If it's something you would use even if you didn't have to, launch it.

I generally agree with the other points, as well. Good to push yourself to launch sooner than you're ready. With a couple caveats...

The bar has been raised in general in the industry. There is more and better competition for every bit of attention in every segment. As a result, users have less tolerance for lack of polish than we used to be able to get away with. They're more likely to just move on if something is janky. This may be extra true in mobile apps (much harder to get people to try something a second time—but not impossible).

I worry about the mantra of "fail fast." I think there's too much churn through ideas by entrepreneurs who are just looking for a hit instead of following a vision or trying to solve an important problem they're passionate about. It's good to fail fast on approaches or implementation but solving hard problems and creating really revolutionary things takes a long time, and they're usually rejected by the market at first.

path.com

@josh - from my experience w Branch I'd launch w/o Discovery & focus on getting the Branch discussion thread right. I find this satisfying enough w/o needing an audience. if it's not interesting to the conversants, it's not interesting to the lurkers (and I don't think you should exist just on the notion that I'll be motivated to do it by audience)

@hunter i agree

I think @ev makes a solid point - the bar for product design is just higher now (and rightly so). I think there's a sweet spot between too raw and perfect that you've gotta hit when building v1 features/products. It may not -look- incredible (yet) but the experience around using it has to be cohesive enough to make me say "whoa, I get it".

As far as launch blockers, sometimes, especially as an engineer, it's hard to separate the cool-to-build factor from the this-makes-the-product-better factor. A trick I've found helpful is trying to look at each feature through a lens of "will the product suck if this isn't there on day one?" Sounds a little backwards but it's proved to be a good bar for "must-haves on day 1".

I was thinking about this question yesterday as we shipped something off the app store. I see the threshold / bar as different for iOS than for web development. The iOS development process has made it next to impossible to launch in beta, and as with any closed distribution process it has shifted the emphasis of development. While, I agree with @kylebragger there is a sweet spot between too raw and perfect, I see that spot as different for web and iOS.

@hunterwalk couldn't agree more about the conversation vs. public branch/discovery. I view these branch threads as conversations, akin to an email thread -- where I consider the people in the thread, their positions, their experience, their words. I dont think about the public aspect of these conversation.

@goldman i was thinking about the delighting factor of launch and totally agree, except i would add that its too confusing to know if you and your team are delighted so its incredibly important to have a fairly wide group of people you trust and believe in to be showing it to. when they start saying "omg can i share this, can i join, can invite" etc i think you know you have the kernel of things ready to go.

@borthwick totally agree about accepting environments, super frustrating to find a vital bug in an iOS app and then have to wait days for it to clear the appstore and then for users to go re-download. completely difference from a site where you fix and that reaches everyone in seconds/minutes

Speaking of iOS apps, are any of you in favor of going the HTML5 route (a la Facebook) until you find product-market fit? It allows you to iterate constantly without pushing updates, though we all know how choppy the experience is.

Borthwick, almost all of betaworks' in-house companies are mobile-first AND native. Why?

Paul, Kyle, and Ev– you three chose web-first. But when you do get around to a mobile app, do you think it'll be native or html5 to start?

[P.S. I ask because Branch just hired an iOS developer (!!!) so we are having this debate, internally, as we speak.]

I would like to believe that you can go HTML5 and then flip to native when you achieve fit but it hasnt worked well for us. The distance between HTML5 and native is just too great. Furthermore - its becoming increasingly important for app's to have access to the data infrastructure that native app's offer (ie: calendar, address book, notifications etc.).

@josh for Forrst web-first made sense since it's still easiest writing code or doing design on a desktop/laptop, but the apps that some of our users built for iOS are all native (e.g. leefapp.com)

@john That is an interesting observation and something that I've experienced as well. The html5 experience never quite felt "right". Even with phonegap or trigger.io or other such frameworks, there's just something about a non-native experience that doesn't quite work in my eyes.

Though I think it's interesting to think about doing an MVP in html5 and investing resources to port to iOS later, it seems that from a use of time (and funds) perspective it would be worthwhile to just start in iOS anyway. If it catches on, you're a step ahead.

There's a heuristic I keep coming back to that I hadn't quite thought of this way until this conversation: If what you have improves the world for those using it, release it.

That's clarifying for me.

I think you can often tell this amongst you and your team. (It's another take on "would you use it if you didn't have to?") But sometimes you need external feedback to figure this out.

It means your product has to be better -- for *some* purpose -- out of the gate than existing things. But not polished is ok. So many bugs it's going to frustrate people is not.

For Branch, clearly there is value in how it works now, so I agree with Hunter.

That makes a lot of sense. Thanks.

I really appreciate the time, everyone! It sounds like it's time to...