Building A Great Product is Really Hard — A Note to First Time Founders

For many first time founders, their biggest challenge is underestimating how much thought must go in to building a phenomenally simple product.

The pursuit of simplicity is a complicated endeavor.

The only apps they’ve ever used are those built by enormous companies (unicorns, decicorns, or dragons, if you will) that employ talented product, design, user experience and development teams.

As users we complain when Facebook’s app is a bit slow or when Twitter occassinally crashes on our phone. These are public companies that have been working on their products for years — they serve as proof that at any scale building a simple, elegant and “easy-to-use” application is difficult.

Yet the app that comes to everyone’s mind before they get ready to build their product is “Uber” and they think: “well, why can’t my app be just as simple? I just want someone to click the most obvious button on the screen to make the most obvious thing happen.”

And here come the problems:

(1) Development firms talk to clients and in trying to make the sale say “of course we can build an app as simple as Uber — building a couple of screens with a ‘buy now’ button isn’t hard at all.” These firms aren’t lying, building a couple of screens with a “buy” button really isn’t difficult — but they know like any other firm that build many products that the process of pairing down to that level of simplicity is a daunting and complicated one.

They don’t set expectations appropriately because they have to compete with everyone else who is also saying the product will be a really easy one to build.

(2) Feature Creep: “My app will only let users do this one thing — they’ll open the screen and just click one button, and it’ll happen.” As soon as I hear this I’m pretty convinced our firm should not get involved with a company. There is just too much of a learning process that the founder will have to go through if they think it’s going to be that easy.

What happens if something goes wrong? For Uber, what happens if a car cancels? What happens if you cancel? What happens if your credit card has expired and you need to go into your profile and then re-enter your AMEX credentials? And then what happens if you enter those digits incorrectly?

And what has to be built to coordinate the drivers? What kind of rules do we need to implement to decide which driver gets to pick up the rider? “The first one who confirms!” You might say… but what if the first one that confirms is really far away, and has been with that passenger before and has gotten a bad rating from that same passenger?

And then of course there are other things any user should also be able to do. A founder will talk to their mom, their boyfriend, their startup friend who was really early at Facebook and knows everything and they’ll get new feature ideas mid-build.

They say “we must have this feature!” And then two weeks later wonder why the timeline for the final release has been pushed back? At this point the developer must explain the concept of chronology: “if you are going to ask for 2 things and they will take 2 weeks, if you ask for a third thing, it will take a third week.

(3) Perhaps the biggest advantage engineers have in getting a product out to the market quickly is that their product ideas are inspired by “what is readily possible based on pre-existing technology?”

First time founders wonder why engineers can push out an app within a weekend hackathon, and yet are dumbfounded when their team says it’ll take over a month to code the app they’d like built.

The reason is that in a hackathon developers are using libraries that seriously restrict what functionality they can build going forward (they don’t care, of course, it’ll get rebuilt anyways and just needs to be done by Sunday later afternoon).

And those engineers are using a parse backend (which you can’t use cause it gets expensive as you scale) and they are using dummy data (which you can’t do because you actually need to deal with live user data).

So suddenly it’s taken you three weeks to figure out what actually needs to get built, you’re frustrated, your developers are already behind schedule and have been billing you this whole time and not a single line of code is written. How could this be? Do they suck?

You talk to your developer friend who laughs and says he/she could have built the app in a week. What that developer friend is not telling you is that her ability to build the app so quickly is (1) a lie (2) doesn’t include QA and (3) Is only sorta possible because you just went through a major learning curve and spent a ton of time actually deciding what you wanted to build.

Building a great product is really hard — not just from a technology perspective — perhaps that’s the easiest part. But even non-technical founders must be deeply engaged in the process. They must decide what user stories will exist, must go through every detail of every possible scenario — they must be rigorous in eliminating superfluous functionality not deemed necessary by perviously gathered user data.

And engineers/developers need to set expectations appropriately. We are a part of an unhealthy culture where “I can do this better and faster than anyone else” leads us to set expectations too high, target unrealistic timelines and frustrate the hell out of everyone.

I’m a big fan of lean startup, of build and push live quickly, etc. But sometimes we’re taking it way too far.