When to Break the Lean Startup Rules
A confession: The first time I read The Lean Startup, I didn't get it. It seemed useful enough in its call to test and retest every product idea, to measure everything and presume nothing. But I didn't understand the cult of it or how it had become dogma in Silicon Valley.
But at that time, I wasn't running a company. Now that I have my own startup, I've not only gotten the Lean Startup religion; I've become downright evangelical. We implement lean processes in just about everything we do, and we have from the start.
Lately, however, I'm feeling a little heretical. I've been brooding over what the Lean Startup doctrine allows, and when it's OK to break ranks with the faithful.
The appeal of the Lean Startup rests, I think, with the fact that in an atmosphere of ambiguity, the lean playbook offers a precise template for building something useful. Second, it assumes adjustments and failure are part of the process (welcome assurances to any startup).
But like any rules, sometimes even The Lean Startup's don't apply. Occasionally, you can't test an assumption, and you have to just take that leap of faith. Learning when to ignore the lean playbook can be one of the hardest lessons it offers.
Finding this balance has been a challenge at my startup, Iodine, where we're building digital tools to help consumers make better medication decisions. Our chosen industry, health care, is highly regulated and doesn't exactly move fast. This created an immediate problem with running lean. Most startups can recruit users through Google AdWords; a few well-chosen keywords offer an easy way to draw enough traffic to test a minimum viable product. The MVP is the most rudimentary yet viable version of a product that will generate relevant feedback from consumers but won't require too much financial or human capital to build. Testing MVPs is a key precept of the Lean Startup doctrine. But we couldn't test ours, because Google won't run ads against pharma products without an "e-Advertiser" accreditation from a third party. Though we filed our application early, it took five months to get approved. Not exactly quick and dirty.
Since then, though, we've diligently tested several MVPs with dozens of people facing real medical issues. But we reached a point when user testing wasn't teaching us anything other than that people like nice websites. Our testing was validating but not necessarily illuminating. To really see what users need, we had to commit to a product even though we aren't certain users will respond to it in the wild. That product--code-named Eggplant (it's purple, like Iodine!)--launches soon.
Another challenge with lean dogma is that all that testing and prototyping can feel aimless, even to key members of the team. At Iodine, we spent a lot of time brainstorming and prototyping various features to test, which left some staff members unclear what we were working toward.
They were right. Iodine's leaders--especially me--need to be much clearer about why we are testing and sometimes abandoning our MVPs. And I need to say out loud (and more often) how all our testing aligns with our core mission, which is to turn clinical data and human experience into better consumer decisions around health.
For me, the biggest challenge in running a lean startup has been letting the lean process play out while offering the team a coherent vision. Testing is great, but sometimes you just have to build something. That's the most important leadership lesson I've drawn from The Lean Startup playbook: When the rules are crystal clear, it's much easier to know when to break them.