Over Christmas I finally had time to read The Four Steps to the Epiphany by Steve Blank. I had heard from a few people that it was the best book in the world for startups, but of course you take that sort of recommendation with a grain of salt. When I finally got round to ordering it, my first impression was not very impressed. The graphics are misaligned, the typography is ugly, there are plenty of typos, the cover picture is cheesy, the CafePress binding is flimsy. All in all, not a good start.

Well, don’t judge this book by its cover. Despite those apparent flaws, it is absolutely brilliant. And yes, if you have any sort of startup ambitions, you should go out and read it immediately.

In fact, maybe the book is deliberately ‘unprofessional’, because that would be consistent with a theme which runs through the entire book: focus relentlessly on what really matters and what really adds value. What really matters to me with Steve Blank’s book is purely its content (which is clearly articulated and deeply insightful); professional design or editing wouldn’t have changed this book’s value to me. Similarly, what really matters with a startup is to discover and learn what customers need, how the product fits into their lives, and how you are going to get it into their hands. ‘Professionally’ executing a strategy comes later. First you’ve got to learn and discover what the strategy is going to be.

This sounds trivially obvious, but it is not.

Let me digress for a minute. Something else I read recently is The Fable of the User-Centred Designer by David Travis (a short but beautifully written eBook — well worth reading but quite different from the Four Steps to the Epiphany). It made me realise how badly we had gone wrong with Go Test It. Steve Blank’s book further strengthened that feeling. Ok, we built a product which works alright. We did a few informal usability tests (looking over people’s shoulder while they use it for the first time) and we got some useful feedback from the beta tests. And clearly the result was promising enough that Red Gate wanted to acquire it.

Here is my confession: I cannot truthfully say that we really engaged customers in the process. I had some ideas about use cases and I did a few pencil sketches of the user interface before it was implemented. But did I actually go out to potential customers and test my ideas on them? Not a single bit! We thought about the ideas for a few minutes by ourselves, nodded our heads, and then just went ahead and hacked it together.

I have no excuse whatsoever for ignoring our customers like I did. Hell, we even had a poster from the Usability Professionals’ Association hanging in our office for a while, detailing the steps of a user-centred design process. (Some years ago I thought our company was going to be a usability consultancy — that was before we got into web development and ultimately into building Go Test It. Hahaha! By the way, that’s why this blog is called Yes/No/Cancel.) And nevertheless I totally ignored it. We were not doing anything like user-centred design, let alone Customer Development as proposed by Steve Blank, which is a lot further-reaching.

The only thing which saved us was that I was basically building a product to solve my own problem. I had worked on a big, JavaScript-intensive web app project, and had felt the pain of getting it to work in different versions of IE. So I had an idea of the kind of tool I had wanted to make that project less painful.

So: building something which scratches your own itch is better than building something which you don’t even need yourself. But it’s still a pretty bad starting point, because you are only one data point. How do you know that you’re not an outlier? In our case, I was even a pretty bad data point. I had only worked on two significant commercial web app projects — not exactly a great deal of experience. I had never worked in a proper web agency, or a larger software company, or an established e-commerce retailer, or in fact any company which looked remotely like the type of company we’re trying to sign up as customers.

What we should have done — and I understand this now — is to follow a Customer Development route from the start, alongside building our product. Before the coding started, I should have at least made my hypotheses explicit, tested them on my target market, and refined the product idea. Basically, I should have read The Four Steps to the Epiphany a year ago and then followed it.

In my defence, it’s difficult when you are a sole founder. In principle you could multitask between Customer Development and Product Development, but I think the two activities require very different mindsets, and the context switching overhead between the activities is huge. Therefore I suspect that a sole founder doing both will take much more than twice as long compared to two cofounders who specialise in Customer Development and Product Development respectively. Hence it’s extremely tempting for a technical founder like me to pretend that the Customer Development side doesn’t exist, and focus exclusively on the product.

Well, late insight is better than never. Amir is joining me on the Customer Development side of Go Test It, and we have a lot of catching-up to do. In 2010 there will be soul-searching and maybe some changes of plans, but I am really looking forward to it, because I am confident that we can figure out how to turn Go Test It from something ok into a product which you simply must have.

The article which I found most interesting is his “Strategy Letter V” (page 281), which is also available on the web. It explains why, in his opinion, so many large companies are investing in open source software.

On the surface, open source seems a strange model for a business — why should a company spend a lot of time and money developing software, and then simply give it away? The claim that they have suddenly given up on capitalism isn’t exactly convincing. The claim that it’s cheaper from them to get free code contributions from teenagers than to write it themselves… not so sure about that one either.

Joel gives the first answer which I actually find convincing. He explains open source investment in economic terms, through so-called complements. For example, flights to Venice and accomodation in Venice are complements of each other: customers need both in order to get a holiday in Venice, but they are sold by completely different companies. And if flights to Venice get cheaper, more people want to go there, so there is higher demand on accomodation, so prices of hotel rooms in Venice go up. And vice versa. This economic effect of complements has been observed in many different markets.

So, if A and B are complements of each other, and the price of A goes down, then the price of B will go up. So, if you are a company selling B, and you are clever, you will try to push the price of A down as far as possible, even commodify it. That way, you can sell B for a higher price and you’ll be better off.

And now if you look around who is investing in open source software, you’ll notice that often the software released in this free manner is actually a complement of what that company is trying to sell. For instance:

• Google want to sell advertising on mobile web sites. Mobile web browsers and mobile operating systems are complements of mobile web sites, so Google make Android and release it freely in order to drive down the price of these complements.
• Our friends at Collabora are paid by Nokia to work on an open source platform for Nokia’s internet tablets. Nokia sell phone hardware, and the operating system is a complement of the hardware, so it makes sense for Nokia to commoditise it. Moreover, third-party applications are a complement of the hardware, so by opening the platform to the wide variety of freely available Linux software, Nokia increases the value of its hardware even more.

Once you think about it this way, it’s amazing how the economics begin to make sense!