Sales Engineers often need to enforce a little order into the chaotic and disorderly world of the sales rep. If we do it without impeding the sales rep’s progress, we are successful. I have worked with many talented sales reps ni my time-some of them truly inspirational and visionary. Others had no idea why they were there, or what they were doing.

I started compiling many of my methodologies (one of which is described in this article) after working with one such visionary sales rep, Godfrey Unaka. I worked as a consultant in Boston in the late 90s, and back then a consultant had to act as Sales Engineer. He inspired me to look at sales as just another process, like a technical process. He gave me the idea for the 5 (6, really) Ds in the first place, and I owe him for that. I haven’t been able to locate him since, but I hope he is successful-wherever he is. Thanks, Godfrey!

Why have methodologies?

They work. Countless times I have gotten the sale with methodologies and a clear-cut plan when a cheaper bid was present. It is true-no matter what your prospect tells you-that quality can win over price. Price is the worst differentiator. If you are in a price battle, then you have failed to illuminate a differentiator that will put you in a different, better class than your competition. This is the stuff of solution, or relationship selling. Some call it enterprise, or strategic sales, but to a Sales Engineer it is all the same.

So lets take a look at my million dollar methodology for getting the big money.

Discover [optional]

If the prospect dos not know what they want, then it needs to be quantified. This first, optional, D is what is sometimes called an assessment. This word, though, has negative connotations in enterprise software sales. Try instead to use “discovery”.

The result of this stage is a deliverable describing:

– The problems existing with existing systems
– The opportunities available for growth, performance, etc.

So basically, we’ll talk about with “pain points” (they have something they don’t want), or opportunities (they want something they don’t have).

Remember, the deliverable here is objective, and has no hint of suggested remedies or solutions. Keep your documents clean and succinct, or you’ll battle profit-margin evaporation later.

Describe

This is the more familiar “requirements” gathering phase that you’re familiar with. This second D is simply the description (without any mention of solution, remedy, etc.) of what they want. In most cases, they already know what they want, but (to their own detriment) they also [think] they know what the solution/fix is.

We know that the prospect is virtually never correct when guessing what it is they need, much less how to implement said fix. Diplomatically working with this fact is the difference between good and great Sales Engineers.

The deliverable here is a Requirements Document which concisely states what the prospect needs. In the early 2000s, we could easily charge for this pre-project phase as a consulting engagement. These days, there is less corporate acceptance of the value of this function.

This step is the most important of all, as it is the one we will use at the end to gauge how well the entire engagement went, and ultimately justify our pay for a job well done. Without clear documentation as to which requirements you are after, you aren’t even likely to get executive sign-off.

I once sold a $5.8M professional services engagement while at Sprint E|Solutions, and the differentiator in the prospect’s eyes was simply that I had presented an organized project plan with my methodologies as a framework. Methodologies instill confidence, and get you the sale-believe it.

Define

We’re talking about producing a specification. We take the Requirements Document from the previous phase and turn it into an actual specification for the solution. If the Requirements Document is too vague, or is not understood and agreed to by the prospect, then it is not ready for this phase.

A Specification Document is one in which details the characteristics of the solution. It does not offer any brands, versions or models. If it does, it is a poorly written specification and should be re-worked until it is clean.

There can be more than one kind of specification, too. In the case of a very large engagement, you might find it easier for the prospect to sign off on if there are a few more selective, focused documents to approve. Examples include:

– Financial Specification: What budgetary constraints exist within which the project must adhere/fall?
– Security Specification: What are the security, access and authentication aspects addressed by the proposed solution?
– Functional Specification: How will the solution work, and interface, with existing systems throughout the implementation phases?
– Operational Specification: What will the user experience be during transition as well as in the final release/product?
– Business Specification: How will the solution impact the strategic objectives of the business?
– Technical Specification: What are the “speeds and feeds” of the solution? These are the metrics by which the solution will be judged, along with the baselines, milestones and goals of each.
– Implementation Specification: In consideration of all of the above, how will the solution need to be implemented so as not to impact the course of daily business and still achieve the desired improvements (or elimination of undesired elements)? See DSOs…

These documents, as with all of the Ds, need to be approved and signed off by the prospect before proceeding. This ensures that they “own” the solution with us. Without the prospect working with you to compile these documents, your efforts are doomed.

Design

Now we’re getting somewhere! With the specification in hand, create a design that includes hours, skill sets, brands, models and versions. This is the real design, and in qualification it is one of the cornerstones: The customer knows, and agrees with, what they are buying. We call this collectively the Design Document.

The design may need to be broken down, as in the above, previous phase, especially if vastly different groups need to sign off on it. Examples of how you can break this Design Document down (whether in chapters or separate documents) include the same basic naming conventions used above. One document that is unique to this phase, or D, is the Implementation Plan (sometimes called the Implementation Document).

If you can’t create a design because the Specifications Document is too elusive or obtuse, or is irrelevant to the problem at hand, the Specification Document needs to be returned for re-writing. As you can now see, each prospect-approved phase/step requires the one before it to be firmly approved and placed. Each builds on the ones that have come before.

Deliver

With Implementation Plan approved and in hand, the engagement begins. Because our Implementation Plan has included all the timelines and milestones, resources and prerequisites, a skilled tem would need little else in order to fulfill the engagement. In fact, this brings up a good point to remember about good documentation:

Each D, or phase, of the engagement must be able to stand on its own, capable of enduring deep scrutiny.

We’ve had our prospect sign off on every step, or D, of our engagement, so they have to be written exceptionally well. Ensure the documents are all in plain english, or at least summarized in a way that allows the buyer to understand what they are buying.

“So we’re done, right?”

Nope. Not yet. So far we’ve had only 5 Ds:

Discover
Describe
Define
Design
Deliver

Remember how I said that the Requirements Document was the most important? Well, the 6th D brings the engagement back full circle to have the customer sign off.

Debrief

How well has the result compared to the Requirements Document? If it has done well, then the customer has no choice but to sign off on it, and acknowledge any scope creep as being either a for-pay/gratis extension of the existing SOW (Statement of Work), or the impetus for a completely new and separate engagement.

Bear in mind that if the engagement is done in phases, each with a set of deliverables, they should be considered a sub-set of the over-arching project, and be signed off by the customer just like any other phase.

So there you have it! A simple methodology that has made me lots of money, and it should be able to help you as well. Use this methodology in a variety of circumstances, as well-not just sales. Can you think of a few?

Deprecated: Function get_magic_quotes_gpc() is deprecated in /homepages/16/d105165054/htdocs/atcp.us/blog/wp-includes/formatting.php on line 4819