Startup Hardness

Why Bad Ideas look like Good Ideas

Not all ideas are created equal.

Some ideas are inherently better or worse than others. Suffice it to say, most ideas are bad. But why do bad ideas so often look like good ones?

Idea = [Problem] + [Solution to solve it]

A problem is what you want to fix (such as “not enough kittens in the world”), a solution consists of what you do to fix it (such as breeding kittens, hiring employees, delivering kittens, and offering kitten-based services). An idea is the unique combination of the two.

A good idea is one that solves the right problem with the right solution.

Needless to say, good startup founders need to have many good ideas, and execute them extremely well, to be successful. When solving a problem, there may be a host of sub-problems that also need to be solved. For example, hiring 1000 employees is a (sub-)problem, and the entire process for recruiting may be the solution.


Bad ideas can look like good ideas for two simple reasons:

  1. You are not solving the right problem (and you don’t even know it)
  2. Your solution is wrong (in counterintuitive ways)

You are not solving the right problem (and you don’t even know it).

Here’s a thought experiment.

Imagine two startups set out on a mission to deliver kittens everywhere! For simplicity, assume a world with houses connected by a network of roads (see images).

Our imaginary world of houses connected by roads. [left] Startup A takes route d→a→b→e→c→f that visits every house exactly once but doesn’t visit all of the roads. [right] Startup B takes route d →c →f →b →e →c →b →a →d that visits every road once, but visits some houses more than once.

Startup A (HouseKitties.ai) decides to deliver a kitty to every home. As a cash-strapped startup, they only have one driver and one truck full of kitties. Their big idea is to develop an AI to plot a route through the roads so that they can drop off a kitty at each house and each house is visited exactly once.

Startup B (RoadKittens.com) decides to leave kittens in the streets! After all, who wouldn’t want to see a kitten on every road on their way to work!? All else being equal, they decide to develop an AI to plot a route through the roads so that they can drop off a kitty beside each road, and each road is visited exactly once.

While both variants sound eerily similar, Complexity Theory (the mathematical study of “difficulty”) tells us that one of these startups is destined to fail, while the other actually has a fighting chance:

  1. One variant is computationally easy: there’s an algorithm to efficiently solve it, even with millions of homes and roads; while
  2. The other variant is computationally hard: no one on Earth knows how to efficiently solve it, and anyone smart enough to do so could probably also break all of cryptography

But which one is which?

Take a minute to guess.

.

.

.

.

.

.

Unless you’ve seen these problems before, you probably have a 50/50 chance of getting it wrong.

It turns out, Startup B (the “roads” variant), is the easy one. This is known as the Eulerian Path Problem, which computer scientists know how to solve very efficiently.

Startup A (the “houses” variant) is called the Hamiltonian Path problem. It is among the so-called “NP Hard” problems, which have all been mathematically proven to be at least as hard as breaking public key cryptography.

All it took was a slight modification (“roads” vs “houses”) to change the problem from tractably easy to impossibly hard.

The same happens in startups. Your problem might unknowingly include one or two “Startup Hard” sub-problems: those that look deceptively easy, but are actually extremely non-obvious for even the smartest people to solve.

For example, someone building a social network might ask: “How will I monetize once I have 1,000,000 users?” But “monetization” is the easy(-er) part. Acquiring 1,000,000 users is hard. It requires solving the Cold Start Problem — no one wants to join a network when only a few people use it! This is the “Startup Hard” problem that kills 99.9% of social networks. So much so that you’d be better off building something really valuable for 1–5 users, and modifying the app each time your user count grows 10x.

Thus with your ideas, be sure that you are not glossing over “Hard” problems that render your idea useless. These can be avoided. But first, let’s consider the second way your idea could actually be bad.

Your solution is wrong (in counter-intuitive ways)

Let’s consider another thought experiment.

Suppose you are a city-planner for a city with exactly four locations and four roads (see image). There are 4000 citizens commuting from START to END each morning. Some roads take a constant 45 minutes to cross, and others get congested easily, adding an extra minute of commute time for each 100 cars on that road.

A city with four locations (START,A,B,END). Some roads take a constant t = 45 minutes to cross, and others take time proportional to the number of cars (T) on the road (t = T / 100 minutes).

Everyone optimizes for their own commute time, so eventually traffic will reach an equilibrium. 2000 cars travel Route A and 2000 cars travel Route B. All cars take 65 minutes to reach their destination.

As a smart city planner, you want to improve commute times. You add an express road from location A to location B that takes almost 0 minutes to go across (imagine, say, a hyperloop)!

The express road A-->B is being proposed by city-planners to improve traffic.

Intuitively, this should be great! Some inhabitants can now take an express route if the road from A to END is too slow.

Intuitively, yes.

But this is dead wrong.

