Most weak demos are not demo problems. They are discovery problems that showed up late.
Technical discovery is the Solution Engineer’s craft of turning a vague request — “we need integration,” “we want AI,” “we’re modernising APIs” — into a design you can defend, a pilot you can scope, and a deal you can qualify.
This is the framework I use when the room is full of architects, platform owners, and executives who each mean something different by “success.”
What technical discovery is (and is not)
It is: a series of conversations and artefacts that reveal constraints, decision criteria, ownership, and risk before you propose an architecture.
It is not: a product tour, a feature checklist, or a monologue about your platform’s greatness.
If you leave a discovery call knowing more about your product than about their landscape, you did not discover anything.
The discovery outcome you should leave with
Before you design or demo, aim to answer these six questions with evidence:
- What business outcome must improve in the next 2–3 quarters?
- What technical constraint is blocking that outcome today?
- Which systems, data, and identities are in the critical path?
- Who owns build, run, security, and budget?
- What does “good enough to buy” look like for this account?
- What would make this a bad fit — for them or for you?
If any of those are still foggy, keep discovering. Do not compensate with a longer demo.
A five-layer discovery model
Layer 1 — Business & urgency
Start above the architecture. Tools without urgency become shelfware.
- What decision is this initiative supposed to unlock?
- What happens if nothing changes for 12 months?
- Is this cost reduction, revenue enablement, risk reduction, or all three?
- What executive narrative already exists — and must your design fit it?
Layer 2 — Process & experience
Map the journey before the systems.
- Which process breaks today (onboarding, order-to-cash, case resolution, partner onboarding)?
- Where do humans re-key data or wait on email?
- Where do exceptions explode the “happy path”?
- What SLA or customer promise is being missed?
Layer 3 — Systems & integration reality
This is where many SEs finally feel at home — and where they must stay disciplined.
- What are the systems of record vs systems of engagement?
- Sync or async? Batch or event-driven? Near-real-time or overnight?
- Which APIs exist, which are shadows, and which are sacred cows?
- Where is transformation happening today — and who regrets it?
- What volume, peak load, and failure modes matter?
Ask for a current-state diagram. If none exists, draw one live. The silence in the room will tell you as much as the boxes.
Layer 4 — Data, AI & trust
If AI is in scope, discovery must get sharper — not vaguer.
- What knowledge must the model be grounded in?
- Where does that knowledge live, and how fresh is it?
- What actions should the system be allowed to take?
- What is the permission model across users, agents, and APIs?
- How will they evaluate correctness, groundedness, and risk?
This is where RAG pattern choice and API strategy stop being abstract. If they cannot name sources of truth, they are not ready for an agent demo.
Layer 5 — Operating model
Architecture that nobody can run is not architecture. It is a proposal.
- Who builds the first integration or AI use case?
- Who runs it in production — centre of excellence, platform team, or business IT?
- What skills exist today vs what must be hired or trained?
- How do environments, CI/CD, secrets, and observability work?
- What governance forums approve new APIs, patterns, and agents?
The discovery agenda that actually works
A 60–90 minute technical discovery should feel intentional:
- 5 min — Align on purpose of the session and decision timeline
- 15 min — Business outcome and process pain
- 25 min — Systems, data, and constraints (whiteboard)
- 15 min — Security, ownership, and success criteria
- 10 min — Recap assumptions, open questions, next artefact
Protect the whiteboard time. If you spend 40 minutes in slides, you already lost the discovery.
Artefacts worth producing after discovery
- Current-state sketch — ugly is fine; accurate is mandatory
- Target-state sketch — one page, decision-oriented
- Constraint log — non-negotiables (data residency, latency, offline plants, partner SLAs)
- Risk register — top 5 technical/commercial risks
- Pilot hypothesis — what you will prove, with whom, by when
- Open questions — owned by name, not left floating
These artefacts do more for deal momentum than another feature matrix.
Questions that unlock rooms
Keep a shortlist of high-leverage prompts:
“If this works perfectly in six months, what changes for the person doing the work every day?”
“Where have previous integration or AI initiatives stalled — and what stalled them?”
“Which system are people afraid to touch?”
“What would security need to see before saying yes?”
“Who gets paged when this breaks at 2am?”
Listen for contradictions between business urgency and technical ownership. That gap is usually the real project.
Anti-patterns that waste cycles
- Discovery-as-demo — showing product before you understand the problem
- Happy-path theatre — designing only for the 80% that never includes the 20% that pays the bills
- Stakeholder blindness — solving for IT while the business buyer needs a different proof
- Requirement collecting — writing down wishes without ranking constraints
- Premature architecture — naming components before naming outcomes
- Fake certainty — answering “we’ll figure it out in implementation” for deal-critical risks
How discovery feeds the rest of the SE motion
| Discovery finding | What you do next |
|---|---|
| Clear outcome, messy systems | Architecture workshop + phased integration plan |
| Strong platform interest, weak ownership | Operating-model conversation before deep technical proof |
| AI ambition, unclear data rights | Grounding / RAG / permissions deep-dive, not an LLM showcase |
| Competitive bake-off | Pilot scoped to the hard constraint competitors will dodge |
| Bad fit | Qualify out early, preserve trust, propose a narrower path if one exists |
A simple scorecard after every discovery call
Rate yourself 1–5:
- I can state the business outcome in one sentence.
- I can name the top three technical risks.
- I know who the economic and technical buyers are.
- I know what proof will move this deal.
- I know whether we should proceed, reshape, or walk away.
If you score below 18, schedule another discovery session. Do not “wing the demo.”
Final take
Technical discovery is how Solution Engineers earn the right to recommend architecture. It is also how you protect customers from elegant solutions to the wrong problem.
Ask sharper questions. Draw the messy current state. Write down constraints. Only then design, demo, and propose.
That sequence is not slower. It is how good SEs look fast — because they stop rebuilding the story every week.
For the broader role context, see The Role of a Solution Engineer / Sales Engineer.