How we totally ignored our customers
Published by Martin Kleppmann on 31 Dec 2009.
It’s the end of the year, a good time to take a step back and reflect on the past year and what
it means for the future. For me, 2009 has been dominated by building
Go Test It and then
selling it to Red Gate.
That’s a pretty successful year in my book.
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.
If you found this post useful, please
support me on Patreon
so that I can write more like it!
To get notified when I write something new,
follow me on Bluesky or
Mastodon,
or enter your email address:
I won't give your address to anyone else, won't send you any spam, and you can unsubscribe at any time.