Audi or Honda? Striking the Design vs. Development Balance

February 29, 2012 by Leave a Comment

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.

Filed under Product Development Tagged with , , , ,

Increasing the Odds of Success: Don’t Expect Cascading Miracles

October 21, 2011 by Leave a Comment

Recently one of our investors asked me to meet with a friend of his who had his own startup and was looking to raise money.  I often get asked to look at startup companiesor ideas by people in my network to let them know what I think. Typically it is because they are looking to make an investment, join the company or want me to give them advice on starting their own company.  I both love and hate doing this.  What I do like is learning about new companies and the problems they solve, the different spin each one of them has and most importantly seeing how other entrepreneurs work.  What I don’t like is when I have share with another entrepreneur what I really think about their idea.  You see, like any VC will tell you, most ideas that I see aren’t venture fundable. However, unlike most VCs, I feel I have an obligation as an entrepreneur who has been around the block a couple of times to be candid in my feedback about the prospects for their company based on what I learned (so far).  In my mind, since I personally don’t have an agenda, I feel  giving the entrepreneur feedback that other folks may not share with them can be pretty helpful. I know I want to hear that kind of stuff, even if it hurts.  Anyone who knows me well knows that if asked I am pretty candid about my assessments.  And while I am occasionally wrong, I have saved my network lots of money and time (last year I helped one of my investors save over $1M).

So when I was asked to meet a fellow entrepreneur I agreed to meet for breakfast with my investor’s friend who was working on a new kind of calendaring product.

Evaluating a Startup for Investment

Before our meeting, I checked out his website and saw that I needed to complete the site’s registration process in order to see the product.  Immediately a flag went up in my head when I couldn’t use my Facebook, Google or Twitter profile to authorize the app.   In 2011 there is basically no excuse not to offer at least one of these login options for a consumer application.  I also checked out the founder’s profile on LinkedIn and saw he had some phenomenal PD experience at one of the most successful consumer technology companies around so he knew how to build great products.  Heading to breakfast I didn’t know what to expect but I was hoping my initial login issue was just a beta release nit and that I would be blown away by when I learned more about what he was doing.

At breakfast I was pretty impressed with my fellow entrepreneur’s background. Great product and technology experience. Also lots of startup stints, so he knew what he what he was getting into.

We started by him explaining the problem he was trying to solve. And it is clearly a big problem that many people have.  And many people have tried unsuccessfully to solve. There are dozens of free competitive/substitute solutions in market. None have solved the problem completely, but most people use some solution that solves part of the problem. So, kudos to him for trying to solve a big unmet need.

He spent a few minutes giving me a demo of his product and it was clear he knew how to build software. The UI was very attractive, looked pretty easy to use and had lots of features that would be needed to complete the most common jobs to be solved. But as I started asking questions about what it would take to make the product work well for most users things started to unravel pretty quickly.  It turns out that a lot of the content required to populate the application would need to come in via a feed similar to an RSS feed. These feeds would be provided by both large and small publishers. It turns out that most sites do not offer this kind of feed.  It would also require users of the application to know how to import these feeds. I don’t know about you, but I never figured out how to use RSS feeds properly. If it weren’t for the Rockmelt browser that basically did it for me, I would never use  feeds.  I couldn’t imagine your average user to be able to know how to import feeds for this app. In fact the overall product seemed like it would be easy to use IF it was an enterprise application, but it was a consumer application. It was apparent that it was not drop dead simple to figure out how to make it work for most users given the nuance of how each event could be created and shared.

Risk factors:

I then started going down the typical list for evaluating companies…user acquisition, retention, monetization, network effects etc.  It turns out my sign on process wasn’t misguided. There was not social networking capabilities built into the product other than email notifications.  Non-event organizers would not need to use the software and probably wouldn’t want to given the limited benefit unless everyone they knew used it too.  Hmmmm.  Retention was dependant on power users but lots of light users – kind of like Evite but without the pageviews.

So there was nothing built into the product that was social or incentivized non-users to use the product themselves.  The target would then be power users with no easily identifiably attribute to be able to find them in a haystack.

Given the competitive landscape he couldn’t charge for the product and I have my doubts about the other monetization options given all the factors that need to work in order to make the big bucks. The current plan for monetization was contextual advertising and selling content (specialized feed and template) subscriptions. Advertising seemed to be too distant from the core problem being solved to be able to capture high conversion rate CPAs and the subscriptions could work, but for a small market.

