Skip to content

Lean Publishing Outline

I’ve been extremely busy with client work lately, and we’ve been working extremely hard on Leanpub. However, I have an outline for my Lean Publishing book figured out now, and I’m just going to post it right now in advance of actually, oh, writing the posts!

So, without further ado, the new outline for Lean Publishing…


Introduction: Why Lean Publishing?

A Book is a Startup

  • Screw Romance, You are Creating a Product
  • The Casino Hotel
  • Authors and Founders
  • Stealth Mode

Lean Startups and Customer Development

  • This is the Easiest Time in History to Start a Startup
  • Customer Development and the OODA Loop
  • The Lean Startup: Customer Development + Agile Methodology
  • Open Source Software: Release Early, Release Often and Listen to your Customers

Lessons Learned from Lean Startups

  • Publish Early (Fail Fast)
  • Publish Often and Listen to Your Readers
  • Build a Community of Readers

Lessons Learned from Blogs

  • Blogs are Free Beta Books
  • Successful Blogs Build Communities
  • Successful Bloggers do Customer Development
  • Underpants Gnomes and Blog Authors
  • The Most Successful Bloggers Monetize their Communities

Lean Publishing in Five Steps

  1. Start a Blog
  2. Produce and Sell an In-Progress E-Book
  3. Finish the E-Book Using Lean Startup Principles
  4. Market the Completed E-Book
  5. Transition to Other Channels

Publishing 2.0

  • Publishers add Most Value at the End of a Book
  • Develop Your BATNA Before Negotiating with Publishers

About the Author

About Leanpub

Acknowledgments


Look interesting? Subscribe and stay tuned…

Hello! Flex 4 Launch Update: Free Excerpts and Glowing Reviews

Hello! Flex 4 launched to some glowing reviews!

First of all, however, the free stuff…

Session #14, one of my favorite workshop sessions from Hello! Flex 4, is reprinted in full in the following Adobe DevNet article:

http://www.adobe.com/devnet/flex/articles/flex4_graphics_game.html

You can also read chapter 1 and chapter 3 for free at:

http://manning.com/armstrong3/

Now for the reviews.  Hello! Flex 4 has also been getting excellent reviews:

First, Ryan Stewart’s blog:

“Peter Armstrong is a gung-ho kind of guy. He has the very first book on Flex 4, Hello! Flex 4 and it’s currently available on Amazon. I got a PDF copy of the book and it is a really fun way to get up to speed on Flex 4. A ton has changed including the component model, how we do states, a new graphic language called FXG, as well as other tweaks and optimizations. This book goes through them all and provides a great overview of how to use Flex 4 with existing projects and frameworks . . . Well worth it for anyone who wants to see what’s coming in Flex 4.”

- from http://blog.digitalbackcountry.com/2009/12/the-first-book-on-flex-4-hello-flex-4/

Second, from the Amazon reviews page:

“If you’ve been thinking about Flex, or know someone who wants to get a basic understanding in a very short amount of time you’ll want to check out Hello Flex 4 by Peter Armstrong.

This short 234 paged book is an action packed light hearted casual read for programmers who are curious about Flex but may not be at the point where they want to invest a ton of time until they get a general understanding of how it works and if it’s a right match for them.

The tone of the book is laid back, and Peter doesn’t bore you with exhaustive detail, while at the same time there are small cartoons to keep it fun. Structure wise the approach uses sessions/labs to demonstrate concepts, and these sessions provide real working code. As each session progresses it builds upon the last - leading up to a full blown application.

So the examples are small and easy to understand, while at the same time being practical that you could then apply for you own purposes. In the very last chapter he’s a bit gutsy by incorporating the Cairngorm MVC framework as part of the lab… Cairngorm is a pretty heavy duty topic, so my reaction was would using it in a introductory book be good idea?

Well, if you really wanted to get an honest quick feel if Flex is right for you, you might as well get a taste of what a framework driven Flex application would look like. To my surprise though, Peter pulls it off, and makes Cairngorm digestible (especially considering the reader may not have any prior Flex/ActionScript exposure) by keeping it simple, to the point, and clear about what it’s role is in a Flex application.

