Ebookmakr Failure: The Fallacy of Knowing What to Build – The Overdue Post Mortem

by Stefan Wolpers November 24, 2015 Follow @StefanW

November 24, 2015

Ebookmakr’s Origin: Turning A Food Blog Into A Recipe E-Book

Back in early 2012, I was looking to turn my food blog – I love to make ice cream (without milk or eggs, though, due to some food allergies on my side) – into a recipe book. And given my curiosity for e-books and self-publishing, I wanted to publish it myself on Kindle.

To my surprise, it turned out that turning a WordPress blog into Kindle e-book was quite a complicated process, not to mention that the .mobi file would not be compatible with the other e-book stores such as iBooks, Kobo etc. So, I thought to myself: Wouldn’t it be great to create a software as a service, that turns available content into e-books, particularly if the content is already available as a blog?

Back then, content marketing was still in its infancy and I saw a great potential in harvesting the huge amount of available quality content, repackage it and distribute it as e-books – be for profit, non-profit, user-base growth or personal reputation. The opportunities seemed to be endless, particularly if the software would be as simple as a typewriter to use. (Later, we had a catchy pitch built on that idea: „Did you become a […] mechanic before you wrote your first letter on a typewriter? No. So, why would you – as a writer – have to learn HTML & CSS for writing an ebook?“)

I Know What Needs To Be Built

That was the moment, when Ebookmakr – I quickly registered the trademark and secured the most important top level domains – came into being. In spring 2012, I was interviewing friends with a lot of content at their hands and people from the industry who confirmed my idea of the messy situation as far as e-book production was concerned.

After a while, I was convinced that my analysis of the publishing industry and its potential were right. Someone respected from the industry called Ebookmakr a “system relevant technology” and it was clear to me that the venture would have a good chance of becoming a homerun.

Looking back, I have to admit that at that time, my love for Ebookmakr started clouding my judgement and the project started going south. It didn’t do so in technical way, though. I found some great developers in Wroclaw that were building a state of the art JavaScript-based prototype.

Ebookmakr’s Product-/Market Fit Troubles

We had quite some sign-ups initially, but only a few projects were actually created. People seem to love the import function from WordPress and other blogs, but not a single blog-based e-book ever rolled off the Ebookmakr’s product-line to be distributed via the Kindle store.

Users suddenly started complaining about Ebookmakr being only available in English.

Also, users started asking about the import of Word documents, a function the prototype didn’t support at that point. And being offered in Germany, quite some discussions circled around privacy and a SaaS offering that would be hosted in USA.

It turned out, that we ran too many user interviews among our (early adoption-minded) peers, who were comfortable with English, Ebookmakr being hosting in the USA, and who had no privacy issues.

Ebookmakr’s End

At the end of December 2012, we shut down Ebookmakr. My recipe book never got published and my ice cream blog is long gone. (You can still watch some videos on ice cream making, though.)

We never managed to sell or open source Ebookmakr’s software. (You would have to start over now anyway.)

And when I published my “Lean User Testing” e-book back in spring 2015, I used one of Ebookmakr’s former competitors and it worked well. Just like I expected Ebookmakr would.

Ebookmakr Failure – Lessons learned:

Love the problem more than your solution.
Don’t push too far your dreams of China in your hand.
Use prototyping tools such as Marvel or Invision when running user interviews. (Read more on this approach in my post: Four Lessons Learned From Making Customer Value Your Priority.)
Be careful with the selection process for user interviews: You might end up picking those that will support your vision – it’s a self-fulfilling prophecy trap.
Beware of false positives in user interviews.
Never start writing a single line of code before an appropriate number of customers signed up. (For clarification: Customers are paying users.)
Never spend money on developing a prototype when you’re not working full-time on growing the user-base and increasing customer value.
Be patient and give your product the time it needs.
Always make branded t-shirts and wear them later regularly to preserve the recollection of the disaster.