Audi or Honda? Striking the Design vs. Development Balance

Last year I bought my first non-Japanese car in over 20 years of car ownership. I purchased a pre-owned Audi A6 from a friend of mine.  It is a wonderfully designed car for the driver with a great interface and   powerful engine.  Quite frankly it is a little too fancy and stylish for my personality, but my wife and kids love it.

A few months after driving the Audi I had to take it in for an oil change. To my surprise, instead of it being the usual $40 plus a free car wash in about 15 minutes, it cost over $100 and took almost an hour. I asked the service person why it was so expensive, and he explained it was partly due to the higher grade synthetic oil required, but mostly because of the time required to remove several components under the hood just to get to the oil tank and drain it. He told me that it takes almost 15 minutes for this preliminary step before they even start the oil change. When done, they need to reassemble all the parts again and it takes another 15 minutes to complete. I was so surprised at how two different makes of cars could have such dramatically different maintenance costs and times for basically the same operation.  When I took in the Audi for its scheduled maintenance session a couple of months ago the same themes reappeared.  The Audi dealership told me they would charge me $300 just to tell me why a dashboard indicator light was on. It took longer and cost more for the Audi check-up compared to similar work on my other car, a Honda.

This experience got me thinking about the choice car manufacturers make when designing and developing their automobiles. Forgetting the different class of car for a moment, it seems clear to me that Audi optimizes for an awesome user experience, but there is a trade-off, the cost of maintenance is much harder for those tasked with keeping the Audi running lean and mean.  In contrast, Honda strikes a balance differently, clearly making some compromises on the user experience but makes the total cost of ownership much lower, giving them a more broad appeal.

Do you think these kinds of choices only apply to cars? Well if you have owned an iPod or iPhone for a while you may have had the not-so-wonderful experience of the battery dying. It is almost impossible to change the battery on your own. Instead it is a long and expensive process to get it repaired or replaced relative to just buying a new one at Best Buy or Amazon and popping it in yourself.

So how does this relate to a technology startup?

Product Design is all the rage these days and clearly user’s expectations of a great experience is going up. But as a small startup with limited resources there are many time when you need to make choices about what and how you build your product.  Thus the question I am asking is should you build an Audi or a Honda?

At the early stage of your company when you are just trying to get to product-market fit, it is more important to make sure you solve an unmet need of your target user with a product that can easily be improved and scaled rather than ensuring an absolutely amazing end-to-end user experience.  Here are some examples of when you are making these choices, knowingly or unknowingly.

Design:

In an ideal situation every pixel on a screen is beautifully designed with cool interaction widgets and impeccable graphics and colors. Several applications make wonderful use of animation and detailed graphics that bring a certain ‘wow’ factor to their users. However, each element takes time and money.   I have several creative ideas for Jernel that will certainly delight users in their initial and ongoing use of the product, but at this time when we are still trying to make sure we solved the right problems in the right way. Now is not the time for us to be investing time and resources into these cosmetic elements. We’re still focused on the ‘steak’, when we solve product-market fit, we can put more effort into some more ‘sizzle’.

Focused Components vs. Multi-Functional Systems:

As mentioned in the Audi oil change example, Audi is optimizing for the user experience not the mechanics that will be performing maintenance on the car. So making changes and updates takes longer and costs more.  Audi has taken individual components and combined them into multi-functional systems. So when one component requires attention the entire system must be taken apart and reassembled.  Software code can also be written in very small modular, bite sized code that has logical break which is easily tweaked as you scale and adjust your offering.  This provides meaningful division between critical components and keeps them properly separated within the different layers of the application.  All this allows for easier maintenance, scalability, reliability and performance. However, all too often I have seen engineers hack several components together in order to get them to work for a release. If something needs to be changed at a later date significant surgery needs to be performed to address many shortcuts that were taken to quickly get a release out the door and unnecessary mixing of different tasks into a single, bloated chunk of code.

Simple Maintenance – Leverage Existing Tools vs. Building Everything Yourself

With all the open source tools out there, it is really worth taking the time to investigate what is already available to re-use for you needs. Almost always they will not be a perfect fit, but good enough.  The key is that there these open source resources are constantly improving over time and leverage those benefits as your product grows up.  An example of this trade-off for us has been using our own unique buttons in our application. We have over unique 100 buttons in buttons in our application, many times requiring different colors depending on the user context. While it is not expensive to have each button wonderfully designed to look great, it can be a challenge to maintain all these assets as the product grows the way we hope and expect.  Instead, we have moved to using CSS3 HTML standards as a way to simplify our lives and have one less item to worry about maintaining as the product evolves and expands over time. The buttons may not be as pretty, but it sure simplifies the lives of several product folks charged with managing the buttons.

