Successful Proving of Concepts

“Hola Jesus”
“Hola cómo vas”
“Su ubicación ha desaparecido”
“¿Cómo cambiar esa configuración?”

That is an excerpt from a Whatsapp conversation I had with one of the drivers while conducting a Proof of Concept (POC) in Quito, Ecuador. I do not speak Spanish, and the conversation could have been interpreted by both the participants differently. That day, I was left at the mercy of Google Translate to communicate with the driver. It was only thanks to his sheer determination that we were able to successfully complete the route. 

I recollect this experience as I try to document a sales engineer’s journey to lead successful Proofs of Concept. As sales engineers, we are tasked with the responsibility of taking Locus from an ensemble of concepts and products to a successful process for our clients. As a company attempting to mold the future of decision-making in supply chain management, an integral part of this attempt is proving that Locus solutions make positive changes on ground. We bear responsibilities not limited to just meeting the agreed metrics but also not impacting our client’s business in any negative manner. 

This is my effort at contriving a mold to increase the probability of success during the proof of concept stage. However, this is not a to-do or checklist of items required to conduct POCs, but a stab at elucidating some broader aspects of this stage through my experiences. 

Stage 1: Pre POC

We, at Locus solutions, are ardent believers of over-preparation. Defining the scope, solution, and account configuration, through simulation exercises forms the crux of this Pre POC stage. However, there is a lot more to it here than the technical setup. This stage marks handing over the baton from Account Executives to the Sales Engineers. Understanding this ownership sets the tone and path for the success of the POC. 

Changing Face of Contact 

As sales engineers, we need to become the primary point of contact from this stage and not burden account executives with handling POC communication. The former should take communication ownership while keeping the latter in the loop. Establishing a close liaison, henceforth, with stakeholders on the client-side will comfort them in acknowledging the credibility of someone who will tell them to change the way they do business. 

Account Preparation

Pre POC stage will involve data-gathering and simulations. Optimization software are data-hungry. From my experience, working with such software can sometimes be overwhelming. As sales engineers, we are responsible for this data gathering and for making the process as undemanding as possible. Simplifying the required data and communicating in client’s terminologies can go a long way in reducing the back and forth efforts and time. 

Metricize or Don’t

During the pre-POC stage, we have to always agree on a bunch of tangible metrics with our clients to measure the success of the POC. This would require establishing baseline metrics and measuring against them. What we miss in many cases are the intangible metrics that are beyond the scope of the problem statement directly. Sales engineers need not quote them but, understanding and realizing these metrics improve the probability. An example would be improving driver experience. While this cannot be measured, I have come across instances where drivers have had to use multiple apps on their phones for every process of delivery of their goods. Logically merging all those different apps into one functional driver’s app like LOTR would directly improve their experience and affect their compliance.  

Stage 2: Proof of Concept

Post preparations, we are now entering the battleground. Pre-COVID allowed us to move around the world, while it is mostly virtual now. I believe that the physical presence of a sales engineer can improve the probability of success because actions, reactions and feedback are immediate compared to emails/Zoom. Physical attendance also helps assess the chemistry between all the stakeholders. However, as Locus proved during these challenging times, virtual POCs can be equally successful with a good feedback loop. With this proven assumption, let me define some more factors. 

Master of the Trade

During my initial years at Locus, while shadowing my colleague at one of the POCs, I was told to understand client operations better than they do. It seemed like overkill then, but I soon realized that this is the one overarching principle that can define the fate of the POC. During POCs, we are making changes to legacy practices and processes. On-ground stakeholders, from drivers to warehouse managers, will be forced to change their habits and follow new processes. By understanding their operations, by becoming Subject Matter Experts (SME), we gain credibility in this change management process and are in a position to command these changes. 

Casting Stakeholder Role

Assigning roles for every stakeholder involved from client to colleagues improve a sales engineer’s tone of communication with them. Identifying a champion stakeholder is just as crucial as identifying decision-makers or naysayers. By identifying and assigning these roles, we would be able to manage expectations and deliverables aptly. Through this process, a sales engineer should also be able to gauge the intent of implementation from the client’s side. When POCs are cost centers, the intent is, more often than not, there. However, in case of complimentary POCs, the intent has to be gauged so as to not waste the efforts of involved stakeholders. 

Mutual Empathy

I once offered a delivery executive to track me while I drive his truck on a given route, to prove that higher efficiency is achievable if he adhered to the suggested delivery manifest. Twenty minutes into the drive, I got a glimpse of their hardships  and understood why they do what they do. I came back with more empathy and was able to present a more realizable solution by the end of the POC. This also reinstated the confidence of the warehouse personnel in our system. They now trusted that we understand their difficulties and that the optimization is able to factor that in. We, as sales engineers, often expect warehouse personnel and drivers to adhere to every process change suggested. We also work with the assumption that we understand our customer requirements, so a change is in their best interest. It is only when we place ourselves in their shoes do we realize the implications of those changes and develop mutual empathy.

Download WhitePaper on How Locus is managing customer-preferred time windows for its clients

Stage 3: Post POC

Control Systems

Establishing a proper feedback loop from relevant stakeholders during the POC is very important. And essential parts of this loop are solutions and actions on feedback. While most feedback can be incorporated during the POC itself, some require post-POC action. Completing this loop even post POC will improve client experience and learning multifold. It also means presenting a holistic report of the engagement. Transparent discussions of blockers and solutions can prove pivotal in the success of POCs at this stage. 

Accepting Failure

Lastly, we are not going to win every battle. Cultural barriers, language barriers, change management, product fit-gap, knowledge gap, solution errors, and many more factors can be deterrents to our success. We must be prepared to accept failure despite investing time, money, and effort. Every failed POC has taught me to take the learnings and move on. 

Conducting a Proof of Concept is an enormous engagement in itself. Every sales engineer’s story of succeeding in it will be different in one way or another and there is no one conducive solution. This is my story from the multiple opportunities I’ve had in my three and a half years at Locus.