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 #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.

Where Am I?

You are currently browsing entries tagged with POC at rdschneider.

%d bloggers like this: