Monday, December 24, 2007

The Best of 2007

Well, we got through another year crammed full of PoCs, Demonstrations, RFPs, RFIs and RFTs, and now there is a short time that we can look back and reflect on the year that was. What better way to do it other than just look back at some of the top articles of the year:

Proof of concept
When to run a PoC is a big questions, closely followed by how to run it successfully.

What does a sales engineer do?
This is a question I often get asked at parties, and it is often tricky to explain it...

Role of a sales engineer
What is the role of an SE in the sales process. Again, pretty deep stuff.

Training for sales engineers
How do you become an SE, and if you are one, how to improve.

How is a good sales engineer compensated
Finally, a recent article expressing how to best incentivize your SEs to ensure they deliver.

This was a pretty big year for me, so there were often gaps between many of the posts, but I'd rather post quality than quantity so unless I have lots of quiet times, expect more of this in 2008!

Happy New Year and Merry Christmas (I don't go in for this Happy Holidays stuff).

Monday, November 26, 2007

How is a good Sales Engineer compensated?

I've been asked a few times in the last month or so, how are SEs compensated. This is a good question, and there are a couple of ways at looking at it.

First of all, what is the best way for the company to compensate their SEs. This is closely related to how a company should pay anyone in Sales. Basically, it should reward people who are able to sell loads of product, and be an incentive for people to work as hard as they can to achieve their goals. From a company perspective, giving away a % value of new business is not as hard as having fixed costs that are not connected to their revenue. Therefore, a company would best focus on making the SE earn a larger fraction of their income from commission. The balancing factor is that companies cannot afford to lose SEs who aren't successful, as they take more time in general to train than Sales reps.

The flip side is from the employee. First of all, the incentive side is good, as it drives your actions towards the right goals. Secondly, the employee needs a good base as well, because the job should provide for the ups and downs of the sales cycle, and the fact that SEs are not fully responsible for the results. So the fixed component should provide for the employee and should be competitive against the other positions they could be holding down.

So most of the time, an SE will end up with a split between 70/30, 75/25 or maybe up to 90/10 of fixed to bonus income. As an employee, you should feel comfortable with whatever level you agree with, make sure it gives you confidence in what you are trying to achieve, and what you need for yourself or your family.

The calculation or structure of the bonus is also an important factor. It could be as simple as a percentage of revenue earned either by the sales team, deals worked on directly, or even how the whole company works. This will depend on what resources the company has to work this kind of thing out in an impartial way. It also depends on whether the SE works closely with particular people in the sales team, or is a general resource shared across a large territory.

As for specifics of the calculation, it is hard to comment here. It depends on the margin of the products or services being sold, how many people get bonuses paid out of it already, whether it is direct/indirect, and whether the company has already established a market, or it is new.

I have worked under various different schemes, and the ones I find best and fairest ensure that the SE and the Sales reps need the same goals (with the same revenue targets) so that they work together as a team. Of course at bonus time, it is also good that all members in the team share in the happiness - but in varying degrees of course.

Things that I don't like for SE bonuses are when there are huge differences in making quota and not - as this is not fully under the control of the SE, it is very disappointing to miss out on a large bonus by a very small amount of revenue not coming in.

Tuesday, September 4, 2007

Changing your Fiscal Year

Just a short post today, but one I wish I had the power to change in my organisation.

It often happens that you are trying to reach someone important in a company in order to close a deal at the end of a quarter, when they are totally unreachable. Have you ever thought that this might be because they are really busy trying to close business themselves. Aaron Ross blogs on his blog, Build a Sales machine about changing your fiscal year to ensure that your deadlines aren't blocked by someone else's. This is especially true if all your customers are sales executives.

Wednesday, August 29, 2007

Statistics for SE Reporting

Although there is much of an art to being a good SE, there are many ways of honing that art. To best do this we need some statistics.

These statistics should focus on how well the SEs are able to win a technical recommendation, and also how many of those recommendations turn into successful deals. You might think that this second one is the job of the commercial people, but the amount of demand the end-users of the tool have for it, will help quicken the process of the prospect becoming a customer.

Another important indicator is the size of those deals. While it is not necessarily easier to win smaller deals, it is the large deals that really matter to a business.

So at the end of every week, every SE in our organisation sends a spreadsheet to our Worldwide SE team leader, who collates the information and presents it to the VP of Sales.

The information in the report shows: Outstanding POC requests, Custom/Special Work Needed, Products to Opportunities, Demo Requests, Past Week Activity (Prospect, $ Size, Activity Type), Next Week Planned Activity (Prospect, $ Size, Activity Type). Then come Win/Loss reports, for every prospect that has moved off from the previous week.

The SE team leader presents to the VP the Number of PoC requests, All special works (Development projects) and the size of those deals, Number of Demos, % Customer time for each SE.

The SE team leader will also see from this reporting (and also by talking with the other SEs) where there is opportunities for SEs to work together to bring in deals easier.

Monday, August 13, 2007

Training for Sales Engineers

Just a brief post today, I am looking for recommendations for effective training to help develop and extend skills for SEs beyond mere technical know-how.

In particular, I am thinking of courses to help the sales/commercial side of the skills required of SEs, and the skills that would help SEs make the transition to full Enterprise Sales positions.

Once I have a few good suggestions, I will post them here of course. Let me know if I need to keep any suggestion anonymous or unpublished.

Wednesday, August 8, 2007

Getting the customer referenced

I was reading dealarchitect today, and his Burning question is a very important one: Is software sold or bought?
An aggressive answer would say that sometimes we do indeed oversell products, or get companies to buy products that they are not in a position to use. Sometimes buyers will go through a long process of testing, proofing, and accepting a product and then it gets shelved until the key people are ready to implement it.

However before this ethics question is decided, one should ask is it the buyer or the seller at fault here? The seller spends a lot of time consulting and presenting, and needs a return on investment or else they would be doing something else.

It can be quite frustrating also for the seller when the buyer does buy something that seems to never get implemented. Although you (usually) don't give the money back, a part of selling requires reference customers who are able to honestly say how they use the product, and promote its use to new customers. If your product becomes shelfware, it will be noticeable to new prospects and can be damaging if word gets around.
On top of that, the business is unlikely to get upsell or continual revenue from that customer, and this is often key for a healthy ongoing revenue figure.

Part of the process of selling, therefore should include the incentive for the customer to use what they buy, and for them to be happy referenced customers.

Friday, July 27, 2007

Reporting for Sales Engineers

A recent visitor raised some new points to discuss here:
As a Manager of SEs, I need certain reports from my team and the complain about the amount of reports they have to write. For example, I need PoC success Rates, Evaluation success rates, SE involvement in wins, etc. What reports to other use? How to enforce the need to account for their work?
Thanks for the questions Kevin, I think we can follow these up with a few posts on each!

In my business SEs are reporting weekly on many statistics to ensure that the right support structure is there for PoCs, and also that the Sales VP is able to manage the demand for resources appropriately. We follow this up with a team meeting to discuss current actions and problems. Also, we have Quarterly reviews on Wins and Losses on all major accounts.

The SE Manager is responsible for compiling this information to present to the VP of Sales along with success rates, and metrics for how much resources are needed in each account to bring it in. Also in the background we need to be aware that there are teams helping by coding small tools, data connectors, prototypes and also documentation to help bring in the business.

The capacity of this manager is highly dependent on how well the SEs respond to these reporting requirements, and this will also indicate whether the manager should or could hold a quota of their own.

Thursday, July 19, 2007

End of the Quarter

Since the salesperson (and normally the SE as well) is motivated by quarterly (or periodical) results, this leads to some frantic behaviour as the period comes to its close.

This comes to a particular head at the end of the year.

The effect of the results ranges from loss of job to enormous bonuses, and therefore people will react to any activity from the customer.

Most sales related staff though are not just led by the lure of the large rewards but also want to have that sense of achieving their goals, and creating business relationships.

I am going to look into a few parts of this end of year period and comment on them in the next few weeks including
  • Achieving that Quota
  • Negotiating the next Goals
  • Good incentive schemes versus bad incentive schemes
  • Team building exercises at Sales Kick Off events
A post that I read recently relating to some of the negatives of being Quarter based is Stop the (end-of-quarter) Madness at

Wednesday, June 27, 2007

Problem: Sales people want the best SE

Selling as a team is a little bit like a relationship. You always want to be sure the person you are selling with complements you, and also is able to make up for your deficiencies.

In fact that is the reason why Sales Engineers are necessary at all, to make up for the deficiency in the Salesperson to know enough technically about the product in order to sell it. The reason why SEs need a Salesperson is equally about the SE's lack of ability in commercial, negotiation and selling skills. There are probably rare cases of people who can do both, but then, if you are a good salesperson, you probably won't want the bother of having to stick around and explain technical details with techies.

So at the end of the day, the Sales staff will try to get the SE who can fill their gaps, and naturally the SE who can fill multiple gaps will be more desireable. So they will be encouraged by the Sales staff to learn all of the company's products, and be an expert in each of them.
Once someone has that aura of success over them, other Salespersons might feel that their deals are not as successful, and that with this SE, they might solve their problems. So they will gradually demand that this successful SE will help them as well. This is good for the SE if they are paid on commission and if they can choose to do the biggest and best deals, but in general, they will be torn in too many directions to make them all work.
Also it means that other SEs will miss opportunities when they are available, and possibly better positioned (either through knowledge or location) to deal with them.

How to solve this problem? Ensure that SEs and Salespeople have well defined pairings or groupings, and that the roles are well understood among the company. Also it is vital that new SEs get the training and attention they need to get up to speed and make their Salespeople successful. Its equally important that the Salespeople don't lose confidence in their SE, and that both sides feel comfortable in the relationship and optimistic in its success.

Thursday, June 21, 2007

Problem: Sales people don't like the SEs

What's there not to like? Actually, quite a lot. Since many salespeople have a 50/50 commission to base ratio or higher, it is quite important for the salesperson to get along with and value the work of the sales engineer. So I guess you have to be a likeable person.

More importantly, as an SE, you need to make the salesperson successful. Its also your commission, but with a ratio of 2:1 or more salespeople to SEs, sometimes you have to make more than 1 salesperson happy. This can also lead to competition for your valuable time, which in turn means you need to spend your time on the things that make you more successful.

This final idea is probably the most important point. If you are able to manage your own time effectively, you should spend most of your time on the things that will make the most money.
That $500,000 deal that you spent 6 months on? Less important than the $100,000 deal that just took a 2 hour demo.

The salesperson who made you do all the work on a doomed project? Less important than the other guy who wins every deal he goes into.

Once you are into making the right balanced decisions on where to spend your time, you will see something leading to my next post... that the Sales person will always want the best SE.

Monday, June 18, 2007

Problem: Sales people cannot get an SE

It might be difficult for an SE to be available every time a salesperson wants them. In fact, the better an SE is, the more salespeople will lean on them, and also prefer them to other less successful SEs in the organisation.

The trick is, as a salesperson, sometimes it is an easy option to just get the techie in to show them the product. However, done too soon, this leads to giving an evaluation before finding that vital power person who could actually buy the product.

So obviously, a good SE skill is to have that power to lean back on the salesperson and get confirmation that the process has been followed up to that point. And then ask, is this necessary.

Although it is nice showing the product around, it doesn't always move the deal forwards, and if you show the wrong things, it can move things backwards!

Focus on PROOF. Prove that the product does what they need. No point in showing irrelevant things, just make sure they believe it works, and that it fits their vision (or redefines) of how they can solve the business problem.

Doing the right Proofs leads to moving the sales process forward, and removing any final doubts over whether this is a solution to the customer's problem.

Beware of people who just want to see the product, or think it is their job to evaluate fully every product under the sun. If you don't have any reason to think the customer could and will buy if the evaluation is succesful, then you shouldn't be in there.

Monday, June 11, 2007

The Role of the Sales Engineer

I was reading a good article on Pragmatic Marketing about The Role of Sales Engineers in sales, and problems that occur in organisations that can't effectively use their SEs, or try using Product Management to fill the gap.

The article points out the main common problems, such as

Problem: Sales people cannot get an SE

Problem: Sales people don't like the SEs

Problem: Sales people want the best SE

and that Salespeople often try to use product management interchangeably with SEs. Product Management however is developing the next version of the product, while SEs are knowledgeable about the current one.

Over the next week, we will look at these three problems and possible solutions for them.

Friday, June 8, 2007

Pricing in a market - Bumps, Rollers and Cheapos

I was reading Seth Godin's blog today, on bumps or price points within a market. I then though about how it affects the Enterprise Software market.

A funny thing that happens is that you come in with what you feel is a reasonable price for a product and you could be out of alignment with other solutions easily by a factor of 10. I.e. Vendor XYZ is selling a tool for $100,000, and finds itself up against Tool ABC at $10,000 and also Enterprise Suite HAL for $1,000,000 or more. And it isn't necessarily the cheapest or best tool that wins.

How can this happen?

Well, software is created in various ways. Engineers write code, designed by overall product architects to achieve business goals.

Cheap Tool
Sometimes, an engineer or a small group of independent people will write a small point solution product and then just release it onto the web. This becomes a low-end solution, when a few companies use these products to fulfil a business need, but in general these products need the customer to do most of the implementation, support and basically fund upgrades themselves. This forms the low end of the market (normally) because this software doesn't have a business that is actively selling it to support.

Mid-Range Tool
Above the low end tools are the mid-range solutions developed by large and small software houses, who support their products and usually actively develop them. They usually can also help customers implement the product, and can also sometimes get into the business of building business process around them.
These tools can be attractive because they are new disruptive technologies, niche players fitting custom needs, solutions accurately tailored to the problem, rather than systems designed to do everything or else just fit a price/benefit point good for the customer.

Rolls Royce
At the top end of the market, you get tools similar to mid-range solutions, but it is usually the Rolls Royce solution of that market. Usually these are long established tools, perhaps owned by Corporations who have acquired the original manufacturer, to own the best of breed solution and even put it into a suite or toolbox of tools.
These products usually have big lead in times for implementation, but the software company or its partners will do the whole implementation, it might even be a hosted solution that sits off site, and even the processes surrounding the product are managed by the vendor. The attractiveness of these tools is that they are well known, referenced, and are overall a safe choice for CIOs.

With this knowledge in place, you see that different kinds of customers will want a tool from a different part of the market. Some companies might not expect their staff to be able to use a command line tool. On the other hand, other companies will not want an extended on-site presence from the vendor.

In the end the Cost of Ownership of the products can be mapped out, and the customer might decide on that basis. Building a framework of infrastructure to get the cheapo tool to achieve the business need might cost much more than the tool.
Midrange tools might require an amount of staffing, but basically do enough to solve the problem.
Rolls Royce solutions might need only minor staffing, but they might have already priced themselves out of it.

Wednesday, June 6, 2007

Another Death by Powerpoint

I was reading David Airey's Creative Design site today and saw this funny video of Don McMillan showing his Life After Death By Powerpoint presentation. He gives great examples of things that shouldn't be in your powerpoint presentations, such as:
  • Including all the text that you speak on the slides
  • Having too much data
  • Spelling Mistakes
  • Death by bullet point
  • Bad Colour Schemes
  • Using the default font - and I'd extend this to default templates and styles - they've all been seen before...
If your presentations look too much like this, get yourself over to Presentation Zen to learn the art of presenting.

Friday, June 1, 2007

What does a Sales Engineer do?

Having searched in many of the wrong places I found an excellent article on Frank Hecker's site, telling the world what a Sales Engineer (SE) does.

Fundamentally, it is the job of the SE to support the sales process, to the point of selling the product, until the customer has paid the money. By that time, a full transition of the account should pass it on to a long-term implementation or support based team, whose job it is to keep the customer happy.

You often hear of customer's complaining that the consultant who got things working disappeared after the customer paid up, but that is basically their job. They are also called Pre sales consultants...

The basic tasks that exist before the sale are:
  • Getting technical requirements from customers
  • Web and Live Product demonstrations
  • Advising customers which products they need for a proposed solution
  • Writing more formal documents such as proposals, and answering RFIs
  • Managing the relationship with the customer at a technical level - including support questions, evaluation requirements, proof of concept, architecture
  • Assisting salespeople with sales strategy for an account
But the SE should work themselves out of the process by the time the product is sold. In my company this is facilitated by the Services Manager getting introduced before the sale, and assisting with the final Statement of Work (SOW) for the implementation. This works well if the Services Manager is aware of the product requirements of the customer at an early stage. Of course it is not good if the SE is the Services Manager...

SEs are also in an excellent place to feed back to the company any customer requirements that are not satisfied by the current product, and see if it is possible to find solutions. Often the ability to think outside the box will be of great assistance.

Thursday, May 31, 2007

Surface computing - how will this help?

Microsoft has just made a major announcement that they are re-inventing the tabletop computer.

Is this a big thing? Is it new? Is it going to change the world?

First of all, what is it?
Basically Surface is a hardware product which allows the user to directly interact with a smart application system on a tabletop directly, without the need to use a keyboard, mouse or other device. The surface also is able to read, sense and interact with devices, cards, and documents placed upon it to perform various tasks.

The first applications of this are going to be in major hotels as a functional kiosk type device, to assist people finding out information. It could do things like plan your day's trip, outings, restaurants and so on, and then send them to your phone's calendar and mapping programs to help you get there.

T-mobile seem to be using it to help sell new phones. In fact the demo seems to imply that you walk into a shop, put a few phones on the surface, and it will compare their features on the screen, and help you decide. Once you decide, put your current phone on the table, and transfer all your details. Then, just put down your credit card and buy the phone.

I guess the other uses are perhaps endless, and perhaps this device can do a lot of things quite smoothly and easily.

What is the Reaction to Surface?
Reading around a bit, I have come across a few ideas from different people.

First of all, it will be aimed at first at enterprise purely from a unit cost point of view. These things will cost around $5-10K, so its obviously not a home use thing. Also you will need to start writing applications to fit your use of the device, since it is such a new thing.

Deal Architect notes that this product is already getting adopted by Harrah's, Starwood Hotels, T-Mobile, and probably others to follow.

However it will take time to see when you are likely to see this product surface in your area...

Saturday, May 26, 2007

Proof of Concept

If everything is going well, and the customer likes the product you are selling, they will probably make you come in and show them that the product does what they want. We usually call this a PoC (Proof of Concept) but it could also be anything from a demonstration to a full pilot of the product in their production system. Ideally you don't go that far!!!

A well-run PoC should have the Sales Engineer contact the customer's technical evaluation team ahead of time, and find out how the product should fit into the customer's system. From this early discussion, a series of steps should be developed that would make up the PoC. As an SE, you should drive the process here to ensure that the tests play to the product's strengths, and shelter any weaknesses you are aware of. If possible, and if acceptable, the PoC should include discussion on the final architecture, and this can even take place of some of those tests.

A colleague of mine recently complained that his customers wanted him to come on site and they would run some tests. They wouldn't tell him ahead of time what they wanted to test, or how they wanted to use the product or any other detail. This is a recipe for disaster. Depending on the customer requirements, your lab can help you prepare for the PoC with custom tools, builds, special reports, or you can even just sit down and work out how to best run all the tests. It is waste of your company's time and resources if you go into a sales situation without being able to prepare for their requirements.

The worst result of doing a PoC, is that it eliminates you from the sale, or you have to go in again to do another, because you weren't able to address the customer's main questions.
The other thing is, if you just have a workshop or planning session with a good demo system, you might be able to avoid doing a PoC altogether.

The other thing is, unless the customer is paying for the software, paying for a report, you should take your software off all their machines as you leave. Unsupported evaluation means that inexperienced users will explore your product and not learn anything about how it is supposed to be used.

Finally, the PoC is a sales tool. It can sometimes be strategic in being the first vendor to do it, and at other times you should refuse to PoC unless the customer prove that the are actually going to buy. You always should be doing the PoC to satisfy the business buyer, not just to show the product to interested technicians. It might be the business buyer's requirement for the technician to like the product, but it might not be as well (especially if the tool eliminates jobs...)

So make sure you plan your PoCs carefully, and only do them if it makes sense to you. A customer asking you to PoC should be sounding interested in your product. Otherwise, they might just be ticking a box to say they checked out X other solutions.

Wednesday, May 23, 2007

Using Visio to architect solutions

Often I have to make up a presentation from scratch. Some of you would argue that this is more of a job for marketing or documentation, but when you have to show a customer a picture of what your product will do for them, you need to be self-sufficient and do it yourself.

Microsoft Visio is often a great tool for doing this kind of stuff. However, if you are like me, and not using it all the time, sometimes you find yourself scratching around for hours getting the right sort of picture going. There are so many different tools and toolsets for getting information in and building diagrams, network maps and other cool stuff, but how do you get them working?

Luckily there are a lot of how-to tutorials online that should get you going quick. The Visio Guy links to some very helpful video tutorials, and in general he is a great resource for finding your way round the program, and programming it to do other interesting things.

I often just build a diagram in Visio and drop it straight into a powerpoint or word document. As they say, a picture tells a thousand words, and looks a damn sight better. A must for any customer response I would say, so I would use them in any of the following situations:
  • Customer Architecture presentation
  • Product Integration Diagram
  • Network Diagram
  • Roles and Responsibilities chart
  • Anything involving an Active Directory or LDAP
  • RFI responses
  • Service Provider model
And I am sure there are many other points of doing a visio presentation as well.

Thursday, May 17, 2007

RFI Time - Answering an RFI

These things sometimes seem to be the bane of my life. A big company or public body decides to buy some big expensive piece of software, so they decide they need to make it a big process for everyone to answer the demand. I usually spend the best part of a week on these documents which can weigh in at 50-100 pages.

An RFI (Request for Information) is a business process (similar to an RFP or and RFT) requesting information from vendors in solving a business problem. All of the vendors will respond, usually in the format of the request for easy comparison to give the company a chance to narrow down the selection process to the tool(s) that they might consider purchasing. Of course, once they have started the process, it doesn't actually mean they need to buy, or even that they only need choose between companies that respond.

What to do with an RFI:
  1. Respond on Time. This is the most important thing to do. If you don't respond on time, you might not be included in the process.
  2. Be Positive. Your job is to represent what you think the product can solve and present it in its best possible light
  3. Conciseness. Do not write a page when a paragraph will do. A short answer says that you know what they want. A long answer tries to answer all sorts of unasked questions.
  4. Pictures, Graphics, etc. A picture tells a thousand words. They also help skip a lot of technical jargon and show basically what the product does.
  5. Be truthful. This document will stick around for the whole sales cycle and beyond, and you will be made accountable for the claims you make.
Remember, the RFI is your 'foot in the door' but won't be enough to sell the solution. You should have plenty of opportunity to do that later.

Wednesday, May 16, 2007

Tools and Books that I aim to review

Over the course of this blog I will try to review all the following tools and books, or at least find good reviews of them already, and link to those.
  • Vmware
  • IBM/Lenovo laptops
  • Windows Vista
  • Office 2007
  • SQL 2005
  • Inside Microsoft SQL Server 2005 series
  • Solution Selling
  • google
But this blog will not be purely on technologies or tools, but will stretch to other details as well, including experiences.

Introducing... the Sales Engineer Guy Blog

Right. Every site needs a first post.

This site will basically help pass on my experiences as a software sales engineer, selling enterprise software products to large organisations, supporting salespeople in my company and channel partners.

I will try to steer clear of things specific to my company and products, and focus on tools, ideas and experiences that are more universal to all sales engineers. Hopefully, over time, I can have other SEs also share their experiences to make this site bigger than just my own ideas.