I love the lean startup ethos and methodology. It is by far the best thing that has happened to the startup community since the onset of the internet-fuel renaissance in entrepreneurship. These days at MuckerLab, we try to utter the basic concepts (mvp, iteration, hypothesis testing, customer development, etc) as much as possible to help our entrepreneurs and ourselves stay on track. People that have heard me talk at panels and conferences probably think I’ve been brainwashed by the cult of Eric Ries, and I would be flattered. BUT certainly before the lean startup movement there were wildly successful and visionary entrepreneurs. And long after “lean” becomes indistinguishable from entrepreneurship itself, there will continue to be failures and disillusioned entrepreneurs. Lean is not a panacea or a blue print for success. It’s a framework and like any framework, it can be misused. After immersing ourselves in the ethos and watching our entrepreneurs apply the lean methodology in their startups, we are starting to learn more how to adjust and adapt the formula in different circumstances.
It is certainly a lot easier to apply the lean methodology to consumer focused businesses than it is enterprise focused businesses. In enterprise, lean works, but it takes more patience, rigor, and flexibility. Customer development will always improve the signal to noise ratio for better product-market fit; but given how hard it is to scale enterprise customer development, it is extremely important for entrepreneurs to be wary of any data they are gathering given the small sample size and potential for sample biases. If possible, I like to start the customer development process with a very wide funnel as to diversify across multiple segments within the target market . . . and quickly narrow down to a specific receptive segment as additional data comes in (essentially abandoning certain customers along the way).
In addition, the enterprise software business follows adoption patterns that are significantly closer to the “Geoffrey Moore” model than the “viral” adoption model we come to expect in the consumer Internet world. In enterprise, early product market fit is just that – early. Until the product has crossed chasm – it hasn’t. In this market, the traditional top down category marketing playbook is still the only playbook to cross the chasm. CIO’s often (for better and for worse) allocate their budgets based on latest trends and research that are heavily influenced by industry analysts (Gartner for example) – so enterprise software entrepreneurs will have to invest dollar and time to slowly build mindshare for its product category and company. Initial product market fit only buys an option to play in the big leagues where old games are still played by old dogs. Most enterprise companies will not come close to achieving the types of exponential growth more common in consumer product (in which signal will overwhelm any noise) until much later in their company lifecycle.
The other interesting dynamic we are seeing is that network effects driven businesses (e.g. marketplaces, social networks, UGC applications) also require a slightly more patient and acquisition focused approach to “lean.” By definition, these businesses need a critical mass of supply / demand (e.g. users and content ) to achieve their core value proposition. As a product or feature is released to market there is a huge temptation to declare the “test” a failure based on initial data when in fact it has nothing to do with the product but as a result of the lack of content and/or users. Pinterest famously stagnated with the same basic product for over a year before hitting a tipping point and taking off once the site achieved usage and user escape velocity. In short, it is more about market-market fit than it is product-market fit. The product’s objective is to retain users and reduce transactional or communications friction, but aggressive acquisition tactics and often lots of luck is needed to truly test for product market hypothesis. There is a tremendous focus on avoiding type I errors in the lean methodology, but avoiding type II errors are just as important to the eventual success of a startup.
