Startups: refined UX vs. quick rollouts

A startup, by definition, is an entity with limited resources. Those resources could be budget, time, talent, or anything related, but what is certain is that there is indeed some form of limitation on resources – otherwise it wouldn’t be a start-up.

It is because of this that a lot of management styles have been tried and battle tested to tackle the challenge that is launching, and running, one of these beasts of time and energy. And over the years there seems to be two independent schools of thought that have emerged within the market: the lean launch, and the big buildup.

The lean launch involves things like agile development processes, user testing, idea validation, purposeful programming, behavior driven development, and many others. Then, on the other hand, you have the big build before launch: in this model one would sink tons of time, and developers into a project to make sure that it is feature complete before a single customer ever sees it once.

These two schools of thought each have their advantages and disadvantages as one might imagine, and they each have managers that believe in them to almost a hard-headed extent. Through in this article, we may find out which ones aren’t being hard-headed and which ones are. Or we may find something surprising. Let’s dive in.

Having a refined user experience

Let’s face it, design is massively important. In fact, design is so important that it has almost entirely overtaken some startups’ processes. They focus all their time and energy on the user experience, and getting themselves to a feature complete state that they have little time for anything else — and perhaps rightfully so. Now, the other side wouldn’t say that it is the right way, but we will leave that argument for later. For now, we are talking about the world of a polished UX and feature set before launching.

The positive side of a refined UX

Leveraging the full brand
Branding is a massive topic, and it is for this exact reason that it seems people feel the need work in this manner. They feel that if they are going to launch they should launch with everything their brand stands for, being built into the site from day one. The classic, “v1 should be feature complete” is something I’ve heard from managers frequently. And there is a good reasoning behind it. They don’t want their website to reflect that which they aren’t, and therein lies the travesty. We will get more into this in the cons section, but this can lead to serious feature creep. My motto is, if you are walking into a space where there are competitors that are branded perhaps more heavily than any other space online (think: Dropbox, or Apple) then you might want to seriously consider this, because in that case branding will be very important. Though, one can marry a lean launch with fabulous technology and a nice brand, all in one — which we will also discuss later.

Receiving immediate interest
Another positive when it comes to the refined and polished roll-out is that it may attract more users up front due to the fantastic design and full service care given to the entire product. At least, that is what we love to assume. Realistically though, it can be a barrier to entry as well. I have seen users who feel a product is too big or has too many features for them to get any feeling of ‘want’ when it comes to using it, and they will bounce off the site in less than a minute. Happens all the time, and is all too sad honestly. I hate to see entrepreneur’s or even manager’s ideas get sucked down the tubes because of the all too frequent feature creep. Although it does happen, it still doesn’t keep entrepreneurs from feeling that the interest will be increased ten fold should they complete their product entirely before launch. This is a big one.

Being feature complete
If you do make it to this stage and are living in this camp, then you are more than likely feature complete at this point. We have spoken about this a bit so far in the above sections, but here is where it gets interesting. A lot, and I mean a lot of start-ups feel they need to be feature complete before they can charge, or make an impact for that matter. I am not saying that there isn’t some merit to that argument, but I think that it has been exaggerated over the years. From my point of view and from what I’ve seen over the years you can simply ask if users would pay for a product before fleshing out the entire thing. Now, let’s say you were gung-ho about being feature complete, and you did indeed want everything in. Well, you could launch a very minimal version of each feature. Something that represents the features in question, or perhaps even videos of the ones missing. Keep in mind there are ways around being feature complete without actually being there.

The downside of a refined UX

Feature creep
This is an all-to-common failure when it comes to the polished UX and feature complete approach to launching a start-up. And this is what we call a situation called the death spiral of feature creep. The managers or owners will feel the need to add more and more features to the product as you complete others, until there is literally nothing to do but add more features. It is a never-ending cycle in some cases, and especially in cases where you don’t have a rigid set guidelines or specifications established.

Waterfall development

Waterfall development is a con in its own right, and not without controversy. A typical waterfall work-flow looks like this: idea, design, development, testing, maintenance. There are some people who thrive in such an environment, but at least an equal number find it absolutely detrimental. Or it is a pretty standard process that feels very normal to most of us, and yet for ideas that will soon become apparent it can often be detrimental to actually shipping a product.

The reason isn’t necessarily in the system model itself, it is in the fact that you have separate teams doing work that is each being micro-managed by individual managers. For instance, a typical flow may look like this: an idea is formed by the founder/entrepreneur; he hires on a design and development team, and perhaps managers or creative directors for each team; the idea gets passed off to design, to create mockups, those mockups get turned into Photoshop documents that are going back and forth with the owner and creative director until they are perfect; then, without any consensus as to what is even possible, it gets passed off to development to be created; and then after going back and forth with the dev team leader, the owner, and possibly even the creative director, they find a meeting ground, and finish the product.

