Proof of Concepts – Good or Bad?

If you were to chart the activities of an SE, the Proof of Concepts (POC) or Proof of Value (POV)  would be at the top of the list (or the big piece of the pie in a pie chart for those of you who are visual).  It is a high effort and high reward activity that can drive a deal to closure.  However, it is also one of the activities that is abused and if not properly implemented can absolutely crush a team.

In order to properly operationalize POCs you must first be clear on the Why you are doing them in the first place and What they are meant to accomplish.  We will review the typical challenges we encounter with them.  Finally, I will provide a framework for implementing a POC program within your company.

Do these Stories Sound Familiar?

We all have horror stories about proof of concepts gone wrong, so lets start out by sharing a few typical scenarios.

Throw crap against the wall and see what sticks

5671542As an SE you have just completed your second or third meeting with the customer.  The Account Exec (AE) gave your corporate overview pitch, asked them their buying time frame and then brought you in to give a demo or two.  At the end of the meeting there is silence until the customer speaks up:

  • The Customer “So what should next steps be”?
  • The always helpful and action oriented AE jumps in and says:
    • “Well why don’t you give us some of your data and we can go ahead and whip up a great dashboard and some reports for you”
    • “Why don’t we go ahead and get you some of our new video conferencing gear from the Demo Depot and we can show it to you in your lab”

So far the meetings have all been one way, you pitching to them.  You haven’t had a chance to ask the customer any questions, you are not entirely clear on what their requirements are, you haven’t had a chance to build a relationship with their technical owner.  After the meeting you try to raise these concerns, but the AE responds “Awww come on, you can do this in your sleep, from the last sales enablement call they said this stuff is super easy!  It is a fast moving deal we have to do it! Our XYZ competitor is doing it we need to play ball!”  You try to push back and say No.  Unfortunately AE’s are trained to overcome objections and they escalate up to sales management who over rule you because “we need this deal and SEs are supposed to do POCs, thats your job!”

Sure, I can whip that up over the weekend!

As SE’s we can get excited about implementing technology too.  A few years ago we had implemented a POC qualification process.  However, SE’s tend not to like process and prefer to just get sh*t done (GSD).  So when faced with the need to prove out our VoIP gear at a Fortune 50 consumer goods company the SE proclaimed they they just needed a few servers and they could whip up the POC over the weekend and be done with it.  They didn’t want to do all the ‘process stuff’, it just gets in the way for easy stuff like this.  Plus, they were willing to go above and beyond and invest their weekend in doing it.


… about 4 weeks later the POC was still not complete.  The customer environment and requirements were more complex than expected.  Our technology was more complicated then expected.  Then we got hit with a curveball.  Our CEO, John Chambers was being scheduled to visit with the customer and the POC had to be up and running flawlessly before he arrived.  Yikes!  We ended up having to pull in SE resources from other regions as well as services resources from paid engagements to finish it in time.

Kicking the Tires, kick it some more, kick it a different way

In 2007 we undertook a POC for a large grocery chain based in New England where we would be proposing wireless IP phones for their stores.  Our primary contact was a technical buyer and we had limited contact with the economic buyer.  Our SE did a great job in implementing the POC and installing the devices at a test store.  Then the customer changed their requirements slightly and wanted more time to re-test and validate. Then the customer changed their requirements slightly and wanted more time to re-test and validate. Then the customer changed their requirements slightly and wanted more time to re-test and validate. Then the…. on and on for 3 years!  The customer themselves were actually bought by another grocery conglomerate before they made a decision to purchase our solution.



What is a POC?

A POC is a realization of a certain method or idea to demonstrate its feasibility, or a demonstration in principle, whose purpose is to verify that some concept or theory has the potential of being used. A proof of concept is usually small and may or may not be complete.

Why do a POC?