What actually happens:

  1. Everyone who notices the express road realizes it will improve their commute. It decreases time from 65 to 40 minutes for the people who figure it out early.
  2. Eventually, everyone catches on. Soon, all 4000 people will take the route with the express road, which leaves everyone with a commute time of 80 minutes (instead of the original 65). At this point, no one has any incentive to switch, because doing anything else could make their commute time even worse.

Thanks a lot, express road. :(


This is completely counter-intuitive. But it’s a real life thing. It is an example of “Braess’ Paradox”, and it’s happened in cities around the world.

Startups are 1,000,000 times more complex than a 4-road city. Customers are complex creatures, each locally optimizing for different things, behaving in unexpected and often undesired ways. When enacting a solution, your intuition can often be nearly right, yet wrong in nearly fatal ways.

How to avoid bad ideas.

Both issues can be solved with discipline and iteration.

Find the Hardest Necessary Problems.

First, understand the problems you are solving. You might create a “model” (spreadsheet) describing all the variables of your business. Fill them in with “best guesses”, then ask yourself what assumptions led to those guesses. The most important (or most made up) assumptions are the indicators of the hard problems.

In a social network, you might ask yourself “how will I really get to 100,000 users?” This would open up a ton of questions around distribution strategy, cold starts, CAC vs LTV, and so on, revealing the hardest problems in your business.

Once you have a sense of all the hard problems, either get rid of them or tackle them head on. Some problems are almost impossible to solve, or “Startup Hard”. Sometimes you can tackle an approximation of the problem (e.g.: maybe it’s easy to get 90% of the way there), a different variant of the problem (e.g.: “roads” not “houses”), or simply ignore it (e.g.: customers don’t care about it).

Eventually you will discover your “Hardest Necessary Problem”. This is the problem that is currently hardest, most risky, and is necessary to achieve your milestones. Hit this one first. And repeat.

Validate your intuition.

Beware of fooling yourself into thinking your solution works when it doesn’t. (Remember Braess’ paradox!)

Your intuitive solution won’t always work as intended, and could even be fatally bad. Intuition gets you 80% of the way there. The other 20% comes from talking to users, running experiments, building Minimum Viable Products (MVPs), and iterating until the right solution proves itself. These are usually referred to as Lean Startup methodology.

Sometimes attempting to solve the problem is the only way to understand its difficulty.

Become an expert.

Ideas can be bad in non-obvious ways. The good news is that the good idea is often hiding in plain sight. There is usually a “structural reason” why one is better than the other: a fundamental truth about the market, the users and their behaviors, or the technology, that makes a slightly different approach the right one, and all other approaches wrong.

In the kitties example, an expert in Complexity Theory could tell you that the “roads” variant is easier because roads are fundamentally less complex than houses. Roads only touch two houses, whereas a house can have arbitrarily many roads attached. Thus restricting yourself to visiting each house only once is impossibly complex. That makes the world of difference.

Similarly, you will eventually discover the hidden structure underlying what everyone was missing — why the problem was hard in the first place, and why your perspective on the problem is so unique. This is also why investors like to ask:

What do you know about the problem that no one else knows?

How this played out for us?

At Forethought, we are building an AI that indexes internal company knowledge and answers questions for employees.

We thought our hardest problem was building a world-class AI. Yet, as a strong technical team, this wasn’t what would kill us. Our hardest necessary problem was “go-to-market”. As trivial as it sounds, it’s hard to figure out the archetypal buyer for a horizontal product — one that provides utility to everyone in an organization. As a result, you either go bottom-up (like Dropbox or Slack), figure it out, or die.

Once we discovered our Hardest Necessary Problem, we completely switched focus. We built our core AI algorithms then literally stopped writing code. Instead, we talked to as many department heads as we could, pitching them on an unfinished product, got feedback, and tested their reaction when asked how much they would pay for it.

Throughout this process, we were discovering our customer archetype, learning how to do a sales pitch, and understanding what verticals were actually bad ideas in disguise. We’ve since gained momentum and raised some venture capital (won’t go into details as we’re still in Stealth Mode ;) ).

In hindsight, we likely would have died if we focused on the wrong problems, or if we hadn’t talked to users to validate our solution.


Conclusion

Ideas are delicate. Bad ideas often look like good ideas because: (a) hard problems can look like easy ones (“Hamiltonian” vs “Eulerian” Paths), and (b) “intuitive” solutions can be wrong in subtle, but fatal ways (“Braess’ Paradox”).

Given an idea, identify your “Hardest Necessary (Sub-)Problems” — the ones that will kill you. Be skeptical of your own intuition. Use Lean Startup principles to test assumptions and iterate until the correct solution proves itself. Interleave and repeat.

You will become an expert in your domain, understand its fundamental structure, and develop your intuition for good ideas.

Along the way, you may even build a hugely valuable business.