What I didn’t mention though, is that each of those steps involved probably 50–100 emails individually, and that is a conservative estimate (very conservative). As you can see, that isn’t really efficient, because at any time the owner and founder could add on more work that wasn’t in the plan, or change things. Micromanaging is often not the best option when it comes to software development, and yet the waterfall system seems to thrive in such a management style.

Always keep that in mind, and if you don’t work well being micromanaged then do let your boss know. Remember, it is always better to be upfront and honest about a possible unproductive future than to go down that road actually being unproductive. And also keep in mind there are more typical micro-managing issues all in the pipeline for this system; from my personal experience it isn’t ideal.

So what is ideal? Well, that is subjective, but I can tell you in my experience the ability to launch quickly and iterate over cycle times has given me and my teams the ability to ship a larger amount of products than we ever could have with Waterfall. So what is this mysterious magical system of shipping product?

Quick rollouts, and the lean start-up

The lean start-up is something that has, in my opinion, revolutionized our community. And that is primarily because it is based on something called the learn-build-measure feedback loop.

The art of the quick rollout — often it can be a simple page that asks if users would pay for this, or it can be a bare bones product — is something that people have perfected over the years, and as I get more entrenched in our tech world I feel it is more and more important.

The big thing here is market acceptance and validation. A key question: who says the code you are writing is meaningful? We live in a day and age where people really can’t fritter away a single ounce of their precious time. It is a time of make it or break it attitudes, and go big or go home mentalities. It is a time when reality hits us in the face every day when we can’t buy food or afford rent, and that is why it is all the more important to make sure you aren’t wasting away coding something nobody will use.

You don’t have to be a genius at marketing, but you do need to understand an experimental state of mind. The constant state of beta is a brilliant metaphor to this. We should never get wrapped up in our pride so much that we can’t even change an item on a project. We have to remember that life is experimental, and the sooner you realize this the better: and there is no better way than with the lean startup.

The upside of the lean start-up

User feedback

Using a method like this is something akin to being told about a stock before it peaks. This is a great way to get info on your core target demographic, and to get validation before you waste your time.

Here’s how you do it. Get a landing page made, and show what your product or service does in a very beautiful and explanatory way. Spend some money on this part if you’d like, because it’s the most important. Then put a simple sign up with your email address if interested in it. Done. Now, that may not seem like you are doing much, but you are doing quite a lot in reality. You are validating an entire product market or service market with one page. You aren’t spending months and thousands of dollars to build something unnecessary that nobody will use, you are simply creating one thing to find out if it is worth it.

There have been people that launch 5 service pages similar to what I just said, and the ones they get the most feedback on, are the ones they move forward with. It is a brilliant act, and it can be seen as investing in a lot of ways. You are getting returns on your investment, and if not you are exiting the market before you lose a lot of potential gains. I think Warren Buffet would love this.

Quicker iteration cycles
One of the best things about doing product development in a lean fashion is that you will often find that your iteration cycles are much quicker, and in some companies they ship code over 20 times a day. There is a lot of philosophy behind this, for instance how at Facebook when a new engineer is brought on board they are given 5 bug fixes in their welcome email on their first day. A lot of the reasoning behind doing things like this is that if you have your system set up in a way that it breaks every time a new employee comes on board, then it’s not them it’s your system that’s broken.

Agile development
Agile development is in essence going from one small thing to the next as quickly as possible. You then move from each sprint to the next sprint, which is often defined by a user story and that is simply a user on your site who wants some bit of functionality. It is very similar to testing in Rails or other framework, as you are only doing as much as you need and nothing more. One can save a massive amount of time by doing development in this fashion.

The downside of the lean start-up

One small negative that may happen when you are a user of the agile development and lean startup system, is that the site may change over the course of time. Now, ideally this would happen because of a user’s request, but still it may be jarring to some users.

So doing it with class and elegance is important. Especially if it is a product they care about. Don’t uproot the core user-base of your product like Digg v4 did, but instead provide details on what you are doing and why, and if all else fails roll back.

Always be sure to use something like git or subversion to save versions of your product. In fact, I do so as branches, so that we can always roll back if need be.

In conclusion

If your startup is so technically advanced that it doesn’t matter, go with the quick roll out. People will care because of the technological change they are seeing. Though, if you are competing in a space with massive competition then perhaps a combination of both is best. In short, always do the best you can with refined UX, but do it in short agile bursts.

Dain Miller

Dain Miller is a former Presidential Innovation Fellow at The White House, and mentor for developers at starthere.fm. He now works to lead engineering teams at a distributed media company. You can find him on Twitter @dainmiller or at his website