Discovery Never Stops
Discovery is a continuous practice. The moment you stop talking to users, your roadmap becomes fiction.
Most teams treat discovery as a phase. They do user research at the beginning of a project, write up findings, build the thing, and move on. This is backwards. Discovery is not something you do before building. It is something you do while building, after shipping, and between projects.
The best product teams talk to users every single week. Not once a quarter during a "research sprint." Every week. Five conversations a week, thirty minutes each. That is less than three hours of your time, and it is the highest-leverage activity a PM can do.
Here is why continuous discovery changes everything: markets move. Customer needs evolve. Your assumptions decay. The insight that drove your roadmap six months ago may already be outdated. If you are not continuously validating, you are building on assumptions that get staler every day.
Continuous discovery also changes how you prioritize. When you talk to users regularly, you develop an intuition for what matters that no survey or analytics dashboard can replace. You start hearing the same pain points from different customers. You notice patterns before they show up in data. You build empathy that makes every product decision better.
The objection is always time. "We do not have time for weekly user calls." You do not have time to build the wrong thing for three months either. Discovery is not a cost center. It is an insurance policy against wasted engineering effort.
“Five conversations a week, thirty minutes each. Less than three hours of your time, and the highest-leverage activity a PM can do.”
When this goes wrong
Treating user research as a phase that happens before development. Going months without talking to a real user. Substituting analytics for conversations. Relying on sales team summaries instead of hearing customer words directly.
In practice
- ✓Schedule 3-5 user conversations every week, non-negotiable
- ✓Keep a running "insights log" that the whole team can access
- ✓Validate every major assumption before committing engineering resources
- ✓After shipping, talk to users who adopted and users who did not