Introduction

Q. What do you call an outdated, unimportant book?
A. Who cares!

This happened to me.

My first book, Flexible Rails, a computer programming book about how to use two relatively new technologies (Adobe Flex and Ruby on Rails ) together, was fairly successful in its niche. So, after completing it in late 2007, I got extremely excited. I signed not one but two publishing contracts with my publisher, and I proceeded to start writing two books. Both books failed, but in different ways—it could be that every unhappy book is unhappy in its own way.

The first of my two new books, Enterprise Flexible Rails, was going to be a sequel to Flexible Rails. It was going to pick up where the first book left off, and go in the direction of using a framework instead of writing all the code manually. This framework was being written by my new startup, Ruboss (yes, I immodestly named it to be reminiscent of JBoss), so not only was the book going to be a profitable sequel, it was also going to launch my startup’s product into the world.

The book lasted two chapters before my publisher decided that my plan was not a good one. Since I refused to change the plan, we agreed to cancel the book and refund everyone’s money. This was a relatively quick, ignoble failure.

The second of my two new books actually had the distinction of failing twice—first as Hello! Flex 3 and then as Hello! Flex 4. This book was going to be a fun introductory programming book about one of the two technologies (Flex ) that I had covered in my first book Flexible Rails. My idea was for it to be Flexible Rails minus Rails plus cartoons: the publisher wanted to create a new illustrated series of introductory books, and I knew J. D. “Illiad” Frazer , the cartoonist who drew User Friendly . I made the introduction, and a book series was born—one which continues to this day.

After I got about six chapters into Hello! Flex 3, the publisher and I realized that the format of the book required an almost complete rewrite, as I needed to make the code examples more self-contained, and make other changes. (Hooray for being the first author of a new series.) Since I was rewriting the book anyway, I decided to also target the next version of Flex (Flex 4): during the writing of the first six chapters and experimenting with the format of the Hello series, Flex 4 had been announced. In the computer book business, books get obsolete quickly!

So, I took the 6 chapters of Hello! Flex 3 and used it as the basis for only one chapter (the last, most advanced one) of the new Hello! Flex 4 book. I then worked day and night and rewrote the rest of the book from scratch over a 3 month period. We launched it after two beta versions of Flex 4 had been released. I was excited to be the author of the first shipping introductory book about Flex 4. With the release of Flex 4 right around the corner, great things were ahead for my book.

The book was obsolete before the ink was dry.

Instead of Flex 4 being launched with essentially bug fixes, Adobe made a totally minor and almost pointless change, renaming something called an XML namespace . This change broke every single code example in my book, 2 weeks after the book went to print. Sure, I immediately updated all the book code that was downloadable, wrote a blog post explaining the differences, etc. It didn’t matter. The book was dead in 2 weeks.

I had gone from being too late (as essentially the last author of a Flex 3 book) to being too early (as the first author of a shipping Flex 4 book, just slightly before Flex 4 was stable enough to print things about). Venture capitalists often talk about how timing is so important for their startup companies. It turns out this is true for books as well, and that I had managed to be too late and too early—with the same book project!

Even worse, it turned out that Flex 4 didn’t matter. Apple essentially killed the Flash platform by not allowing it on iPhone , and Flex was a developer-focused way of creating Flash apps. So not only was my book about Flex 4 dead on arrival, Flex 4 itself was dead on arrival.

I had written an outdated book on an unimportant topic, and nobody cared.

After having written a successful first book, I had started a startup about a framework, and had started two technical books. All three projects were miserable failures. I had gone from being someone who would be flown to Pisa to talk at a Rails conference to someone who, professionally, essentially had nothing but a failed startup and two failed books.

Worse still, was the irony: I had already figured out an approach which would have helped me avoid all of these issues—and then proceeded to not use it again. With my first book, Flexible Rails , I had come up with a fairly unique approach. I launched the book early, in self-published form, iterated in public with feedback from a small but growing and dedicated community of readers, and evolved my book into a finished, good quality book with traction, one that multiple publishers made offers for. I had stumbled into an excellent workflow for writing and publishing in-progress ebooks, and into an understanding of some of the deeper principles around publishing in-progress books.

After learning all those lessons, I then proceeded to ignore all of them. Looking back, I hadn’t really realized the significance of what I’d done. It had just seemed like the right thing to do at the time.

I just hadn’t suffered enough yet.

Only once I had spent about a year spectacularly failing at Enterprise Flexible Rails , Hello! Flex 3 , Hello! Flex 4 and pretty much everything else I touched, did I start to understand. I realized that this wasn’t just suffering that was unique to me, but that the problems I had encountered were endemic to the entire computer programming book industry . As I learned more, I realized that the new Lean Startup techniques which had been developed and popularized by Steve Blank and Eric Ries applied to publishing, and actually dovetailed nicely with the experiences I had writing Flexible Rails. I also figured out that they didn’t just apply to computer books, but to business books, other non-fiction books and, as I learned more about how serial fiction had functioned in the 1800s, even to fiction.

Lean Publishing was born.

I wrote the first version of the Lean Publishing Manifesto in 2010. I proclaimed “A Book is a Startup” . This idea resonated with many people, including Todd Sattersten —his book entitled Every Book is a Startup was strongly influenced by my Lean Publishing Manifesto. We even gave a talk together at a Seattle unconference about the idea.

I also rebooted my startup, Ruboss . Instead of trying to sell a framework, we decided to focus on Lean Publishing. (This was not a “pivot”; this was a reboot.) My original cofounder (and the principal author of the Ruboss Framework) left, and the Ruboss Framework was renamed to RestfulX . My employee #1, Scott Patten , became my new cofounder and together we created Leanpub . Leanpub is our way of implementing the Lean Publishing ideas in this book.

Over the past few years, I have learned a lot of lessons about Lean Publishing from helping build Leanpub, from listening to our customers, and from reflecting on my previous successful and unsuccessful experiences. This short book is the result of these few years of thinking and seven years of experiences. Regardless of whether you are an author or a publisher , I hope that you find this book interesting. I also hope that the Lean Publishing approach saves you some suffering and helps you chart a course ahead in these interesting times.