Managing proof of concept and pilot projects

Wednesday afternoon, the last five minutes of a call that has gone well. The manager on the buyer's side offers something generous: let us try it for two weeks with a few users. The rep says yes immediately, because it looks like progress. Six weeks later: two engineers spent thirty hours on setup, three of the five accounts opened logged in twice, nobody wrote down what was being measured, and the buyer ends it in one sentence — honestly, we did not see a difference. The loss is not the deal. That company now carries a recorded opinion that your product was tried and did not work, and it keeps you outside the door for a year.

A proof of concept or pilot, set up properly, is the most persuasive instrument in a sales cycle. Set up badly, it is unpaid consulting. This article covers why a POC and a pilot answer different questions, which requests to decline, what belongs in a pilot charter, how success criteria get written, why narrow scope rescues pilots, who participates, how long to run, what sales does meanwhile, the hidden cost of free pilots, how the decision gets made, and which indicators reveal the health of your program.

PilotcharterSuccess criteriaScopeRolesTimelineExit condition

A POC and a pilot are not the same thing

They ask different questions. A proof of concept answers a technical one: is this possible, will it run on our infrastructure, will that data reach this system? Participants are technical, the duration short, the output yes or no. A pilot answers an operational question: does this work in our daily routine, with real users and real data? Participants are the people who do the work, it runs longer, and the output is a measurement.

Teams that skip this distinction fall into two errors. The first answers a technical question with an operational pilot: weeks of user training when the buyer only wanted to know whether the integration holds. The second is the reverse — a three-day setup called a pilot when the buyer wanted proof it survives real life. Naming the question up front solves half the problem.

You are not obliged to say yes to every POC request

The common advice is to accept every trial request as a show of confidence. For a small team that is expensive. An unqualified pilot is the costliest thing a company can give away: engineering hours, support hours, selling time and, above all, decision momentum. A request is also not always interest — sometimes it defers, sometimes it compares three vendors cheaply, sometimes it is internal cover.

Find the real question behind the request

Before declining, ask one thing: what happens if the pilot succeeds? If the answer contains no signing date and no decision-maker, this is a field trip. A second question helps: can we answer this without a pilot? Usually yes — a reference from a comparable setup, a bounded technical check, a scenario walkthrough. As we describe in how to run a product demo, a prepared demo satisfies many pilot requests far more cheaply. For reading the decision process itself, the MEDDIC methodology gives a solid qualification frame.

One exception matters. If you are displacing something the buyer already uses, inertia is so strong that a pilot is often the only breaking point. Absorbing the cost is then the right call, because your competitor is not another vendor. It is habit.

A pilot that is not written down is not a pilot

Most pilots fail on misalignment, not product. The two sides expect different things, nobody writes it down, and the buyer ends up defining success alone. What prevents that is not a long contract but a one-page charter.

• The question: Which single question will be answered when this ends, stated plainly; more than one question means you are running a project, not a pilot.
• Success criteria: A measurable, pre-agreed threshold the buyer owns; whoever writes the criteria also wins the argument about them.
• Scope: Which team, which process, which data, which integration — and, more importantly, what is explicitly out.
• Data and access: Real data or not, who supplies it, when it is ready; delayed data is the most common cause of death.
• Roles and time commitment: How many hours a week each person on the buyer's side will give; time that is not committed is not spent.
• Timeline and decision date: Kickoff, mid-point review and decision meeting all on the calendar before anything starts.
• Exit condition: What ends the pilot early; this clause protects both sides and, oddly, increases trust.

Putting the charter on a jointly owned calendar eases the rest. The logic in the mutual action plan applies directly here: a plan whose dates both sides set holds far better than a one-sided project schedule.

How do you write success criteria?

Good criteria are numeric, written in the buyer's own language, and agreed before the pilot starts. A clear cut in the average time to produce a quote is a criterion. The team being happy is not. Let the buyer write it and confine yourself to making it measurable: a buyer who clears a threshold they set does not have to defend the result internally. They want to.

With no measured before, you have already lost

This is the subtlest failure in pilots. Proving improvement requires having measured the current state, and almost nobody does. At the end you say the process got faster, finance asks compared to what, and you have no answer. Baseline measurement is the pilot's first task: how long does this take today, how often does it repeat, how often does it go wrong. Three numbers, an hour of work, the floor for every later conversation. Holding that conversation in numbers is covered in value selling.

Whoever discusses the success criteria after the pilot has ended has already lost that discussion.

Why narrowing the scope rescues the pilot

