6 Habits of Successful Sales Engineers
An original, practical framework for how great SEs think and work.
- Name and explain the six habits
- Self-assess against each habit
- Pick one habit to practice this month
Matthew Fabian's framework
This is my own framework, built from what consistently separates sales engineers who win and keep customers from those who just answer questions. It is not taken from any published methodology. Each habit has what it looks like in practice, what to stop doing, and a question to ask yourself after every customer interaction.
Habit 1: Discover before you demo
Never show the product until you understand the problem. A demo without discovery is a feature tour; a demo after discovery is proof that you can solve their problem.
- Ask about the incident that started the project, the current process, who is affected and what it costs.
- Walk the site. The door with the propped-open fire exit and the camera pointed at a wall tell you more than any RFP.
- Confirm what success looks like and how it will be measured before you design anything.
Stop: opening every meeting with the corporate deck and a 45-minute demo.
Ask yourself: could I explain this customer's top three problems in their own words?
Habit 2: Translate technology into business outcomes
Customers buy outcomes: fewer incidents, faster investigations, lower cost, compliance, safer staff. H.265, OSDP and unified platforms matter only because of what they make possible.
- Use the chain feature β capability β outcome β metric. Example: doorβcamera association β operator sees video with every forced-door alarm β faster, better-informed response β alarm verification time from minutes to seconds.
- Tailor the message: the security director cares about response and evidence, IT about risk and supportability, finance about total cost and lifecycle.
- Quantify with the customer's own numbers wherever possible.
Stop: reading datasheets aloud.
Ask yourself: did every feature I mentioned connect to something they told me they care about?
Habit 3: Own the technical win
The technical win is the moment the customer's technical evaluators agree your solution will work for them. The SE owns it end to end: design, proof, objections and risks.
- Know the evaluation criteria and who decides; build a plan to prove each criterion.
- Run pilots and proofs of concept with written success criteria, agreed before you start.
- Find and resolve technical risks early (network readiness, code requirements, integration gaps) rather than leaving them for delivery.
- Ensure what is sold can be delivered: involve project and support teams before the design is final.
Stop: treating the technical evaluation as someone else's job or as a checkbox.
Ask yourself: if the deal closed today, would installation go smoothly?
Habit 4: Build trust with honesty
Trust is the SE's most valuable asset and it is built one honest answer at a time. Customers remember the SE who told them what the product could not do, and come back to them.
- Say "I don't know, I'll find out" and then follow up quickly with a real answer.
- Be explicit about limitations, prerequisites and conditions ("this analytic needs X px/m and works poorly in heavy rain").
- Never promise a roadmap feature as if it exists. Never design to win at the expense of the customer's outcome.
- Respect competitors in front of customers; compare on facts.
Stop: stretching "yes" to cover "yes, with a custom integration and a lot of work".
Ask yourself: would I be comfortable if the customer's installer read my notes?
Habit 5: Never stop learning
Physical security now spans IT, networking, cloud, cybersecurity, AI analytics, identity, codes and regulation, and it changes every year (new codecs, new standards editions, new regulations). The best SEs schedule learning like any other commitment.
- Block time weekly for product release notes, standards changes and vendor training and certifications.
- Build and maintain a home or office lab: a controller, a door kit, a few cameras, a VMS.
- Learn the customer's world too: healthcare, education, critical infrastructure, retail each have different drivers.
- Teach others. Writing a training page (like this one) is the fastest way to find gaps in your own understanding.
Stop: relying on what was true three years ago.
Ask yourself: what did I learn this week that I can use in my next meeting?
Habit 6: Partner with sales and document everything
The SE and account manager are one team with one plan. Great SEs make the account team stronger and leave a trail that makes every handoff easy.
- Plan each meeting together: objective, roles, who asks what, and what the next step should be.
- Debrief after every meeting and agree on actions and owners.
- Record discovery notes, requirements, design assumptions, decisions and open risks in the CRM or opportunity folder, not in your head.
- Write a clean handoff to the project team: scope, assumptions, exclusions, site details, contacts.
Stop: surprising your account manager in front of the customer, or keeping the design rationale only in your memory.
Ask yourself: if I were out tomorrow, could someone else pick this opportunity up?
Self-assessment
Score yourself 1 (rarely) to 5 (always) on each habit. Pick the lowest one and choose one specific behaviour to practise for the next month.
| Habit | Evidence you're doing it | Score 1β5 |
|---|---|---|
| 1. Discover before you demo | I can state each active customer's top three problems and success metrics | |
| 2. Translate tech into outcomes | My proposals lead with outcomes and metrics, not feature lists | |
| 3. Own the technical win | Every active evaluation has written success criteria and a risk list | |
| 4. Build trust with honesty | I've told a customer "no" or "not yet" this quarter and kept the relationship | |
| 5. Never stop learning | I spent time on structured learning in the last two weeks | |
| 6. Partner with sales; document | Every opportunity has current notes, design assumptions and a next step |
Check your understanding
1.Explain the feature β capability β outcome β metric chain with a video example.
2.What is the 'technical win' and who owns it?
3.A customer asks for a feature that is on the roadmap but not released. Habit 4 says you shouldβ¦