Glue Products Have An Advantage When Customers Determine Value for a Solution

“Glue products” connect sections of software solutions for customers. At the application layer examples include Tibco, IBM’s MQ Series and more. At the functional level, examples include software systems for training, networking, data collection, and many more. This post will discuss functional glue products.

A brief word on how these products tie together sections of functional solutions may be helpful:
I have current experience working with Microsoft’s SharePoint server product and related training solutions. So I will present what follows specifically on training as a glue product and how I think sales teams should address value with their customers.

SharePoint customers, on-premises, have objectives like “collaboration”, “compliance reporting”, internal communications (intranet), communications with partners (extranet), etc. Without training, personnel may not be able to successfully deliver on any of these objectives. So does the value proposition for the training component depend simply on the training itself, or should the calculation of value be based on how the system chosen for the training requirement optimizes the overall value of the SharePoint solution? Sales teams should help customers understand the most accurate value calculation will be based on the value of the overall SharePoint solution with the training component included as the optimum choice for the job. This tactic enables a favorable pricing discussion for the training component for the sales team while, at the same time, promising the best chance the customer will have to extract the highest possible value from investment in the overall solution.

If sales teams don’t do the work (in other words come up with a description of the solution the customer expects to build with SharePoint, and the expected role for training or one of the other glue solutions I mention above), then the value proposition will likely come down to an “apple vs orange” comparison where one training option is compared to another without any attention to the overall solution. The sales team will likely find itself haggling over price, while the customer struggles to get to the highest possible return on investment in the overall system.

Convincing customers to participate in a value calculation as I have just described depends on trust. So sales teams should also implement supporting tactics capable of elevating the relationship with the customer.

I am often surprised to see how few early stage ISVs marketing functional glue products demonstrate understanding of these tactics. Successful efforts to sell to enterprise software customers almost always include this type of value discussion, calculation and proposition.


How do ISVs incorrectly estimate the value prospects see in products?

ISVs often incorrectly understand the value estimates prospects come up with for product offers. In my experience this wrong understanding leads to decisions to price products below fair market value. These ISVs make related decisions to proceed with a problematic product marketing plan and, too often, fail.

Clayton Christensen’s book “Competing Against Luck: The Story of Innovation and Customer Choice” presents the notion of Jobs Theory for product marketing. Jobs Theory, as I understand it, provides product marketers with a way to conceptualize their products from the perspective of prospects. This transformation of view point is absolutely the first step in framing a useful estimate of the value (if any) target markets may attach to a product. ISVs unfamiliar with jobs theory are hard pressed to wield a tool with comparable power and, therefore, often mistakenly estimate market perception of product value.

Jeff Thull’s book, “The Prime Solution” includes a lengthy section on the importance of value for selling products to large organizations (Mr. Thull is well known for promoting a sales theory, “The Complex Sale” for markets characterized by these same large organizations. From my own professional experience I can confidently endorse the usefulness of his theory).

One example comes to mind as typical of how easy it is to base value estimates on simply the wrong data: Mr. Thull recounts a story about a product sale to one of these large organizations. This business had been losing money for years in one division. The sales team had qualified this division as a reasonable candidate for its software product, but mid level management at the division expressed little interest. Despite losing money, this division was still budgeted for operation. So line management saw no reason to do anything. Their “job to be done” (to use Mr. Christensen’s terminology) was to operate successfully within the budget, regardless of whether or not the parent organization was making money or not.

But when the sales team changed its focus and had some conversations with managers within the parent organization who actually had responsibility over the ongoing losses experienced at the division, they heard a different story. Senior management had a “job to be done”: “we need something to help us stop losing money and start operating this division profitably, once again”. Once the sales team identified a contact in the senior management team, the dialogue could proceed.

I hope readers can see how different prospects at different organizations can come up with widely different estimates of the value of software solutions. Market prospects at different levels in a decision-making process need to be surveyed before estimates of value can be correctly formalized for products.

ISVs otherwise unfamiliar with Mr. Christensen’s “Jobs Theory” and/or Mr. Thull’s Complex Sales methods come to a wrong conclusion, most of the time, on market value for their product offers. Therefore, the “Measure” step in Eric Reiss’ “Build, Measure, Learn” has to be “done right” if useful results are to be had from the effort.