Stop Worshipping the Customer Interview – Issue 15

More than a decade ago, I was working at Orange. Tasked to build an internal tool to automate paperwork, I carried a notebook and one question:

“What problems do you currently face in the paperwork process”

Every employer I met answered. Their words guided our tool. For a while that was perfect. Then it became paralysis..

• “I want the tool to remember my birthday” 🎂

• “Will I be able to rearrange the modules with drag and drop” 🫳

• “Can I scan the paper and auto-upload to the tool?” 🖨️

Shipping slowed. Nothing was released.

We were learning and “brainstorming” but not moving.

Since then I have learned two inconvenient truths:

1. Interviews come in many flavors. Some are light and fast, others are heavy and expensive. Using the wrong one is like trying to cut a steak with a spoon. 🥩

2. You do not always NEED an interview. Sometimes the fastest progress starts with your judgment and a quick experiment.

Books, bootcamps, and expensive conferences preach that talking to users is the highest virtue. The advice is well-intentioned. The danger is treating it like a rule.

Picture a writer who edits every sentence before finishing the paragraph. The story never moves forward.

This is exactly what happenes..

When teams obsess over interviews they reach a local maximum: perfect knowledge and zero momentum.

Most people imagine a user sitting across the table while we ask open questions. That is only one type on a broad spectrum of discovery ideas.

I created a Cheat Sheet where you can understand discovery mechanics:

📃 Customer Interviews Spectrum - Cheat Sheet [Download it here]

Below is the field guide that explains this spectrum.

I watched a podcast with Kevin Weil, the CPO of OpenAI. I love how they keep on shipping new work, this is what differentiated them them from every other LLM tool.

He said their secret is simple: decide, build, ship, repeat. No long customer interviews, no endless product reviews. They trust their own taste, release a small version, then learn from real use.

Kevin applied the approach at Instagram. When the team thought of Stories, they didn’t run focus groups for months. They shipped it internally. In just one week half the office was posting photos with stories. That reaction was louder than any survey. They fixed a few bugs and shipped Stories to everyone.

Good judgment plus fast shipping beats endless interviews. Use interviews only when the risk is huge. For most ideas, trust your gut, ship, and learn fast.

Here is the rule I live by:

• Talk when the cost of a wrong release is high or irreversible: pricing pages, data models, big navigation changes.

• Build when an experiment is cheap and usage will speak louder than words: UI tweaks, novel ideas, ranking algorithms.

As much as possible try to push problems in the “Build” bucket instead of the “Talk” bucket

1. Label the discovery. Decide upfront if you need a biased experiment or full-on research mode.

2. Time-box Discovery. Give yourself one/two weeks of research, then commit. With the rise of AI tools, there isn’t a reasonable answer to why discovery would take more than two weeks.

3. Write the hypothesis first before running an interview. If you cannot write the assumption you want to test in one sentence. You are not ready for a customer interview.

Customer conversations are important, but they are a tool, not a rule. Choose the right tool and you will move faster than teams who worship the process/ritual.

Trust your taste. Use the product. Ship something small. Then listen.

Now close this tab, take the risk and make a biased assumption.

Want more stories like this? Please subscribe and ❤️ this post.

I write about my journey in building Enterprise SaaS and Marketplaces