How to Build a grows well Discovery-to-PoV Handoff Process

The handoff between discovery and proof of value keeps breaking, and everyone keeps trying to fix it with better documentation. More fields in the CRM. A new template. A longer form with more checkboxes. And it keeps not working, because the problem was never documentation.

It’s translation.

The discovery-to-PoV handoff fails when sales captures what the customer said and presales needs what the customer meant. Those are different things. They’re sometimes wildly different things. And no template in the world bridges that gap, because the gap isn’t in the notes - it’s in the reasoning that was never shared between the two people who needed to share it.

The Failure Mode Nobody Talks About

Here’s what happens in most enterprise deals. The AE runs discovery. The customer says they want to “reduce manual reporting time.” The AE writes this down, qualifies the deal, and hands it to the SE with a note that says something like “they want to see the reporting module - can you build a demo for Thursday?”

The SE builds a demo around speed. Fast dashboards. One-click exports. Automated scheduling. It’s technically excellent. It lands completely flat.

Post-mortem - if there even is one - reveals the customer’s actual problem was data inconsistency across three systems. The reporting took ages not because the tool was slow, but because someone had to manually reconcile numbers that never agreed with each other. “Reduce manual reporting time” was the business stakeholder’s way of describing a data integrity problem they didn’t have the vocabulary for.

This isn’t a competence gap. The AE heard what was said. The SE built what was asked for. The process worked exactly as designed. It just produced the wrong output.

The instinct here is to add more discovery questions. Ask deeper. Probe harder. But more questions don’t help if the two people asking them aren’t working from the same hypothesis about what matters. You just get more data with the same misalignment baked in.

The Structural Tension You Can’t Template Away

That reporting example has a nastier dimension, too. Say the SE does figure out that the real pain is data inconsistency. Now you’ve got a PoV scoping problem.

If you scope the PoV around data integrity, the technical buyer loves it. But the economic buyer - the one who said “reduce manual reporting time” - doesn’t see their problem reflected in what you’re showing. They wanted faster. You’re showing them more accurate. Those aren’t the same pitch.

If you scope around speed, the technical buyer sees through it immediately. They know the speed problem is a symptom. You’ve just demonstrated that you don’t understand their architecture.

This is a structural tension. Both framings are partially right. Neither is sufficient. And the only way to build a PoV that handles both is to have figured this out before anyone opens PowerPoint - which means the AE and SE needed to be aligned on what they were listening for during discovery, not just what they heard afterwards.

What a grows well Handoff Actually Needs

Three things. Not twelve. Three.

A shared pre-discovery hypothesis. Before the AE and SE walk into any discovery call, they need to have committed - even loosely - to a problem statement. “We think the pain is in onboarding velocity, owned by the VP of Customer Success, and proof means showing time-to-value reduction.” It doesn’t need to be right. It needs to exist, because a wrong hypothesis that gets corrected in discovery is infinitely more useful than no hypothesis at all. Without one, both people are just collecting data with no framework for what matters.

A translation layer. This is the bit everyone skips. After discovery, the output shouldn’t be a notes dump. It should be three lines that answer: what is the customer’s real business risk? Who owns it? And what does proof look like to them? That’s it. If you can’t answer those three questions, you’re not ready to scope a PoV. You’re ready to do more discovery.

A PoV scope contract. Agreed before build begins. Not after. Not presented as a deliverable. Agreed, mutually, with the customer, before the SE writes a single line of demo script. More on this shortly.

Getting Aligned Before Discovery, Not After

The pre-call sync is where this lives or dies. Fifteen minutes. Specific agenda. Not a briefing where the AE updates the SE on what they know - a working session where both people stress-test the hypothesis together.

Who’s the real economic buyer? What does “success” mean to the champion versus the person who actually signs? What’s the competitive context - are we displacing an incumbent or filling a gap? Does that change what we need to prove? The SE brings technical hypotheses about where the pain likely sits in the customer’s stack. The AE brings political context about who cares and why. The output is a shared mental model.

Not a shared document. A shared mental model. The difference matters.

I know the objection. AEs don’t want to do this. It feels like friction. Another meeting before the meeting. And I’m sympathetic to that - AEs are already drowning in process. But the reframe is straightforward: this sync doesn’t add time, it redirects time that was going to be wasted anyway.

The SE who shows up to discovery without context asks basic questions that erode credibility with technical buyers. I watched this happen on a call last year - an SE asking a principal engineer to explain their deployment model when it was documented on their public status page. The temperature in the room dropped about fifteen degrees.

