Discovery Is Architecture

The demo is the easy part. Building something that looks impressive on screen, walking through a workflow, showing the art of the possible — any competent SE can do that. The hard part, and the part that separates good SEs from great ones, is the discovery that comes before it.

The Demo Is Not the Product

I've been in enterprise solutions engineering for seven years. The pattern I see most often when deals stall is this: the SE jumped to the demo too fast. They showed the product before they understood the problem. The prospect nodded politely and then went quiet.

What happened? The demo answered questions nobody asked. It solved problems the prospect didn't know they had — or worse, didn't actually have.

Discovery as System Design

Good discovery is really system design in disguise. You're mapping the prospect's current state — their data flows, their pain points, their organizational constraints, their political dynamics. You're building a mental model of how they work today and where the friction lives.

This is architecture. Not software architecture in the formal sense, but the same discipline: understanding the system before you try to change it.

The Questions That Matter

The most powerful questions in a discovery call aren't about requirements. They're about consequences:

These questions reveal the shape of the problem. They tell you what to show in the demo, what to skip, and what to emphasize. They turn a generic product walkthrough into a story about the prospect's world — with your solution as the resolution.

The Payoff

When you do discovery right, the demo practically builds itself. The prospect sees their own reality reflected back to them, and the conversation shifts from "interesting product" to "when can we start?" That's the difference between presenting features and solving problems.

The best SEs I know spend more time in discovery than in demo prep. That's not a coincidence.