Just Talk to the Customer

A Product Manager talking to her customer.

Product discovery doesn't have to be complicated. Most organizations have made it that way, but that is a choice, not a requirement. The teams that consistently build products people love aren't running the most sophisticated research programs. They are simply talking to customers more than anyone else.

The teams that consistently build products people love are simply talking to customers more than anyone else.

The pattern I see most often in struggling product organizations is not a lack of process. It is the opposite. Product Managers are buried under internal meetings, approval workflows, and documentation requirements that were built to manage risk but ended up managing people instead. The customer, the one person whose opinion actually determines whether the product succeeds, gets represented through filtered feedback, stakeholder summaries, and secondhand assumptions. The PM never actually speaks to them directly.

A few years ago, I started working with a client whose product had solid functionality but almost no adoption. The Product Manager was talented and experienced, yet completely overwhelmed. Her calendar was wall-to-wall with internal meetings. Stand-ups, syncs, reviews, planning sessions, retrospectives. She was working hard every single day and burning out doing it. When I looked at her schedule for the previous month, I could not find a single customer meeting. That’s no exaggeration.  She was 100% internally focused.

That was the problem. Not her skills. Not the product. The organization had built so much internal bureaucracy around the work that the actual work - understanding what customers needed - had been completely crowded out.

We made one fundamental change. We cut 90 percent of the internal meetings and replaced that time with customer conversations. Not workshops. Not journey mapping exercises. Not analysis sessions with sticky notes on a whiteboard. Conversations. The PM sat down with real customers and listened to what they were struggling with.

What she heard in the first month changed everything. The product was not solving the problems customers actually had. It was solving the problems that the team had assumed they had two years earlier when the roadmap was built. That gap between assumption and reality had been there the entire time. Nobody had found it because nobody had been talking to customers consistently enough to validate it.

Nobody realized the gap between assumption and reality because nobody had been talking to customers consistently enough to validate it.

Over the next six months, we implemented structured design sprints to gather rapid feedback from prototypes before committing to development. We built a lightweight discovery rhythm that fit into the team's actual schedule rather than adding to it. We stopped treating discovery as a phase that happened before delivery and started treating it as a discipline that ran alongside everything else. The result was a 100x increase in product adoption in six months. Not because we built more features. Because we finally understood which problems were worth solving.

Discovery does not require a complex methodology. It requires one foundational commitment. Talking to customers regularly and validating the problems that actually need to be solved. Everything else, the frameworks, the templates, the research protocols, is only useful if it serves that commitment. When it gets in the way, it needs to go.

The most effective Product Managers aren't the ones with sophisticated research tools. They are the ones who make the time every day to talk to their customers.

The Product Managers who are most effective at discovery are not the ones with the most sophisticated research toolkits. They are the ones who have protected time on their calendar every single week for direct customer contact. That time is not optional. It is not something that happens when the sprint slows down. It is the work.

If the calendar doesn't show customer conversations this week, the discovery practice isn't broken. It just hasn't started yet.