Not every startup can afford to have a Pixar animation engineer or an Apple designer on their team, so the reality is that you will probably have to make choices early in your product development about how sexy your product will be.  No doubt with the right people and resources you can indeed create an elegant user experience, but first solving an important user need and striking the balance amongst your limited resources is critical. With the right team and a little luck you could build an Acura in your first releases as you search for product-market fit.

Building a great product in a weekend – is it possible?

So I’ve been thinking a lot about advice I have seen on Twitter about getting your product out there super-fast. In particular, I have pondered about the statements that encourage entrepreneurs to build a product in a weekend, launch it, get feedback, iterate and, if you can, charge money for it; all within a few days.

What I’ve been struggling with is:

Is that reasonable? Could we have done that?

Even more so, what kind of traction is reasonable to expect?

How long would it take to demonstrate enough traction to raise an institutional (VC) round from such a fast time to market?

As an early stage entrepreneur we hear a lot about finding the Product/Market fit. Which basically means figuring out if you have solved a problem with your offering that a significant number of people have.  The way I describe it is ‘do we have a winner?’ i.e. is this a winning, big idea concept if we keep going with it?

However, finding Product/Market fit and have a mass-market appeal product are different. You can probably figure out if you have Product/Market fit with Innovators as well-described in the Diffusion of Innovation Graphic:

Diffusion of Innovation

And this is a tremendous milestone in itself, because it is very hard to get product/market fit with any sized market. But then there is the next major milestone which I call 80% product/market fit.

To me, 80% Product/Market fit means that the significant majority of users in your target market can use your offering successfully. In other words it solve the jobs they do in order to want to continue using your product again (and again). This does not mean having certain advanced features that leading edge / pro users want, but solving the problems the vast majority will need in order to adopt your product on a regular basis.

80% Product/market fit from a time perspective can occur somewhere between the latter portion of ‘Early adopters’ and the early ‘Early Marjority’. Why isn’t it a specific milestone on the graphic? Well because I am separating the product development cycle from the customer acquisition and distribution aspects of technology adoption. The graphic shows when users actually adopt the product. The product may be ready for the vast majority at times different from when users actually start using them due to the  acquisition capability of the organization (sales force, channel management, social media etc.).

There is a wide spectrum of what it takes to get to Product/Market fit at the 80% level. While by no means simple, it is pretty fair to say that the timeline varies by the types of offering you are developing. Some very successful products like Instagram, Twitter, eBay, Turntable.fm surely had a much shorter time-to-market compared to complex applications like most EA titles, enterprise software, ad serving technology and popular analytical tools like Google Analytics.  An interesting observation is that many of the companies that have had shorter development timelines seemed to have large amounts of user generated content and participate in markets with network effects.

There are some companies like SAP which started in 1972 and took years to build to solve enough problems (aka ‘jobs’) to become an option for large corporations in the early 90’s with R/3. Most of Microsoft’s products took several iterations to find 80%Product/Market fit.  The period between MVP launch and 80% Product/Market fit could easily be measured in years (decades?).

Why I am writing this post? Well, we certainly could have been in market several months sooner if we just built what we released as our MVP.  As you might recall, after building several workflows, we removed a large amount of functionality for our public release with the expectation that most will be added back in at a later time.  However if we just built the MVP to start I don’t think we would have gotten our Product/Market fit to the 80% level much faster. In fact, we may have slowed it down.

Let me explain…

Because we were designing and building a product that was striving for the 80%, we made several architecture and infrastructure choices and investments that we would not have anticipated upfront had we just been building our MVP.  So while we may have gotten some early traction with Innovators and very early adopters, it may have taken us longer to get to the 80% level by having to re-architect various aspects of our product at a later date (see my post The Biggest Decision). John’s perpective on this is almost always ‘better to do it now while the patient is open’, and after four plus years of working together he is usually right.  Of course, it was very possible we made some investments in areas that turned out to not being needed or important so that may have worked against us. We also missed some feedback that we should have gotten sooner (Launch & Learn – quickly adapting to insights from our users), luckily that wasn’t too costly. However, on balance we feel confident we will move faster once in market to quickly get to 80%.

Since traction is so important, our speed to 80% product/market fit is what we are solving for; so that we get hundreds of thousands of users not dozens or hundreds of Innovators or Early Adopters. If we got the right initial product/market fit then our speed will be the key to our success.

If someone else has a new product that can be built in a weekend and get 80% product/market fit right away (and ideally benefit from network effects) that is awesome, and I commend them with coming up with such a great idea and opportunity. However, those opportunities are rare. I think the significant majority of meaningful companies require several months to get to 80% product/market fit and in many cases even longer.