Guest Post: The Cranky Sales Engineer Shares Sales Secrets

Annual planning is nearly over and the Cranky Sales Engineer almost has his quota for the year.  In a tequila inspired fit of account-planning ecstasy, he has decided to share how he and his brethren actually sell products and what product managers can actually do to help.

The Cranky Sales Engineer and the rest of the sales force look for a mystical confluence of three features to make any deal happen:

  • A Technical Problem—Nobody buys anything because its “cool” or “neat” unless they are penniless early adopters.  The rest of the market needs a problem to solve or they aren’t interested.  We need to find a real problem.  Not a “my back bothers me sometimes” problem but a “I’m going to knock my own septic molar out with an ice skate” kind of problem.
  • A Relationship—The Cranky Sales Engineers spends an inordinate amount of time at sporting events, dinners, lunches, and, yes, pub crawls, with customers.  Why?  Because customers will only buy if there is a relationship. Without it, they don’t trust us to actually solve the problem.
  • A Business Proposition—There needs to be a business deal on the table that makes economic sense.  Without it, the problem remains unsolved, and the relationship is just another excuse to go to the ball game.  The business numbers must add up.

The Cranky Sales Engineer is constantly astounded by product managers who manage to be completely irrelvent to this process.  These managers talk about features with no problems.  In fact, that’s all they talk about.  Features they have, features they will have, features they don’t have, and the Cranky SE’s favorite: features that don’t work.

What can you do to help your SE’s sell your product?

  • Tie features to technical problems—You should know what gawd-awful problem you’re solving before you invest in new features.  It’s true, that sometimes the problem being solved is that the customer is tired of five mouse-clicks when there could be three. But that’s a problem if you have to do it 100 times a day.  Show us a technical problem to solve.
  • Make sure the features work—Trust is one of the keys to a sale, and the Cranky Sales Engineer loses trust and credibility every time a feature isn’t fully tested.  Here is a clue to when your sales engineers have lost the customer’s trust: the customer asks, “Don’t you guys test your programs?  Why do I have to do it?”
  • Ask the sales team about pricing—You can screw up pricing two ways.  If you make it too high, we can’t sell the product.  But worse, if you make it too low, we can’t make any money selling the product.  Here’s a thought.  Ask us.  Ask the good account managers and good sales engineers.  The good ones don’t want to sell cheap products, and they especially don’t sell on price.  Make it worth our while.

It’s hard to make all three parts of a deal line up.  Customers have no money.  They are retrenching.  Help us find toothaches and give your sales team the tools to pull the the deals together.

13 comments

  1. Trevor Rotzien

    Your post is painfully true. To help insure against Product Manager delusions of adequacy, I make sure I spend time out in “the field”, shoulder-to-shoulder with the people who bring in the revenue to pay my salary (i.e. Sales and Account Reps), and face-to-face with the people whose pain I am supposed to be helping to alleviate.

  2. Lauren

    If you need to point this out, then you are either:
    a) working in a company where the products organization only reports to R&D.
    b) working in a company where the Product Managers have no effective leadership. or:
    c) both
    I really can’t believe that any PM worth their salt needs to have this stuff explained!!

  3. Paco

    “knock my own septic molar out with an ice skate” <– That’s going to be a new value for “customer priority” in an enhancements database, just above “high” and “very high”. It will become a regularly uttered phrase in product planning meetings – “yeah, but is it ‘septic molar‘ important?”.

  4. Don MacLennan

    This all makes sense. I wish it was always true in practice.

    If I had a frickin nickel for every time an SE came to me for help but without a customer problem to solve, I’d own…well…. something I don’t have yet. Thus making me (or my team) in the business of problem diagnosis. Isn’t that an SE responsibility?

    Seriously, life is easy when the problem statement is clear. Either the product solves it or it doesn’t. Any competent product manager can make the connection between a product and his/her product’s ability to solve it.

    I suspect there’s an ever broader issue at hand. And that is, when a customer appears willing to spend money, the sales force’s product better be the one that’s bought. Without regard for the fit of problem-to-your-solution. Do economic times like these make vendors more desperate and less disciplined in this regard? Is there any point in resisting it as product managers?

  5. Gander

    I will expand upon Don in this. What the CSE is absolutely, 100% true.

    However, as PM’s we (at least I) have about 60 CSE’s world wide, and each one of them has a different opinion on what the Product needs to be (and it is usually what caused them to lose their last order). Thus we are blessed with the wisdom of 60 opinions on what is right, and guess how many of them can be right enough to make it into the product.

    I live in a hardware world, where it takes a fairly long time to alter course (you have to design the changes, then you have to model the impact (usually a FEA modelling exercise), you have to prototype it, you have to check the actual performance (is it on par with the MRD, or do we need to iterate), then we have to ensure that our change doesn’t f*ck up any other aspect of performance (and believe me, it is VERY common for an innocuous change to destroy a finely tuned system), and then we commit to the main product the change. Oh, and by the way, a truck load of SW is usually required to achieve some of this.

    Then you go to the annual sale meeting and tell the CSE’s what is not available, and you get 1 or 2 people cheering, and 58 throwing rotten fruit, since their pet requests got dropped below the cut line.

    The value that falls on me and my team is to make sure that our limited resources are used to address the biggest business problem our customer base has. We are pretty successful, but the enhancements are usually not platform changes that the CSE’s like to see.

    Of course, as a final note, I am displeased that my GM is about to drive e complete platform evolution for a single customer, that will have no applicability beyond this one (small) customer, and will destroy all our other development efforts for the entire year, but hey, we need the $1M in bookings for it…

  6. Ray Salemi

    I once inherited a product that had been almost destroyed by a GM-led product-management-by-latest-deal philosophy. The ultimate insult is that he rarely got the money promised to him for these “features.”

  7. Frank Jensen

    Tie features to technical problems

    It puzzles me why this seem to happen so rarely.

    In interaction design they create user goals, and let the goals define the features. With this approach they often find that fewer features solves the goals better.

    It buffels me that Product managers and other managers underestimate interaction design. They make it so much easier to deside witch features to ignore.

    Why should the PM tell 58 sales engineers to sod off every week, when an interaction designer can show them why their features are irrelevant in the big picture?

    -Frank Jensen, Developer

Post a comment

You may use the following HTML:
<a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>