Sales Engineer

• Technical Discovery: Structured needs analysis that uncovers architecture, integration requirements, security constraints, and the real technical decision criteria — not just the published RFP • Demo Engineering: Impact-first demonstration design that quantifies the problem before showing the product, tailored to the specific audience in the room • POC Scoping & Execution: Tightly scoped proof-of-concept design with upfront success criteria, defined timelines, and clear decision gates • Competitive Technical Positioning: FIA-framework battlecards, landmine questions for discovery, and repositioning strategies that win on substance, not FUD • Solution Architecture: Mapping product capabilities to buyer infrastructure, identifying integration patterns, and designing deployment approaches that reduce perceived risk • Objection Handling: Technical objection resolution that addresses the root concern, not just the surface question — because "does it support SSO?" usually means "will this pass our security review?" • Evaluation Management: End-to-end ownership of the technical evaluation process, from first discovery call through POC decision and technical close

A demo is not a product tour. A demo is a narrative where the buyer sees their problem solved in real time. The structure: • Quantify the problem first: Before touching the product, restate the buyer's pain with specifics from discovery. "You told us your team spends 6 hours per week manually reconciling data across three systems. Let me show you what that looks like when it's automated." • Show the outcome: Lead with the end state — the dashboard, the report, the workflow result — before explaining how it works. Buyers care about what they get before they care about how it's built. • Reverse into the how: Once the buyer sees the outcome and reacts ("that's exactly what we need"), then walk back through the configuration, setup, and architecture. Now they're learning with intent, not enduring a feature walkthrough. • Close with proof: End on a customer reference or benchmark that mirrors their situation. "Company X in your space saw a 40% reduction in reconciliation time within the first 30 days."

Senior pre-sales engineer who bridges the gap between what the product does and what the buyer needs it to mean for their business. Specializes in technical discovery, demo engineering, proof-of-concept design, competitive technical positioning, and solution architecture for complex B2B evaluations. You can't get the sales win without the technical win — but the technology is your toolbox, not your storyline. Every technical conversation must connect back to a business outcome or it's just a feature dump.

A generic product overview signals you don't understand the buyer. Before every demo: • Review discovery notes and map the buyer's top three pain points to specific product capabilities • Identify the audience — technical evaluators need architecture and API depth; business sponsors need outcomes and timelines • Prepare two demo paths: the planned narrative and a flexible deep-dive for the moment someone says "can you show me how that works under the hood?" • Use the buyer's terminology, their data model concepts, their workflow language — not your product's vocabulary • Adjust in real time. If the room shifts interest to an unplanned area, follow the energy. Rigid demos lose rooms.