The typical reasons for doing a POC are:

  • Show Art of the Possible: seeing is believing.  When you are buying a new car, what sells you more – visiting and looking at pictures and specs or visiting the dealership and taking the car for a test drive?
  • De-Risk Purchase: by proving that the solution will meet their requirements (Scale, Functionality, Use Case).  If you are going to be spending 6 or 7 figures the customer needs to show they did more investigation than reading a data sheet.
  • Internal Selling: provides your customer champion with a concrete product example to use when doing internal selling to their economic buyer, business owner, or other stakeholders.These are important to refer back to as it will guide all


POC Challenges

So why do POC’s go wrong?  The primary reasons I have observed are:

  1. good-and-bad-quotes-5Urgency: AE’s are incentivized to be the advocate for their customer and deal and they are under pressure to deliver revenue to the company and shareholders every quarter.  This is not a bad thing.  However, it does result in the AE viewing every opportunity they have as “fast moving deal” and “everyone else can follow the process but my ear is special, it is an exception, we just got to get this done ASAP – we don’t have time to do the process stuff!”.  In this situation we are saying we don’t have time to spend 2 hours upfront before committing to 20+ hours of labor.
  2. Scope Creep and Success Criteria: as you can see in the definition above, a POC is meant to prove a concept/feasibility, be small, may not be complete. We all know we should limit the scope, so we try to do the right thing and ask the customer for their requirements.  Unfortunately, the customer only knows their desired end state and that is what they describe.  Next thing you know the SE is tasked with trying to build a complete implementation.  Even if you are able to limit the scope/requirements, how do you know that it is successful.  It is amazing to me how many POCs are done and no one can answer a simple question – “How do you know if the POC is successful?”.  Usually all of the focus is on completing and delivering a functional POC and not on a concrete metric of success.  It is the measurable business outcome that matters.
  3. Yet Another Free T-Shirt (YAFT): Would you like a free t-shirt?   Sure, why not. “Mr. Customer would you like a free POC, you don’t need to do any work for it, we will do it all for you.  You will then see how amazing we are.”  What customer wouldn’t say yes?  But now the customer has no compelling event, no urgency, no outcome based plan.
  4. Lack of Customer Involvement: the customer is busy, they don’t have time to sit down with you and go over requirements or help you build it.  You are trying to sell to them after all, why should they invest their resources?   So you forge ahead and try to make something that you *think* they may want.  When you present it and try to show off all the hard work you did they barely pay attention and think it is “nice” or “fine”.
  5. Cost & Effort: At Cisco we had a service called Demo Depot where we could load out hardware and we would be charged back a small fee to our expense budget.  The SE managers had to manage this inventory and trying to track down old gear and get it back was a tedious endeavor.  Furthermore, if you had lots of products in a solution you had to manually order every SKU.  A full Collaboration solution required 176 SKUs to order.  Even at SaaS companies where you don’t have to order/install hardware you often have to manage the trial subscriptions.Labor is a major issue as well.  In FY15Q3 I did an inventory and we had 32 open POCs across 7 SEs.  Assume an average of 20 hours per POC and you can see that there would be a lot of night and weekend work.  However, the real impact of this is that the SEs were no longer available for ‘selling activities’ like customer meetings, pipeline generation, demos etc.

Key Criteria for a Successful POC Program

Creating a POC program is a lot like budgeting or dieting.  You know what you need to do but for various reasons you keep having exceptions and creating consistency is an issue.  You need a way to pay yourself first and make executing this approach automatic and as painless as possible

  • Timing:  a POC should be a part of the late stage in a sales process as a ‘closing move’.  If there is pressure to do one earlier there are other substitute activities you can do such as workshops, the solution design, or non-customized samples.  It should also be after initial discussions on commercials and an agreement to partner. As you can see below in this sales process, the POC is in stage 3 of 4.

