Category Archives: Chasm Crossing

Can You Solution Sell without Selling Solutions?

Yes.  And for those who get the distinction, I’d might add, somewhat obviously.

But too many people don’t get it.  Too many folks equate “solution selling” with “selling solutions.”  In fact, they’re quite different.  So, in this post, we’ll try to make the world a better place by explaining the difference between selling solutions and solution selling [1].

What is Solution Selling?

First and foremost, Solution Selling is a book [2].  And it’s a book written by a guy, Michael Bosworth, who, if memory serves, was trying to sell Knowledge Management Software in the 1980s.  Never forget this.  Solution Selling wasn’t written by a guy selling easy-to-sell products in a hot category, such as (at the time) Oracle database or PeopleSoft applications.  Solution Selling was written by a guy trying to sell in a tough category. Look at the subtitle of the book:  “Creating Buyers in Difficult Selling Markets.”

Necessity, as they say, is the mother of invention.

When you’re selling in a hot category [3], this is what you hear from the market.

“Yes, we’re going to buy a business intelligence tool and Gartner tells us it should be one of Cognos, Brio, and you — so you’re going to need explain why we should pick you over the other two.”

Nothing about value.  Nothing about problems.  Nothing about ROI.  We’ve already decided we’re going to buy one and you need to convince us why to buy yours.  [4]

When you’re selling in a cold category, the conversation goes something like this:

“A what?  An XML database system?  Wait, didn’t Gartner call that ‘the market that never was’ about two years ago — why in the world would anyone ever buy one of those.” [5]

In the first case, the sales cycle is all about differentiation.  In the second case, it’s all about value.  In the first case, it’s why buy one from me.  In the second, it’s why buy one at all.

Solution selling is the process of identifying a business problem that the product solves, finding the business owner of that problem, and selling them on the value of solving that problem and your ability to do so.

To use my favorite marketing analogy [6], solution selling is the process of selling the value of a ¼” hole.  Product selling is talking all about the wonderful titanium that’s in the ¼” drill bit.

For example, at MarkLogic we sold the world’s finest XML database system and XQuery processing engine.  In terms of market interest, that plus $3 will get you a tall latte.  That is, no one cared.  You could call up IT people and database architects and database administrators all day and tell them you had the world’s finest XQuery engine and no would care.  They weren’t interested in the category.

Certain businesspeople, however, were quite interested in what you could do with it.

  • If you called the SVP of K-12 Education at Pearson and talked about solving the tricky problem of customizing textbooks to meet many and varied state regulations, you’d get a call back.
  • If you called an intelligence officer at your favorite three-letter agency and talked about gathering, enriching, and querying open source content to build next-generation OSINT systems, you’d get a call back.
  • If you called the SVP of Digital Strategy at McGraw-Hill and talked overall about how the industry needed to separate content from the container in building next-generation products in response to the massive threat to media caused by Google, you’d get a call back.

Simply put, if you called a person about an important problem that they needed to solve, they’d call you back.  Whether they’d buy from you would come down to the extent they believed you can solve the problem based on several factors including a technology assessment, conversations with reference customers for whom you’ve solved the problem before, the cost/benefit associated with the project, and whether they wanted to work with you. [7]

What is Selling Solutions?

Geoffrey Moore refers to an important concept called “whole product” in Crossing the Chasm.  And it’s the idea that you’re not just selling technology platform to your beachhead market, you’re selling the fact that you know how to solve problems with it. Solving those problems might require hundreds of hours of consulting services, integration with complementary third-party software packages, and data integration with existing core systems.

But nobody said the “whole product” had to be packaged up, for example, as a set of templates that you customize that help accelerate the process of solving the problem.  This is the zone of “solutions.”

Many companies, early in their lifecycle for focus reasons or late in their lifecycle to increase the size of a saturating market [8], decide they want to package up a solution after repeatedly solving a problem in a certain area.  This often starts out as leftover consulting-ware and over time can evolve into a set of full-blown applications.

At most software companies, particularly bigger ones, when you start talking about packaged solutions, this is what you mean:  the combination of know-how and leftover intellectual property (IP) from prior engagements not licensed as software product but nevertheless used to both accelerate the time it takes to build the solution and reduce the risk of failure in so doing.

For example, during my time at MarkLogic, we often debated whether and to what extent we should create a packaged custom publishing solution or simply think of custom publishing as a focus area, something that we had a lot of know-how in, and re-use whatever leftover IP we could from prior gigs without glorifying it as a packaged solution.  Because the assignments were so different (publishers used as the the platform to build their products) we never opted to do so.  Had we been selling a business-support application as opposed to do product development platform, we probably would have.

The Difference Between Solution Selling and Selling Solutions

Solution selling is an approach to (and a complete methodology for) the sales process.  Selling solutions means selling packaged, typically application-layer, know-how typically built into a series of templates and frameworks that help accelerate the process of solving a given problem.

They are different ideas.

You can solution sell without a single packaged solution in your product line.  To again answer the question posed by the title of this post:  Yes, you can solution sell without selling solutions.

Solution selling is simply an approach to how you sell your product.  Certainly it can be easier to solution sell when you are selling solutions.  But it is not required and one is not tantamount to the other.

# # #

Notes

[1] In fact, rather perversely, you can sell solutions without solution selling.  If your company built a custom-tailored solution to solve a specific business problem and if you sold it emphasizing the features of the solutions (i.e., “feeds and speeds”) without trying to understand the customer’s specific business problem and its impacts, then you’d be guilty of product-selling a solution.  See end of the post.

[2] Which has largely been replaced by the author’s next book, Customer Centric Selling, but which – like many classics – was better before it was “improved” in my humble opinion.

