John Spooner

Playbook

Technical Trials: Turning evaluation into evidence

A technical trial should be a controlled evaluation of whether a product can deliver an agreed business outcome. I designed Surfly's enterprise trial process around defining success before activation, instrumenting the evaluation, intervening early and reviewing evidence against agreed criteria.

  • Technical Sales
  • Enablement & Leadership
  • Technical Build

In this playbook

  1. How do I define whether a technical trial has actually succeeded?
  2. How do I keep an evaluation moving before problems become visible too late?
  3. How do I turn a trial into evidence rather than temporary product access?

A technical trial isn't two weeks for a prospect to click around a product. It's a controlled evaluation of whether the product can deliver an agreed business outcome.

Define success before it starts, build towards it, measure it, and make the result difficult to argue with.

Technical trials are where complex deals are often won or lost.

Without structure, they quickly become expensive periods of unrestricted product access. Customers explore features without a clear objective, technical resources get consumed solving problems that don't matter, engagement drops and two weeks later everyone asks: “So, what did you think?”

By then, it's too late to discover that the customer and vendor had different definitions of success.

A trial fails when the criteria for success aren't defined before it begins.

Do

Agree what success means before activation so both sides know what the trial is trying to prove.

Avoid

Open product access first and wait until the final review to decide whether the evaluation worked.

I designed and implemented the standard enterprise trial process at Surfly around one principle: agree the goalposts before you start playing.

A trial only began after we had established:

  • The business outcome being tested
  • The use cases and user flows required to test it
  • Measurable success criteria
  • What was explicitly in and out of scope
  • The people required to make the evaluation work — trial owner, technical resources, users and, where relevant, customers
  • Clear ownership of every implementation task and milestone
  • The technical resources available
  • The environment and configuration required
  • What a successful transition into production would look like

I treated the trial as the first phase of implementation, not a disposable proof of concept. Wherever possible, what we built during evaluation became the foundation of the customer's production deployment if they signed.

I created a three-stage process supported by a trial framework I designed and maintained.

Before activating an enterprise trial, the AE and I ran a full technical intake with the customer.

We mapped the use case, flows, stakeholders, required features and responsibilities. We also agreed what was in and out of scope before activation, so neither side entered the trial expecting work or functionality that had never been agreed.

Most importantly, we agreed what success actually meant.

For a customer support use case, that might mean reducing average handling time or improving user feedback. For a sales use case, it could be increased conversion. For a technical evaluation, success might simply be proving that a required integration or workflow worked reliably.

The metric depended on the business problem. Having one didn't.

I would challenge vague, unrealistic or irrelevant success criteria before activating the trial. This protected both the integrity of the evaluation and the resources we were about to invest in it.

We then prepared the environment as if it were going into production: configuring settings, building flows, testing integrations and identifying likely blockers before the clock started.

Every meaningful task had an owner. If a button needed embedding, users needed onboarding or a webhook needed configuring, we agreed who was responsible before the trial clock started.

Where customer resources were limited, I could provide code snippets, build a test implementation, use tooling such as my Session Builder or work directly with their technical team. How far we went depended on the opportunity and likelihood of closing — SE resources have to be protected too.

Do

Start the trial only when success criteria, scope, responsibilities and the environment are ready enough to produce meaningful evidence.

Avoid

Use trial activation as a substitute for preparation or hope that ownership and scope will become clear once the clock starts.

Once activated, the trial ran for two weeks.

I built SQL-backed dashboards in Looker and Superset to monitor trials at both portfolio and individual-account level.

Instead of relying on “everything is going fine”, we could see what was actually happening: sessions started, users created, Spaces configured, API keys generated, features used and overall activity.

That data informed our midpoint check-in and allowed us to intervene earlier.

If a customer had committed to adding 20 users but the dashboard showed none, we knew before the meeting that something had gone wrong. We could contact them, identify the blocker and get the evaluation moving again rather than discovering the problem at the end of the trial.

The AE owned the commercial relationship, scheduling and stakeholder engagement. I owned technical success alongside them, working primarily with the customer's technical representative and trial owner while the AE maintained the decision-making relationships.

Do

Instrument the evaluation and intervene while there is still time to change the outcome.

Avoid

Rely on status updates alone and discover at the final review that the customer never meaningfully ran the trial.

The final meeting wasn't “did you like the product?”

We returned to the success criteria agreed before the trial and reviewed the evidence against them.

What worked? What didn't? Did we achieve the business or technical outcome we set out to test?

Because the goalposts had been established in advance, the conversation was much less subjective.

From there, we could move naturally into implementation planning while the AE moved the commercial conversation towards pricing and signature.

The work wasn't thrown away. The environment, configuration, technical decisions and documentation created during the trial formed the starting point for implementation and could be handed cleanly to the TAM after signature.

The process also taught us when not to keep a trial alive.

Enterprise evaluations can easily become indefinite when stakeholders aren't ready or implementation work stalls. Extensions were possible, particularly for larger organisations, but they needed a reason and a commitment.

Rather than “here's another two weeks”, an extension might be:

We'll reactivate the trial when you're ready to demonstrate this internally.

Or:

We'll extend access so you can complete this specific integration by Friday.

The objective was never to force an artificial deadline. It was to prevent an evaluation without momentum from consuming customer and SE resources indefinitely.

Failed trials were useful too.

If a technical issue cost us an evaluation, I wanted to understand why and prevent it happening again. That could mean advocating for a hotfix, feeding a recurring gap into my Product Board or building supplementary tooling around the problem.

The Session Builder itself emerged from exactly this kind of observation: prospects were spending too much of their evaluation learning our JavaScript API rather than proving what it could do.

I designed the full trial framework used to take an opportunity from scope definition and stakeholder assignment through activation, midpoint intervention and final review. It became the shared record between Sales, Solutions Engineering, the customer and the post-signature implementation team.

I built the underlying SQL queries and dashboards in Looker and Superset to monitor both the overall trial portfolio and the behaviour of individual accounts.

  • Session Builder — reduced technical friction during API-heavy evaluations
  • Demo Repository — made sophisticated configurations reusable rather than rebuilding them for every opportunity

  • Define success before activation. Agree the outcome, scope, responsibilities and evidence required before the trial clock starts.

  • Treat the trial as the first phase of implementation. Build something worth keeping, instrument the evaluation and intervene while problems can still be fixed.

  • Turn evaluation into evidence. Review the result against agreed criteria so the decision is based on what the product proved, not whether somebody simply liked using it.