Founder Lesson
A few years ago I had an epiphany moment about startups...the best founders are problem solvers. They see the world as infinitely malleable and proceed to think about ways to change it to add value. This might sound obvious, but when you compare "problem solving" to money, power or fame as primary career drivers, it seems way more niche (which it is).

This "problem solve" philosophy is especially true for developers, important members of founding teams. The developers that I know are craftspeople and take great pride in building elegant products to solve major problems.

One thing that I find myself thinking on a regular basis is how problem solvers (technical or non-technical founders) often get satisfaction thinking about and working on elegant solutions at the expense of the problem they are solving for customers. Said another way, it's easy to get lost in the product details that add-up to solve a perceived problem and lose site of the main problem you are solving for customers.

Recently I was talking with a first-time founder about the mock-ups for the soon-to-be-built first version of his product that he plans to launch to 100 beta users in a few months. He has a very unique perspective on an app for college students. His MVP app will be built to focus on testing this behavior and then some pretty standard features (eg calendar, payment) will be added.

When we got to those "standard feature" screens I recommended that he make them almost 100% manual (with no technology connected). For example, instead of spending development time integrating payments into his app for (what will likely be) a few dozens users, that time should be spent making sure the parts of the app that test his theory of human behavior are as perfect as he can make them.

This founder isn't testing whether or not college students will do financial transactions on apps...that's well documented. I told him that if I were him I'd get the Venmo accounts of the few dozen beta testers and do payments manually and move that development time to the what he's really validating. I'd do something similar with every other part of the app that isn't focused on testing the singular action that he's expecting.

This philosophy might seem strange, so here's some of my thinking...

- All startups pivot. Since all startups pivot, you have to assume that you will only be happy with 10-30% of what you initially build. As a result, make what's different about your prototype app amazing and make the rest basic/manual.

- You are the best version that will ever exist of your app. Startup founder often believe that their product is their startup and it will just get better over time as they raise money and build more. I would argue that the first hundred beta users of Tinder's first app on the campus of SMU (story at bottom of this blog post) talking directly with the founder were the Tinder users that got the "best app" because the founder weaved the dream to them and explained every part of the beta app as they were using it. As Tinder grew over the years to millions of users, a staff of hundreds can only hope - with product, brand & marketing - to duplicate most of what those beta users experienced with a combination of founder vision and minimal product.

- Manual means staying very close to customers. Taking all the less important features of your technology (eg payments) and doing them manually for your first 100 beta customers forces you to talk with them more. This gives you many more opportunities for customer feedback...what you should optimize for until you have product-market fit.

- Manual oftentimes is a better customer experience. In this particular case I recommended that this founder manually Venmo payments to people instead of having his customers do it. If he decides to go this way - while it will take more hustle work on his part - his customers will get the money immediately because he'll Venmo them instead of waiting for one side of the marketplace to do it. I can imagine many situations where building a non-critical feature into a beta app means that the feature is just average, but doing it manually makes it much better...and the customers won't even know it's manual.

- Do one thing great (versus a dozen things good). About a decade ago I started a startup that didn't do one thing great, but I could rattle off a dozen things that were better than what existed. When I told this story to potential customers, I could sell this product to them, but that business never was high-growth. This was a powerful lesson to me that the biggest startups (eg Uber, Waze, Airbnb) do one thing better than any other business in the world...not a whole bunch of stuff pretty good. If you have trouble narrowing down the focus of your beta app then you have to ask yourself if your startup idea does one thing better than anyone.

- Adjust your perception. Over the years I've mentioned this notion to hundreds of founders. I would say that over half still don't believe it after we discuss it. They continue to think "well...a small, focused app is okay, but it's always better to have a big, fully-feature app that's my eventual vision." If you are a founder building your first app and you think this then I would encourage you to think deeply about whether or not you are just a problem solver enamored with an elegant solution or you have a truly unique insight about how to serve your customers. If you think you have a clear way to make something that your customers love then it can be tested in a small way to start and your customers should love it in its smallest form. If you have trouble narrowing the focus like this then you might be just enamored with big, elegant solutions.

A decade ago - as a non-technical founder - I use to look at teams with strong developers and be jealous of their ability to build big products. Fast forward to today and I believe that big builds are one of the worst things you can do as you look for product-market fit with a new startup product.

The experienced startup person on this podcast describes how engineers know how all the systems work. He says that knowing the technical requirements of systems is important, but sometimes this can be a challenge because it can color what matters most...surprising and delighting customers. This was his big learning as he helped to create Instagram.

Sidenote: Here's a great blog post about overbuilding.

Sidenote: If you enjoyed this post, you might like this one as well.

Get Right to the Lesson
I’d recommend listening to the entire thing, but to get right to the point go to minute 9:22 of this video.

Thanks to these folks for helping us all learn faster
Kevin Weil (@kevinweil), VP of Product at Instagram (@instagram)
Stanford University (@Stanford)
Stanford ECorner (@ECorner)

Please let me and others know what you think about this topic
Email me privately at dave@switchyards.com or let's discuss publicly at @davempayne.