[3] Which leads to one of my favorite sayings:  “if you have to ask if you’re working in a hot category, you’re not.”  If you were, two things would be different:  first, you’d know and second, you’d be too busy to ask.  QED.

[4] Which results in what I call an “axe battle” sales process, reminiscent of knights in heavy armor swinging axes at each other where each is blow can be thought of as feature.  “We have aggregate awareness, boom.”  “We have dynamic microcubes, boom.”  And so on.

[5] Gartner did, in fact, say precisely this about this XML database market, but that didn’t stop us from building MarkLogic from $0 to an $80M revenue run-rate during my six years there.  It did, however, provide a huge clue that we needed to adopt a solution-selling methodology (and bowling-alley strategy) in so doing.

[6] “Purchasing agents buy ¼” holes, not ¼” bits.”  Theodore Levitt.

[7] Because a startup can only develop this fluency and experience in a small number of solutions, you should cross the chasm by focusing on an initial beachhead and then build out into other markets through adjacencies (aka, bowling alley strategy) as described in Inside the Tornado.  In many ways, the solution selling sales methodology goes hand in hand with these strategy books by Geoffrey Moore.

[8] Geoffrey Moore calls these +1 additions that help grow the market as the once-hot core technology market saturates and you need to switch back to a solution focus if you wish to increase the market size.

Rethinking Crossing the Chasm

Read/WriteWeb had an interesting post a few weeks back entitled “Rethinking Crossing the Chasm.” Those of you who know me know that I’m a fairly devout practitioner of chasm-crossing ideas and that I’m a big believer that they work, particularly in markets where there is no mainstream demand, for either a specific time period or in general.

I’d argue that some markets, however, are born lucky and never have a chasm-crossing phase. For example, we once hired The Chasm Group when I was at Business Objects to help us with a strategic planning session and we spent most of the time arguing with the consultant about whether the model even applied to us. My personal conclusion from the discussion was that business intelligence (BI) never had an in-the-chasm phase.

Why? Perhaps my training in seismology causes me to remember the elastic rebound theory part of the book better than most, but remember that Crossing The Chasm (CTC) was primarily about disruptive infrastructure technology. The idea was that a crack in the bell curve developed because disruptive technologies were, well, disruptive. That therefore caused more normal, mainstream individuals and companies to fear adopting them until they were “safe” (i.e., generally perceived by the herd to be mainstream, safe, and reliable).

That in turn drove the creation of the chasm phase — you’d already sold everyone who wanted whizzy-ness, so after what appeared to be a smooth take-off for a company, you’d find yourself flying into the chasm because all the whizzy-oriented people had already bought precisely one copy of your product and no one in the mainstream would yet dare touch it. CTC theory says the solution to this problem is total focus on a single entry point (one industry, one problem) in order to build a complete solution, attractive to mainstream buyers.

In the sequel, Inside the Tornado, Moore then argued that the single entry point should be treated as the “head pin” (switching metaphors) in a bowling alley and that companies should treat further market development as an exercise in leveraging success off that head pin, by targeting and knocking down adjacent pins (i.e., markets).

But, back to my first point, everyone seems to forget a few basics of CTC theory:

  • The chasm is caused by reluctance of the mainstream to buy
  • The tornado is a release of pent-up demand caused by the chasm (i.e., the elastic rebound theory part)

Simply put, in my opinion:

  • If there is nothing disruptive about the technology
  • Then there is no chasm
  • And there ensues no tornado

My theory explains BI evolution very well. The market experienced neither a stalled, chasm phase, nor a hypergrowth tornado phase. Nor did the BI market naturally coalesce around a single leader early on, instead having several strong leaders even to this day (e.g., Business Objects, Cognos). Because the technology was not disruptive there was less risk, so no chasm.

Because BI technology was more tool than infrastructure, there was no market need to identify one clear leader. No one died if they picked Cognos instead of Business Objects, whereas with a real infrastructure technology, getting the wrong guess on platform (e.g., ASK’s choosing Ingres instead of Oracle) could be fatal. In ASK’s case, it cost them their birthright to transition their leadership in MRP into leadership in ERP. Instead, by betting on the wrong platform, ASK handed that multi-billion dollar prize to SAP, and faded off to obscurity within CA.

While I’m a big fan of Crossing the Chasm theory, I don’t think it applies to every situation. I think it was written to apply to disruptive infrastructure technologies. I think it can generalize to any new technology that involves significant risk to adopt. I think people over-generalize CTC theory to consumer applications and products where no such risks exist.

My other quibble is that the Read/WriteWeb post suggests that early adopters are a homogeneous pool of gadget freaks who are burning out because too much whizzy technology is being thrown at them too quickly. While I do pity the gadget guy in the midst of today’s consumer tech frenzy, I think the assertion misses the bigger point that “early adopters” isn’t a demographic — i.e., it’s not primarily about people, but rather about companies and the situations they find themselves in. Put differently, CTC is largely about industrial (or B2B), not consumer, marketing.

For example, publishers are one of the early adopters of Mark Logic’s XML content server technology. Is that because publishers, as a rule, are generally early technology adopters? No. Is that because the gadget guys in publishing bought MarkLogic to play with it and discovered early uses? No.

It’s because of the situation that publishers find themselves in. It’s not about personalities and gadget orientations. Nor is it about industry norms on the use of technology for competitive advantage.

It is, instead, all about the death of print, the transition to online, Google, free information, and the urgent need to find ways to add value in the fast-changing world around them. Trying circumstances can turn the most staid publisher into an aggressive early adopter of a technology that just might save their business.

Quibbles aside, I’d say the ReadWriteWeb post is definitely worth reading. My single favorite piece of it was this graphic by Tara Hunt. With one picture she nails one of the biggest mistakes that most startups make — so read it carefully. Enjoy!