0
0
A few weeks ago I was speaking with a client and the topic of “Buy vs. Build” came up. If you’re not familiar, the phrase refers to whether an organization should “buy” a solution or “build” their own. Its commonly used in the software sector although by no means limited to that context. The reason its so common in the software domain is because many organizations have their own information technology (IT) departments, and the skilled engineers and developers in that department often times claim “We can build that” as they attempt to deliver more value to their employer.
Savvy technology leaders realize that “building” a software application is from only writing lines of code. In addition to writing the code, there’s the need to design it with a lot of consideration on the “User Experience” (UX), Privacy & Security, and ultimately ongoing support and management of the solution for the long-term. Each of these require specific skills and dedicated, ongoing effort that, unless yours is a software development organization, you may not have the necessary skills or processes to do effectively. The ongoing maintenance and support alone can be daunting; some models suggest that for every $1.00 of development cost, ongoing maintenance and support can be upwards of $0.40 (40%) every year thereafter.
So “building” a solution is not for the feint of heart. But that’s not where my client’s and my conversation went.
She made the comment that “You can never really buy a solution in the conventional context of ‘Buy vs. Build,’ and that’s where a lot of organizations struggle.”
I asked her to explain what she meant, and I found her explanation ally insightful in the context of Marketing & Sales, as well Client Success and other things vendors might consider.
She explained that even if they bought an “Off-the-Shelf solution” (OTS) her organization still has to implement it. The purchased software is not in and of itself a “solution to the problem they have.” She simplified it with an example: if they had run out of toilet paper in their washrooms it might seem obvious that they are likely best served to buy more toilet paper. But that doesn’t solve the problem. The toilet paper still needs to make its way to each of the washrooms, and be placed on the empty holders next to each toilet. Furthermore, there should be a process to check the toilet paper on a routine basis to make sure it doesn’t need re-stocking in the washrooms. In other words, there is an “implementation process” that is required, and the vendor of the toilet paper may or may not be able to assist with that.
She went on to explain that the vendor might say “If you give us this order, we will deliver the rolls of toilet paper to each washroom and the supply closets throughout the facility.” On the surface, she explained, this seemed like a great “solution” to the problem. In fact, many readers will recognize this is the essence of the “supply chain.”
But she then went on to say that in order for the vendor to succeed with this offer, each of the vendor’s representatives that will deliver the toilet paper to the facility need to have background checks because of their policy for safety and confidentiality of information. Furthermore, they would each need keys to the supply closets and the toilet-paper holders next to each toilet. Then we would need to organize when they do the deliveries; during the middle of the day when the washrooms are busy, or after hours when things slow down? This is all added work for others in the organization such HR, Security, possibly procurement, and maybe even IT if they expect the vendor to record how many rolls of TP are going into / out of inventory in the “Materials Management” system.
She was highlighting that the solution to a problem is almost never just about the product. The entire process of implementing the product must be considered. This is made even more challenging if the product brings with it new (perhaps innovative) features that, in order to realize their benefits requires the organization to change how it does things; universally known as “change management.”
As we discussed our experiences with successes and failures of this, she then said, “Let me give you a personal example a lot of people can relate to.” She said “If your family decides to go on vacation you have 2 options: contact a travel agent to arrange everything, or go online to a travel site like Expedia or Travelocity and make the arrangements yourself. The travel agent is like ‘buying a solution’ and doing it yourself is like ‘building a solution.’ You might choose to spend your weekend or evenings searching for flights, hotels, excursions, etc. and “building” your own itinerary. The internet and sites like Travelocity or Kayak have certainly simplified that.
Even if you choose to use the travel agent, the travel agent is going to ask a lot of questions like ‘Where do you want to go?’, ‘How many people?’, ‘What kind of accommodations – 5-star resort or camping?’, ‘Any specific activities or excursions you’re interested in?’, etc. So that’s similar to the requirements gathering and interviewing users of a solution to gather their needs.”
She continued “Then the travel agent delivers your tickets and itineraries. But you have to pack. You have to get the cat to your sister to watch while you’re away. You have to get your vaccinations. You have to notify the post-office to stop delivery, and you have to get to the airport for your flight. Even though you ‘bought’ the itinerary, you are still responsible for implementing it. And when you think of ‘Buy vs. Build’ in that way, ‘Buying’ is never as cut-and-dry as it might seem.”
This should be a critical consideration for solution sellers and marketers alike.
While many ‘sellers’ want to focus on the features and benefits of their product or solution, the more successful sellers quickly move past the ‘demo’ and listen to the prospective client as to their readiness, willingness, and ability to implement a solution. This means taking into account everything beyond the product that needs to happen to both purchase the product, and then implement it. This is particularly important when it involves innovative solutions that have the potential to significantly disrupt the client organization – conceptually for the better.
Often times what the client has to go through internally from getting stakeholders around the table to first acknowledge the problem but then consider solutions (i.e. attend a demo), purchasing or procurement process, legal or privacy & security input, finding budget, and ultimately install and train on the solution are what slows down the buying (selling) process. It’s not about the product, but what impact the implementation of the product will have on the organization that is the challenge. All of this needs to be considered vs. “building” the solution.
She closed our discussion on this topic by saying “The vendors we like working with understand this. They realize a demo is easy to do, and understand the product meeting our technical or functional needs is a small part of the solution. Sometimes the vendor we choose may not even have the most advanced product. But their appreciation of, and sensitivity to what it takes to solve our problem, and recognizing how they can help us implement their solution is what makes the difference. This may even mean doing things during our buying process to make it easier on us.”
Have you every wondered why your demo went great and the audience loved the solution, but then things slow down to a snails-pace, or the opportunity simply stalls entirely? Does your sales process involve consideration and collaboration with the client around all of these other things they have to consider beyond your product?
As I routinely tell my vendor clients….”It ain’t about your product.”
