“Lean” medical device, cleantech, telco startups

The Lean Startup movement is a good example of the new internet-company methodologies mentioned in my last post. I got around to reading Eric Ries’ book over Thanksgiving. I liked it a lot, and I have been mulling over what its lessons are for non-internet businesses – particularly for the sort of science-based business I am interested in (medical devices, cleantech, telecom infrastructure).

Does “Lean” need tweaking for science-based startups?

It seems to me that there are several important topics here:

  • Regulation.
  • The number of available early adopters, and ease/cost of access.
  • Speed of each iteration cycle.
  • Metrics.

Lean startup methodology: key points

I know you don’t want me to rehash the book here. But these are the key takeaways from Eric’s book that relate to this blog.

  1. Start with the minimum viable product (MVP) (to me, its a prototype), and get it out asap;
  2. Iterate rapidly, based on carefully measured metrics that relate to the business hypothesis;
  3. Think of the business aspects of the startup as an “experiment”, and design ways to test the various hypotheses about how the customers will get acquired, who the customers are, why they value the product, and what the product’s key features are;
  4. So, instead of just iterating the “product”, it is really the entire “business” that gets iterated.

Regulation slows cycle time

If you work in medical devices, or telecom infrastructure (eg networking equipment) or cleantech, you know that the path to market typically goes though a powerful regulatory or standards body (FDA, Telcordia, EPA/Utility regulation etc).

Let’s use medical devices as an example. Depending on the exact nature of the product, and the way it is regulated, it may be feasible to try out different prototype variants either in animal trials, or in non-significant-risk-type scenarios in clinical settings. So iterating to get the right “product-user fit” may be possible.

But a medical device product needs to be cleared or approved before it can be marketed. And the clearance/approval cycle is long. And you cannot just “change” the product without going back through the regulatory approval process. So, the idea of iterating the other aspects of the business (the customer acquisition model, the revenue model, the growth hypothesis etc) may run into problems if they involve any tweaking of the product. If you think about the model of releasing production code multiple times per day, it seems to me that just does not work for a regulated product, once the product is “marketed”.

Does this mean that this type of regulated industry, in which there is a long cycle time to get approval on product modifications, limits our ability to use lean methodologies to their full extent? And does this mean we are doomed to get slower innovation in regulated markets than in the internet wild west? And how do we think about the tradeoffs between safety and slower innovation this all suggests?

Not sure what the answers to this are (beyond offshoring), but I would love to engage in a dialog if you are interested.

Online: the power of numbers

Reading the Lean Startup reminds me just how transformative the internet business model is. One of the key aspects of the lean methodology is the idea that you get a new “cohort” of users each day/week, and that you can measure how each cohort behaves using metrics like whether they register, whether they use the “product”, and whether they pay. Thus you can measure the impact of changes to the product or the business model or the customer acquisition model or the growth hypothesis across a significant number of users on a week by week time scale. This allows for a very rapid cycle time.

To stick with my medical device example, there are some fundamental differences that limit our ability (I think) to take advantage of this rapid cycle time.

Because the product is not software, it is hard and expensive and time consuming to get the prototypes in front of multiple cohorts of users. There are the costs of making multiple prototypes, and the costs of getting them used by multiple users. Traditionally, a prototype will get used by a small handful of luminaries, whose feedback is used to shape future iterations. But this cycle typically takes months. And the cohort size is very small.

This line of thought, though, opens up some interesting possibilities. I wonder if we can redesign the traditional approach to customer development for physical products like medical devices. Perhaps using virtual prototypes, or online environments, or in some other way breaking down the work flow in a different way, with the goal of getting more rapid cycle time across a more diverse user group? Food for thought.

“Swiss roll” software techniques are not new. But its much faster now.

I see a lot of talk in the blogosphere about how the MVP and rapid iteration is an important and radical concept. I certainly agree its important. But I remember being very impressed by a book on software development back in the 90’s that described this exact approach, which they called the “swiss roll” approach to development. The idea was a series of successively more complete iterations of the product, and a sort of spiral development methodology. The goal was to get a prototype with a minimum feature set out to be “tested” by a friendly potential customer early on in the process, rather than to wait for ever to have a feature-perfect, final product that might bomb.

