Monday, August 24, 2009

The Potential (But Not Necessary) Evolution of Solution-Selling

So by now you probably have figured out that there can be a very fine line between solution-selling and selling solutions and that many people confuse and interchange the two phrases. While sales and marketing people can understand solution-selling (but I’ve always approximated that 1/3 of technology-drive sales people can intuitively understand solution-selling with minimal training, 1/3 with LOTS of training and 1/3 will never get it), there is still confusion over what a solution is.

Defining ‘solution-selling vis-à-vis a ‘solution’ can be a chicken and egg thing so let me start by including this picture that I believe is one viewpoint on how a solution-sell can evolve – but that doesn’t mean it has to in every solution case and/or for every software provider.

For example, many enterprise software companies and system integrators only ‘solution-sell’ and never evolve to the next level. Regardless of the number of installations and customer success stories, these organizations may never ‘publicly package’ an individual success – no matter how many times it is or can be repeated. Every implementation is a custom and potentially ‘one-off’ implementation. This is not to say that behind the scenes, these organizations aren’t using reusable or repeatable code for subsequent like-kind implementations but that is not advertised. The perceived value is strictly domain expertise.

Other software vendors evolve their solution-sale to a Level 2 – that is, they sell the value of domain expertise with emphasis on one or more customer references. These organizations may advertise “speed to implementation” by using reusable or repeatable code while also emphasizing personalization and customization. (Note: Service Oriented Architecture (SOA), Java, .Net Framework are examples of architectures and developer tools that are based on concepts of reusable services and code. Note: I chose links that can explain these terms to the non-technical individual - see other links below for more information.) The solution is typically demonstrable in some form – perhaps even as simple as a reference customer site visit. Many of these types of providers are “boutiques” typically specializing in selected segments or solutions. As with Level 1 providers/integrators, many of these organizations stay at Level 2.

Many enterprise software providers have tried to move to Level 3 with mixed success. The benefit of a ‘solution template’ is that it sends a strong message regarding domain expertise – Wow…this vendor has done this so many times!! . Typically, the template offers anywhere between 60-80% “standardized code” with the ability to customize. There are many reference customers to showcase, collateral, success stories, demonstrable ROI’s and a packaged demonstration and some technical documentation. In many cases, the template is not supported per se because of the amount of customization that is typically done by the customer or a 3rd party developer.

Level 4 solutions are what I call ‘out-of-the-box’ applications that offer extensive documentation, training, upgrades, enhancements, domain expertise, many reference customers, collateral, success stories, on-going support, demonstrable ROI and a packaged demonstration for many different scenarios.

Deliberately evolving from a Level 1 or 2 solution providers to a Level 4 provider means that the initial implementations must keep repeatability, market opportunity and mass appeal in mind when writing initial requirements and code. This means that initial implementations will take longer vis-à-vis a ‘one-off’ implementation, using the first few charter customers as alpha/beta testers. Some providers encourage this by offering special discounts, royalties, special considerations, etc.

Bottom line is that a solution is not necessarily an ‘application’, nor does it ever need to be. What level a provider achieves or maintains can be different than another provider and both strategies can succeed. I have found that some technology is conducive to being ‘packaged’ as a ‘repeat performance’ while other technologies are not.


Some interesting links

http://hoskinator.blogspot.com/2006/06/10-tips-on-writing-reusable-code.html

http://searchsoa.techtarget.com/news/article/0,289142,sid26_gci968206,00.html

http://www.streetdirectory.com/travel_guide/148379/programming/repeatable_code___a_step_up_from_reusable_code.html

No comments: