Why I'm building 20 startups in a year

I’m going to attempt to build 20 startup experiments of varying sizes within the space of a year, with the aim of maximising exploration, learnings, and further pursuing one or more of the startups beyond the #20startups experiment. Yes, it sounds ridiculous (and maybe it is).

Why I'm building 20 startups in a year


I’m going to attempt to build 20 startup experiments of varying sizes within the space of a year, with the aim of maximising exploration, learnings, and further pursuing one or more of the startups beyond the #20startups experiment.

Yes, it sounds ridiculous (and maybe it is).

This experiment format is inspired by the likes of: Pieter Levels, Jon Yongfook, Andrey Azimov and my own experiences of building products.

Why am I doing this?

This process will aim to test startup hypotheses while overcoming the following problems:

1. Delayed failure

By being a perfectionist and polishing ideas before sharing them, failure and learning is merely postponed. Rather than working on a product in isolation for any extended period of time, I aim to expose an idea to the reality of the market in its roughest acceptable form. This will force the scope of each startup to be kept down to the features that really matter. By learning, improving or killing a project sooner, less time and money is wasted.

Realising error early vs. realising later with greater time and money investment

2. Success pressure

Following on from the last point, many viable ideas don't get market tested at all!

Instead, they get built and abandoned, sitting on the proverbial garage shelf. This is because 'success pressure' increases the longer that a product has been worked on — leading to a fear of failure if the product is exposed to the harshness of real world testing and customer decision-making.

Imagine a person that has put 6 months+ into working on something before exposing it to customers. There is much greater pressure for it to be successful than something that received only a fraction of the time. Did they waste their time or spend it well? Each day added to the development prior to a test incrementally adds pressure.

'Success pressure' increases as more work is done without validation, resetting if work is validated with customers. (Of course never resets to zero, as there is always a risk)

3. Competing priorities

No one has singular focus on what they are working — we all have lives filled with other things. When you collaborate with anyone, decisions need to be shared and agreed for everyone to stay engaged and feel a part of the process. However, of course each person brings their own life and competing priorities. As the number of people increase, the number of competing priorities also increases — which can impact the pace of progress in the early stages. Growing a team is essential with a scaling business — however at the very, very early stages, it can be fastest to run solo.

As the number of collaborators increases, so do competing priorities. 

4. Lack of deadlines

A task takes as long as the time that is assigned to it. But self-assigned tasks without a clear deadline can drift and don't push their way up your personal priority stack in the same way that more immediate things do.

An effective deadline isn't just a date or time, but consists of another component: a consequence. Without any consequence for non-completion, a deadline is meaningless.

To give meaning to the #20startups project deadline, the consequence mechanism will be social accountability. Without people knowing that you're working on something, it's easier to make excuses to yourself. By working in public, I'm held accountable to finish each project, and have to keep moving.


That’s what #20startups is about. Building and validating at pace: minimising time wastage, maximising exploration speed and learnings.

It's more of a portfolio approach and if done right, provides upside with relatively low downside. Test a lot, see what wins. After all, the first thing I work on is extremely unlikely to be the best route to pursue longer-term.

How will it work?

The man who does things makes many mistakes, but he never makes the biggest mistake of all — doing nothing. — Ben Franklin

The goal is to get ideas into the real world at speed: to measure, refine and pivot along the way, keeping the best and ditching the rest. Each startup is an experiment. And the journey itself will also be a meta-experiment, learning about the process of building, launching online and testing. I'll review at regular intervals to evaluate what is working and what isn’t.

Within every startup idea is a list of assumptions; things that I've banked on being true for the startup to be viable, but I don't yet truly know. In this process, I'll unpack those by asking questions such as 'what must be true for this idea to work?' and 'what have I assumed to be true here?'

By identifying these, sorting by impact (how critical they are) and systematically evaluating if my assumptions were right or wrong, I can know if a startup is worth continuing and developing further.

A lot of the time, the best way to test will be by building a basic product. Other times, there may be alternative methods: user interviews etc.

Isn't 20 too many?

It’s possible to test and evaluate an idea quite quickly. Testing 20 startups also gives me the freedom to work on more crazy ideas and stops me putting all my eggs in one basket.

20 is (more than) sufficient to force momentum. Of course, this isn't a 'hard' number: the experiment can pivot in response to new learnings, and this may change.

The startups will also wildly vary in scale: some will be major projects consisting of multiple launches, whereas others will be smaller, crazier, and launched more quickly. #20startups is about putting as many sensors as possible into interesting niches in the market, and making decisions off the back of it.

This approach has a number of benefits:

Some elements will surely be similar across products, so pieces may be reusable. I will also become more proficient along the way, so time-to-build will come down.

Marketing can take time to bed-in and gather traction, and I will also be able to try different marketing approaches to see what clicks.

Lastly, this will be a chance to intensively broaden skills across the full width of a startup, as well as different industries — making me a better founder and product manager.

Why in a year?

It's an entirely arbitrary deadline, but as good as any. It serves the purpose of providing pressure to keep moving. The speed forces me to stay broad rather than jumping into going too deep, too early on any idea (depth can come later).

What will the startups be?

Well, they'll focus around a number of themes, including 'the future of work' but they won't be grouped within a single industry.

But "these aren't real startups”. Right. And wrong. At what point is a product-driven business deemed a worthy startup? These ‘startups' are not finished businesses, but a vehicle for testing hypotheses.

Nothing starts as a fully fledged business. The only startups that the general public are aware of are mass-market, venture-scale monoliths. Really, these have ceased to be startups and are more accurately future-focused corporates or 'scale-ups'. The majority of their innovation is imported through acquiring other startups. Virtually all interesting startups begin as a scrappy solo founder/pair of founders hacking something together to find a path for growth.

Wrap up

“I don't know where I'm going from here, but I promise it won't be boring.” — David Bowie

To sum up, #20startups is a mega-experiment of smaller business experiments, each testing a business hypothesis, but also collecting broader learnings along the way.

Because the entire thing is an experiment, everything you've just read may change entirely! (Sorry) But that's part of the process.

In any case, some of the startup experiments will definitely fail, some might succeed. But I'm sure it'll be interesting. Wish me luck...

To follow along my journey, I'll be sharing progress at 20startups.me and also blogging about the process here.