What do you think?
Rate this book
The Six Habits of Highly Effective Sales Engineers
TECHNICAL SALES ENGINEERS / TECHNICAL PRESALES SUPPORT: In today’s digital economy, software is eating the world, and the companies with the best sales demonstrations are winning the game.
Is a convincing demonstration the only thing that's standing between you and your next customer? Are you ready to make your next demo the best demo of the year? Do you feel that you can do better but don't know how?NEVER AGAIN LOSE A DEAL YOU SHOULD HAVE WON!
Walk into ever demo feeling confident and prepared Include the one critical moment that must be in every demo Hit that home run and know how to set it up Master the art of answering difficult questions Leverage the power of saying NO with easeA BOOK WRITTEN SPECIFICALLY FOR YOU!
Avoid late nights and long sales cycles Accelerate pipeline velocity and close more deals Learn and apply the best practices in the business Know exactly what to say and do before, during and after a demo Achieve the technical win alarming, predictable consistencyThis book addresses the root causes of the most common mistakes made by sales engineers. Add it to your cart NOW to permanently improve your software demos and sales results.
- GenresBusinessTechnology
198 pages, Kindle Edition
Published June 14, 2019
319 people are currently reading
287 people want to read
About the author
Chris White
196 books10 followersLibrarian's note: There is more than one author in the GoodReads database with this name.
Ratings & Reviews
Friends & Following
Create a free account to discover what your friends think of this book!
Community Reviews
Displaying 1 - 12 of 12 reviews
May 8, 2022
The book you want to read to go into presales
With lot of experience the author go into 6 steps, habits, to get it done. And do not get burn in the process. Some key insights: you are there to partner with your sales executive and your objective is to secure the technical win. A good advise to most technical mindsets to change your mental approach.
With lot of experience the author go into 6 steps, habits, to get it done. And do not get burn in the process. Some key insights: you are there to partner with your sales executive and your objective is to secure the technical win. A good advise to most technical mindsets to change your mental approach.
February 27, 2025
# **Summary**
Six Habits of Effective Sales Engineers online course.
The six habits 👇🏻
1. Partner - with sales team
2. Probe - Technical Discovery Call
3. Prépare - demo plan, story and content
4. Practice
5. Perform
6. Perfect
Focus: Technical win, keeping in mind the business win.
The mistakes we can make:
- Focus on us, not the customer
- Focus on product, not the message
- Training instead of technical sales. Get people excited, not expert of the tool.
- Dice too deeply in business pain.
- One size fits all.
- Show unnecessary content and capabilities.
- Overlook little things
## **01. Partner**
Review the customer situation BEFORE scheduling a presentation.
- Who are we talking to?
- What are they trying to accomplish?
- What have they seen before? Do they know us?
- Third-party / consultant involved?
- Timeline? Budget?
Have a technical discovery call.
## **02. Probe**
The Technical Discovery Call’s goal is to understand what to SAY, SHOW and DO. Topics to cover include:
- Goals / objectives
- Motivations
- Burning issues - what’s causing pain? Losing money?
- Success - how to measure?
- Requirements - constraints to work within?
- Capabilities - anything specific they want to see?
- History - with us and other companies?
Remember this is a call to UNDERSTAND and LISTEN, not to SELL.
Understand:
- Do you need to sell the CONCEPT or the PRODUCT?
- Selling against STATUS QUO or a COMPETITOR?
- Are you selling TO or WITH the technical sponsor?
## **03. Prepare**
Difference what you are going to SHOW (*demo content*) and what you are going to say (*demo story*).
Storytelling best practices:
1. **Establish the problem**: what is it? Why is it bad? Identity the symptoms? Empathise.
2. **Give hope**: describe the « utopian solution ». Give a vision. Address symptoms.
3. **Demonstrate the vision**: lead with result. Show the magic. Give a taste of success.
Don’t overrun. Prepare for 50% of the allocated demo time. If they’re keen enough, they will come back.
Focus on customer requirements, not your product.
Demos should follow **the rule of the capital T**: Go broad enough to cover all requirements, but only « ankle deep ». Don’t do a bottom-up demo. Ensure every element of your demo passes the « So what? » test. Would someone care about that?
## **04. Practice**
The objective is to enter the demo with CONFIDENCE.
Click every click of a demo before it happens.
For derailing questions, use the 3-Vs:
1. Verbal answer - if not enough 👇🏻
2. Visual evidence - if not enough 👇🏻
3. Vivid detail - only if it outweighs the risks
If a bug happens:
- DON’T freeze, panic or blame the tool or someone
- DON’T act like nothing happened
- DON’T think aloud, spend too much time trying to solve the problem, or reconfigure / recompile the demo
- DO act surprised, acknowledge the problem, apologize and move on.
- DO explain what happened if you can fix it
- DO take it to your advantage by explaining a strength of the software (e.g. Identity)
## **05. Perform**
While the best product does not always win, the best demo usually does.
**Pre-demo set-up**
**Get agreement upfront**: reiterate your objective for the demo and ask for validation. DO NOT move forward if you don’t get a response. Don’t take silence as a yes.
Use a one-slider « this is what we heard ».
**Know the players**: Know who’s in the room and where the center of the room is (who holds they keys and budget).
Be wary of « uninvited » guests. They have the potential to disrupt the meeting.
Addressing people by their name is powerful.
**In the demo**
**Begin with the end**: when starting a demo, you must show the most compelling capability / screen / aspect of the demo in the first 2 minutes.
Show the magic before explaining how the trick is done! ⭐️
If the first ‘ah-ha’ moment does work, pause. Tease it out to have a response.
**Explain but don’t over-explain**: a demo is not a training. Only explain to a certain degree.
**Don’t think aloud**: Make your demo a story, not an explanation of what’s going in your mind (« I’ll click here then do that … »).
**Don’t assume they understand your terminology**: it confuses people and makes you sound arrogant. Use their language, the one they have used in the discovery call.
**Slow down**: don’t excitedly move your mouse everywhere. Make it look easy.
**A confused mind always says NO**: An impressed but confused audience will say no.
**Know your « Ah-Ha » moments**: Demos should be built around them. Aim for 3 to 5 per demo, with the biggest one in the first 2 to 5 minutes.
Then pause. If it clicks, nice. If it doesn’t, ask and probe. Do not forget ahead.
**Be yourself**: be authentic, be who you are.
**Get the technical win**
**Answering questions**: expect questions. An audience not asking questions is an audience that won’t buy.
Consider what the question is, but also why is the person asking this question.
Acknowledge questions, including naming the person.
Then repeat the question, in your own words.
**Not all questions are equal**: there are questions that make or break the deal. We must able to recognise them.
Matrix: key player / not key. On topic / off topic.
- Q1 (not key / off topic): Dismiss
- Q2 (not key / on topic): Defer or quick answer
- Q3 (key / off topic): Discovery
- Q4 (key / on-topic): Direct Attention
**Don’t be afraid to say ‘I don’t know’**: it builds credibility and rapport.
**And to say ‘no’ without saying ‘no’**: qualify the question first before giving your answer. When we give a definite ‘no’, ensure the question is harmless to the deal + check « is that going to be a problem? »
**Make it conversational**: ask questions but avoid repeating « Does that make sense? » over and over again.
**Add « mini-close »**: see if you can check the box for part of the demo. Be sure to ask them for part of the software, not the entire demo.
## **06. Perfect**
Have a debrief.
Plan for time to build answers to demo elements you couldn’t show or questions you could not answer.
Six Habits of Effective Sales Engineers online course.
The six habits 👇🏻
1. Partner - with sales team
2. Probe - Technical Discovery Call
3. Prépare - demo plan, story and content
4. Practice
5. Perform
6. Perfect
Focus: Technical win, keeping in mind the business win.
The mistakes we can make:
- Focus on us, not the customer
- Focus on product, not the message
- Training instead of technical sales. Get people excited, not expert of the tool.
- Dice too deeply in business pain.
- One size fits all.
- Show unnecessary content and capabilities.
- Overlook little things
## **01. Partner**
Review the customer situation BEFORE scheduling a presentation.
- Who are we talking to?
- What are they trying to accomplish?
- What have they seen before? Do they know us?
- Third-party / consultant involved?
- Timeline? Budget?
Have a technical discovery call.
## **02. Probe**
The Technical Discovery Call’s goal is to understand what to SAY, SHOW and DO. Topics to cover include:
- Goals / objectives
- Motivations
- Burning issues - what’s causing pain? Losing money?
- Success - how to measure?
- Requirements - constraints to work within?
- Capabilities - anything specific they want to see?
- History - with us and other companies?
Remember this is a call to UNDERSTAND and LISTEN, not to SELL.
Understand:
- Do you need to sell the CONCEPT or the PRODUCT?
- Selling against STATUS QUO or a COMPETITOR?
- Are you selling TO or WITH the technical sponsor?
## **03. Prepare**
Difference what you are going to SHOW (*demo content*) and what you are going to say (*demo story*).
Storytelling best practices:
1. **Establish the problem**: what is it? Why is it bad? Identity the symptoms? Empathise.
2. **Give hope**: describe the « utopian solution ». Give a vision. Address symptoms.
3. **Demonstrate the vision**: lead with result. Show the magic. Give a taste of success.
Don’t overrun. Prepare for 50% of the allocated demo time. If they’re keen enough, they will come back.
Focus on customer requirements, not your product.
Demos should follow **the rule of the capital T**: Go broad enough to cover all requirements, but only « ankle deep ». Don’t do a bottom-up demo. Ensure every element of your demo passes the « So what? » test. Would someone care about that?
## **04. Practice**
The objective is to enter the demo with CONFIDENCE.
Click every click of a demo before it happens.
For derailing questions, use the 3-Vs:
1. Verbal answer - if not enough 👇🏻
2. Visual evidence - if not enough 👇🏻
3. Vivid detail - only if it outweighs the risks
If a bug happens:
- DON’T freeze, panic or blame the tool or someone
- DON’T act like nothing happened
- DON’T think aloud, spend too much time trying to solve the problem, or reconfigure / recompile the demo
- DO act surprised, acknowledge the problem, apologize and move on.
- DO explain what happened if you can fix it
- DO take it to your advantage by explaining a strength of the software (e.g. Identity)
## **05. Perform**
While the best product does not always win, the best demo usually does.
**Pre-demo set-up**
**Get agreement upfront**: reiterate your objective for the demo and ask for validation. DO NOT move forward if you don’t get a response. Don’t take silence as a yes.
Use a one-slider « this is what we heard ».
**Know the players**: Know who’s in the room and where the center of the room is (who holds they keys and budget).
Be wary of « uninvited » guests. They have the potential to disrupt the meeting.
Addressing people by their name is powerful.
**In the demo**
**Begin with the end**: when starting a demo, you must show the most compelling capability / screen / aspect of the demo in the first 2 minutes.
Show the magic before explaining how the trick is done! ⭐️
If the first ‘ah-ha’ moment does work, pause. Tease it out to have a response.
**Explain but don’t over-explain**: a demo is not a training. Only explain to a certain degree.
**Don’t think aloud**: Make your demo a story, not an explanation of what’s going in your mind (« I’ll click here then do that … »).
**Don’t assume they understand your terminology**: it confuses people and makes you sound arrogant. Use their language, the one they have used in the discovery call.
**Slow down**: don’t excitedly move your mouse everywhere. Make it look easy.
**A confused mind always says NO**: An impressed but confused audience will say no.
**Know your « Ah-Ha » moments**: Demos should be built around them. Aim for 3 to 5 per demo, with the biggest one in the first 2 to 5 minutes.
Then pause. If it clicks, nice. If it doesn’t, ask and probe. Do not forget ahead.
**Be yourself**: be authentic, be who you are.
**Get the technical win**
**Answering questions**: expect questions. An audience not asking questions is an audience that won’t buy.
Consider what the question is, but also why is the person asking this question.
Acknowledge questions, including naming the person.
Then repeat the question, in your own words.
**Not all questions are equal**: there are questions that make or break the deal. We must able to recognise them.
Matrix: key player / not key. On topic / off topic.
- Q1 (not key / off topic): Dismiss
- Q2 (not key / on topic): Defer or quick answer
- Q3 (key / off topic): Discovery
- Q4 (key / on-topic): Direct Attention
**Don’t be afraid to say ‘I don’t know’**: it builds credibility and rapport.
**And to say ‘no’ without saying ‘no’**: qualify the question first before giving your answer. When we give a definite ‘no’, ensure the question is harmless to the deal + check « is that going to be a problem? »
**Make it conversational**: ask questions but avoid repeating « Does that make sense? » over and over again.
**Add « mini-close »**: see if you can check the box for part of the demo. Be sure to ask them for part of the software, not the entire demo.
## **06. Perfect**
Have a debrief.
Plan for time to build answers to demo elements you couldn’t show or questions you could not answer.
This entire review has been hidden because of spoilers.
February 5, 2025
Six Habits of Effective Sales Engineers online course.
The six habits 👇🏻
1. Partner - with sales team
2. Probe - Technical Discovery Call
3. Prépare - demo plan, story and content
4. Practice
5. Perform
6. Perfect
Focus: Technical win, keeping in mind the business win.
The mistakes we can make:
- Focus on us, not the customer
- Focus on product, not the message
- Training instead of technical sales. Get people excited, not expert of the tool.
- Dice too deeply in business pain.
- One size fits all.
- Show unnecessary content and capabilities.
- Overlook little things
## **01. Partner**
Review the customer situation BEFORE scheduling a presentation.
- Who are we talking to?
- What are they trying to accomplish?
- What have they seen before? Do they know us?
- Third-party / consultant involved?
- Timeline? Budget?
Have a technical discovery call.
## **02. Probe**
The Technical Discovery Call’s goal is to understand what to SAY, SHOW and DO. Topics to cover include:
- Goals / objectives
- Motivations
- Burning issues - what’s causing pain? Losing money?
- Success - how to measure?
- Requirements - constraints to work within?
- Capabilities - anything specific they want to see?
- History - with us and other companies?
Remember this is a call to UNDERSTAND and LISTEN, not to SELL.
Understand:
- Do you need to sell the CONCEPT or the PRODUCT?
- Selling against STATUS QUO or a COMPETITOR?
- Are you selling TO or WITH the technical sponsor?
## **03. Prepare**
Difference what you are going to SHOW (*demo content*) and what you are going to say (*demo story*).
Storytelling best practices:
1. **Establish the problem**: what is it? Why is it bad? Identity the symptoms? Empathise.
2. **Give hope**: describe the « utopian solution ». Give a vision. Address symptoms.
3. **Demonstrate the vision**: lead with result. Show the magic. Give a taste of success.
Don’t overrun. Prepare for 50% of the allocated demo time. If they’re keen enough, they will come back.
Focus on customer requirements, not your product.
Demos should follow **the rule of the capital T**: Go broad enough to cover all requirements, but only « ankle deep ». Don’t do a bottom-up demo. Ensure every element of your demo passes the « So what? » test. Would someone care about that?
## **04. Practice**
The objective is to enter the demo with CONFIDENCE.
Click every click of a demo before it happens.
For derailing questions, use the 3-Vs:
1. Verbal answer - if not enough 👇🏻
2. Visual evidence - if not enough 👇🏻
3. Vivid detail - only if it outweighs the risks
If a bug happens:
- DON’T freeze, panic or blame the tool or someone
- DON’T act like nothing happened
- DON’T think aloud, spend too much time trying to solve the problem, or reconfigure / recompile the demo
- DO act surprised, acknowledge the problem, apologize and move on.
- DO explain what happened if you can fix it
- DO take it to your advantage by explaining a strength of the software (e.g. Identity)
## **05. Perform**
While the best product does not always win, the best demo usually does.
**Pre-demo set-up**
**Get agreement upfront**: reiterate your objective for the demo and ask for validation. DO NOT move forward if you don’t get a response. Don’t take silence as a yes.
Use a one-slider « this is what we heard ».
**Know the players**: Know who’s in the room and where the center of the room is (who holds they keys and budget).
Be wary of « uninvited » guests. They have the potential to disrupt the meeting.
Addressing people by their name is powerful.
**In the demo**
**Begin with the end**: when starting a demo, you must show the most compelling capability / screen / aspect of the demo in the first 2 minutes.
Show the magic before explaining how the trick is done! ⭐️
If the first ‘ah-ha’ moment does work, pause. Tease it out to have a response.
**Explain but don’t over-explain**: a demo is not a training. Only explain to a certain degree.
**Don’t think aloud**: Make your demo a story, not an explanation of what’s going in your mind (« I’ll click here then do that … »).
**Don’t assume they understand your terminology**: it confuses people and makes you sound arrogant. Use their language, the one they have used in the discovery call.
**Slow down**: don’t excitedly move your mouse everywhere. Make it look easy.
**A confused mind always says NO**: An impressed but confused audience will say no.
**Know your « Ah-Ha » moments**: Demos should be built around them. Aim for 3 to 5 per demo, with the biggest one in the first 2 to 5 minutes.
Then pause. If it clicks, nice. If it doesn’t, ask and probe. Do not forget ahead.
**Be yourself**: be authentic, be who you are.
**Get the technical win**
**Answering questions**: expect questions. An audience not asking questions is an audience that won’t buy.
Consider what the question is, but also why is the person asking this question.
Acknowledge questions, including naming the person.
Then repeat the question, in your own words.
**Not all questions are equal**: there are questions that make or break the deal. We must able to recognise them.
Matrix: key player / not key. On topic / off topic.
- Q1 (not key / off topic): Dismiss
- Q2 (not key / on topic): Defer or quick answer
- Q3 (key / off topic): Discovery
- Q4 (key / on-topic): Direct Attention
**Don’t be afraid to say ‘I don’t know’**: it builds credibility and rapport.
**And to say ‘no’ without saying ‘no’**: qualify the question first before giving your answer. When we give a definite ‘no’, ensure the question is harmless to the deal + check « is that going to be a problem? »
**Make it conversational**: ask questions but avoid repeating « Does that make sense? » over and over again.
**Add « mini-close »**: see if you can check the box for part of the demo. Be sure to ask them for part of the software, not the entire demo.
## **06. Perfect**
Have a debrief.
Plan for time to build answers to demo elements you couldn’t show or questions you could not answer.
The six habits 👇🏻
1. Partner - with sales team
2. Probe - Technical Discovery Call
3. Prépare - demo plan, story and content
4. Practice
5. Perform
6. Perfect
Focus: Technical win, keeping in mind the business win.
The mistakes we can make:
- Focus on us, not the customer
- Focus on product, not the message
- Training instead of technical sales. Get people excited, not expert of the tool.
- Dice too deeply in business pain.
- One size fits all.
- Show unnecessary content and capabilities.
- Overlook little things
## **01. Partner**
Review the customer situation BEFORE scheduling a presentation.
- Who are we talking to?
- What are they trying to accomplish?
- What have they seen before? Do they know us?
- Third-party / consultant involved?
- Timeline? Budget?
Have a technical discovery call.
## **02. Probe**
The Technical Discovery Call’s goal is to understand what to SAY, SHOW and DO. Topics to cover include:
- Goals / objectives
- Motivations
- Burning issues - what’s causing pain? Losing money?
- Success - how to measure?
- Requirements - constraints to work within?
- Capabilities - anything specific they want to see?
- History - with us and other companies?
Remember this is a call to UNDERSTAND and LISTEN, not to SELL.
Understand:
- Do you need to sell the CONCEPT or the PRODUCT?
- Selling against STATUS QUO or a COMPETITOR?
- Are you selling TO or WITH the technical sponsor?
## **03. Prepare**
Difference what you are going to SHOW (*demo content*) and what you are going to say (*demo story*).
Storytelling best practices:
1. **Establish the problem**: what is it? Why is it bad? Identity the symptoms? Empathise.
2. **Give hope**: describe the « utopian solution ». Give a vision. Address symptoms.
3. **Demonstrate the vision**: lead with result. Show the magic. Give a taste of success.
Don’t overrun. Prepare for 50% of the allocated demo time. If they’re keen enough, they will come back.
Focus on customer requirements, not your product.
Demos should follow **the rule of the capital T**: Go broad enough to cover all requirements, but only « ankle deep ». Don’t do a bottom-up demo. Ensure every element of your demo passes the « So what? » test. Would someone care about that?
## **04. Practice**
The objective is to enter the demo with CONFIDENCE.
Click every click of a demo before it happens.
For derailing questions, use the 3-Vs:
1. Verbal answer - if not enough 👇🏻
2. Visual evidence - if not enough 👇🏻
3. Vivid detail - only if it outweighs the risks
If a bug happens:
- DON’T freeze, panic or blame the tool or someone
- DON’T act like nothing happened
- DON’T think aloud, spend too much time trying to solve the problem, or reconfigure / recompile the demo
- DO act surprised, acknowledge the problem, apologize and move on.
- DO explain what happened if you can fix it
- DO take it to your advantage by explaining a strength of the software (e.g. Identity)
## **05. Perform**
While the best product does not always win, the best demo usually does.
**Pre-demo set-up**
**Get agreement upfront**: reiterate your objective for the demo and ask for validation. DO NOT move forward if you don’t get a response. Don’t take silence as a yes.
Use a one-slider « this is what we heard ».
**Know the players**: Know who’s in the room and where the center of the room is (who holds they keys and budget).
Be wary of « uninvited » guests. They have the potential to disrupt the meeting.
Addressing people by their name is powerful.
**In the demo**
**Begin with the end**: when starting a demo, you must show the most compelling capability / screen / aspect of the demo in the first 2 minutes.
Show the magic before explaining how the trick is done! ⭐️
If the first ‘ah-ha’ moment does work, pause. Tease it out to have a response.
**Explain but don’t over-explain**: a demo is not a training. Only explain to a certain degree.
**Don’t think aloud**: Make your demo a story, not an explanation of what’s going in your mind (« I’ll click here then do that … »).
**Don’t assume they understand your terminology**: it confuses people and makes you sound arrogant. Use their language, the one they have used in the discovery call.
**Slow down**: don’t excitedly move your mouse everywhere. Make it look easy.
**A confused mind always says NO**: An impressed but confused audience will say no.
**Know your « Ah-Ha » moments**: Demos should be built around them. Aim for 3 to 5 per demo, with the biggest one in the first 2 to 5 minutes.
Then pause. If it clicks, nice. If it doesn’t, ask and probe. Do not forget ahead.
**Be yourself**: be authentic, be who you are.
**Get the technical win**
**Answering questions**: expect questions. An audience not asking questions is an audience that won’t buy.
Consider what the question is, but also why is the person asking this question.
Acknowledge questions, including naming the person.
Then repeat the question, in your own words.
**Not all questions are equal**: there are questions that make or break the deal. We must able to recognise them.
Matrix: key player / not key. On topic / off topic.
- Q1 (not key / off topic): Dismiss
- Q2 (not key / on topic): Defer or quick answer
- Q3 (key / off topic): Discovery
- Q4 (key / on-topic): Direct Attention
**Don’t be afraid to say ‘I don’t know’**: it builds credibility and rapport.
**And to say ‘no’ without saying ‘no’**: qualify the question first before giving your answer. When we give a definite ‘no’, ensure the question is harmless to the deal + check « is that going to be a problem? »
**Make it conversational**: ask questions but avoid repeating « Does that make sense? » over and over again.
**Add « mini-close »**: see if you can check the box for part of the demo. Be sure to ask them for part of the software, not the entire demo.
## **06. Perfect**
Have a debrief.
Plan for time to build answers to demo elements you couldn’t show or questions you could not answer.
November 2, 2023
Dobrze, krótko podsumowane czym jest praca Sales Engineera.
Celem jest zdobycie Technical Win u potencjalnego klienta.
1. PARTNER - Zawsze pracuje się w tandemie z Salesem, i pracuje się W SPRZEDAŻY, co inżynierom (mi) było ciężko przełknąć na początku
2. PROBE - zachęca aby przed każdym większym demo zrobić najpierw discovery call, żeby poznać wymagania i ludzi
3. PREPARE - ważniejsze jest przygotwanie skryptu/historii niz samego demo, inżynierowie lubią dopieszczać w nieskończoność demko, które i tak nigdy nie będzie pokazane. Przygotuj demko z zasadą litery "T" - po powierzchni powinno być szeroko, różne aspekty pokazane, ale głebiej wystarczy tylko jedna gałąź żeby była pełna ścieżka (dokumentacja, bardziej skomplikowane usecasey, dane etc)
4. PRACTICE - trzeba przeklikać przed prezentacją każdy klik który zamierza się zrobić przed klientem, kiedy coś sie schrzani na demie, wez wine na siebie (musiałem coś źle kliknąć) a nie wiń systemu
5. PERFORM - zacznij od przypomnienia o czym jest to demko i poproś o potwierdzenie, kto jest na spotkaniu, kto podejmue decyzje,
znaj imiona, i adresuj pytania/odpowiedzi bezposrednio, żeby ludzie nie przysypiali
Zacznij od końca dema - inżynierowie mają tendencje to pokazywania najpierw jak doszli do czegoś, powinno się uderzyć od razu od efektu finalnego, tego co najwazniejsze a potem ewentualnie tlumaczyc jak. Tak żeby ludzie zapamietali chociaż tą jedną rzecz póki jeszcze mają uwagę.
Demo jest jak sztuczka magiczna - jak najpierw pokażesz magie a potem wytlumaczysz jak to zrobiles wszyscy sie ucieszą i zapamietaja. Jak napierw wytlumaczysz cala inzynierie, a na koncu pokazesz tą nagą już sztuczkę to będzie to bardzo nudne
Nie należy myślec na głos - "teraz kliknę tu, a potem klinę tam", to powinna być historia klienta a nie log klikacza
Rób przerwy, zadawaj pytania czy wszystko jasne
Kiedy ktoś zada pytanie - podziękuj z imienia za pytanie. Powtórz pytanie swoimi słowami
Pytania Na temat / nie na temat
Key player / jakiś chłopek
Chłopek nie na temat - podziekuj z imienia za pytanie, zwróc się do key playera i spytaj sie czy to jest częścia wymagań, bo wcześniej nie wyplyneło, dismiss
Chłopek na temat - podziękuj powiedz ze odpowiedz jest w dalszej częsci demka
Key Player nie na temat - wejdź w tryb discovery, postaraj sie dowiedzieć jak najwiecej o tym wymaganiu
Key Player na temat -porzucasz swój wypieszczony skrypt i lecisz z dokladną odpowiedzią
"Nie wiem" jest spoko odpowiedzią, pokazuje że traktujesz serio słuchaczy
"Tak kwalifikowane", czyli jak powiedzieć "nie" z klasą - poproś najpierw o doprecyzowanie o co dokładnie chodzi, wymyśl jakiś sposób jak to wymaganie może być aktualnie spełnione, nawet jak z leksza naciągane
Raz na demo można powiedzieć "NIE" dla jakiegoś dziwnego wymagania, żeby uwiarygodnić siebie, że nie jest się jadaczką klepiącą tylko "tak, tak"
Mini Close - jeśli demo idzie dobrze, to spróbuj dostać potwierdzenie że ten mały wycinek demka spełnia wymagania, tak aby klient potwierdził słownie że ten fragment wymagań jest zaspokojony, jest to ważne dla całości sprzedaży, żeby dać naboje salesom
6. PERFECT - po skończonym demie, trzeba przejść feedback od salesa i naprawić demo/skrypt, żeby nastepnym razem bylo gotowe na to co poszło nie tak tym razem
Celem jest zdobycie Technical Win u potencjalnego klienta.
1. PARTNER - Zawsze pracuje się w tandemie z Salesem, i pracuje się W SPRZEDAŻY, co inżynierom (mi) było ciężko przełknąć na początku
2. PROBE - zachęca aby przed każdym większym demo zrobić najpierw discovery call, żeby poznać wymagania i ludzi
3. PREPARE - ważniejsze jest przygotwanie skryptu/historii niz samego demo, inżynierowie lubią dopieszczać w nieskończoność demko, które i tak nigdy nie będzie pokazane. Przygotuj demko z zasadą litery "T" - po powierzchni powinno być szeroko, różne aspekty pokazane, ale głebiej wystarczy tylko jedna gałąź żeby była pełna ścieżka (dokumentacja, bardziej skomplikowane usecasey, dane etc)
4. PRACTICE - trzeba przeklikać przed prezentacją każdy klik który zamierza się zrobić przed klientem, kiedy coś sie schrzani na demie, wez wine na siebie (musiałem coś źle kliknąć) a nie wiń systemu
5. PERFORM - zacznij od przypomnienia o czym jest to demko i poproś o potwierdzenie, kto jest na spotkaniu, kto podejmue decyzje,
znaj imiona, i adresuj pytania/odpowiedzi bezposrednio, żeby ludzie nie przysypiali
Zacznij od końca dema - inżynierowie mają tendencje to pokazywania najpierw jak doszli do czegoś, powinno się uderzyć od razu od efektu finalnego, tego co najwazniejsze a potem ewentualnie tlumaczyc jak. Tak żeby ludzie zapamietali chociaż tą jedną rzecz póki jeszcze mają uwagę.
Demo jest jak sztuczka magiczna - jak najpierw pokażesz magie a potem wytlumaczysz jak to zrobiles wszyscy sie ucieszą i zapamietaja. Jak napierw wytlumaczysz cala inzynierie, a na koncu pokazesz tą nagą już sztuczkę to będzie to bardzo nudne
Nie należy myślec na głos - "teraz kliknę tu, a potem klinę tam", to powinna być historia klienta a nie log klikacza
Rób przerwy, zadawaj pytania czy wszystko jasne
Kiedy ktoś zada pytanie - podziękuj z imienia za pytanie. Powtórz pytanie swoimi słowami
Pytania Na temat / nie na temat
Key player / jakiś chłopek
Chłopek nie na temat - podziekuj z imienia za pytanie, zwróc się do key playera i spytaj sie czy to jest częścia wymagań, bo wcześniej nie wyplyneło, dismiss
Chłopek na temat - podziękuj powiedz ze odpowiedz jest w dalszej częsci demka
Key Player nie na temat - wejdź w tryb discovery, postaraj sie dowiedzieć jak najwiecej o tym wymaganiu
Key Player na temat -porzucasz swój wypieszczony skrypt i lecisz z dokladną odpowiedzią
"Nie wiem" jest spoko odpowiedzią, pokazuje że traktujesz serio słuchaczy
"Tak kwalifikowane", czyli jak powiedzieć "nie" z klasą - poproś najpierw o doprecyzowanie o co dokładnie chodzi, wymyśl jakiś sposób jak to wymaganie może być aktualnie spełnione, nawet jak z leksza naciągane
Raz na demo można powiedzieć "NIE" dla jakiegoś dziwnego wymagania, żeby uwiarygodnić siebie, że nie jest się jadaczką klepiącą tylko "tak, tak"
Mini Close - jeśli demo idzie dobrze, to spróbuj dostać potwierdzenie że ten mały wycinek demka spełnia wymagania, tak aby klient potwierdził słownie że ten fragment wymagań jest zaspokojony, jest to ważne dla całości sprzedaży, żeby dać naboje salesom
6. PERFECT - po skończonym demie, trzeba przejść feedback od salesa i naprawić demo/skrypt, żeby nastepnym razem bylo gotowe na to co poszło nie tak tym razem
August 7, 2022
If you just started your path as pre-sales /technical sales engineer (SE) , it is a good book, I think especially if you just came from the engineering/technical only background. For me, who was in the field for some years, it was good because I could grasp some pre-sales common terms and learn how some one just like me, does his/her job. Pre sales science, I mean as a methodology, is new, so someone who took the time to write a book on it deserves kudos. Personally, I dislike this 6 habits, 5 steps, do this to achieve that marketing term. This will not happen on a pre-sales engagement like the book name indirectly implies or I interpret it as. Sales is a volatile space, lots of out of your control variables exists. There is simply no way to have a good statistics on what to do on human interactions. But again, there are good overall tips, like focus on discovery (the most important sales cycle phase). Prepare yourself, on the sense that reflect on what can be done next in a better way. I mean, you will see that as a SE you might get into robot mode like : discovery -> demos -> use case discussions -> solution evidence (like POC) -> sizing -> value/comercial proposition presentation -> deal won or lost. For example, spend some time thinking how you do your discovery better, ask your peers and managers. Also, after a discovery sit down with the topics at hand and do a script of the demo. If you just do a canned demo it might work, but not as effective as structured one where you devoted time to create it based one the customers needs. An awesome phrase from the book: move away from "this is what this feature does" to get closer to "why this feature is important to you". So good overall tips like this is good to have, but you will only see its value after you are in the field trying and error them out. Good luck on you SE journey!
January 28, 2025
I agree with many of these reviews that this book is a great introduction for new SE's or SC's. There certainly were many great reminders for veterans. One thing I would like to see in a new edition would talking about the different approach that is required for scripted demos - meaning demos in which the customer gives you a list of specific demo items they want to see (and oftentimes, the order in which they are to be covered). Many times this stems from a RFP. That's not to say that the 6 habits don't apply in those circumstances, they do, but there are variations that could be explored. I also think it's worth calling out that in a more complex software (ERP systems for instance), 20-30 minutes for a demo (as Chris prescribes as an ideal duration) would never suffice. All in all, a good and informative (and quick) read.
December 17, 2020
Good, but really basic. Definitely best practices, and if someone is trying to understand Sales Engineering as a new career or to transition, then I definitely recommend this. Without these habits, you can't be successful as an SE
July 30, 2023
Good summary and approach to this work. I think it was well structured and clear on the approach. There was engaging content and actionable insights that one can implement straight away. It was an easy read and very helpful
July 20, 2022
Well, I’d say that it got me my current job as Solutions Engineer. So couldn’t be more grateful. Highly recommended for anyone into this kind of role.
September 27, 2024
Interesting book. Nice breakdown of all the habits you need to develop in sales engineering at a high level.
August 12, 2025
For work. Was pretty enjoyable read honestly.
February 18, 2026
Amazing book.
It would be super easy to make a boring book about pre-sales. Besides all knowledge on it, it is an enjoyable experience.
It would be super easy to make a boring book about pre-sales. Besides all knowledge on it, it is an enjoyable experience.
Displaying 1 - 12 of 12 reviews