So, I dont think the significance of all this is that it is new. One of the big differences is that this time around people are really paying attention.

But what I think is really amazing about the approach that Eric Ries and colleagues are now advocating is the different time scale for all this. Back in the 90’s, a medical device that was developed using the spiral development approach might, if you were very lucky, lead to a new prototype iteration every few months. Eric talks of software production releases multiple times per day. Last week at a conference organized by 500 startups, I heard Randy Hunt from Etsy describe releasing production code as many times as 30 times per day. And that is for a site that gets over 1 Billion page views / month!

Finding the right metrics is a challenge

It seems like one of the key points Eric makes in his book is the importance of finding the right metrics to measure whether or not your business is learning the right things as it experiments and seeks a scalable business model. For traditional medical devices, the challenges have been about product-need fit (does the product solve a compelling need for some user); the path to regulatory approval; and the path to getting paid (reimbursement). Mostly, the business models have been pretty straightforward.

However, I am increasingly seeing signs of emergence of all sorts of new business models in verticals like medical devices and cleantech.

For example, there is now a whole category of health 2.0 products targeted at well consumers (avoiding disease rather than treating it) and these have very non-traditional business models. Or, in the cleantech space, there are interesting experiments in demand response, or distributed power generation, for which the business models are different and in many cases as yet unproven.

So, what should we be measuring for these product-based businesses as metrics to test our value hypotheses and growth hypotheses? And how do we get a handle on that early, before we scale up and spend huge amounts of capital?

I am realizing this is a very important set of new questions to be asking every startup I see.

Comments

  1. Hello Richard,

    Nice review, and having spent most of the last two years working in the wireless telecom space I can certainly understand the difficulty applying Lean Startup’s rapid iteration techniques when you may have only a handful of companies who purchase your product! In legacy situations, sometimes the best they can do is compile the software a few times a day, let alone deploy it to the field. 🙂

    One thing I would quibble with, though, is using the terms MVP and Prototype interchangeably. A prototype, as you say, is quite incomplete but enough to show potential and existing customer the progress on a product. An MVP, while still not the full product, is something complete enough that customers would pay for it, or can at least use it “in anger”. That may seem like a semantic difference, but it really drives different behaviour with respect to determining which features or parts of features are delivered first or, to use Eric’s terms, which experiments are done first.

  2. Thanks for the feedback Dave. I think your point about the semantics of MVP vs prototype is an interesting one. Lets use your definitions. That raises an additional point however.

    You don’t really know if people will buy the MVP until you try selling it to them. But you can’t really do that (eg if it needs FDA approval) without waiting for a long regulatory cycle. Or in the case of telco infrastructure, you typically need Telcordia certification before someone would really “buy” it. Again, a long cycle.

    As I was thinking through my blog post, I was thinking to myself that you could do much of the customer need/product fit experiments using a prototype, but would then have to wait for the subsequent buying experiments until you had regulatory approval. So, I guess I was modifying the lean methodology in my mind a bit.

    I dont really see how it works to try and go straight to a MVP and do the sales-related experiments if you are operating in a regulated environment.

    Of course, with my medical device example you could argue you would create a MVP, then do all the experiments in a country that has no regulatory hurdles. Then come back to the more regulated world only after getting a stable, scalable business model and proving out all the experiments.

    In any case, it seems you need to think a little differently than in the Internet world. What do you think?

    • Yes, I absolutely agree. The MVP for a life-critical product such as a medical device is significantly different than the MVP for a social media site. Like you, I saw the same issue in the telecom space, although there was more room there to improve innovation and getting the features that customers actually wanted to market much, much faster.

  3. easy to follow says:

    Greetings! Very useful advice in this particular
    article! It’s the little changes that produce the most important changes.
    Thanks for sharing!

Trackbacks

  1. […] 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 […]

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: