Throughout my career, I tried to create some products (Books, courses, video tutorials, software). Most of them failed, especially the ones in the early years. They failed in a really un-spectacular way: People were not even interested in them.

And I think the ones that failed, failed because I wanted to finish them before showing them to anybody.

Now, I have two products that people are interested in: They are downloading them and buying them. I do not make much money from them, but still… They are infinitely more successfult then the ofther ones.

Here’s what I did differently.

Learnings

Over the last 11 years, I learned a lot about how to work in a software development team. And I tried to apply my learnings to my own way of working.

So, none of what you’ll read here is really new. You may have read it before, in a book or a blog.

But it was new to me at some time. And some of the things, I had to learn the hard way.

Feedback

This was the most scary thing for me to try: You must get good feedback early.

And this means showing unfinished work to others - lots of others. But what if they don’t like it? What if their feedback is devestating? Obviously, they would like it more if I showed them the finished thing… If they saw the big picture.

Well, that “obviously” is not so obvious at all. In the past, I wasted a lot of time “finishing” stuff that, then, nobody would be interested in. Or not even finishing it, because at some point, I ran out of time.

With my React / Redux course, I did it differently. I announced on Twitter that I would be giving a webinar (and recording it) without having any material prepared. As I went on, I was completely open about my progress and what would happen next. The webinar was sold-out, and the content I created later led to a published book.

I did something similar with my other book, Quick Glance At: Agile Anti-Patterns: I presented some ideas at a conference. The audience liked them, so I wrote them down.

I gave the very first draft (which was still quite rough around the edges) to almost 200 readers (and promised that they’d get the finished book for free). I got almost 20 emails and messages with valuable, thoughtful and respectful feedback. The finished book is now much better than anything I could have created completely on my own.

But beware: Releasing something unfinished to the public or some friendly users does not mean releasing low quality. In both cases, I tried to create a small slice of the final work in almost the final quality. Otherwise, I guess I would not have gotten good feedback - People would have only complained about the quality.

Iteration

With both products, I tried to work in an iterative way, creating increments along the way.

For the Agile Anti-Patterns book, I did the following iterations, seeking feedback after each of them:

  • I presented a short list of anti-patterns in my keynote at the Lean - Agile - Scrum Conference Zürich
  • I created a draft ebook with those anti-patterns
  • I changed the structure and content based on feedback I got
  • I added more anti-patterns based on the feedback
  • I created a mobile-friendly, single-column version of the PDF
  • I published the final book on Amazon and Gumroad
  • I changed the distribution platform from Gumroad to Payhip after some problems
  • I added bonus material (Large Poster, small posters, illustrations, …)

After every iteration, I had some finished product that I could show to people and ask them what they think about it. And I proceeded based on their feedback.

Detours

What I wrote above is not entirely true: It just describes the happy path, for both products. I actually took some detours and saw some dead ends with both.

With the React / Redux book, for example, I took some detours and some dead-ends. Here is how the book came to be, and unsuccessful steps in between:

  • Successful: Host a webinar and record it. Attendees and some other people got the videos for free
  • Unsuccessful: Sell the videos
  • Unsuccessful: Give the first 5 videos to subscribers of a mailing list for free
  • Successful: Write a short ebook based on the 5 first videos, give it to subscribers of a mailing list for free
  • Successful: Write a longer ebook based on the whole course, sell it on Amazon and Gumroad
  • Unsuccessful: Up-sell from free ebook to complete ebook

…and some more mostly-unsuccessful things. So, only half of the things I tried were actually successful - and some of them only moderately or only on some metrics.

And I also had a large detour with the “Agile Anti-Patterns book”: Before I presented the anti-patterns at that conference, I had already a concept and almost 5 chapters for an “Agile Excellence” book, but I did not like them. So, after the positive feedback I got at the conference, I threw the 5 chapters away and started over.

The lesson here is: Be prepared to throw stuff away. Be prepared to go backwards when you face a dead end.

This was very hard for me to learn… I spent so much time on this thing, now I’m supposed to throw it away? I had to learn to overcome the Sunk Cost Fallacy.

Lessons…

So, I had to learn to stick to the main agile ideas.

  • Work together with your customers to create a product
  • Seek feedback early and often
  • Start small, iterate, and have a “working product” after every iteration
  • Take small steps

All four are scary. And just like when you are developing software in team that is part of a company, all four help you reduce risk and create a better product.

And I think I could do even better. I must learn to take even smaller steps, and seek feedback even more often.

Maybe next time…