Philipp's Technical Wiki

The 16 Hour Product

On a quest to build financially successful products end-to-end in 16 hours. I call this build power. 🏗💪

Why not 24 hours? 8 to sleep. 🛌 Why 16 hours then?

At its simplest I believe there are:

  1. people,
  2. outcomes they want.

If you can help them accomplish those emotional+functional outcomes in a significantly better way you will be rewarded. Concretely you can make something faster, take less effort, be more pleasurable, or be possible at all. The more important the outcome is to them and the more significant your help accomplishing it, the more they’ll reward you with their money or time.

Motivation

In my opinion two types of clear-cut opportunities in entrepreneurship are:

1. Easy to build, hard to find

People dissatisfied with their ability to accomplish an important outcome. It wouldn’t be particularly hard for a good team to create a solution and get paid. But no entrepreneur has discovered this opportunity yet. This is a findability problem. Here’s a bunch of examples. These don’t usually make a ton of money unless they are crazy counterintuitive like AirBnB and Facebook was.

2. Hard to build, hard to persuade

People satisfied with the tools they use to accomplish an important outcome. Using a recent scientific discovery allows building a solution to do it 10x better. You need to be living on the bleeding edge of the technology. This is Wozniak from Apple, Max Levchin from PayPal, and Hotmail co-founders if you read their story in “Founders At Work” by Jessica Livingston. Not only do you need to be damn good at applying your technical expertise in the right place, you need to prove to people how dissatisfied they should be with something they thought they were perfectly happy with.

My Plan

After spending 2.5 years on several MVPs in both #1 and #2, I am switching exclusively to #1 and only if I can do it in 16 hours. Of course there is a class of problems in #1 that would require 2 days, 1 week, 1 month, 3 months, and so on. That comes with uncertainty tolerance. As an engineer I find myself making excuses too often that I just need 1 more day… The reality so far has been 100% a lack of demand. I can find whether there is demand either in 1 day or 1 month. It seems to be Parkinson’s Law. Since inputs don’t equal outcomes here, I’d rather try as many tiny inputs as possible.

Demand

To me, demand is roughly the inverse of how much accomplishing an important outcome sucks in some way. Whether there is true demand is the key uncertainty to resolve and I rather not wait more than 1 day to find out.

A lot of times I’ve heard it be called “risk”. I think this is misleading. I prefer using Frank H. Knight’s definition in “Risk, Uncertainty, and Profit” from 1921:

  1. risk is present when future events occur with measurable probability
  2. uncertainty is present when the likelihood of future events is indefinite or incalculable

When building an MVP you don’t know what % chance it has of generating revenue. Even if you have pre-orders in cash (we had $15k once) you might not actually generate revenue after you release. You only start having measurable risk once you can measure your e2e funnel of generating revenue through product usage. Until then you have pure uncertainty.

Build Power

Another common inner refrain I had was: “But Philipp, sure you can build the logic to do cool stuff in a day but getting a production ready product deployed takes more than that.” I’ve come to think of that as an excuse as well. Great, so I should optimize a system so it takes 0 seconds to create anything but value. Things are basically UIs/DBs/REST APIs. It’s the same process over and over and over again. Hence “build power”.

If you are interested to join me on either my technical or product journey, I have 2 Twitters since they don’t let you define “topics” or “facets” of what you tweet about:

Entrepreneurship Twitter

Tech/Nerd Twitter