So overall, for a quick read and low price, this is a great way to jumpstart your Flex skills.”

- Tariq Ahmed, Author of Flex 3 in Action and Flex 4 in Action in an Amazon.com review

Also, the Manning page has for Hello! Flex 4 has many other great quotes people (not me!) have said about it, including:

“Friendly and fun.”

“Armstrong again creates a must-have guide for Flex development.”

…and my favorite…

“The most fun technical book I have ever read!”

My 2010 New Years Resolutions

If I blog these then I have more pressure to stick to them, so here I go.  Yes, this is a more self-centered post than usual, but it will possibly be interesting to read in a year and see how it went.  I’m only including personal resolutions, not Ruboss / Leanpub ones…

My 2010 New Years Resolutions

  1. Spend more time with Caroline and Evan, including setting aside enough time to play Lego and Wii with Evan between dinner and book time.  Teach Evan using Lego Mindstorms if he’s interested.
  2. Exercise at least 3 times a week, and personal train at least once a month.  Actually do the workouts that the trainer creates (and do ALL 3 sets!), not just 1 or 2 based on how rushed or tired I am.  Go from my current 216 lbs and 36″ waist to 200 lbs and a 34″ waist.  (Yes, it’s totally stereotypical to have “go to the gym” on a New Years Resolutions list, but I don’t claim to be a beautiful and unique snowflake — only a slightly out of shape one!)
  3. Eat vegetables regularly, especially broccoli, spinach, etc.  Eat less processed food, white flour, starch, etc.
  4. Get the 7:10 train instead of the 7:40 train when working out in the morning.
  5. Blog here at least once a week, hopefully more.  Ideally, something about Lean Publishing, but if I don’t have anything interesting to say about that, then blog about something else.
  6. Limit social media and news consumption (Reddit, Hacker News, RSS feeds, TechCrunch, Twitter, etc) to 30 minutes a day. Ideally, use my iPhone to check all of this, rather than my laptop, since that way I’ll be more focused while working and less tempted to switch to distractions.
  7. Self-publish Lean Publishing on Leanpub once I have at least 50 pages worth reading.  Accomplish this by March 1.  This should include everything worth keeping from my half-completed Publishing 2.0 manuscript that I had written and abandoned a couple years ago.
  8. Promote Hello! Flex 4 better.  The ratio of about 400 hours writing to about 4 hours promoting is a really stupid one.  Specifically, make helloflex4.com link to all blog mentions, reviews, etc. Also, hook up affiliate codes and determine if it’s profitable to buy Google ads.

Obviously this isn’t a complete list of everything I need to do, but it’s measurable.  In a year I can check how many of these I kept, and make new ones for 2011.  I don’t want to make a prediction about how many I’ll actually accomplish, since I like being right and I don’t want to be self-defeating :)

About the Two Previous Lean Publishing Posts

I’ve just copied my two previous posts onto my blog from their original location on my http://leanpublishing.net blog: One of my new years resolutions is to blog more, and I’ve realized that I should start by centralizing all my blogging in one blog. Since I’m not editing these posts at all, I’ve also set their posted dates to be the dates that I originally posted them on http://leanpublishing.net, rather than today’s date.

Lean Publishing Principle #1: A Book is a Startup, So Use Lean Startup Principles

The parallels between writing a book and doing a startup are numerous. I’m going to start by going over 3 of these parallels, and then introduce why the Lean Startup approach should apply to the process of writing a book. Specific technical details about how this can be done will be discussed in the next post.

Parallel #1: There are market risks, technical risks and a very low probability of success.

Doing a startup is a highly risky endeavour. There are market risks (is there a market for the product? will some other company beat us to market?) and technical risks (is the product even possible? will it be any good?). The founders take all these risks because of the potential for a huge payday and to change the world–this has been referred to as “changing the world, one million dollars at a time.”

