Chapter 3: Why I Wrote This Book


People often ask me how my husband and I have been able to grow our software company, Geocodio, to over one million dollars in annual revenue without external funding.

Do you want to know the secret?

Here it is: listening to customers is embedded in everything we do. Listening to customers is the cornerstone, foundation, and pillars of how we make decisions. By listening to customers and learning their processes, we learn how to get and retain customers by helping them accomplish things faster, cheaper, and easier.

Hearing that, people then wanted to learn how to interview customers themselves. I didn’t feel like I had one solid place to send them, and I would find myself typing out long emails that were a mix of chapters of books, podcasts, and blog posts, with my own perspec‐ tives spliced in. (As you’ll learn in this book, repeated manual work like that is a symptom of pain that can be solved by a product. In this case, a book.)

Most resources on customer research are only partly relevant to people trying to start or grow businesses and are written for user experience professionals. I needed a resource that presumed no


previous experience with customer research and was also biased toward action.

This book is specifically intended to fill two gaps in the existing (and wonderful) body of work on customer research, much of which I reference throughout this book.

The first is specific words, phrases, and scripts to use when talking to customers, whether in an interview setting or support setting. Many books mention phrases and tactics, yet they often do not get into the nitty gritty of exact questions to ask in specific situations to the extent that would be needed by someone who has zero customer research training. The idea of this book is that, if you had to, you could read How to Talk So People Will Talk to get an idea for how to get people to open up, and then take one of the scripts into an inter‐ view with only minor adjustments. It is designed to be grab-and-go.

Second, with the exception of The User Experience Team of One, many of the books on user research are written with large, well- resourced teams in mind.

If you’re in a team setting, I suggest using this book in tandem with The Jobs to Be Done Playbook by Jim Kalbach. Steve Portigal’s Interviewing Users is excellent for those who have the resources and ability to meet with customers in person. Consultants might look to Erika Hall’s Just Enough Research, which is written from a design agency perspective.


This book attempts to make customer research methods accessible to even the smallest of companies—including companies of one, in soft‐ ware entrepreneur Paul Jarvis’ words.

Paul Jarvis’ Company of One is one of the most influential books in the world of small software companies. Rob Walling’s Start Small, Stay Small and Arvid Kahl’s Zero to Sold are also part of that canon.

The sparking motivation for this book was to offer a way to help founders and prospective founders, often developers, run their own companies with customer understanding built into the core of their decision-making process. Building products and features that people don’t want is painful and if people knew how to talk to customers and potential customers to get useful information, they wouldn’t have to go through that.

Trying to introduce customer perspectives into the product devel‐ opment process later on in a company’s lifecycle can be painful, too.

Anyone who has tried to introduce customer research into a company that makes decisions without talking to customers knows just how much of a slog it can be.

Cindy Alvarez’s Lean Customer Development is written from the perspective of a product manager and has specific tips for introducing customer research into a resistant organization. If you are in that situation and have skeptical higher-ups, read Alvarez’s book yourself and try to get your leadership to read one of Clayton Christensen’s books, which are written from a high- level, executive-friendly perspective.


But what if more companies were built with customer empathy from the very beginning? Retrofitting customer research into the organiza‐ tion wouldn’t be necessary, because it would already be baked in.

In the early days of Stripe, founders Patrick and John Collison personally answered support emails and watched users integrate the product.

According to Stripe product manager Theodora Chu, “they built up a strong sense of ‘What do developers want? And how do we make our APIs better by virtue of spending time with developers and watching how they use our APIs.” As a result, user research is something that’s “baked into Stripe’s DNA” because it’s been there from day one.

And it still is for new employees. “One of the first things you do when you join Stripe is you try and answer a support ticket, and you try and help a user through their pain point…We care a lot about people who are focused on users in general. You’re expected to talk to users throughout your time at Stripe, regardless of function.”1

It is my grand ambition to help people learn how to listen to customers and integrate it into their workflow from the start. While they are only one group of readers of this book, I believe that devel‐ opers and makers are the next huge wave of founders. Demystifying the skills to pull wants and needs out of potential customers would save them hours, months, and years of pain.


Before I was a software entrepreneur, I was a product manager at a mid-size company. We’d look at analytics and talk to customer service and then make educated guesses about what we needed to do to a product to get the metrics to go in the right direction.


Even though I was a frequent visitor in the customer service department, it never occurred to me that we could talk to customers directly.

I remember the first time someone suggested the idea of user testing our products before we launched them. “How are we supposed to find time for that?” I thought to myself. A week of user testing and then another two weeks of tweaking based on that feedback just wasn’t in the cards for our hectic four-to-six week product launch cycles.

It was only later, as my mind became more open to qualitative research and I had my own “Aha!” moments while talking to customers that I learned that it is absurd to start customer research the week before launch—because it needs to happen much sooner, as part of guiding the development of the product.

I saw for myself how it can improve product roadmaps, increase team motivation, and get numbers moving in the right direction.

Talking to customers was a revelation.

Practicing and applying empathy didn’t come naturally to me, and it’s something I’ve had to learn.2 I was fortunate enough to learn customer research under the wing of an experienced design leader and a PhD user researcher. I observed their interviews for months before conducting my own.

It took me a long time to realize the value that can come from listening to customers and how to do so in a way that leads to results, and I try to keep that in mind whenever I’m talking about this.

If you’re new to this, you may not believe me until you start seeing the results and having those “Aha!” moments of learning for yourself. I recognize that interviewing customers and integrating them into your decision-making is a mental leap for a lot of people.

Let’s embrace your doubt. I accept that you may be worried that this will be a waste of time. If you follow the methods outlined in this book, you will get useful feedback out of your interviews and you can stop spending time on things that people don’t want. You’ll get there, and this book is your step-by-step guide.