A proof of concept is a technical exercise most sales engineers will be involved with at one time or another to help identify the specific performance, security, and other factors such as usability that the customer is trying to establish will work for their use cases.

A POC is essentially a realization of a certain method or idea to demonstrate a solutions feasibility. It’s a demonstration process in principle that is usually a “visual” process for the customer to establish that the solution could work. This section contains my best practices with POCs.

First, when I am performing a proof of concept, the critical thing I do is to discuss with the sales team that the customer has been vetted and has a procurement viability. (Has the customer been vetted financially?)

As a best practice, your organization’s account executives (AEs) should be vetting the proper leads and then following up with appropriate stakeholders to ensure that a POC is a valid and proper exercise for both the customer and the sales organization.

From my experience, it’s a wise decision to question the AE about customer validation to ensure that a POC is in the company’s best interest from technical and business perspectives. It’s one thing to perform a packaged 30-minute demo remotely, but it’s a totally different situation to spend a weekend setting up for a specific use case and two days on-site.

You as an engineer are fully responsible for your time and should want to ensure you’re not “fishing in a dead lake.” . Ensure that all the components, software and even customer knowledge all goes together.

Second, I request the customer and the sales team work directly with me to establish clear “success criteria” for the POC. This can be done via a conference call, for example, before going on-site. The POC must be clearly defined for you as an engineer; you must be able to state the goals and the desired results that are the success criteria.

You can get in your car and drive aimlessly, or you can get in your car and have a destination. It’s your choice to control the POC you’re running, and I suggest you’re clearly identified as the driver.

Lastly, I like to confirm with the sales executive that they have commitment from the customer that if we deliver on the success criteria, we will win the procurement. If the expectation is not set correctly with the customer, then it shows the sales team is weak, and you as an engineer may very well be involved in another exercise in futility.

Generally, you are being asked to perform a POC for a reason. Some of the common reasons to perform a POC are the following:

• To show the customer the functionality of the solution as well as how the solution solves their pain points
• To remove some of the risk of the solutions procurement for your customer
• To leverage the procurement process and establish trust with the potential stakeholders

Enterprise blockchains have different use cases, limitations, and features that as an engineer you need to be aware of. When considering a blockchain POC, it’s important to identify the blockchain architecture as well as the application stack. The application stack is where the complexity can come in. The complexity could involve integration of the end-user applications, commercial APIs, decentralized and open source applications, or even compliance implementations.

For example, Hyperledger Fabric is based on a three-tiered architecture. The tiers of Hyperledger Fabric are the blockchain network, chaincode, and client application. When performing a POC, your role as a sales engineer may very well be to install chaincode. Chaincode can be written in one of three development languages: Go (Golang), Java, and Node.js.