Writing a book has a similar set of risks. There are market risks (will anyone want to buy the book? will someone else write a similar book first?) and technical risks (do I have what it takes to finish a book? can I write a book that is entertaining and engaging?). The author takes these risks for the possibility of fame and fortune–albeit a smaller fortune than can be acquired by building a successful startup.

Also, both startups and books can be derailed by personal issues. These can include interpersonal issues between co-founders or co-authors, or personal problems (health, relationship) that can crush a founder or author. These problems seem to happen more frequently than with normal 9-5 jobs, since doing a startup or writing a book is so much more demanding than a normal job.

All things considered, it’s completely unsurprising that the probability of success for both startups and books is so low. That people attempt either, and do so on a regular basis, is a testament to the entrepreneurial spirit. (Speaking as a Canadian who has lived and worked in Silicon Valley for a number of years before settling in Vancouver, the ability to take huge risks without a stigma attached to failure is one of the things I admire most about the culture of the United States, and of Silicon Valley in particular: this spirit is more alive there than anywhere else I have been…)

Parallel #2: Both writing a book and creating a startup are highly creative processes undertaken by one or a few people working closely together.

There is a reason that there are no startups founded or books written by 100 people: doing anything creative with that number of people produces a product in which any brilliance is diluted. (This is the reason why the phrase “designed by committee” is not a compliment.) A book or a startup is best created by 1 or 2 people, who are the authors or founders. You can create a book with 3 or 4 authors, but essentially all the great books have been written by one author. In fact, if you have more than 4 authors, you’re not even really producing a book–you’re really producing an anthology of individual essays. Similarly, a startup typically has 2 co-founders (Apple had Steve Jobs and Steve Wozniak, Microsoft had Bill Gates and Paul Allen, etc.). You can create a startup with 3 or more founders (BEA had three: B, E and A), but that’s the exception–and it’s extremely rare for any successful startups to have more than 4 founders.

Despite the similarities, there is actually an interesting difference between the ideal number of authors and founders. To achieve great results, it seems the ideal number of authors of a book is 1 and the ideal number of founders of a startup is 2. My personal take on the reason for the difference, having written two books and started one startup, is that writing a book is essentialy the technical portion of creating a startup–a solitary endeavour which requires long periods of sustained thought. However, creating a startup is a more multi-dimensional activity: besides the solitary time spent at your computer creating the product, there are a vast number of activities (raising funds, reacting to the market, acquiring customers and evolving along with their needs, etc) which are too much for almost all individuals to sustain over the time it takes to develop a product.

Parallel #3: Historically it has taken about a year, often spent in isolation or “stealth mode” and funded by outside investors (angels or VCs, publishers), to develop and release the first version.

Startups have traditionally operated in secrecy from the moment of being founded until the “first customer ship” or “product launch.” This period of time is spent raising money from angel investors (accredited wealthy individuals) or VCs, possibly hiring a few early employees (depending on the amount of money raised) and then rapidly building the product envisioned by the founders in order to get it to market before anyone else does. Startups that don’t raise money support themselves by bootstrapping, either on the savings of the founders or by doing other jobs (typically consulting) until the startup is earning enough money to feed the founders. (This achievement is called being “ramen profitable” by Paul Graham, and it is an important milestone since it means that the startup founders can focus more on their business and less on scrounging up money from investors or consulting.)

A similar situation exists for authors. One risk is that someone else will write essentially the same book first. After all, while there are an infinite number of book ideas to be had, it seems that there is a finite number of good ones at any given moment in time. Assuming this is the case, since there are millions of potential competitors, authors are justifiably paranoid that someone else will publish first–especially if the subject is topical, or is a Ph. D. thesis. Another parallel with authors and startup founders is the role of the publisher. Just as startups are often funded by angels or VCs, books are often funded by publishers. A publisher typically pays an advance against royalties, which the author typically uses to replace some of the lost income that s/he would have earned during the time spent writing the book. Since the prospect of repaying an already-spent advance is distasteful, this typically gives the publisher a lot of leverage over the author in terms of the content of the book. This can be a good thing, since it incents authors to actually finish their books, but it also can lead to a book being finished prematurely or at a lower quality.

