The Learn/Measure/Build Cycle
In preparing for Startup Lessons Learned next Friday I took a page full of notes during a conversation Eric Ries and I had about my keynote. I will wait for the conference to unleash the Big Message, but here is a smaller lesson that I found interesting.
Ordinarily we talk about the Build/Measure/Learn cycle (as in these slides from Ash Maurya, another SLL speaker). When Eric and I were talking, I realized that the loop is backwards.
From a programmer’s perspective, the loop is certainly correct. You write a program. You watch how someone uses the program. You learn something that you use to improve the program. I have had this experience many times. I have an idea for a program, I write it, I learn something.
Contrast that with the Lean principle of Pull: avoid the waste of overproduction by only creating based on demonstrated need. The customer orders a product, then you build it and deliver it. If that takes too long, make it take less long, don’t pile up a bunch of inventory in hopes that someone will buy it some day. Being able to instantly deliver a product no one wants is false economy.
I am working on two products right now that contrast nicely with respect to which way the loop runs. One product is a set of narrated screencasts illustrating test-driven development. For this product I’m running the loop forwards. I made a screencast, I saw how many people watched the unedited excerpt, I learned something about how many people are interested and how effective Twitter is as a marketing tool. Yes I learned something but now I’m at a bit of a loss. I’m not even sure what else I need to learn. I’ll make a couple more screencasts and then make the whole series available for sale. I hope they do well, but because I’m running the loop forwards I don’t expect to learn more about my audience until the casts are out there.
Contrast that with my other project, a poker-related game. Yes, I “primed the pump” with a very simple version of the game, but I’m now in a learning directed loop, running the cycle backwards. I start with an assumption, for example that I can make the game sticky. If the game is sticky, then people playing it will play several game per session and come back for multiple sessions. Now, what do I need to build to make it stickier?
The feeling is completely different between the two projects. With the screencasts I feel a bit lost. Yes, I know people are interested and I’ll sell quite a few units. However, I have no idea how to improve their value short of getting them out there and incorporating what people say into the next series of casts. It feels a bit like writing a book or the bad old days of writing a program for a year before trying to sell it.
Running the loop the other way, pulling the “build” from the needs of the learning, is much more energizing. I know why I am building when I build. I don’t create anything just grins. Programming’s still joyful, but it also has purpose. I know when to stop–when I’m ready to learn.
Here’s an exercise, gentle reader. Explain how to run the learning loop backwards for screencasts. One of the constraints is that people will only make one transaction per series, at least the way they are sold now.