How to be a better sales engineer

The job is not the demo#

A lot of people move into sales engineering because they are the person who knows how the product actually works. That is a good start and a bad finish.

The best description I found was from a 2025 research report, The Future Sales Engineer, based on interviews with 38 SE leaders. More than 60% said high performers connect technology to business results. Curiosity was the most selected skill for the future (66%), ahead of business value discovery (53%). Objection handling came near the bottom.

So the question is not "how do I know more about the product". It is "how do I help a buyer decide, with confidence, that this solves their problem". Everything below is a version of that.

Do discovery, and mean it#

The most common mistake is jumping to the answer. A customer says they are worried about protecting their website and the SE starts listing features. One SE director in that report called it a knee-jerk reaction. The better move is to walk it back and ask how long it has been a problem and what it is costing.

A useful checklist for what you should leave a discovery call knowing:

• Pain: what is broken, slow, risky or expensive today.
• Impact: what that costs in money, time or risk.
• Current state: how they cope now.
• Decision process: who evaluates, who approves, who uses it.
• Timing: why now, and what happens if nothing changes.
• Success: what would prove it worked.

Two habits help. First, ask questions that cannot be answered with a yes or no. Gong's advice is to swap "do you use automation?" for "how does your team handle automation today?", and to use openers like "walk me through". Second, repeat the last few words the buyer said back as a question. "We can't switch until next year." "Next year?" Then stop talking.

You do not need to hit a magic number of questions. Gong's 2025 analysis found reps who won deals talked 57% of the time and asked 15 to 16 questions per call. Reps who lost talked 62% of the time and asked about 20. More questions did not help. A better conversation did. Gong's older research on over 500,000 discovery calls found the same pattern: top performers asked questions spread through the call about the buyer's real problems, not a front loaded checklist.

Build the demo around their words#

A demo is not a tour. One demo framework puts it simply: pick the two or three product moments that resolve the buyer's top ranked pains, and cut everything you cannot tie to something they said.

• Open by reading back their problem, in their vocabulary, and ask them to confirm it.
• Show the smallest credible moment of value for each problem. Not every screen.
• Use their world in the environment. "Acme Corp" and "test user" tell the buyer this was not made for them.
• Deliver it in short bursts. Gong found that winning demos had about 21% more back and forth than losing ones, and it did not find a single won deal where the rep pitched for more than 76 seconds without a break. Losing demos had stretches of up to 106 seconds.
• End with a dated next step. "Any questions?" is not one.

Have a fallback for when something breaks: screenshots or a short recording, clearly labelled as such. Do not blame the customer's network and do not pretend the fallback proves the live behaviour.

Run proofs of concept like projects#

This is where many SEs lose weeks. A proof of concept with no agreed finish line is free consulting.

Before anyone builds anything, write down three things:

1. What success looks like, in the buyer's words. Aim for three to five measurable criteria.
2. The timeline, and who does what on both sides, including the data and access the customer provides.
3. What happens when it passes. A specific next step such as procurement or executive sign off, not "we'll evaluate".

Keep it short. Guideflow suggests three to four weeks and treats anything longer as a qualification problem rather than a technical one. If the customer cannot provide data, access or a decision path, that is information. A tightly scoped POC that ends in a clear no is a better outcome than one that drifts for a quarter.

Then close the technical side deliberately. Ask for 20 minutes with their technical lead before commercial terms: "are there any technical blockers to signing?" Pulling those issues forward stops deals stalling in legal because something surfaced late.

Protect trust above everything#

The pull toward closing can make an SE hand wave. A coaching guide from PulseRevOps describes the failure mode as an SE who has drifted into being a second account executive: fluent and vague about business impact, and losing the trust of the buyer's engineers. The deal closes and implementation finds three assumptions that were never true. That costs more than a stalled demo.

Some rules that keep you out of it:

• Never claim a capability you cannot back with documentation or a live test.
• If you do not know, say so. Write down the question, give it an owner, and send the answer by a date you named.
• Keep a library of your security questionnaire and RFP answers. It turns a two week chore into a two day one.
• Tell the buyer when something is a poor fit. It costs you a deal now and earns you the next one.

Read the room too. Early on, with a business buyer, lean commercial. Later, with the platform team, lean technical authority. The skill is noticing which room you are in.

What to do this month#

You do not need a course. Pick a few small habits and repeat them.

• Record and review. Watch one of your own calls every week and count how long you spoke without a pause.
• Shadow better sellers. Eight calls, mixing discovery, demos and technical validation. After each, write down what they did that you would not have thought of, and what you would have blurted out.
• Write a one page POC plan before your next evaluation, even if nobody asks for it.
• Learn the customer's money. How do they make it, and what does the problem cost them? Tie one capability to a number.
• Practise the sentence "I don't know, I'll find out by Thursday". Then do it.

Being a better sales engineer is mostly being the person a buyer is relieved to see on the call: someone who listens, shows only what matters, and does what they said they would. The tooling and the AI assistants will keep changing. That part will not.