Coupled with the focus on speed to launch and secrecy is the fact that both publishing and venture capital are hit-driven businesses. Venture capitalists (VCs) build their businesses on the assumption that only 1 of 10 startups they fund will be a hit, 2 of 10 will limp along, and 7 of 10 will completely fail, losing all the money invested. Similarly, publishers produce many books but get the bulk of their profits from only a handful. Once these books are developed and begin to be marketed, the publisher gets a better sense of which books (if any) have the potential to be breakout successes, and focus their marketing efforts on those ones. Since publishers want to produce hits, they tend to force all books to seek as wide an audience as possible. This presumably isn’t much of a problem for fiction, but it is a problem for technical books such as computer books, since it forces much introductory material (that the author doesn’t want to write) into books, in order to theoretically broaden the potential market for the book as much as possible. (Of course, the risk is that this material will bore and alienate some readers, but publishers seem willing to take this risk.) This doesn’t just apply to computer books: how many otherwise-decent business books about startups seem compelled to explain (badly) the history of Silicon Valley or who Marc Andreessen is?

So, when you put combine all these factors, the outcome is that with a startup or book, what typically happens is that the founder(s) or author(s) get some money, lock themselves in a room and slave away to produce something targeted at a very broad market (it has to be a hit, remember?), which the market may or may not want. And if they get the product slightly (or completely) wrong the first time, the advance or investment money is mostly (or entirely!) gone and there’s not enough money left to buy the time to iterate enough times to actually produce a product that people want. Historically it has been extremely difficult to iterate on books: the only iterations are second and subsequent editions, and those editions only get produced for successful books. It has been very difficult to iterate on an unfinished or unsuccessful book, in a way that distributed these iterations to its readers. (Full disclosure: my company Ruboss is producing a product called Leanpub that makes it much easier to sell and iterate on unfinished books. So I’m completely biased in thinking that this is a real problem, and a problem worth solving, since I’m hawking a solution.)

Now that we’ve considered the parallels in the problems of writing a book and doing a startup, we can start looking at the parallels in the solutions.

Solution: Use Lean Startup Principles

One movement which has spread over the past year throughout the startup community is Eric Ries’s concept of the Lean Startup. This concept originated with applying Steve Blank’s concept of Customer Development to the problems of creating web 2.0 startups like Eric Ries’s IMVU, of which he was the CTO and co-founder. Briefly, the concept of a Lean Startup involves launching the product extremely early (so early that you’re embarrassed by it) and iterating rapidly in response to customer feedback. These iterations follow the OODA loop (Observe, Orient, Decide and Act) of USAF Colonel John Boyd, applied to consultation with customers using a process of Customer Development. Both Eric Ries’s blog and Steve Blank’s blog and book The Four Steps to the Epiphany are essential reading for anyone interested in Lean Startups (or Lean Publishing), so I’m not going to summarize their thoughts more here. Instead, I’m going to urge you to read their blogs and Steve Blank’s book.

The Lean Startup approach of doing Customer Development and getting meaningful feedback from early customers is very similar to the process of releasing a book very early in the writing process and getting meaningful feedback from readers. In both cases, if the Lean approach is done well, the startup or book will evolve in ways that are not necessarily planned from the outset. (This is similar to the concept of Agile software development, but the scope is actually broader in that the entire direction of the startup or book can change.) This isn’t armchair speculation for me: I have written 2 books (Flexible Rails was written using a Lean approach, while Hello! Flex 4 was written using a traditional approach) and I have been part of 2 startups before founding my own Lean startup. Our Leanpub product is very much evolving in response to early customers.

