“Just go and show our tool in the best way possible.”I have heard this sentence wayyyy too often coming from a salesperson, and the solution engineer on the receiving end just died a little bit inside.Of course you want to make a good impression when showing your tools to your customer, but more importantly, you want to start building a relationship and engage with them. For that you have to get them to a point where they open up and tell you what they *really* think—and a “no” is a good indicator that this relationship has formed.And we are happy to have a pro in this field as the guest of this episode: Max Lüpertz. Max is a solution engineer who took over as account executive and grew until he led the whole sales organization of the UK for one of the companies he worked for. Now he helps fast-growing SaaS companies close more deals by making their sales demos (and their general presales) better. He provides hands-on coaching and sets up a simple, repeatable demo process with his firm, PreSales Rockstars.In this episode of the podcast, we talk about: Solution engineers are too often treated as “demo monkeys”—pulled in before proper discovery has happened because AEs need to show pipeline progress. There is no solution without a problem: if you don't understand what the customer is trying to solve, any demo you run risks being irrelevant or overwhelming.Once a prospect has seen the functionality and shortlisted vendors, their mindset shifts entirely—from “Can it do this?” to “What happens to me personally if this goes wrong?” Oversharing is one of the most common and costly demo mistakes. Bombarding a prospect with features increases cognitive load, raises perceived risk, and dilutes the message. Max's lesson from an 18-month stalled deal: FOMO caused him to show 50 features when the customer only needed three. The extra complexity made the project feel like a burden, and the prospect concluded they weren't ready. The “shotgun” method—showing everything and hoping something lands—is an AE-driven trap. Effective demos need a curated storyline built around confirmed needs, not a feature parade.Discovery is not a one-time AE activity. SEs need to run a secondary, deeper discovery to uncover the personal risks and motivations of individual stakeholders—not just the organizational problem.How you introduce yourself sets the ceiling on your influence. Being framed as the “technical conscience” boxes you into a narrow role. Instead, position yourself as someone who knows the industry, has seen implementations succeed and fail, and will proactively surface the risks the customer doesn't yet know about—the things they don't know they don't know.SEs act as a “human API” between customers and product management—translating vague feature requests into actionable feedback and pushing back on requests that turn out to be aspirational rather than genuine buying signals. POCs are high-cost investments—often two people for two to four weeks—and should never be offered just because it's “the next step.” Success criteria must be defined upfront, and the SE should use the POC as a “gift and get”.The value conversation must anchor every interaction. If a customer can't explain why they want to model processes beyond “so that we have modeled processes,” they aren't ready to buy. Every conversation needs to come back to outcomes, not features. Max is also on LinkedIn—check out his profile here: https://www.linkedin.com/in/max-luepertz/.Please reach out to us by either sending an email to [email protected] or signing up for our newsletter and reading articles about process and architecture on our Substack… Go and subscribe at whatsyourbaseline.substack.com.And if you like to support “the little podcast that could,” become a Patron at https://www.patreon.com/c/whatsyourbaseline. We appreciate you!

Ask this episode

“What did the council decide on item 42?” — answered with the speaker and the moment.

Transcript

Related