John Spooner

Playbook

Discovery: Building Enough Context to Make Good Technical Decisions

Discovery should give an SE enough context to make good technical decisions without restarting the deal from zero. I use a structured intake, stakeholder reasoning and microfeatures to understand what actually matters before deciding what to build, show or test.

  • Technical Sales
  • Communication
  • Product & Market

In this playbook

  1. How much context does an SE need before deciding what to build, show or test?
  2. How do I uncover the reason behind a customer's technical requirement?
  3. How do I know when discovery is deep enough to move forward?

When I join a deal, I don't expect the AE to have completed my technical discovery for me. I do expect enough business context that I don't have to restart the conversation from the beginning.

My job is to take what we already know, identify what is missing, go deeper where the solution requires it, and use that understanding to decide what we should actually do next.

The test I use is simple: can I explain why the customer is talking to us, what they are trying to change, why it matters and what a good outcome looks like? If I can't, I probably don't know enough yet to design a useful technical response.

Download my Discovery & SE Intake TemplateMake your own copy of the intake document I use to capture business context, stakeholders, technical landscape, microfeatures, competition, outstanding gaps and strategy for the next customer interaction.Opens in a new tab.

The AE and SE need much of the same context, but they contribute different depth.

Before an SE becomes involved, I want the existing business and non-technical discovery documented: what the customer does, why they're looking, what happens today, what they're trying to improve, who's involved and what we've learned so far.

I then sit with the AE and use that information as the basis for the next step. We look for gaps, assumptions and areas that need validation. If the context is weak, I'll help fill it in; I just don't want us repeatedly asking the customer for information we've already had an opportunity to learn.

The objective isn't a perfect handover document. It's to let the SE start from the point the deal has actually reached.

Do

Start from the context the deal already has, then identify the gaps that matter to the technical response.

Avoid

Restart discovery from zero and make the customer repeat information the team has already had an opportunity to learn.

A customer requirement is much more useful once you understand the reasoning behind it.

At Surfly, customers would sometimes ask about retention policies for session recordings because they assumed we would store the recordings ourselves. In reality, recordings could be sent directly to their own S3 storage without being stored at rest by Surfly.

If I simply answered the retention question, we could spend significant time discussing a compliance concern based on the wrong assumption. Once I understood why they were asking, I could explain the architecture and often remove the concern entirely.

I don't challenge requirements for the sake of challenging them. I want enough context to know whether we're solving the actual problem.

Do

Understand why the customer is asking before deciding which technical answer or solution they actually need.

Avoid

Treat the stated requirement as the problem when it may only be a symptom of an assumption or underlying concern.

I use microfeatures to make this more systematic.

A feature is a broad capability such as session recording. A microfeature is the particular characteristic of that capability that matters to a stakeholder: storage location, retention, access control, export, API availability, recording quality or something else.

This matters because three stakeholders can ask about the same feature for completely different reasons.

FeatureMicrofeatureStakeholder concern
Session recordingStorage locationWhere does sensitive data live?
Session recordingRetrievalCan Operations use it for QA?
Session recordingAPI / exportCan it feed an existing workflow?

Recording “customer wants session recording” is therefore weak discovery. I want to understand which part they care about and why.

That lets me map:

Stakeholder → concern → microfeature → reason → desired outcome

It also makes the eventual demo much more precise.

Once I'm involved, the depth of technical discovery depends on the solution.

I might need to understand the customer's architecture, integrations, authentication, security requirements, data handling, deployment constraints, available developers or likely implementation blockers. I don't collect technical information for completeness; I look for anything that could materially change the solution or create expensive backtracking later.

The same applies to stakeholders. Formal labels such as champion, technical evaluator and economic buyer are useful when they fit, but my more practical rule is that if someone is in the meeting, I should know why they're there.

That becomes particularly important when priorities conflict. Security may want tighter controls while CX wants maximum flexibility. Part of the SE's role is understanding both arguments well enough to use the platform intelligently and find an approach both sides can support.

I also want to know what the customer is comparing us with, including the status quo.

If another vendor is involved, I'm interested in what the customer likes about them. That exposes weaknesses, builds market understanding and helps identify the areas where comparison will actually matter.

If I know we perform particularly well on something important, I'm comfortable suggesting that the customer test the same capability with both vendors. A useful comparison is stronger than simply claiming we're better.

Urgency matters here too. A genuine problem with no reason to act can still become a no-decision. Understanding why the customer is looking now, and what happens if they do nothing, helps distinguish an active project from general interest.

Discovery has only done useful work if it changes what happens next.

It should influence the solution we recommend, the demo we build, the capabilities we leave out, the questions we continue asking, the stakeholders we focus on and the amount of technical effort we invest.

This is why I won't spend significant time building a bespoke demo when I don't understand the opportunity well enough to make it relevant. That doesn't mean refusing to help because a form isn't complete. It means doing another discovery session first when the missing context could materially improve the result.

There isn't a rigid threshold. Good SEs develop judgement about when they know enough to move.

Do

Let discovery change what you build, show, test and invest technical effort in.

Avoid

Commit significant SE effort while material unknowns could still change the direction of the solution.

Discovery doesn't finish because the CRM stage changes.

A demo exposes new information. A developer reveals an implementation constraint. A security question uncovers an assumption. A trial shows that the customer behaves differently from how everyone expected.

Those findings should feed back into the same customer profile rather than disappearing into individual calls or forcing the next team to rediscover them.

Over time, the intake becomes the technical and commercial context behind the opportunity and can follow it through evaluation and ultimately into implementation.

The discovery mistake I care about most is moving into features before understanding the problem and landscape.

The customer knows their business better than I do. I should understand their reasoning before prescribing anything. But I also know my product better than they do, so once I have that context I should contribute an opinion.

In most substantial demos I expect to show something the customer didn't explicitly request, even if only as an alternative. Sometimes it is a better technical approach; sometimes it removes complexity; sometimes it costs more and I should say so.

The objective is not to accept every requested solution or to force my own. It is to understand the customer well enough that we can design the right answer together.

I don't judge discovery by whether every field in a template contains text.

I consider it sufficient when we understand the situation well enough to make the next important decision confidently, and there is nothing material left unknown that could invalidate the direction we're taking.

There will always be more to learn. The difference is that by this point we're no longer exchanging requirements across a table; we're pulling in the same direction and working on the problem together.

  • Start where the existing discovery ends. Don't restart the deal simply because the SE has joined.

  • Understand why the customer is asking, not just what they asked for. The reasoning behind a requirement is often more useful than the requirement itself.

  • Let discovery determine what you build, show and deliberately leave out. Its value is in changing the technical response.