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.
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.
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 (that later led to my React / Redux Book), 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.
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.
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.
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…