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.