Lean Medical Device Startup: Test Your Problem Hypothesis

 

 

Having trouble getting your medical device startup funded?  Most likely, you have picked the wrong problem to solve.  Think about it this way: When you launch a new medical device, you are asking physicians, hospitals, nurses and patients to change medical practice.  That’s a big deal.  A really big deal.  So get it through your head that medical practice will only change if your new device solves an important problem.  That’s why the lean medical device startup defines its problem hypotheses first.  That’s also why the lean medical medical device startup tests its problem hypotheses early and often.  You need to make sure you are solving the right problem.

What does ‘testing your problem hypothesis’ mean? How do you go about testing your problem hypothesis?

Testing the problem hypothesis means gathering external data from early adopters, to verify the severity and frequency-of-occurrence of the problem.  A high severity problem is really significant to your customer, while a low severity problem is just an annoyance.  A high frequency of occurrence means that the problem is significant for a large number of patients, not just a small subset. (Yes, I know I’m hijacking risk management terminology here).

Steve Blank tells of his experience at super-computing company Ardent:

I had needed to ask customers four simple questions. Did the customers know they had a problem? If so, did they want to change the way they were doing things to solve that problem? If so, how much would they pay to solve the problem?Would they write us a Purchase Order now before our supercomputer was even complete, to be the first to solve their problems?

You need to do the same thing.  Track down your early adopters, and ask them about your problem hypothesis, its severity, and its frequency-of-occurrence.

Let’s use a hypothetical example of a startup making a biodegradeable coronary stent.  The problem hypothesis states:

• Around 0.5% to 1% of coronary stent recipients suffer a heart attack due to late stent thrombosis, and the risk of late stent thrombosis requires the patient to take anti-platelet medications to reduce the risk of late stent thrombosis.

Ask your early adopters if they see this as a significant problem today, and if so, ask they why it’s significant.  Ask how they manage the problem today.  For example, they may manage the late stent thrombosis problem today with increased use of intravascular ultrasound (IVUS) to verify stent-to-artery-wall apposition.   If the problem is truly significant, your early adopters must be doing something to manage the problem.

Ask your early adopters if they are dissatisfied with their current problem management, and why?  For example, they may find IVUS time-consuming, expensive and/or difficult to interpret.

Ask them to tell you how often they use their current solution, and on which types of patients.  For example, if the interventional cardiologist is only using IVUS on 10% of patients, how are these patients selected?  Why aren’t the other 90% getting IVUS – do these other 90%  really have a severe problem, or just an annoyance?

While you are discussing your problem hypothesis, you are collecting external data that informs your product and your business.  You may also be collecting quotes that investors will love.  If our hypothetical company is lucky, they will hear:

• “I hate putting patients on Plavix indefinitely.  It creates a bleeding risk, it’s expensive, and I worry about compliance.”
• “IVUS works, but my hospital is always in my face about the cost when I use it.”

So listen carefully and take good notes.  Steve Blank advises “listen more, talk less.”  He states that customer development is about “learning and discovery” not “linear execution.”

If your early adopters verify your problem hypothesis, its severity and its frequency of occurrence, congratulations.  You are ready to move on to the next step.  Unfortunately, this is rarely the case the first time out.

More often, your first hypothesis won’t be exactly right.  That’s why customer development is a learning process.  Returning to our hypothetical example, suppose our customers tell us that 90% of the time, their patients can tolerate Plavix, and that the artery condition is such that they aren’t worried about stent apposition.  So, the original problem hypothesis is correct in severity, but incorrect in the frequency-of-occurrence.   Only 10% of the patients have the problem you want to solve, so your market is pretty small.

However, if you are listening carefully, your early adopters may tell you about another market for your product.  It turns out that the late-stent-thrombosis problem caused a 20% drop in stent sales when it was discovered, because off-label usage dried up.   For example, some physicians had been treating patients with moderately narrowed arteries.  This effort stopped with late stent thrombosis.  So, your new stent may unlock a new market, that isn’t being served today.

In our example, when we tested our problem hypothesis we learned that the original hypothesis was partially incorrect, and we gathered some data that might help us form a new hypothesis.  Lean startups call this the “pivot” – the formation of a new hypothesis, based on learning gained by testing the prior hypothesis.  I’ll talk more about pivots in future posts, and I’ll tell you about some real-life medical device examples.