I need to write a post explaining why the Lean Startup has relevance to BPM, in a logical, specific way. But before I do that, I want to get the raw impressions and data I've collected from watching sessions at SXSW and then I'll post my analysis. Because much of this content is available on the web, the key attraction to the event was to hear it live, rather than Memorex - much of the analysis is the same, but with fresh input.
Eric Ries kicked off the SXSW Lean Startup event with a good introduction to Lean startups. My notes from the session (rough notes):
- Entrepreneurs are everywhere
- Lean Startup is about Validated Learning:
- (scribbled something about innovation)
Next, Eric talked about Scientific Management, and Fred Taylor. On the one hand, a scientific approach to business is generally a good thing, and on the other, his approach falls on its face in startups. The argument seems to be, that in startups, we would collectively benefit from a more scientific, rigorous approach (rather than the trial and error that often happens, and rather than the waterfall approach we often see). But also, that scientific approach has to account for the fact that the both the problem and solution are not well-known. Taylor assumes the problem and solution are well understood.
The key idea is the Pivot. His example:Groupon was building "petition++" and made a huge pivot to daily deals. Their first daily deal was for pizza at the pizza place in their building. A very humble beginning, but also a very useful way to start testing their concept in the real world.
So the goal is to reduce time required to pivot (rephrasing: reduce the time required to learn what you need to know, so that you can pivot effectively sooner rather than later).
The Waterfall/Taylor approach just doesn't work well in startup land (I had visions of Phil Gilbert's old bucket brigade slides when I saw Eric's slides). Eric points out he was kind of annoyed to find out that even manufacturing doesn't follow a Tayloristic approach anymore - they're using Lean. So why are people teaching software and engineering still teaching this approach that is proven to be wrong?
The problem with a waterfall approach: Achieving failure, on time, on budget, with high quality, good design. Only one problem: wrong product.
Deming and Ohno put the focus on the customer, and lean manufacturing as the way to get there.
[caption id="attachment_3348" align="alignright" width="300" caption="Customer Develment + Agile Development"]
Agile Development was a big improvement to delivery models for software companies. But even agile doesn't work well, by itself, in startups. It needed to be paired up with Customer Development (Steve Blank's process for hypothesis testing your business model, at right). Meanwhile, it becomes clearer when to employ the two key parts of a lean startup: the approach to unknown problems, and the approach to unknown solutions...
[caption id="attachment_3349" align="alignright" width="300" caption="Unknown Problem, Unknown Solution"]
Not that executing these two models is necessarily easy, but it sure is a whole lot easier to do right if you know which situation you're in. If your problem is known, and solution is unknown, Agile development is a good choice. But if your problem is unknown as well, then you need to employ the customer development process to dig into what problem you're really solving.
Eric described the cycles at IMVU, by way of example. And explained that the "pivot" is one cycle through the "build-measure-learn" loop. A great quote was that "learning is the fundamental measure of progress" in a lean startup - not revenue, or users, or any other metric that a typical board might latch on to.
Translating to BPM terms: The pivot in business process management would be when we take what we learned from our last process improvement, measure what is really happening, and identify the new opportunities and tackle those. In BPM we're not pivoting the company hypothesis, just the hypothesis for where the bang-for-the-buck is in the process.
I particularly like his coverage of Lean myths:
- Lean means cheap. On the contrary, lean is about speed much more than about cost.
- Lean Startup is only for Web2.0 style companies. Actually, Lean Startup applies to all companies that face uncertainty in what the customers will want.
- Lean Startups are bootstrapped. In fact, many lean startups are ambitious and can deploy large amounts of capital (see, Groupon).
- Lean Startups replace vision with data. Actually, lean startups test the vision with real data. They still require vision!
Eric's talk was followed by case studies on pivots by Pascal Louis-Perez (Wealthfront), Ash Maurya (USERcycle), Parker Thompson (Pivotal Labs).
Perhaps the most interesting nugget from these three case studies, with respect to the customers BP3 works with - was Pascal's presentation on Wealthfront. His company processes manages over $180MM. And yet they have a continuous deployment setup - meaning they deploy changes to production as much as 30 times a day. Their company puts lie to the idea that a highly regulated industry with very important financial outcomes can't adopt a continuous deployment development model. I'm not advocating that every Fortune 500 company do the same with BPM - but clearly there is a happy middle-ground between 18-month roll-outs and 30 times a day... And whatever your number of days between deployments is, we should be looking at ways to reduce that number.
Ash Maurya was up next (slides here), and I admit to being surprised when he presented the use of kan ban boards to visualize the workflow of feature ideas (this is, truly, treating development of product as something that can be measured and improved and understood). He advocated moving only so fast as you can learn or aid the process of learning - that moving faster than that, or slower than that, amounts to waste (a big no-no in Lean thinking).
Parker Thompson, of Pivotal, advocated having a vision, but being humble and pragmatic in the near term. If testing with users or customers proves that your vision isn't getting traction, don't assume you have the wrong test subjects, be willing to revisit your hypothesis and test different ideas.