I spent three years doing customer discovery the standard way. Schedule calls, run calls, write notes, add quotes to Notion. Repeat. In the weeks before a planning cycle, pull the Notion page and try to synthesize six weeks of notes into a coherent picture of what customers needed. The problem was not that I was not talking to customers. I was. The problem was that the synthesis step consumed nearly as much time as the calls themselves, and the output was still shallower than it should have been.
The note-taking trap
Most PM note-taking happens under the worst possible conditions for retention: during a live conversation where you are simultaneously listening, asking follow-up questions, and watching the customer's screen share. What ends up in the notes is what caught your attention, which correlates more with what was surprising or interesting than with what was representative or recurring.
The customer who mentioned their Salesforce integration problem twice, in passing, may get two words in your notes. The customer who walked you through their entire current workflow gets two paragraphs, because there was more to write down. Later, when you are synthesizing, the workflow description is vivid and specific. The integration problem is a fragment. You weight accordingly, even though the integration problem may be the more important signal.
Synthesizing without a baseline
The second place time disappears is in synthesis. If you do not have a consistent tagging system across calls, you have to re-read everything at synthesis time and categorize as you go. Even PMs who tag their notes run into problems when the same theme gets different labels across calls: "slow export" and "export speed" and "CSV export is broken" are all the same issue, but they do not aggregate naturally.
The synthesis work that actually produces usable output is cross-account frequency analysis: which problems or requests showed up in more than one call, from more than one distinct account. That question is almost impossible to answer accurately from a Notion database without a structured tagging taxonomy and the discipline to apply it consistently under time pressure across every call. Most teams do not have that. So synthesis time grows, and the output is still an educated guess.
Where discovery time actually goes
When we looked at how discovery time was being spent, it broke down roughly like this: about a third on the calls themselves, a third on note-writing and tagging immediately after calls, and a third on synthesis, Slack back-and-forth about what customers had said, and answering follow-up questions from engineering or leadership. The calls were the most valuable hour. The rest was largely overhead required to make the call outputs usable.
That third of time spent on synthesis and follow-up questions is the target for improvement. Not by doing less discovery, and not by skipping synthesis, but by having a system that does the aggregation work continuously, so that synthesis at planning time is a review of an already-aggregated view rather than a construction project.
A different structure for discovery work
The structure that actually changes the efficiency equation starts with automated transcription and signal extraction immediately after each call. The PM does a five-minute review of extracted signals per call instead of a twenty-minute note-writing session. Signals are tagged and attributed to the account automatically. Frequency scoring across accounts runs continuously.
When planning time arrives, the PM is not sitting down to synthesize weeks of raw notes. They are reviewing a signal view that has been accumulating since the last planning cycle, showing which themes have recurred, across how many accounts, and which accounts are driving each theme. The planning conversation changes from "here is what I think I heard" to "here is what the data shows, and here are the three calls you should read for context."
This is not faster discovery. The calls take the same amount of time. What changes is how much of the non-call time produces output that compounds versus output that gets re-processed and summarized into something that still only one person has read.
What this does not fix
Better tooling does not fix discovery if the calls themselves are shallow. If you are running validation calls instead of exploration calls, or asking closed questions, or talking primarily to your most vocal customers, you will get a beautifully organized view of a biased sample. The infrastructure is only as good as the raw material. Discovery discipline still needs to be a PM skill. What automation changes is the cost of extracting value from well-run calls, so that discipline is actually worth investing in.
