Like many people leaving academia to join quantum tech in industry, I thought that learning about how startups work would be a good way to hit the ground running. This is because the industry is mostly made up of startups or startup-like organizations within large companies.

But it didn’t take long to notice that a lot of what I read about startups didn’t seem to apply to what I was seeing first-hand.

Eventually, I figured out what was up: quantum computing startups are not regular startups. Quantum computing startups are deep tech startups.

So what’s the difference between a regular startup and a deep tech startup?

Before diving into that question, we first need to understand how a startup is different to a small business:

  • A small business is designed to grow organically while a startup is designed to grow inorganically.
  • A small business is designed to earn revenue and spend it while a startup is designed to raise capital and burn it.

(For a great discusion of this, check out the first episode of The Startup Podcast with Yaniv Bernstein & Chris Saad.)

Another way to think about it is that for a small business, there is a fairly linear relationship between capital investement and profit, while for a startup, the relationship is highly nonlinear. If things go well for a startup, the non-linearity will exhibit an inflection point where the profit starts (a hockey stick curve).

This distinction is important because it affects how you should run your business. If you’re a small business and you operate like a startup (or vice versa), you’re going to have a bad time.

So what does it mean to “burn capital”? Is it just a fancy way to say “lose money”? Not at all. Burning capital is a conscious decision to spend money on growing your business inorganically until it reaches the point where it can generate profit.

Here are two scenarios in which this makes sense.

The first is when your product is built using software and relies on a huge number of users to generate profit. With software, the more people you serve, the cheaper it is to serve each person and you’re able to create outsized returns at scale. But while you grow your user base, you may need to offer your product at a loss. So you have to burn capital until you “reach scale”…that is, until you have enough users to generate profit.

The second is when your product relies on technology that is extremely complex, takes a long time and a lot of money to develop and commercialize, but will be very valuable once it exists. You might not need scale effects to generate profit, but you do need a product. So you have to burn capital while you develop and commercialize the underlying technology.

The first approach is how most regular (aka traditional, aka silicon-valley style, aka shallow-tech) startups work. The second approach is how deep tech startups work.

So why does this distinction matter?

In the (regular) startup world, the recommended approach is to build your company around a problem that needs to be solved, not around a product or a technology. There are sound reasons for taking this approach, and it’s completely feasible to do so if the solutions to your problem use well-developed technology like software. Once you’ve identified a problem to solve, you have a plethora of software tools and experts to develop the solution, and test it on users, in a reasonable amount of time.

This isn’t the case for the kinds of technologies being developed by deep tech startups. The underlying technology is usually developed during one or multiple people’s PhD degree/s, possibly based on years of prior work in the PI’s lab, then developed even further outside of the lab on its way towards commercialization. It’s usually not practical to start from a problem and then ask someone to spend 20 years developing a deep-tech solution to it. Instead, deep tech startups start with the technology, then commercialize it (i.e. develop the product and move it to market). The terminology for this is that deep-tech startups are “technology first”.

These are drastically different approaches to product development: having a problem and looking for a solution vs. having a solution and looking for a problem.

The fact that deep tech startups are technology-first has several important flow-on effects, such as longer time scales, higher and different kinds of risk, and the kinds of investors they should work with. You can read more about all of this in the following articles:

All of this brings up some interesting questions:

  1. Is every quantum computing startup a deep tech startup? (If they’re building hardware, probably. If they’re building software, it depends. If they’re providing services, probably not.)
  2. Does it make sense for quantum software companies to use the kinds of agile methodologies used by regular software companies if the time-scales aren’t short enough to iterate quickly? Or should they revert to traditional project management techniques common in engineering, like waterfall? Or are there other approaches that make more sense?
  3. What metrics should quantum computing startups (and quantum computing orgs) use to gauge whether they’re on the right track? For regular businesses, revenue growth is a good metric. For regular startups that haven’t reached scale yet, user growth is a good metric. But what’s a good metric for deep tech startups, specifically quantum computing startups?

What do you think?

There’s a lot of material out there about how to successfully run a startup, but most of it is aimed at regular software startups. Many quantum computing startups, on the other hand, are deep-tech startups which are “technology first”. In any kind of startup, product-market fit is critical for success, but the approaches can be different: regular startups can (and should) start by identifying a problem, then work on finding a solution for that problem, while deep tech startups are forced to start with the solution (the technology), and must find a problem that’s solved by that technology. This has some interesting flow on effects and raises some interesting questions. If you’re running or working for a quantum computing startup (or organization), it’s important to know the difference so you don’t apply the wrong lessons from regular startups.