And the AE who runs discovery without SE input misses technical signals that would have changed the deal strategy entirely. I know of a deal where an SE spent two weeks building a PoV around integration capabilities. Beautiful work. The AE ended up closing on price because the customer’s real concern was vendor risk - and the integration demo, which showed deep hooks into their core systems, accidentally amplified that concern.

The dead-end alternative people reach for here is async Slack updates and shared CRM notes. These transfer information. They don’t transfer understanding. There’s a meaningful difference between reading “customer mentioned data quality concerns” and hearing your SE say “their principal engineer went quiet when we asked about reconciliation - I think there’s something they’re not telling us about their data pipeline.”

Scaling Without Killing the Nuance

grows well and standardised are different things, and conflating them is how you end up with a 47-field Salesforce form that nobody fills out properly and everyone resents.

A standardised process gives everyone the same form. A grows well process gives everyone the same questions to answer, in whatever format fits the deal. The mechanism that makes this work is the decision log - not a CRM field, but a running record of what was learned, what was decided, and what was ruled out.

A decision log entry looks like this: “Considered scoping the PoV around workflow automation (AE’s original hypothesis). Ruled out after discovery call revealed the IT buyer has a freeze on new workflow tooling until Q2. Rescoped to data visibility use case, which sits in a different budget line. Champion confirmed this framing resonates with CFO.”

That takes four minutes to write. It saves four hours of misalignment when the deal re-engages after going dark for three months, or when a different SE picks it up because someone’s on holiday, or when the manager needs to understand why the PoV was scoped the way it was without scheduling a 30-minute download.

And when five SEs are each writing these, patterns start to surface. “Every time we lead with automation in manufacturing accounts, we hit the same IT freeze objection.” That’s not anecdote anymore. That’s a process insight that improves the pre-discovery hypothesis for the whole team.

The rejected alternative here - and I’ve seen multiple teams try this - is a master playbook with vertical-specific templates. “For manufacturing, use this PoV structure. For financial services, use that one.” Templates answer the wrong question. They tell SEs what to build. They don’t help SEs think about whether to build it, or how to scope it for this specific customer’s version of the problem.

What a Good PoV Scope Contract Looks Like

Most SEs have lived the scope creep version of a PoV. It starts as “show us how your product handles X” and by week two the customer is asking for Y, Z, and a custom integration that would take six months in production. The scope contract exists to prevent this - not as a legal document, but as a shared commitment that creates permission to say “that’s out of scope for this PoV, and here’s how we’d address it in a next step.”

The difference between a weak and strong scope contract is specificity.

Weak: “We’ll demonstrate the reporting module and show how it saves time.”

Strong: “We will show that Acme Corp’s weekly revenue reconciliation process - currently taking 6 hours across 3 systems - can be completed in under 45 minutes with a single source of truth, validated against Acme’s actual data set from Q3.”

The second version is quotable in the readout. It’s measurable. It gives the champion something to take to their CFO that doesn’t require interpretation. And it protects the SE - when success criteria are defined in advance, the PoV either passes or it doesn’t. There’s no ambiguity that lets a sceptical stakeholder move the goalposts at the eleventh hour.

The scope contract gets agreed before build starts. Both the AE and SE sign off internally. Then it gets shared with the customer - ideally the champion and the technical evaluator - and confirmed. Format doesn’t matter. A Slack message works. A shared Google Doc works. A Notion page works. The ceremony is irrelevant. The commitment is everything.

The Uncomfortable Bit

None of this is complicated. A fifteen-minute pre-call sync. Three lines of translation. A one-page scope contract. Decision logs that take four minutes to write.

The reason it doesn’t happen isn’t that people don’t know about it. It’s that it requires the AE and SE to have a working relationship where productive disagreement is normal - where the SE can say “I don’t think that’s the real problem” and the AE can say “I don’t think that framing will land with the economic buyer” and neither person takes it personally.

Process can’t manufacture that. But it can create the space for it to happen. The pre-call sync isn’t really about the hypothesis. It’s about two people practising the act of thinking together before they have to do it under pressure in front of a customer.

Some teams get this naturally. Marcus and Priya on my last team could finish each other’s discovery questions. Most teams don’t, and pretending a better template will fix a relationship problem is how you end up with beautifully documented PoVs that miss the point entirely.