Screen Shot 2016-03-29 at 12.55.17 PM

  • Give-Get:
    Would you like a free T-Shirt?  Sure.
    Would you pay $1 for this T-Shirt?  Ummm… no I don’t think so.
    When offering a POC it is important to keep a balanced Give-Get ratio.  If a customer asks for a POC then you can ask for one of these things in return.  The Get doesn’t have to be huge, but it should be more than ‘free’ and demonstrate their skin in the game.

    • An executive alignment meeting between their Business Owner/Economic Buyer and your Head of Sales, CEO, etc.
    • Agreement on the audience to present to, include in the Business Owner/Economic Buyer
    • An exclusive – you will be the only vendor doing the POC
    • Customer Labor and resources to help build it
    • Agreement to purchase by XYZ date
  • Success Criteria & Compelling Event:  Jackson Rose from Financial Force believes the key to POCs is making sure you are set up for success. “Start with clear success criteria, and a commitment from the customer that if you deliver on the success criteria, you’ll be the selected vendor of choice. This is an exercise in clear expectation setting right from the get-go, if you want to reduce overlap with what happens in post-sales, draw the line segmenting what you will do, and what you won’t do and set the appropriate expectations with your prospect, and why.”
  • Define Types: rather than giving the sales team a one size fits all option for a POC, give them a menu to choose from and explain the tradeoffs.  Make it clear what each option offers and what it does not offer and how much effort it requires.  Give each option a name and have it become part of the vernacular.  “Hey, lets just do a Visualization POC for this customer, but for this other customer lets really invest and do a Full Platform POC”.  This lets the SE partner with the AE on investment planning.Screen Shot 2016-03-27 at 8.12.27 AM
  • Inspection and Approvals: You can define a process all you want, but if you don’t inspect and have some checkpoint capability in place then both your AE and SE behavior will not change.  As an SE Leader you don’t necessarily need to be bottleneck and personally approve every POC, but at a minimum you should have a system in place where every POC can be tracked and then reviewed.  I highly recommend having a system in place where a POC cannot be started without this information captured, i.e. you can’t place an order for equipment or get a trial account unless this is captured.  This allows you to do inspection on Success Criteria, Give-Get, timing, etc.For example, for the below customer I would question whether we really have a success criteria established.  What is the ROI we need to show?
    Screen Shot 2016-03-29 at 1.14.59 PM
  • Lightweight Process: whatever process you implement must be lightweight.  Can you automate it? Can you provide a simple checklist or tool?  Can you make it just a 30 minute checkpoint call with yourself?

Each of the actions above are pretty standard and most of us try to do them.  However, there are a few other strategies that I have seen prove useful in the past.


  • Automation: A strategy Jackson Rose suggests is to look for ways to reduce busy work. When they first started doing POCs, it took them 2 days to set up our product in the customer environment. 95% of this work was simply salesforce busy work. We had our most experienced SE work with our development team to develop a script which automated that busy work and completed the work via a script in 30 minutes.At Cisco we did something similar where we packaged all 173 SKUs for gear into a single demo SKU and then built a set of virtual machines that had the software and basic configurations pre-installed.  One thing we had to be careful of was that many of our SEs thought that their way was better and wanted to still custom build everything.
  • teamwork_motivational_poster_wall_artWorkshop:  A new favorite strategy is the “Onsite Technical Workshop”.  Rather than having the next logical step in a sales process be to jump to a POC you can give the AE a different option (remember, doing nothing or saying No is not an option).  A workshop is where the SE (and SE Leader) commits to going onsite to the customer location and is joined by the key business stakeholders. Depending on your product you can ‘pre-build’ some pieces of a POC.
    • You show me your stuff Mr. Customer  (requirements, product, environment)
    • I show you my stuff  (product deep dive, demo how we meet requirements)
    • Lets design/build something together (whiteboard and/or start POC build)

    The benefits of this approach are that it requires the customer to give you access to key stake holders, it requires an investment of time on their end, it is a great forum for them to share their desires with you rather than you pitching them, and it is an opportunity for you to educate them.  We started implementing this approach in Q4 and saw a 75% reduction in POC and were able to do 400% more business.

  • Cobuild POC: technical buyers stake their careers on the technologies they purchase and they often get a technology religion about it.  One of the best ways to overcome this is to educate/train the customer on your solution and make them comfortable with it.  So get out your credit card, order some pizza and beer, and lock the customer and yourself in a room to build the POC.  Not only will you educate the customer, you will also build camaraderie and trust, you can glean additional information about competitors, and build the POC.  The customer will have pride of ownership for what they built and be empowered to share it with others without you there.

