rdschneider

If you’re selling a sophisticated or costly technical solution, it’s highly likely that your prospect will demand a proof-of-concept (POC) before committing to a purchase. Failing to successfully complete this vital task means that you won’t make the sale. Yet over the course of many years, I’ve seen a surprising number of botched POCs. Sadly, most of these fiascos had less to do with product or service shortcomings, and more to do with the process and people who were involved in the POC.

To help  you deliver better POCs, I’ll be writing a series of blog posts that showcase some best practices. For now, remember these five essential guidelines when you agree to perform a POC:

1. The POC must always occur in the context of a sale. Otherwise, it’s just a costly and time-consuming demo.
2. The POC must have a client-side business and technical sponsor. Otherwise, nothing will come of your hard work.
3. The POC must have a clearly defined set of goals. Otherwise, the client will keep moving the goalposts.
4. The POC must have an agreed-upon timeline. Otherwise, the POC will stretch to infinity.
5. The POC must have internal support from the company that’s trying to make the sale. Otherwise, you won’t get the assistance you’re likely to need.

Tagged: proof of concept, sales engineering, software, technical sponsor

§ 5 Responses to Five fundamental proof-of-concept guidelines

• Proof of concept best practice #1: No POC without a valid sales opportunity | rdschneider says:

  October 18, 2013 at 17:20

  […] I shared some of my observations about guidelines for successfully carrying out proofs-of-concept (POC). In this installment, I want to point out how important it is for the POC to occur – […]

• The 7 habits of highly effective sales engineers | rdschneider says:

  October 18, 2013 at 17:24

  […] Many sales engineers spend a considerable amount of time working on proof of concept (POC) tasks. If you’d like to learn more about this aspect of the job, be sure to check out some of my other blog entries. […]

• Proof of concept best practice #2: The POC must have a client-side business and technical sponsor | rdschneider says:

  November 12, 2013 at 22:43

  […] the introductory post for this series, I present a list of POC suggestions that I’ve learned – too often the hard way. Next up, I describe why it’s so important to […]

• Proof of concept best practice #3: The POC must have a clearly defined set of goals | rdschneider says:

  February 3, 2014 at 12:34

  […] earlier posts in this series, I’ve talked about why proofs-of- concept (POC) are so essential when attempting to get customers to buy a complex product or service, how they must already occur […]

• Proof of concept best practice #4: Always set – and achieve – a schedule | rdschneider says:

  April 21, 2014 at 21:14

  […] this next edition of my ongoing series on proof-of-concept (POC) best practices, I describe how important it is to create and then stick to a schedule for completing the […]