A hallmark of new ventures that are based on scientific advances in fields like medical devices, health tech, or cleantech is that they often have invention risk. Frequently they also have market risk.
And while the standard venture capital reaction to startups with both market and invention risk is “come back when one of the risks has been eliminated”, I find them exciting, have been involved with quite a few of them over the years, and am always looking for ways to optimize the rate of risk reduction per dollar invested.
For the last 18 months I have been trying to apply / modify the principles of lean startup and customer development to a handful of companies I have been helping, each of which has a healthy amount of invention risk as well as a dollop of market risk. I have gained some insights that I have not seen discussed elsewhere, and thought I would share them.
And lest you think invention risk only applies to hardcore science projects, one of the most counter-intuitive things I have come to realize (here) is that many of the new, web-based healthtech startups that aim to change patient behavior, and thereby improve healthcare, have a very high degree of invention risk (as I define the term).
Invention risk & its management
For a variety of reasons, companies with invention risk are quite different to those, like consumer web companies, that are the typical focus of the lean startup movement. And in Steve Blank’s books on Customer Development he is quite careful to differentiate between companies with market risk (the risk there is no market for the product – read his book) and those with invention risk (not his focus).
Invention risk is present when success depends on the team making some critical technology advance that goes beyond straightforward engineering. It may take invention, or unexpected technical breakthroughs.
For example, if one wanted to machine the eye with a laser to change a person’s vision (as we wanted to do in the early days of LASIK) the invention risk was whether or not such a technology could machine the eye with acceptable results while doing no harm. At the time, it was by no means clear that this would ever be possible. The standard example of invention risk is “inventing the cure for cancer”. It’s not at all clear it can be done, and almost certainly any timeline and dollar figure one allocates to the task will be wrong.
A key feature of projects with invention risk is that both the time and investment required are extremely hard to predict accurately. And, whereas for engineering projects one can be pretty certain that with enough money and skilled manpower one will eventually solve the problem at hand, for projects with invention risk it is not by any means certain that one can do so.
Managing invention is an art of its own, with its own literature and skilled practitioners, and its own management techniques. Many of those techniques focus on improving the success rate of the inventing process.
In the context of the startup with invention risk, in my opinion a critical goal is to reduce the invention risk as soon as possible (ideally upfront before taking investors’ money). There is nothing worse than burning through $millions on elegant cosmetic product design, on marketing and sales activities, and on expensive company building, only to find one cannot invent as needed.
For companies with invention risk, I like to find out as soon as possible just what the appropriate definition is of “it works” (this itself depends very much on the use case and the customer). And then start the iterative invention process, testing each improved prototype until we can show that it does indeed “work” at the appropriate level.
A very relevant metric to focus on is the rate of risk reduction per dollar invested.
Lean methodology assumes no invention risk
The Lean Startup Movement is about combining Steve Blank’s customer development techniques for reducing market risk upfront, or as soon as possible in the life of the startup, with fast iterative engineering techniques (like agile, scrum etc).
The big focus is on reducing market risk because as Steve Blank says, a startup is a company in search of a business model. And it is critical to find a business model or pivot before the money runs out.
I am a big fan of this whole approach, but an important aspect of Lean is the assumption that once you figure out what feature set you need to attain product-market fit, it is just a question of allocating the right amount of human and financial capital. The risk on the technology side is about execution, and not about whether a given result is feasible.
Getting from Lean Startup to Lean Science Startup
The basic Lean Startup approach of fast iteration between customer development activities that reduce market risk and product / prototype improvement cycle still works well for startups with invention risk. But these things need to be done differently.
- Instead of agile engineering teams we need to have agile invention and engineering teams.
- This requires very different types of people, and quite different approaches to managing them.
- We need ways to manage the overall project that take into account the inherent unpredictability of invention in terms of duration and result.
- Instead of one big risk (market risk) we have two big risks (invention risk and market risk), and we need a whole new approach to thinking about risk reduction and risk management.
Iterative Customer development and Invention
I believe the right approach to building a new venture which has both market risk and invention risk is an iterative one in which the team advances a little way along the path of customer development, then a little way along the path of invention, then again along the path of customer development and so on.
Application space: optical tissue diagnostics
I think one needs to start with a basic understanding of the application space. By way of example, suppose we go out and learn that surgeons doing brain surgery would very much like to have a tool that they can point at the margins of the tissue they have cut out / left behind and tell immediately whether or not it is cancerous. And suppose that there is a promising technology, based on optical scattering and fluorescence, that might make that functionality possible.
Multiple MVP’s not one
Based on the team’s understanding of the application space and of what is technically feasible, I advocate conceptualizing three Minimum Viable products (MVPs) rather than the one of conventional customer development approaches in which the primary risk is market related.
The MVP the team believes in (which has some invention risk)
Assume our team has been working away in the University on optical tissue diagnostics, and has found they can differentiate between cancerous and non-cancerous tissue with an accuracy of 60%. They hypothesize that the world would beat a path to their door if they made a product based on that technology, somehow improved so it has accuracy of 80%. This is the preferred MVP. There is pretty large invention risk, in that they need to improve their technology somehow so it has greater accuracy.
The no-risk MVP
More or less the same product, but with sensitivity of only 60% counts as the “no-risk” MVP. In reality, lab results often don’t survive the first encounter with the realities of product development, and most likely this MVP is not really “no risk” of course. But the hope is that this MVP would require quite modest invention.
The ideal MVP
Inevitably someone in the team will say “but 80% seems too low. My father in law who is a surgeon says it needs to be at least 95% accurate to be useful.” The team decides that the ideal MVP is one that does the same function as the other MVPs but with accuracy of 95%. This has the biggest invention risk, and may well seem out of reach to the team.
Customer development
With these three MVPs defined, the next job is to get out of the building and interact with customers very much along the lines of the standard customer development approaches. However, now when the team talks to customers the goal is to find out which customers “need” each of the different MVP’s, and for which different use cases each MVP would be deployed.
Ideally, one builds up a two dimensional map of the different use cases vs the different MVP concepts, together with an understanding of the market size and value of each one.
And most importantly, one can develop a set of performance break points. For example, we might learn that use case 1 will be very interesting to specific types of surgeons so long as accuracy is 70% or greater. But use case 2, which by the way would be used by a different type of surgeon in a slightly different clinical procedure, requires an accuracy of 85% or better to be useful. And so on.
Most often, the way to quantify these breakpoints is by comparison with whatever the customers do today.
Iteration
Then begins an iterative process.
- Develop a MVP with the minimum performance for which there seems to be a viable use case. If this requires invention, this needs to be managed quite differently to a conventional engineering program.
- Test MVP with customers to validate our hypotheses.
- Improve the MVP by doing some more inventing and thereby improving performance enough to access the next use case.
- Repeat until MVP performance matches the required performance levels for a commercially viable application.
- Then one can move to a more conventional engineering project (still iterative but engineering not invention) and develop an actual product.
Need a different approach to risk reduction
In companies with primarily market risk, the focus is on upfront reduction of that risk as soon as possible, or on pivoting if there is no product market fit.
In companies with primarily invention risk, the focus is on doing sufficient invention, as fast as possible, to surpass some target threshold of performance for a given use case.
When there is both invention risk and market risk, the optimal approach is more complex. I have found each company needs a carefully thought out iteration process. You want to reduce market risk (or pivot) as fast as possible while in parallel reducing invention risk as fast as possible (or pivoting).
But the targets for the invention process depend heavily on what one learns during customer development. So it is tricky.
Avoid serial risk reduction
Its quite important not to do these activities serially, which I have found to be a very classic trap. Typically founders are either strong on the market/business side of things, or strong on the technical side.
The technical founders want to spend all their time and money reducing invention risk first, with the idea that after that the commercial stuff will follow smoothly. The trouble with that is that often you end up with a great product that noone wants (poor product market fit), or you end up with a great product concept, but with the wrong target level of performance.
Commercial founders tend to overlook the need for invention, and the challenges of building an organization that can invent on demand. They tend to end up with a nice looking product, with lots of marketing and pr activity, but which at the end of the day is discovered not to “work” at the performance level required.
Science startups with one risk
And about that startup beloved by professional investors: the science-based startup that has either invention risk or market risk but not both.
Steve Blank’s work is all about the idea that most/all startups have market risk. Even that “cure for cancer” probably has market risk. What if the cure is not perfect or has side effects or costs too much. Is there still a market for that?
As for the science based startup without invention risk, I think those do sometimes exist. But all too often, it turns out that when you dig deeply into what the technology can do without improvement, and exactly what customers might like to use it for, there is a performance gap. And some invention is required.
I have decided that most interesting science based startups have some combination of the two risks. Hence this post.
If you would like to share your experiences, I would love to hear them.
Leave a Reply