Money Can’t Buy Knives

Most technology startups involve some amount of engineering risk. Can we build it at scale? Can we build it for $X by our launch date? Can we refine the product to be attractive before we run out of money? There is a ton of material from the lean/agile world on how to approach these challenges. I’ve read it all. Frankly, while much of this advice has been useful to me in my transition from PhD to CEO — the existing literature just wasn’t very applicable to the very early stages of polySpectra.

The problem was that polySpectra was facing significant scientific risk — which I want to distinguish from other types of engineering or technical risk. A key differentiating feature of scientific risk is that the probability of solving the problem does not necessarily increase with more money and time. (In other words, the outcome is a highly non-linear function of effort.) Most scientific questions lead to more questions, rather than answers. If you are writing a software product, you can pretty much guarantee from the beginning (if you are competent) that it can be done, with enough time and money. If you are building hardware which utilizes components already on the market, same thing. It might not come together exactly as imagined, but you can be sure that the product is possible within the known laws of the universe. If, on the other hand, you are trying to figure out if newly discovered molecule behaves the way you want it to — forget about it.

Enter Surf Ninjas (indisputably the greatest film of all time). For the context of this article, you really only need to remember one line from the movie, young Rob Schneider’s sage advice that “money can’t buy knives”. I’ve embedded the clip below, but I’m sure this link will break eventually. The metaphor: true scientific breakthroughs are the Knives of Kwantsu — you can’t simply buy them. It has to be your destiny to find them.

The point that I am trying to make here is that most of the agile methodologies (and classic Silicon Valley playbooks) out there will not help you address true scientific risk. It is very hard to “scrum” when you cannot predict the outcome of any of your experiments. (Believe me, we’ve tried.) Having more money might help you prove (or disprove) your hypothesis faster, but it might not. “Move fast and break things” assumes that there is a working product to break in the first place. What you need isn’t money, it is a place to do science, a team, and (ideally) a community of scientists to inspire you to develop new ideas. For us, that was Berkeley Lab and the Molecular Foundry, via Cyclotron Road.

Here is my advice for deep tech companies that still have significant scientific risk:

  • Find your foundry. Keep it in the lab for as long as possible. Don’t raise a bunch of money just to run your first experiment. Find a home that already has the basic research infrastructure you need to attack the most fundamental risks. These types of deep tech incubators are popping up all over the place, as universities and labs realize that they can build mutually beneficial partnerships with startups.
  • A publication is not a product. You probably have way more scientific risk left than you think, because you are a biased expert. If you can’t transfer your process to a new lab, with a new person running everything — you still have scientific risk. If you can’t teach a contract manufacturer how to make a railroad car full of your new material — you likely still have scientific risk (although your scale-up might be considered engineering risk if the process is well-precedented).
  • Who has done this before? There is nothing new under the sun. Someone has gone through a similar challenge in the past. They can’t tell you the answers, but they can give you frameworks, benchmarks, protocols and processes to accelerate your scientific derisking. Find them.

Deep tech needs a different playbook. If it offends you that Silicon Valley refers to programmers as ‘engineers’, you’ll likely agree. There is a small community starting to put that playbook together the hard way. If you want to help, learn, or just peek at a work in progress, please consider signing up for my newsletter over at PhD to CEO.