Chapter 2. Running Lean Illustrated
A great way to understand the meta-principles covered in Chapter 1 is to see them applied to a real product.
I wanted to pick a simple example that would be readily understood. So, rather than picking a software or hardware product, I decided to outline the process I used to write this book.
Even if you haven’t written a book, you can probably appreciate the steps that go into writing a book, which, as you'll see, isn't unlike building a product.
Case Study: How I Wrote Iterated This Book
Writing a book was never in my plans. I was too busy running my company. I started my blog in October 2009 because I had more questions about Lean Startups than answers.
Along the way, a few of my blog readers started suggesting that I turn my blog posts into a book. I knew writing a book (even from blog posts) would be a massive undertaking, so while I was flattered by the requests, I did nothing at first. After about a dozen such requests, I decided to explore further.
What follows is how I applied the Running Lean process to writing this book.
Understand the Problem
I called these readers and asked them why they wanted me to write a book. Specifically, I asked what would be different about this book from what was already on my blog, or in other blogs and books that are already out there. In other words, I was trying to understand this book's unique value proposition in relation to existing alternatives.
From these interviews, I learned that, like me, my readers were also struggling with taking Customer Development and Lean Startup techniques to practice (problem statement) and viewed my blog posts as a "step-by-step" guide for applying these techniques from the ground up (solution). Many of them were also technical founders like me who were building web-based products (early adopters).
Define the Solution
With that knowledge, I spent a day building a demo. It was a teaser landing page with a table of contents, a title, and a stock book-cover image (see Figure 2-1)
I knew the riskiest part about writing this book was nailing down the table of contents—not the title, book cover, or even price (since most business books have fairly established pricing).
I called the same readers and asked them: "If I were to write this book, would they buy it?" Their feedback helped me refine the table of contents (define the solution) and gave me a strong signal to move forward.
While encouraging, writing a book for just a dozen or so readers wasn’t indicative of a problem worth solving. So I left the teaser page up and announced the book with a "coming this summer" launch time frame on my blog in March 2010. My readers helped spread the message (channel testing). Then I went back to running my company.
By June, I had collected 1,000 emails (potential prospects), which made writing the book a problem worth solving for me. My rationale for this was at least covering my costs using a simple back-of-the-envelope calculation.
Validate Qualitatively
Writing a whole book was still a massive undertaking. I tried writing the first chapter using "copy-and-paste" from my blog but wasn’t happy with the results. I needed to build something even smaller that allowed me to start learning from customers (a minimum viable product).
I took the table of contents and turned it into a slide deck with the same outline and a few bullet points under each topic. I announced a free Running Lean workshop in Austin, Texas and got 30 people interested.
A local incubator, Tech Ranch, was gracious enough to provide a venue but only had room for 10 people. This was perfect, as it meant I could run at least two more workshops with the others (iterate in small batches).
Based on the success of the first workshop, not only did I run more workshops, but I also started charging for them (getting paid is the first form of validation). With each workshop, I continually tweaked the slide deck content for better flow and doubled pricing until I hit some resistance.
By the end of the summer, I understood the solution well enough and started writing. Here again, instead of writing the whole book in isolation, I contacted my potential prospects from the teaser page, many of whom were growing impatient as my initial launch date had come and gone. I apologized for not having finished the book and told them I’d be writing and releasing the book iteratively, much like software. Rather than waiting six more months to get the book, if they preordered the book, now they would get two chapters of the book every two weeks in PDF format.
About half of the people agreed to this arrangement. The others chose to wait for the "finished product," citing print, iPad, and/or Kindle as their preferred reading format. This further helped me distinguish early adopters from latter-stage customers. These early adopters were driven by the content alone and didn't care how it was packaged. The content for me was still the riskiest part of the product to test.
Customer feedback during this two-week iteration cycle was immensely valuable. Entire chapters were rewritten for better flow, illustrations were improved,[7] and little typos and grammatical errors were nipped in the bud. Not only was I able to write a better book using this process, but I did so faster.
Verify Quantitatively
Only once the book was "content-complete" in January 2011 did I hire a designer for the book cover, start testing book subtitles, research print/ebook options, and build a marketing website (right action, right time).
While I’d always been prepared to self-publish this book, an interesting thing happened. I was contacted by a major publisher in December 2010 that got wind of the fact that I was writing this book. Not only had they already reviewed the latest version out at the time, but they were interested in publishing the book as-is.
I asked them if my model for writing and selling the book so far would be a deal breaker. On the contrary, they wished more authors wrote their books this way.
At first I was confused, but then it all made sense. The fact that I was able to sell 1,000 copies of the book on my own demonstrated early traction, which helped mitigate market risk for the publisher. This is not unlike how a latter-stage investor views a startup.
As with building a product, the ideal time to attract external resources is after product/market fit, which may or may not be the right action for you at that time.
In my case, I’m happy to say that additional conversations with other publishers, along with advice from Eric Ries, helped me determine that going the publisher route was the right action given my goals. I signed a contract with O’Reilly. Not only had the O’Reilly folks been early proponents of the Lean Startup movement, but they were also highly supportive of an official Lean series of books.
As of September 2011, I had sold just over 10,000 copies of Running Lean on my own and was writing a new and updated edition (the book you hold in your hands). This version was even further refined through countless interviews and workshops with entrepreneurs that spanned a wide spectrum of products (build a continuous feedback loop with customers). The goal was to synthesize my learning over the past year and broaden the audience beyond my initial prototypical early adopters of web-based entrepreneurs.
The timeline shown in Figure 2-2 summarizes the process I used to write the first edition of Running Lean.
Is the Book Finished?
A book, like large software, is never finished—only released.
Because I wrote this book iteratively about a topic that is still evolving, the book was just the beginning (See Figure 2-3).
- I still share my raw learning on my blog.
- I write a biweekly “Running Lean Mastery” newsletter.
- Demand for my workshops has gone up.
While I love teaching these workshops, my true passion still lies in building products. Immersing myself in the world of hundreds of startups helped me identify a number of problems worth solving.
That is how Lean Canvas and USERcycle came to be.
Lean Canvas is a business model validation tool. It’s a companion tool to this book that helps you document your business model, measure progress, and communicate learning with your internal and external stakeholders.
USERcycle is customer lifecycle management software that helps companies convert their users into passionate customers. Passionate customers come back and use your product, tell others about your product, and pay for your product (or get you paid).