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

Executive Summary – Lessons Learned from Ebookmakr’s Failure:

  1. Love the problem more than your solution.
  2. Don’t push too far your dreams of China in your hand.
  3. Use prototyping tools such as Marvel when running user interviews. (More here: Four Lessons Learned From Making Customer Value Your Priority.)
  4. 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.
  5. Beware of false positives in user interviews.
  6. Never start writing a single line of code before an appropriate number of customers signed up. (For clarification: Customers are paying users.)
  7. Never spend money on developing a prototype when you’re not working full-time on growing the user-base and increasing customer value.
  8. Be patient and give your product the time it needs.
  9. Always make branded t-shirts and wear them later regularly to preserve the recollection of the disaster. (See below.)

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?

Ebookmakr post mortem: Lessons learned from the failure of the Ebookmakr team in 2012 – Age of Productt

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. (I can highly recommend Monterail, let me know if you like an introduction to Szymon.)

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:

  1. Love the problem more than your solution.
  2. Don’t push too far your dreams of China in your hand.
  3. Use prototyping tools such as Marvel when running user interviews. (More here: Four Lessons Learned From Making Customer Value Your Priority.)
  4. 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.
  5. Beware of false positives in user interviews.
  6. Never start writing a single line of code before an appropriate number of customers signed up. (For clarification: Customers are paying users.)
  7. Never spend money on developing a prototype when you’re not working full-time on growing the user-base and increasing customer value.
  8. Be patient and give your product the time it needs.
  9. Always make branded t-shirts and wear them later regularly to preserve the recollection of the disaster.
    age of product: failure of ebookmakr t-shirt

2 thoughts on “Ebookmakr Failure: The Fallacy of Knowing What to Build – The Post Mortem”

  1. I’m a big fan of having real customers first. First meaning: before you have a name or a domain or even a product. Then the first ten sells should be done by performing the service you provide completely manually. This is necessary to really understand how it works, what are the challenges, the risks. Talking to these customers permanently will ensure you will understand what their domain language is. Then you find out how other service providers provide that service and learn that domain language as well. Only if you understood the customers and the market, you can even begin to create a vision of how to optimize the processes by automating or facilitating parts of it.

    Most founders are ensnared by new technologies and their capabilities, and see how some market doesn’t use it, and conclude it’s a sure winner to fill the gap. So they build a product first, because they never doubt that people want that. Then they make a thousand mistakes without any understanding about which ones are silly or expected, trivial or crucial, easy or complex. And then they discover they have no idea what they are building for whom and where to go next.

    It’s like: “Let’s be a service provider” but not having a single Service Designer on board right from the beginning. Most founders are too attracted to dreams and bad KPIs and blind spots – more attracted than to humility and patience and scepticism and trusting professionals. Nothing would give a better reality check for the founders than external Service QA telling them exactly why their solution sucks 😀

Leave a reply

Your email address will not be published. Required fields are marked *