Intuition favors breadth: the more we show, the more convincing we are. In practice the reverse holds. A wide pilot lengthens setup, multiplies participants, splits attention and produces no clear result anywhere. A narrow pilot shows an undeniable difference in one process, and that difference argues for everything else.

The practical measure is one process, one team, real data. The real-data part is not negotiable: a pilot on clean demo data hides how messy the buyer's own records are and surprises everyone at go-live. A small cleanup crisis inside the pilot is far cheaper than the large one waiting after it.

Who takes part in a pilot?

Participant selection determines the outcome as much as the product does. Four roles are needed: the sponsor who decides, the champion who drives it internally, the daily users, and IT or security where relevant. The champion matters most, because in every meeting you cannot attend, that person represents you. We cover that relationship in developing an internal champion.

Here the usual advice deserves inverting. Staffing a pilot only with enthusiasts teaches you nothing; an enthusiast is already convinced and silently works around every obstacle. Put at least one skeptic inside. A skeptic hands you the real objections during the pilot, and hearing them in the purchasing meeting instead costs far more. With larger buyers, security and compliance join early too — covered in answering security and compliance questionnaires.

How long should a pilot run?

Duration follows the question you want answered, and every duration has a price. Let us try it for two weeks is usually a courtesy, not a plan.

Duration	Question it can answer	What it costs you
Three to five days	Can it be installed, does data flow?	Real usage and habit stay invisible
Two weeks	Does it fit the daily routine?	Period-end work falls outside the window
One month	Does it carry a full business cycle?	Participant attention starts to fade
Two to three months	Is the team genuinely adopting it?	Decision momentum dies, sponsors change
Open-ended	None of them	The pilot quietly becomes free usage

The last row is not a joke. Pilots with no end date turn into months of free usage with nobody acting in bad faith, and past a point deciding becomes unnecessary for everyone. The end date is the most important field in a pilot.

What does the sales team do while the pilot runs?

Stepping back once a pilot starts is the most common mistake sales teams make. Giving the buyer space looks like courtesy but amounts to letting the pilot die: usage drops, questions pile up, nobody resolves them, and the product takes the blame. A pilot is the most contact-intensive stretch of the sales process.

A healthy rhythm: setup and training in week one, a mid-point review in week two, a short weekly check after that, a decision meeting at the end. The mid-point review is the heart of it — you open the usage data together, see who never logged in, and decide what changes if you are behind. That discipline also shortens the cycle; the other levers are in shortening the sales cycle.

What does a free pilot really cost?

A free pilot leaves no trace on the buyer's side. What costs nothing is not budgeted, what is not budgeted is not tracked, and what is not tracked slides down the priority list. Some form of commitment — a nominal fee, a written time commitment, a kickoff meeting senior management attends — is what makes a pilot visible inside the organization.

But this has a limit. In some organizations pushing even a small paid pilot through procurement takes longer than a straight purchase: contracts, vendor registration and an approval chain turn a two-week pilot into six weeks of paperwork. There, charging destroys the momentum you meant to protect. Ask for payment when it increases commitment, skip it when it lengthens the process. How the procurement side works is in negotiating with procurement, and the logic of self-serve trials in converting trials to paid.

How is the decision made when the pilot ends?

The biggest risk in a pilot is not that it fails. It is that it succeeds and nobody decides. The only reliable prevention is putting the decision meeting on the calendar before the pilot begins and writing its agenda in advance: what was the criterion, what was the result, on what conditions do we proceed. Do not re-present the product there.

If the pilot failed, there is a way to lose well: write down plainly what did not hold, state which condition would reopen the conversation, and attach a date to it. If it succeeded, the real work starts — how the pilot setup becomes the production setup, which data moves, how training expands. Hand all of it over in writing, a transition covered in the handoff from sales to customer success.

Which indicators reveal the health of your pilot program?

Judging pilots one at a time is misleading; the truth appears at program level. Compare the close rate of opportunities that ran a pilot with those that did not — no difference means the pilot is not persuading anyone, only delaying them. Measure engineering and support hours per pilot, because until that number is visible pilots are assumed free. Actual duration against planned shows scope control. And the share abandoned midway, with reasons, is the most honest mirror of your qualification.

Faced with those numbers most teams reach the same conclusion: fewer pilots, better built. A team running fifteen loose pilots a year wins less and tires more than one running six disciplined ones. Treating a pilot as a small bounded project rather than a sales stage is what creates that gap.

Managing pilots means gathering tasks, dates and ownership around one opportunity record: criteria, participants, mid-point review, decision date and handover note in the same place. Rocketly keeps deal stages, tasks and reminders, document history and reporting on a single record — create a free account and build your own pilot flow.