What's Really Needed for Solution Selling - DevOps for Vendors?

Solution selling has been held at the pinnacle of achievement by IT vendors for a long time. The goal is to become the trusted advisor to the customer and, ideally, so integrated into their strategy & decision making process that sales simply happen as a side effect.

This isn't as easy as to achieve as the corporate bods who run sale training programs would like to think:  a couple of years ago the Harvard Business Review published an article describing how conventional solution selling has reached the end of its usefulness, especially when the "solutions" being applied to customer problems are really just pre-packaged configurations of what products are available "on the truck".

The hardest thing about B2B selling today is that customers don’t need you the way they used to.

 – Brent Adamson, Matthew Dixon and Nicholas Toman in Harvard Business Review (July 2012)  

The thing is, given the Internet and other ready sources of information, many customers no longer need to approach vendors simply to acquire data about products and capabilities. Customers are also naturally suspicious of the "sales" approach, not wanting to be either baffled by (or simply subjected to)  techno-babble or waste valuable time when they perceive that a vendor simply has a quota to meet.

What they do need, whether they know it or not, is someone to help take them on the journey past simple product selection and into design and deployment stages with deeper insight than they can manage themselves. This is clearly evident by the large number of "vendor neutral" consultants that are often found floating around major projects. Of course, the the challenge that these consultants often have is they lack the detailed design & implementation knowledge required to take full advantage of the technologies purchased by the customer, and also don't have access to the back-line support to engineering & product teams for detailed assistance.

This is where vendors can really help the customer by integrating the sales, design and delivery portions of their organisation. With simple feature & product comparisons already done by the customer's online research, the sales team can become more valuable by being really involved with the design process, and helping see this through to implementation (& even beyond).

Sadly, all to often corporate structures aren't set up to cope with this idea: too often there's a strong demarkation between sales and delivery, with only a few very large customers having access to a team of solution designer^[1] and professional services delivery people as part of a vendor relationship. The difficulty is further compounded, even in these cases, by the separation of profit & loss for sales, professional services and education. Of course it's important to measure performance, but in complex sales situations the complete solution is almost always going to be a combination of product, services and training.

What IT vendors need is to have someone (let's call them a solution architect^[2]) to take the customer on the journey from idea to deployment. What I mean by that is to have someone who will listen to (and help document) the customer's requirements, be involved in pitching a solution concept, work on a developed design, and then guide the customer (and perhaps a larger team) through the implementation phase to successful operation.

The Architect - by BoonieT

This may be easier said than done, as it requires a skill set and temperament to see things through from inception to deployment, and may include the need for project management skills if the architect is to lead a team of others, especially if they are from other organisations. The biggest hurdle, though, may be entrenched corporate structures or simply industry culture in the vendor organisation. This is clearly a significant role, yet the prevailing wisdom is that "sales" jobs are more senior/appealing/lucrative than "implementation" roles. Even if senior, technically-competent people exist in an organisation, it is often the case that such folk are seen as being "too valuable" to tie up on on account or one project for a long time: either they need to get on to the next sale, or fight some fire at another customer.

This is where the traditional concept of separating sales and implementation needs to be changed, to be thought of as simply different phases along the same continuum. Perhaps this idea is really a vendor version of devops.

Of course, operations is where the real rubber hits the road, more on that in a later post.

1 - I studied "real" architecture - buildings and suchlike - so the application of the word "architect" to stuff we do in IT often seems wrong to me

2 - This is more like what a "real" architect does, so I'll consent to use the term here