Continuing an analysis of the Lean approach, both startups and books used to have a much higher barrier to entry than today. One aspect of this barrier to entry was high capital requirements and lack of access to distribution channels for individuals. This led to much of the infrastructure which is less necessary today. You can’t launch a hardware startup without outside investment (unless you’re a multi-millionaire), but you can launch a web 2.0 startup with a few thousand dollars for the lawyers and a few weeks of work. Similarly, in the past, you couldn’t publish a book and get it in distribution channels without a publisher, but now anyone can write a book and stick it on sites like Leanpub (which is designed for selling in-progress ebooks) or Lulu (which is designed for selling print books).

Since you can sell in-progress books today using sites like Leanpub, you can do the “launch fast and iterate” approach recommended by Eric Ries for building a Lean Startup, but for a book. I did this the hard way with my book Flexible Rails, selling it on Lulu as an unfinished PDF–and getting in the top 100 books all-time by revenue–using my own techniques which I evolved over 18 months. These techniques were remarkably similar to Steve Blank’s process of Customer Development, which is why when I encountered them and Eric Ries’s Lean Startup concepts I realized the parallels and my company created Leanpub to embody them.

The techniques I created to sell an unfinished book on Lulu evolved out of necessity, since the process of selling an unfinished book on Lulu was very cumbersome. For example, Lulu does not tell you who bought your book. So, you have no way of knowing who your customers are! So if you don’t know who your customers are, how do you give them free updates to your book?

How did I use Lulu to do the Customer Development with Flexible Rails? How did I build a community using freely available tools? How did I sell an unfinished book and distribute updates to people whose identities I could not confirm? These topics are the subject of my next post…

Note: This principle was called “A Book is a Lean Startup” in my top-ten list I launched this blog with. However, I’m evolving my thinking as I write the principles, so I’m renaming it here. My guess is I’ll probably rename some of the other principles too…

The 10 Principles of Lean Publishing

I’ve been thinking a lot about publishing lately.

I started thinking (and writing) about publishing based on my experiences self-publishing Flexible Rails before it became a Manning book. Also, I just finished writing Hello! Flex 4 for Manning: it’s in Fourth Pages now, which means that the typesetter needs to apply the last 16 edits we have made and that’s it. So, I’ve now done the self-published author thing (getting Flexible Rails into the top 100 all-time books by revenue on Lulu) and the traditionally-published author thing with both Flexible Rails and Hello! Flex 4.

So, I finally have a deep enough understanding of how publishing and self-publishing works from an author’s perspective to have meaningful opinions about it.

I’ve also been doing a lot of thinking about Eric Ries‘ concept of a Lean Startup (since that’s what my company Ruboss is) and Steve Blank’s concept of Customer Development.

From this, I’ve realized that, in many ways, writing and self-publishing a book resembles running a Lean Startup.

I’ve also realized that many of the lessons learned about Lean Startups by people such as Eric Ries and Steve Blank can be applied to the process of writing, marketing and publishing a book. This insight, combined with my previous thoughts on publishing, led me to the concept of Lean Publishing. I’m now convinced of the following:

Lean Publishing is the future of publishing.

Translated from marketing speak into something more specific, I will claim the following:

The vast majority of new non-fiction books should first be self-published using the principles of Lean Publishing. Once the first draft of a manuscript is completed using the Lean Publishing approach, the book may be suitable for publication by a traditional publisher. (Traditional publishers do add value, but the value they add is mostly at the end of the book writing process, not the beginning.)

This blog is going to explore the concept of Lean Publishing, based on the lessons I have learned from writing Flexible Rails and Hello! Flex 4 and also drawing on recent examples of books from around the internet that have used Lean Publishing principles.

I will start by attempting to list what I think are the principles of Lean Publishing. Since this is a blog post, there has to be a numbered list somewhere, so without further ado I give you…

The 10 Principles of Lean Publishing

1. A Book is a Lean Startup
2. Publish Early (Fail Fast)
3. Publish Often and Listen to Your Readers
4. Trust Your Readers (DRM is Evil)
5. Pick and Own a Niche
6. Give Something Meaningful Away with No Strings
7. Build a Community with Web 2.0 Tools and Automation
8. Only Sell High Margin PDF Books While Still Niche
9. Publishers Add Most Value At The End of a Book
10. Develop Your BATNA Before Negotiating with Publishers

I’m going to explain each of these principles in depth over the weeks and months ahead, using Flexible Rails as the primary case study and various other examples from around the internet.

Also, I’m going to put my money where my mouth is: my company Ruboss is building a product which will facilitate the Lean Publishing process. (We have been working on this for a while, and we’re close enough to launching it that I can start talking about Lean Publishing now.)  So if you think that I’m engaged in self-promotion here, all I have to say is (1) you’re right and (2) this is a blog: what did you expect?

If you want to be notified as soon as we launch our Lean Publishing product as well as getting the in-depth posts explaining the principles of Lean Publishing, please subscribe to this blog’s RSS feed.

Eric Ries is going to be speaking at the Vancouver Ruby/Rails/Merb Meetup!

We are incredibly lucky to have an amazing talk this month!

Talk: The Lean Startup: a Disciplined Approach to Imagining, Designing, and Building New Products

Speaker: Eric Ries

Talk Description:
Eric Ries is in town for Agile Vancouver, and he has agreed to do a “slightly-more-technical version of the lean startup talk, with plenty of time for Q&A and discussion.” The talk he’s referring to is his Lean Startup talk from the recent Web 2.0 expo in San Francisco. For a full description of that talk, see the page at O’Reilly’s site.

Speaker Bio:
Eric Ries is the author of the blog Lessons Learned. He was the co-founder and served as Chief Technology Officer of IMVU, his third startup. He is the co-author of several books including The Black Art of Java Game Programming (Waite Group Press, 1996). In 2007, BusinessWeek named Ries one of the Best Young Entrepreneurs of Tech. He serves on the advisory board of a number of technology startups including pbWiki, Smule, 750i and KaChing.

When: April 20, 7 PM

Where: WorkSpace (21 Water Street, #400)

Thanks very much to Owen Rogers from Agile Vancouver for setting this up!

Pivotal Tracker rocks!

Pivotal Tracker is my new favorite project management app.  Congrats to them for their Jolt award

Back to Blogging

After a long hiatus, I am going to attempt to start blogging regularly.  The first step is to retire the old Typo-based blog and switch to WordPress.  (I don’t have the time to babysit Typo.)

I’m going to blog occasionally about Flex, Rails and my company Ruboss.  However, the plan is to spend most of the time focusing on bigger issues around publishing, technology, and entrepreneurship.  I’ve worn many hats in life, but “entrepreneur” is the most recent (about 15 months so far), and I’ve made enough mistakes (and had a few successes) that I feel I have something to say.

Pointless Vancouver Ruby Rails Meetup Drama

I hate writing a post like this. It’s about a totally pointless drama over absolutely nothing of any consequence.

However, in the interest of defending my reputation and Ruboss’s reputation, I need to do it: both are being attacked by Gerald Bauer, a blogger who has his blog fed into every conceivable blog aggregator imaginable…

But I really don’t want to write anything. So I won’t. I’ll just link to two things which tell part of my side of the story:

A brief reply showing the, um, misquote:
http://skitch.com/peterarmstrong/itj4/geraldbauermisquotingpeterarmstrong

A more verbose one by my friend and Ruboss colleague Scott Patten:
http://ruby.meetup.com/112/messages/3854645/

This was not what I created the meetup for; this was the kind of stuff I was trying to avoid. I will be more careful in future.

Update, for those people who are reading this from outside Vancouver and who don’t know the background:

  1. I’ve been organizing the Vancouver Ruby Rails Meetup for over a
    year, since I created it in July 2007. I don’t know how I can “hijack”
    something I created.
  2. In that time I have made exactly -$72.00 (that’s a minus) on the meetup: one of
    the two meetup fees was sponsored, the other one I paid. I’m glad I’m
    not in the profiteering business.

-Peter