A few weeks ago I asked my team a simple question: "When was the last time any of us actually talked to a customer?" Not looked at a dashboard. Not read a support ticket. Talked to a real person who uses our product. The silence was telling.
We had data. Usage metrics, NPS scores, funnel reports, heatmaps. We were drowning in signals about what users did. But we had almost no insight into why. Why they abandoned the flow at step three. Why power users suddenly went quiet. Why the feature we were most proud of was the one people used least.
I wrote about the importance of user research back in 2017, and I still believe every word. But five years later, I've realized that knowing research matters isn't the same as doing it consistently. The problem isn't that teams don't value talking to customers. It's that they don't have a habit of it.
Continuous discovery, simply explained
Teresa Torres describes continuous discovery as weekly touchpoints with customers, by the team building the product, conducting small research activities in pursuit of a desired outcome. Not quarterly research sprints. Not big formal studies handed off from a research team. Small, frequent conversations embedded in the workflow.
The key word is "weekly." Not "when we have time." Not "before the big launch." Weekly. The rhythm is the point. One conversation a week sounds almost trivially small. But it compounds. After a month, the team has heard from four customers. After a quarter, twelve. Patterns emerge that no dashboard would have surfaced.
How to start
Start with one conversation a week. Just one. Find a customer who used the product recently and ask them to walk you through what they were trying to do. Don't pitch. Don't demo. Listen.
Then: write down one assumption your team holds that the conversation challenged or confirmed. Share it in standup. That's it. The whole thing takes an hour.
The shift that changed things most for my team was inviting engineers to join the calls. Not every time, but regularly. The first time one of our developers heard a user describe a workflow we'd assumed was intuitive, and watched them struggle through it in real time, the conversation about what to build next changed completely. He didn't need a Jira ticket to explain the problem. He'd seen it.
Discovery isn't a phase
The mistake I made for years was treating discovery as something you do before you build. A phase. A gate. But the best teams I've seen treat it as something you do while you build. The building and the learning happen in parallel, each informing the other.
Discovery isn't a phase. It's a habit. And like any habit, it starts small and compounds into something that changes how your team sees the product.