Sales Engineer

---
name: sales-engineer
description: "Use when an org role acts as sales engineer and must run technical discovery, tailored demos and scoped POCs that prove the product fits the buyer. Covers discovery-to-demo mapping, POC scorecards, objection libraries and reference architectures. For making collateral, use sales-enablement."
tags: ["sales","engineering","communication"]
tools: []
license: Apache-2.0
source: https://github.com/monoes/monomind
---
# Sales Engineer — Best Practices

## Focus
Bridges product capability and customer need during the technical sales cycle — running discovery, demos, and POCs that prove a solution actually solves the buyer's problem, not just that it has features.

## Best practices
- Know the customer as well as the product: their stack, pain points, industry constraints, and competitive alternatives before the first technical conversation.
- Treat discovery as collaborative diagnosis, not a checklist — dig into why a requirement exists before proposing how to meet it.
- Tailor every demo to the specific pain points surfaced in discovery; never run the generic canned demo.
- Front-load the outcome in demos — show the payoff first, then the mechanism. Keep each section under ~3 minutes so attention doesn't drift.
- Scope POCs tightly: agree success criteria, timeline, and required resources with the champion in writing before starting.
- Build and reuse a library of objection responses and reference architectures instead of improvising technical answers live.
- Loop in engineering/product early on anything that looks like a gap — don't let the customer discover it during the POC.
- Debrief every lost or stalled technical evaluation to capture what broke down (fit, timing, competitor differentiation) and feed it back into the playbook.

## Common pitfalls
- Demoing every feature instead of the 2-3 that map to the customer's stated problem — this dilutes the pitch and signals no preparation.
- Answering technical questions with unqualified promises instead of "let me confirm and follow up," creating delivery risk downstream.
- Skipping written success criteria on a POC, which lets a stalled evaluation drag on indefinitely with no forcing function.
- Treating the SE role as purely technical support instead of a co-owner of the deal outcome — disengaging once the "cool demo" is done.

## Tools & techniques
- Discovery-to-demo mapping: every demo section should trace back to a specific pain point named by the customer.
- POC scorecards with explicit pass/fail criteria agreed upfront, reviewed jointly at the end.
- Objection library: a maintained doc of common technical objections and vetted responses, updated after each competitive loss.
- Reference architecture diagrams tailored per vertical/use case for fast credibility in technical conversations.