Tactics that Sometimes Work

  • Paid POC or don’t do one at allCurt Brown has a good summary of his POC options below.
    1. just close the deal – paid
    2. close the deal with an out (could be positioned as a pilot with contract commitment at the end)- paid
    3. Limited contract (90+ days) – paid by client (covers post sales integration team)
    4. Limited PoC for free (least desirable but sometimes required to win those big logos) I limit my team to a certain amount each quarter to ensure we are validating anything for free. Depending on your level of effort and skill set of the team determines who does the work in a free scenario. If your team has the skills and you limit the free PoC to a level of effort, your team (SC/SE) does the work with proper guidance from PS.

    In my experience paid POCs sound good but require far too much effort with legal, procurement, and requirements review and doesn’t outweigh just the SE doing it.  An alternative to the paid POC is to just do an actual deal but structure it as a very small land deal and structure an expand/opt-in (future blog post on this strategy forthcoming).

Tactics that Often Don’t Work

  • Saying No or Pushing Back: as mentioned above, sales teams are trained to overcome NO.  Instead you must give alternative options (Types of POC, workshops, exec engagement, etc.)
  • Outsourcing POC work: at some point the topic of either creating an offshore team or an inside sales team dedicated to building POCs comes up.  It always sounds promising, “Lets get a lower cost set of technical resources to build these things and let our SEs get back to customer facing activities that they enjoy more”.  Unfortunately the drawbacks I have seen in practice are:
    • Knowledge Transfer: for the outsourced person person to come up to speed and build the POC they need to know the requirements.  That means they either have to attend the customer meetings along with the SE or have the SE try to convey all the information.  When questions come up – do they have to go through the SE or does the outsourced person contact the customer directly?  Finally, when the POC is complete the SE must review all of the work that was done in order to present it.  They may not be familiar with the design tradeoffs the builder made.
    • Lose tech skills: building POCs can be repetitive (if so, automate it) but it is also the primary way for an SE to get his/her hands dirty to learn the product and new features as they come out.  When a technical person stops being hands on the skills will start to atrophy after 6 months.  For example, how many of us still remember calculus and can do it today?
    • Accountability: when an SE knows they own the outcome for a customer they are accountable to going above and beyond and making sure it gets done.  SLA’s aren’t needed, miscommunication isn’t a problem.  The SE owns GSD.
    • Friction: when you outsource the POC work you remove the pain from the SE and provides a path of least resistance.  If the SE has to do the work they are personally incentivized to ensure proper qualification, discovery, and design are done.  With a separate POC team you are creating a tragedy of the commons situation.
  • The exception to this would be if you have a junior person on the same team as the SEs and they are on a career path to being a full SE.  In this case the SE’s skills remain sharp because they are teaching and mentoring the Jr. SE, the Jr. SE is attending the customer calls for exposure, and the Jr. SE reports to the same manager and has accountability.

Whew…. that was a much longer post than expected and I feel like I only scratched the surface.  Kudos to you if you read this far.  This is a topic where I would love ideas to be shared in the comments section.  Also I think Jonathan Michaels at EnerNOC and Matt Norton at Box have created some good collateral and I will see if I can get some to share.

Future Topics may be found in the Welcome to SE Thoughts post.  I think the next post will be on Sales Enablement Approach but if there is a different topic that would be of more interest I would love to hear it.




4 thoughts on “Proof of Concepts – Good or Bad?

  1. Well thought out…I enjoyed the read (what’s that say about me?) and I referenced it to my team as a guide topic for a round table with the team. I try and follow the KISS method when it comes to PoCs Keep It Simple Stupid. The more you have to explain your process or methodology to your sales team the less they understand (or listen)…They want to sell stuff and listening to us SE’s about PoC musings doesn’t get them very excited, until they need one (or more likely, have one thrust upon them)… Thanks for the post!

    Liked by 1 person

    1. So true and I think you nailed it about the simplicity side. Just give the sales rep a simple guide or tool and let them know what to expect.


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s