Proof of concept best practice #5: Demand internal support

May 27, 2014 § 1 Comment

We’ve now reached the final installment of my suggestions to improve your proof of concept experience. As I’ve been pointing out through this entire series, for complex products or services, a POC is a critical milestone on the road to a sale. You don’t arrive at a POC by accident: your prospect thinks enough of your solution to dedicate time and resources to making a decision. Yet just when you think you’re going to win the deal, complacency or sluggishness during the POC will doom the sale.

To increase the likelihood of a sale, POCs should always proceed with a sense of urgency. Naturally, you want your prospect to be energized about moving forward, but you also need support from your colleagues, too. Assistance can come from diverse channels like engineering, customer service, operations, and so on – in fact, everyone in your company should be available to help sales.

Yet far too often, your co-workers may have a lackadaisical approach towards ongoing sales efforts, particularly from those who are not customer facing. Meanwhile, the POC flounders and then fails due to this tranquil attitude, yet the blame always falls on the sales team.

To prevent these disheartening outcomes, don’t be shy about asking for help. In fact, you should be extremely vocal in your demands, as long as the other criteria for the POC have been met:

  1. The POC must always occur in the context of a sale
  2. The POC must have a client-side business and technical sponsor
  3. The POC must have a clearly defined set of goals
  4. The POC must have an agreed-upon timeline

Creating a project plan – just like for a post-sales implementation – is a great way to coordinate all of your colleagues on the POC. It should clearly delineate the roles and responsibilities for everyone on the team, and you should share it with your management. It’s your job to keep it updated and provide frequent progress reports.

Finally, if you see trouble on the horizon due to insufficient internal support, don’t stand idly by and watch it become insurmountable. It’s better to alert people to potential problems and take action than to wait and hope for the best: if you’re not getting what you need, your timeline for demanding help should be measured in minutes or hours, rather than days or weeks.

I’ve worked with quite a few technology companies to help optimize their technical sales processes. If you’d like to learn more, you can email me here.

Proof of concept best practice #4: Always set – and achieve – a schedule

April 21, 2014 § 2 Comments

In 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 POC.

For many vendors, the POC is the last step on the road to a deal. Hopefully, a contract has been placed in front of the customer, finances have been negotiated, and the implementation schedule has been set.

Over the course of my career, I’ve seen many deals derailed by an endless POC. Sometimes this was because of technical challenges or general prospect inefficiencies, but there were also numerous cases of deliberate sabotage and foot-dragging by the prospect’s employees who were likely to be impacted by our solution. Whatever the cause, it’s extremely easy to lose momentum and have the POC stall. And when the higher-ups at the prospect check in, they’ll be dismayed to see that nothing is happening. This plants seeds of doubt in their minds, even if it’s not your fault.

Luckily, there are some pretty straightforward things you can do to keep the POC  – and the sale itself – moving forward on time:

  1. Define and communicate a schedule. Earlier I described how important it is to have a statement of work (SOW) for the POC. The same holds true regarding a schedule. Don’t forget to broadcast the schedule to everyone.
  2. Make your schedule aggressive. Try to overcome your natural tendency to allow plenty of time to complete your tasks. Instead, your goal should be to inject a sense of urgency into the POC process, with an achievable schedule that will require a significant effort from everyone that’s involved: POCs should feel frenetic, never leisurely.
  3. Break a highly complex, lengthy POC into smaller, separate targets. As you achieve each of these milestones, be sure to report on your progress to as wide an audience as possible: don’t let the prospect’s lower-level staff act as gatekeepers – or roadblocks – for your good news.

I’ve worked with quite a few technology companies to help optimize their technical sales processes. If you’d like to learn more, you can email me here.

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

February 3, 2014 § 3 Comments

In 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 as part of an active sale, and that they must have a sponsor at the prospect – on both the business and technical sides.

Now, it’s time to discuss how to increase the chances of your POCs succeeding by setting well-understood, widely communicated goals up front. After all, the sale isn’t going to happen without a POC, and the POC itself is much more likely to ignominiously fail if you neglect to gain agreement on exactly what concepts you’re supposed to be proving!

Don’t lose sight of the fact that the burden of proof for a POC falls squarely on the company trying to make the sale, and that the sales engineer (SE) is usually personally responsible for ensuring a positive outcome. Despite this reality, I’ve seen astonishing numbers of POCs that proceed without a single written sentence that describes what’s supposed to happen. Given that lack of guidance and accountability, is it any wonder that so many of those impromptu engagements end in tears? It’s much wiser to write a proper, comprehensive statement of work (SOW) for the POC – just like you would for a professional services engagement.

At a minimum, the SOW should unmistakably document the POC’s:

  • Goals. Be specific, and cite easily understood concepts like use cases, data or transaction volumes, and availability/service level agreements. Checklists are great for this.
  • Schedule. Time is of the essence in a POC: unlike consultants who eagerly seek ways to boost billable hours, the most talented SEs must be efficiency experts.
  • Responsibilities. A POC is usually a team effort; make sure that everyone’s role is plainly spelled out.
  • Next steps. Since you’re not doing this POC just for fun, there’s no harm in stating that a purchase of your product or service will take place upon successful completion of the POC. And if the client won’t sign off on a SOW that references the expected sale, guess what that means?

