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:
- The number of available early adopters, and ease/cost of access.
- Speed of each iteration cycle.
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.
- Start with the minimum viable product (MVP) (to me, its a prototype), and get it out asap;
- Iterate rapidly, based on carefully measured metrics that relate to the business hypothesis;
- 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;
- 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.