Most people treat discovery like a checkbox. One call, some notes, move to the demo. I treat it like the most important conversation in the entire engagement — one that never really ends.
From the first meeting to the final presentation I’m still learning. Still listening. Still looking for the thing the customer hasn’t said yet but needs to say.
I almost never ask yes or no questions. Closed questions get closed answers. I want the customer thinking, remembering, making connections they hadn’t made before.
The right question at the right moment can surface a problem that’s been sitting in a room for two years — waiting for someone to ask about it.
Discovery isn’t the time for answers. Rushing to a solution before you fully understand the problem is how you get it wrong.
I don’t arrive with answers. I arrive with questions and a genuine desire to understand — the technical environment, the business impact, how the two connect, and how the organization itself shapes what’s actually implementable.
Discovery can feel invasive and personal. The difference between a customer who opens up and one who shuts down comes down to one thing — whether they feel like a collaborator or a prospect. When people feel heard, they share things they’ve never said out loud in a meeting before.
Some of my best and most creative ideas have come directly from customers who were thinking out loud in a discovery conversation. That only happens when someone feels like a collaborator — not a prospect.
When we find the solution, we find it together. It’s as much their win as it is mine.
Discovery isn’t a phase. It’s a philosophy that runs through the entire engagement — from first call to final handoff.
Once the primary discovery session concludes I give myself a week. I comb through everything collected, restate the challenges in the customer’s own words, research what’s needed to mitigate each one, and build out the improvements. Custom architecture drawings. A tailored demonstration outline. And finally the solution summary — written for readability and built for speakability, because the same information has to land in two different ways.
When I come back I bring the full room — technical team, business stakeholders, account executive. Everyone who needs to be aligned is in the same conversation at the same time.
I open with the defined challenges. The solution comes at the end.
I have to keep the suspense going.
That structure does two things: it proves I listened — and it keeps the room engaged until the payoff.
When a customer asks for something a product doesn’t do, most Sales Engineers say no and move on. That’s the easy answer. It’s also the wrong one.
My first response is never no. It’s why.
Why do you need that feature? What are you actually trying to accomplish? What happens to the business if you don’t get that outcome? How critical is it — is it a dealbreaker or is it a preference?
That conversation almost always reveals something important. Half the time the customer doesn’t actually need the specific feature they asked for — they need the result that feature would have delivered. And the result? That’s almost always achievable. It just looks different than what they had in mind.
The other half of the time, nobody in the industry offers what they’re asking for. When that happens I’ll tell them that — honestly, directly, without spin. But I still won’t stop there. Because the question isn’t whether the feature exists. The question is whether there’s a path to the outcome they actually need.
There’s almost always a path.
Before anything else gets built, we document the problem. Not my interpretation of it — yours. Every challenge, every gap, every operational pain point captured in your words, in your language, in the context of your environment.
This document becomes the foundation that everything else is measured against. The architecture has to map back to it. The demonstration has to address it. The solution statement has to answer it. If something in the proposal can’t be traced back to a defined challenge, it doesn’t belong there.
I’ve watched deals fall apart — not because the solution was wrong, but because nobody took the time to clearly define what problem was actually being solved. The customer walked away feeling like they got a product pitch instead of a solution. The trust never got built. And without trust, no one signs anything.
Defining the challenges is how we build that trust. It’s how I prove I was listening. And it’s how you walk into the final presentation knowing the solution was built for you — not repurposed from the last customer I talked to.
Custom diagrams built specifically for your environment — not stock graphics pulled from a vendor deck. Every site, every connection, every integration mapped out in detail. Detailed enough that your IT team can build from it. Clear enough that anyone in the room can follow it.Custom diagrams built specifically for your environment — not stock graphics pulled from a vendor deck.
Every site. Every connection. Every integration. Every dependency. Mapped out in detail, built from scratch, and designed around the actual architecture of your organization — not a generic reference topology that kind of looks like your environment if you squint at it.
I’ve sat in enough presentations to know what a lazy architecture diagram looks like. It’s the one with the generic cloud bubble in the middle, a few arrows pointing in vague directions, and your company’s logo slapped on the title slide. It tells you nothing about how the solution actually works in your world. It raises more questions than it answers. And it signals something important — that the person presenting it didn’t do the work.
The diagrams I build are different. They’re detailed enough that your IT team can hand them to an engineer and start building. They’re clear enough that a non-technical executive can follow the logic without needing a translator. And they’re specific enough that when someone in the room asks “but how does this connect to our existing infrastructure?” — the answer is already on the page.
A live demo isn’t always possible — and frankly, a demo environment that lives in a vacuum rarely captures the complexity of an enterprise network that doesn’t.
Most demo environments are clean. Controlled. Optimized to make the product look good under ideal conditions. Your environment is none of those things — and that’s not a criticism. That’s just the reality of enterprise infrastructure. It’s been built over years, layered on top of legacy decisions, shaped by budget cycles and organizational politics and integrations that were never supposed to be permanent but somehow became load-bearing. A sanitized lab demo doesn’t speak to any of that.
When a working demonstration isn’t feasible, I go deeper. Detailed architecture drawings, technical specifications, integration documentation, and a frank conversation with your engineering team about exactly how this solution performs in the real world — not a controlled lab, not a best-case scenario, not a feature highlight reel.
The goal isn’t to impress anyone. It’s to give your technical team enough information that they understand the solution completely, can pressure-test it against their environment, and can stand behind it with confidence when the question comes from above. Because if your engineers don’t believe in it, it doesn’t matter what the executives decide. I’ve seen deals collapse at the finish line because the technical team never got comfortable. I don’t let that happen.
This is also where a Proof of Concept or Proof of Value enters the conversation. A POC isn’t something I push — it’s something I offer. There’s a difference.
And when a customer says yes to a POC, it means something. Running a Proof of Concept requires time, internal resources, stakeholder coordination, and organizational energy. Nobody does that for a vendor they’re not serious about. Nobody volunteers that level of effort unless they’ve already started believing. In my experience, a customer who commits to a POC closes more than 80% of the time.
It’s not just a buying signal. It’s practically a handshake.
Every engagement produces two documents. Same solution. Same recommendation. Two completely different conversations.
Because the person who has to implement this solution and the person who has to approve the budget for it are not the same person. They don’t speak the same language. They don’t care about the same things. And handing them both the same document — expecting it to land equally well in both rooms — is one of the most common mistakes I see in this industry.
So I build two versions.
The Technical Version is for your IT team and your engineers — the people who have to actually live with this decision after the contract is signed. It goes deep. Architecture details, integration specifics, data flow diagrams, implementation sequencing, and a clear-eyed picture of what deployment actually looks like in your environment. No glossing over the hard parts. No hiding the complexity. Your technical team deserves the full picture, and they’ll know immediately if they’re not getting it.
The Executive Version is built for the people in the room who are responsible for the outcome — not the implementation. I learned early in my career, the hard way, that senior executives don’t want to sit through a technical deep dive. I had a C-suite leader stop me mid-presentation and tell me directly — come back when you have something I actually need to hear. That conversation changed how I approach every executive engagement.
That’s it. Answer those three questions clearly, confidently, and without jargon — and you give the people signing the check everything they need to make a decision. Bury those answers in technical detail and feature lists and you’ve just made their job harder.
No jargon. No noise. No 47-slide deck that nobody will read past slide six.