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. (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?

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 home run.

Looking back, I have to admit that at that time, my love for Ebookmakr started clouding my judgment and the project started going south. It didn’t do so in a 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.

Receive a professionally curated summary of the best posts on the Internet about Agile, Lean Methodologies, and Product Management — delivered to your inbox every Sunday.

We've received your request — you're almost subscribed! Please check your email to confirm your subscription. We look forward to sharing the best Agile and Product news and insights with you! NOTE: If you do not receive the confirmation email within about 10 seconds, please also check the spam folder. Thank you!

There was an error submitting your subscription. Please try again.

Name

Email address

We use this field to detect spam bots. If you fill this in, you will be marked as a spammer.

Published by

Stefan Wolpers

Stefan — based in Berlin, Germany — has been working for 12+ years as agile coach, ScrumMaster and Product Owner. He is an XSCALE Alliance XBA Coach (XBAC) as well as a member of Scrum Alliance (CSP, CSPO, CSM). He is also a certified LeSS practitioner (CLP). He has developed B2C as well as B2B software, mainly for startups, including a former Google subsidiary.

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

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 😀