The Discovery Moment
The Discovery Moment: Changing How I Listen
One of the best discovery moments I've had started with a casual question during a customer workflow conversation. We were not in a late-stage escalation, and the customer was not trying to force a roadmap commitment. The purpose of the call was more ordinary: understand how their team moved through the work, where the product would support that movement, and where implementation might require more care than the sales process had captured. That type of conversation can look simple from the outside, but it often produces information that determines whether a solution will feel natural to the customer after the contract is signed.
The customer mentioned a step they were preparing for while explaining how their internal process worked. It was not presented as a blocker, and no one in the room treated it like a formal requirement. The comment sounded like background because, from the customer's perspective, the step had already been accepted as part of their process. They were not asking us to solve it; they were telling us how they expected to work around it. What made it important was not that a product spec had been mentioned, but that the operational context made the comment worth holding.
A customer who has normalized extra work will not always identify that work as a problem, especially if the process has been in place long enough to feel inevitable. In this case, the preparation step indicated that part of the workflow was expected to happen outside the product. The customer had already planned for the manual effort, which made the detail easy to overlook but also more useful once we understood what it represented. The surrounding workflow told us more than the comment itself.
After the call, the detail stayed with the team because it raised a better question than the one the customer had directly answered. The issue was not simply whether we could build a feature to support that step. The more useful question was whether the step reflected a broader workflow pattern that other customers were also managing outside the product. That pushed the internal conversation past the first observation and into the structure around it: who owned the step, why it existed, what happened before it, what happened after it, and whether the same pattern appeared in other accounts.
We built the feature, and it was adopted by nearly every customer. That confirmed the original comment was pointing to something larger than one account's local process. Still, the outcome should not be read as proof that every casual customer comment should become a roadmap item. The feature worked because the comment was treated as evidence to investigate, not as an instruction to follow. The value came from understanding the workflow around the comment before deciding what the product should do.
Discovery is often described as a question discipline, and there is truth in that. Poor questions create poor inputs, and generic questions often make customers repeat information without revealing anything new. But the quality of discovery depends just as much on how the answer is interpreted after it is given. Customers rarely organize their world in the same categories a vendor would use to evaluate product fit, implementation risk, stakeholder alignment, or commercial impact.
Instead, customers describe the work through the sequence in which they experience it. They mention review steps, approval paths, spreadsheets, data exports, manual cleanup, internal meetings, or preparation work because those are the artifacts of the process they live with every day. Some of those details will not matter beyond the immediate conversation. Others are early evidence that the product, the implementation plan, or the sales narrative needs to be reconsidered. The SE's job is to understand which details have operational meaning beyond their surface appearance.
The preparation step from that customer mattered because it showed work the customer had already accepted as external to the system. That is a different signal from a direct feature request. A direct request tells you what the customer thinks they need. A normalized workaround tells you how the customer has adapted their process around a limitation, whether or not they would describe it that way. The workaround often requires more interpretation because the customer may not think of it as evidence.
This is where Sales Engineering can create value that is easy to miss if the role is reduced to demos and technical validation. The SE sits close enough to the customer conversation to hear how people describe their work, while also carrying enough product and implementation context to recognize when a small workflow detail may be structurally important. That position only produces value when the SE is careful with the signal. Treating every workaround as a feature request creates noise; ignoring quiet workflow details leaves the organization dependent on late-stage escalations and post-sale surprises.
A customer's workaround has to be understood before it is translated. The work may exist because of a legitimate business requirement, an approval chain, a reporting obligation, a data-quality concern, or a team structure the product needs to respect. It may also exist because of habit, legacy process, or local preference that should not drive product direction. The surrounding workflow has to be examined before the organization can decide whether the observation belongs in a demo adjustment, an implementation plan, a product discussion, or a simple follow-up question.
Follow-up questions are often straightforward. Asking the customer to walk through what happens at a specific step gives them space to explain the work in their own order. It also keeps the SE from pushing the conversation back into product language too quickly. When a customer explains who owns the step, what information is being prepared, who reviews it, and what happens if the preparation is incomplete, the operational purpose of the workaround becomes clear. That is usually more reliable than an interpretation made before the context is visible.
I have made the mistake of mapping too quickly. When you know a product well, familiar language can trigger a familiar answer, and the conversation moves toward a feature, a limitation, or a prepared demo path before the customer has finished explaining. That instinct is useful when the customer needs a clear response, but it can also reduce a workflow to the part of the product it most resembles. The SE looks responsive while missing the actual shape of the customer's process. Slowing down long enough to understand the customer's language produces a better answer later.
The same principle applies during the demo. A demo should be informed by discovery, but it should not end discovery. Customers often react more specifically once they see a workflow represented in the product. They notice permission questions, handoff issues, data movement assumptions, reporting gaps, approval timing, and administrative ownership in ways they may not have mentioned earlier. Those reactions are not interruptions to the demo; they are part of the evidence the demo is supposed to create.
A product tour asks the customer to translate capability into their own process. A more useful demo tests the customer's process against the product in a way that makes correction possible. If the customer says that a central team gets involved earlier than expected, or that an approval happens outside the department, or that a report needs to be reviewed before it can be shared, the SE has learned something that may affect implementation and adoption. The prepared path may still be useful, but the correction is often where the real discovery continues.
Specific references to the customer's workflow matter in a demo for that reason. A sentence that ties the screen back to something the customer said earlier gives them an opportunity to confirm or refine the interpretation. The point is not to sound attentive. The point is to check whether the product story matches the customer's actual operating model. A demo is more valuable when it allows the room to test assumptions before they become commitments.
The internal note after the call matters as much as the customer-facing conversation. Field feedback loses value when it is reduced to "customer wants this feature," because that framing removes the context needed to evaluate the request. Product needs to understand the job the customer is trying to complete. Engineering needs the constraint and the tradeoff. Implementation needs the operating reality that will show up after the sale. Sales needs to understand whether the issue affects urgency, deal risk, launch success, or long-term account value.
A useful internal note preserves the customer's context while separating observation from inference. It should explain what the customer was trying to do, where the process moved outside the product, who owned the work, why the workaround existed, and what risk or effort the workaround created. It should also be clear about what is known and what still needs validation. That keeps the organization from overreacting to one account's preference and underreacting to a pattern that is showing up across several.
The feature from this discovery moment worked because the original comment opened a line of inquiry. The team did not treat the comment as a spec, and it did not treat the customer's workaround as automatically correct. The workflow around the comment had to be understood before the product decision could make sense. Once that broader pattern was visible, the feature was easier to justify because it was connected to recurring customer behavior rather than one account's preference.
A lot of customer insight gets lost because teams wait for the signal to announce itself. They expect the customer to say something is painful, name the risk, explain the business impact, or connect the workflow to a buying priority. Some customers can do that, especially when they have already diagnosed the problem internally. Many cannot, because they are too close to the work to separate avoidable effort from normal effort. The process has been lived with long enough that extra steps no longer feel like evidence.
Asking what is broken can miss the issue entirely. The customer may not think the process is broken, even when it creates work the product could remove or risk the product could reduce. They may see the process as annoying, political, unavoidable, or too specific to mention. Asking them to walk through the work creates a better chance of seeing where trust has not yet been earned. In enterprise sales, trust often lives inside a specific workflow step where accuracy, visibility, permissions, or handoffs matter.
The SE has to listen across roles because each stakeholder experiences the workflow differently. A leader may focus on reporting, while an admin focuses on permissions. A technical stakeholder may care about integrations, while a department owner cares about whether their team will be cleaning up the process after launch. Those concerns do not always appear in the same conversation, and they rarely use the same vocabulary. Good discovery connects them without flattening them into a generic pain statement.
The best discovery notes are often messy at first because real customer conversations do not arrive in clean analytical categories. There is the official requirement, and near it there is often a side comment that explains why the requirement exists. There is the stated launch goal, and beneath it there may be an operational concern the customer has not fully named. There is the feature the customer asks about, and around it there may be a manual process the team has learned to tolerate. The useful information is often in the relationship between those pieces.
That customer conversation stayed with me because it showed how much discovery depends on patience after the obvious answer has been given. The first comment was easy to miss because it sounded like preparation, not pain. The meaning became clearer only when the surrounding workflow was examined. A customer's context can be more useful than their explicit ask, but only if the team is disciplined enough to understand it before turning it into action.
Sales Engineering is most useful in this work when it keeps the company close to the customer's real process. The goal is not to collect anecdotes, dramatize every gap, or turn the field into a roadmap shortcut. The goal is to bring back context that helps Sales tell a more accurate story, helps Implementation prepare for the work ahead, helps Product see patterns earlier, and helps the customer feel that their operating reality has been understood. In the discovery moment that started this story, the feature mattered, but the listening mattered first.