The best definition I have heard for marketing is “Identify a consumer need, meet a consumer need”.  But for an entrepreneur I have added a word… “Identify a consumer need, meet a consumer need, profitably”.   While it takes skill to build a great product, there are lots companies that can create products that solve a big unmet need, but never make any money.

Cascading Miracles

You see the challenge I found with this company and many other companies I have looked at is that they needed cascading miracles in order to be successful.  A hard product problem in general just to make the product easy, heavy users needed to know how to use feeds, publishers needed to provide them, users somehow needed to find the product, somehow making money would have to come together. This is way too many risk factors for a startup.  The probability of success just seemed too low.

I shared with my fellow entrepreneur my appreciation for him tackling a real, hard problem. But I also questioned the number of challenges he was going to face in order for his company to succeed.  We both understood the incredible effort required to scale a startup even in the best of conditions, why would you make your life so stressful by tackling something that would be hard almost every step of the way?   It takes just as much energy to build a company that only requires one miracle to succeed as one that requires three or four.  So why would you choose an idea/ product/ comapny  that needs more than one (or maybe two if you feel really confident or have lots of cash)? Life is too short to depend on cascading miracles for your company’s success especially if it isn’t riding any waves that give you huge momentum these days like social, mobile or local.

Facing Reality

At the end of our conversation I shared with him that I thought his startup fell in the bottom half of all startups that I see.  It was probably the bottom of the third quartile. No one likes to hear their baby is ugly.  I know I never liked hearing the truth about what was wrong with my startups.  In reality he could pivot and make something of his technology. This introduces a topic for another blog entry about how entrepreneurs can often get too attached to their ideas and develops blind spots to the realities of their company.  I wished him luck and advised my investor to pass on the opportunity.

Filed under Startup, Strategy Tagged with , , , ,

The Biggest Decision

June 2, 2011 by Leave a Comment

So we have been working  on Jernel with our small team since about November. It is now June. We thought v1 would have been completed by March and in reality it won’t be ready until at least next week – so essentially about 3 months behind what we expected. Like most startups we have been trying to deliver a Minimum Viable Product (MVP) for v1 (a la Lean Startup philosophy). The reality is that we are delivering a lot more than an MVP. This has to do with a decision we made a long time ago about how we would architect our product platform.

Let me take a step back and explain.

Last year we had a working model of the Jernel offering and did some user testing which taught us a lot. Not only did we get a feel for what users valued and what they didn’t, we also got a pretty good qualitative feel for the appeal of Jernel. Now past experience has taught us not to overvalue user feedback in usability testing on how well a product will do, but this time was a little different because the sentiment was nearly unanimous and consistent. It has been the same since I have told or shown anyone about Jernel and how it works. I am sure many marketing purists will tell me I should not overweight this feedback – but at this point in time (before we do our next set of user research) I still believe we have something special in development.

After we did the user research I also went to visit a few friends on Sand Hill road just to share with them what we were doing, get their feedback and start having them track our progress. By far the best piece of feedback we received was from a young VC partners at a major firm who suggested we horizontalize our offering and create add-in vertical solutions. This meant that instead of having unique offerings for each vertical to allow users to have a general version of our app and add ‘action packs’ as he called them for each area of interest to the user. “Otherwise you idea seems to narrow” he said. Several other good points were made that I hope to include in future posts.

The main benefit to creating a single product platform would be the ability to only need to acquire customers once and then retain them for life while they Jernel about all their interests in single location. This made a lot of sense given our learning from our first offering.

However, this feedback meant we would need to fundamentally change how we architected the product. Instead of separate instances of each vertical we needed to have a single platform with users would customize by adding the individual verticals that were right for them. This meant the set-up process was to be more complicated and user experiences needed to be adapted to toggle between verticals. It would also mean changing the paradigm the user would need to understand how the product worked. Net-net this added complexity and time to our development.
Now that we have an almost-ready for primetime product it is clear the decision to have a horizontal platform with vertical solution was the most important and best decision we have made so far for Jernel. Without making that choice it is likely we would have created our “start-up ceiling”, limiting our potential before we even started.

Filed under Product Development, Strategy Tagged with , , ,