I’ve worked with quite a few technology companies to help optimize their technical sales processes. If you’d like to learn more, you can email me here.

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

November 12, 2013 § 2 Comments

In 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 have client-side sponsorship.

I’ve already written about why a POC should only happen when there’s an active sales opportunity. Assuming that there’s indeed a live deal, there are still many ways for things to go off the rails. First, every substantial technology sale I’ve ever been involved in was impacted by client-side politics. After all, any significant new systems, processes, or technologies will affect large numbers of people. Some will be strengthened by the purchase, and others will be weakened. These machinations are often invisible to the sales team, but trust me: there are definite winners and losers, your client’s employees know this, and this impacts how every one of them will behave regarding your POC.

This means that there’s a very good chance that some individuals will be rooting for your POC to fail. Resistance may be passive, such as taking a leisurely three days to respond to your emails and calls, or giving you wrong or incomplete information. You might also encounter active opposition, even to the point of deliberate sabotage of your POC.

Given that every POC is a potential minefield, you need at least two trusted guides to help you get through safely. These sponsors should represent both the technical and business side of your prospect. It’s a huge red flag if your client won’t assign anyone, or if they assign people who don’t seem to have the respect of their colleagues.

Good advocates will help remove barriers to your success. They know the landscape far better than you do, and they can head off the active damage to your POC – often without you even knowing that they were acting as your guardian angel. In particular, a technical benefactor will quickly get you access to the resources you need – which is helpful, since time is of the essence on a POC. And a business champion will be intimately involved in drafting up the rules and goals of the POC.

As a sales engineer, you need to speak up – to your sales rep – if you determine that your sponsors are weak, disinterested, or not giving you the resources you need, because guess who will get blamed if the POC fails?

If you’re interested in POCs and all things related to sales engineering, check out my posts on the habits of the most effective sales engineers.

Proof of concept best practice #1: No POC without a valid sales opportunity

October 18, 2013 § 3 Comments

Recently, 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 – always, without exception – in the context of an active sale.

I’ve lost track of the number of times I heard about a huge deal that was about to come in, if only we diverted all sales engineering talent to work for 72 hours straight (usually through a weekend, with bonus points for a holiday) to crank out a last-minute POC. In nearly every case, I discovered that my company was being used as “POC fodder” (i.e. leverage against another vendor that was much further along in the sales cycle), or there was something else strange about the opportunity.

Unfortunately, sometimes even the most levelheaded salespeople get excited and fantasize that there’s a deal when the customer is just kicking tires, comparison-shopping, or finding an excuse to continually evaluate technology without making a decision. I won’t name names, but I personally witnessed one firm – a major credit bureau – spend 8+ years evaluating Web service infrastructure offerings without ever buying anything. They went to conferences all around the world and ran their vendors ragged on custom demos, POCs, and other free work without ever spending a dime on software.

To prevent these time-wasting wild goose chases, remember that no POC should ever be done without an active sales opportunity underway. Look for an RFP or other documentation that describes a well-planned purchasing process. If the prospect starts getting cagey, changing the subject, or otherwise trying to avoid the question, there’s no deal there.

In fact, you actually strengthen your position by – politely – walking away from abnormal POCs. Prospects are notorious for trying to squeeze free research out of vendors, particularly hungry startups that are desperately trying to win a deal at a large customer.

If you’re interested in POCs and all things related to sales engineering, check out my posts on the habits of the most effective sales engineers.

Five fundamental proof-of-concept guidelines

July 31, 2013 § 5 Comments

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.

Don’t proof-of-concept past the close

December 18, 2011 Comments Off on Don’t proof-of-concept past the close

“Don’t sell past the close” is a time-tested chestnut of sales wisdom. It refers to the reasonable recommendation that once you’ve attained agreement from your prospect that they’d like to buy, it’s time to stop selling – even if you have other good stuff to tell them about your product or service. Instead, the moment has arrived for them to “sign on the line that is dotted”.

As someone who has led sales engineering teams for many years, I’m here to tell you that this guideline makes sense when it comes to the proof-of-concept (POC), too. Unfortunately, I’ve seen many situations where this rule gets violated, and the outcome is usually unpleasant for everyone involved.

For example, several years ago I was assisting on a grueling POC. The client had given us a series of seemingly insurmountable challenges to overcome. But with the help of engineering, lots of caffeine, ruined weekends, and lost sleep we managed to successfully complete the POC. All that remained was the client presentation, which went off without a hitch, much to the apparent delight of our prospect.

At this point, all that was necessary was to ask for the order. But that didn’t take place. Instead, the sales rep asked if the prospect would like to see anything else from the POC. The prospect answered ‘No’. The question was asked again – not once, not twice, but three times. On the third re-try, our prospect mentioned that perhaps his European colleagues – who previously had nothing to do with the buying decision – might enjoy seeing what we had done. In fact, they might even have some ideas of their own. Imagine what happened next.

To help you avoid unhappy endings like these, in a future post I’ll offer some humble suggestions about smoothly transitioning from the POC to the sale.

If you’d like to learn more about technical sales and sales engineering, click here.

Where Am I?

You are currently browsing entries tagged with proof of concept at rdschneider.

%d bloggers like this: