The End of Solution Sales?

Read a great article today:

http://hbr.org/2012/07/the-end-of-solution-sales/ar/1

The funny thing about this is not the conclusion, which I think I agree with.  It's the assumption that people are actually doing solution selling today.   When I say I think I agree it's because the article is complex and I haven't fully gotten my arms wrapped around the concepts yet.

However, there is an assumption baked into the article that we're all doing solution selling all the time.  The reality s that this is simply not true.  Solution selling is something that most mature technology companies do, but the reality is that maturity level really varies between companies.  This is not a given everywhere.

Here's the deal:  Unless you are investing in your ability to speak the language of your customer, you are not doing solution selling.  When you sell feeds and speeds, you are not doing solution selling.

From the technical side, that means that we architects need to step up to the plate.  Our position as the intersection between business and technology means that we are the point of the spear in helping our engineering teams understand the business and what they require to be successful. 

What I have seen is that most technical organizations simply replace the words "product" or "feature" and replace them with the word "solution."  Thus we get things like the "Exchange Backup Solution."  Naturally, this is nonsense.  When you use terms like this it just makes it obvious that you have missed the entire point of solution selling.  In order to sell a solution, you must be addressing a specific business problem.  You can't just sell the same product in the same way and call it a solution.

For example, you can sell a "E-Mail Retention and E-Discovery Solution."  That is something that a corporate council may need if they anticipate litigation and is a common business requirement that comes from legal and to IT.

The further you are from the actual business, the more difficult this is.  For a product like a SAN, you can legitimately ask if a solutions approach is really appropriate.  After all, you don't really sell SAN's to the business user or sponsor.  A SAN is something that IT buys in order to provide services back to their internal customers, it isn't a customer facing component.

On the other hand, it is those business users who ultimately write the checks.  By being content to sell features to IT, you run the risk of becoming irrelevant.  The cloud is a huge lesson here for technology providers.  Internal IT customers really don't care about all your nifty features or how many IOPS you produce.  They're happy to rent services from the cloud and completely bypass your entire business.  This means that even low level infrastructure companies need to find a way to become relevant to your customer's business users or run the risk of becoming irrelevant.  Don't believe me?  Look at Sun.  Great products, killer engineering.  They pretty much died and Oracle picked up the bones of the company.

There's a great line from "The Right Stuff" that covers this pretty well:

"No bucks, no Buck Rogers."

In our business this means pretty much the same thing.  No bucks, no engineers.  If you are a technical guy and you like eating regularly, you need to think about how your product or service solves problems for your users.  What problem are you trying to solve?  How is your target user's life better than before they bought your product?  Is this so much better that they'd be willing to pay for it?  Do they have any money?  How does funding for your product get approved in your customer?  Who has the power to make that decision?  How does that power role perceive your product?