Eric Ries’ The Lean Startup advocates rigor in the learning we do while building products or services. While calling learning the startup’s “most vital function”, he rightly warns about falling back on learning as an excuse for failure after the fact. He also calls out the danger of unfocused experimentation: “if the plan is to see what happens, a team is guaranteed to succeed—at seeing what happens—but won’t necessarily gain validated learning.” He goes on to describe various ways to rigorously establish and test hypotheses about the startup’s value and growth model.
Ries’ ideas clearly apply to prototypical software startups, but what about more established organizations/teams? Ries’ does mention wider applications, including the idea of innovation teams within a larger organization (SnapTax within Intuit), and continuing to evaluate previously validated growth hypotheses (because “every engine of growth eventually runs out of gas”). For the most part, though, he focuses on the earlier end of the product lifecycle. I think that some of his ideas are also very important later on, for what I’ll call the lean grownup.
After all, developing software is in almost all cases about building something for the first time. New features–while perhaps less risky than initial launch of the product from which they grow–are jaunts into the unknown. Even a 100% feature parity port tends to exist on a new technology stack, driven by new market conditions, written by new people, serving customers with potentially new needs. The newness creates uncertainty not only about the efficacy of your solutions in addressing customer needs, but even about the very definition of those needs. Where there is uncertainty, there is experimentation, whether teams are conscious of it or not. So, teams might as well design their experiments leanly: to validate their hypotheses for as little cost as possible.
This is not news to followers of the Agile Manifesto, which exhorts us to iteratively collaborate with customers and do so with minimal waste: “Simplicity–the art of maximizing the amount of work not done–is essential.” However, Ries (see also DAKA) broadens the idea of what we deliver: in the very early going, where conditions are particularly uncertain, value frequently does not look like working software. While Agile frameworks leave time for learning (spikes, forecast vs. commitment, etc.), they rightly shy away from too much pure learning, for fear of falling into the trap of waterfall thinking that has us study things to death up front. It’s sort of like how Newtonian mechanics break down at quantum scales: the general rule about focusing on delivering value through working software gets shaky under those initial conditions of extreme uncertainty.
While physics may bend a bit in the transition from lean startup to lean grownup, one idea in particular strikes me as critical to preserve:: rigor in validating hypotheses. Learning is a large part of building at any stage, and we benefit from doing that learning consciously and systematically. To do that, we need to make habit of forming hypotheses. A prototypical startup would first test hypotheses about value and growth, but a lean grownup has likely already validated those at least at a broad scale. So where do they look for hypotheses?
Stay tuned…