Proof of Concept and Demonstrations Questions

Direct answer

I would run proofs of value (PoV, a time-boxed trial that tests whether the product delivers a measurable business result, not only whether it works technically) as a standard programme with a global core and regional addenda: one qualification gate, one charter and success-criteria template, one legal template, three fixed sizes with hard caps on effort and cost, and one reporting model in the customer relationship management system (CRM). Then I would prove the programme is worth running by comparing cohorts after 12 months on cost per PoV, conversion to paid (share of PoVs that become paying customers), and sales-cycle time (days from qualified opportunity to signed contract), and by being honest about what that comparison cannot prove.

1. Programme design

Entry gate (qualification). A PoV is only offered when four things are true: a named business sponsor and a named economic buyer (the person who controls the budget), a measurable outcome the customer cares about, a committed customer team and data access, and a defined purchase path if the criteria are met. This prevents the common failure of running free trials for people who cannot buy.

Three sizes. Fixed tiers stop scope creep and let regions plan capacity. Presales is the technical sales-support team (solutions architects and engineers) that works before the contract is signed.

Anything above the cap needs a named approver (regional director) and a stated reason. (The numbers are illustrative; set them from your own cost data. Staff time dominates cost, which is why the cloud caps look small beside the hour caps. Small and Standard differ little because neither needs heavy infrastructure; Large jumps because integration-heavy trials run bigger environments for longer. The worked example below uses the Standard tier: 60 hours and $400.)

Templates (the reusable kit).

1. PoV charter: objective, sponsor, scope, out-of-scope, timeline.
2. Success-criteria table: metric, baseline, target, how measured, who signs off.
3. Data and security checklist (what data, where it lives, what approvals).
4. Weekly status note and a closing report (results against each criterion, recommendation, next step).
5. A commercial next-step page agreed up front (what happens if criteria are met).

Legal terms. A standard PoV agreement: scope and duration, ownership of the customer's data and our IP, confidentiality, no production use, data-processing terms, liability limits, and an explicit statement of what is promised if criteria are met (for example a negotiation of the paid agreement within 30 days, not an automatic purchase). Regions use a short local addendum for data residency (rules requiring data to stay in a given country or region), language and local law rather than rewriting the core. Legal reviews the template once, not each deal.

Guardrails on scope and cost. Time-boxes are fixed; success criteria cannot be changed after week 1 without written agreement; effort is logged against the cap in the CRM; the programme owner sees a weekly list of PoVs over 80% of cap.

Escalation. Triggers: a blocker unresolved for 3 business days, hours above 80% of cap before the midpoint, or a sponsor no longer attending. Routes to the regional presales lead, then the programme owner. Each escalation has an owner and date in the CRM.

Regional consistency. Same stages, same fields, same definitions of "started", "completed" and "criteria met" everywhere. Regions vary in data-residency rules, local legal terms, language, partner involvement and time zones, handled through the addendum and a regional lead who owns the capacity plan.

2. KPIs to track in the CRM

• PoV-to-paid conversion rate (paid deals divided by completed PoVs).
• Criteria-pass rate (share of PoVs where all must-have criteria, the ones the customer said they cannot buy without, were met).
• Presales hours and total cost per PoV against its cap.
• Cycle time: days from qualified opportunity to signed contract (the definition used above), with PoV start to signed contract reported as a sub-measure.
• Win rate of deals that ran a PoV compared with similar deals that did not (see caveat below).
• Share of PoVs that started without a complete charter (should trend to zero).

3. Showing it is worth running after 12 months

Illustrative inputs (not measurements): 48 PoVs in the year; each costs 60 presales hours at a loaded $85 per hour (the full hourly cost of an employee, salary plus benefits and overhead, not just pay), plus $400 cloud and $500 legal and admin.

$\text{cost per PoV} = 60 \times 85 + 400 + 500 = \$6{,}000 \qquad \text{programme cost} = 48 \times 6{,}000 = \$288{,}000$

Suppose gated PoV deals win 45% of the time and comparable deals without a PoV win 25%, with an average annual recurring revenue (ARR, yearly subscription value) of $120,000:

$48 \times (0.45 - 0.25) = 9.6 \text{ extra wins}, \qquad 9.6 \times \$120{,}000 = \$1{,}152{,}000 \text{ ARR}$

That compares with $288,000 of programme cost. The most sensitive assumption is the win-rate gap: if the gap were 10 points instead of 20, extra wins halve to 4.8 and ARR to $576,000, still above cost, but a gap near 5 points (2.4 wins, $288,000 ARR) would only equal the cost in ARR terms. One caution on comparing the two: ARR is revenue per year that recurs if customers renew, while the $288,000 is a one-time spend this year, so the comparison needs a margin step. At an assumed 75% gross margin, $1,152,000 ARR gives $864,000 of annualised gross profit, about 3.0 times the cost (864 / 288). This treats all 48 deals as live for a full 12 months; in practice the PoVs are spread across the year and each needs weeks to close, so if closes land on average at the mid-point of the year (an assumption), only about half of that, $432,000, is recognised in the first calendar year (1.5 times the cost), and the rest arrives in the following year if customers renew. At the 10-point gap it is $432,000, 1.5 times the cost. At the 5-point gap it is $216,000, below the cost, and payback would take 288 / 216 = 1.33 years, about 16 months, if customers renew. (A full return-on-investment model would add discounting and renewal assumptions; here the programme only needs to clear its own cost and cycle-time bars.)

Caveat I would say out loud: the gap is confounded (mixed up with another cause) because teams choose PoVs for better-qualified deals. I would compare PoVs against deals in the same segment and stage, track cycle time and drop-out reasons too, and set the 12-month review bar before the year starts: for example, conversion of at least the agreed target, cost per PoV inside the cap, and at least one region not subsidising the others.

Trade-offs and pitfalls

• Strict gates reduce wasted effort but can lose deals where a PoV is the only way in; give a named approver an exception route instead of a loophole.
• One template everywhere versus local fit: keep the core fixed and allow only addenda.
• Vanity metrics such as number of PoVs run reward activity, not outcomes. Report conversion and cost per outcome.

Direct answer

The document is a POC (proof of concept: a time-boxed trial of the product on the customer's own problem) charter (also called a success-criteria or plan document): one page that says what is being tested, how a pass will be judged, what each side provides, how long it runs, and who signs. It matters because in my experience many failed POCs fail on ambiguity, such as different ideas of "success" or missing access, rather than on the product (a practitioner observation, not a measured statistic). A signed charter makes the verdict checkable.

One-page template (nine sections)

Sample excerpt (criteria and acceptance)

Pilot agreement components

A pilot (a limited, real-world trial with real users, often under a short agreement) uses the same document but adds: scope of users and use, term and dates, roles and support, data requirements (what data, where it lives, who can see it), acceptance criteria, exit and conversion terms, confidentiality. Exit and conversion terms say what happens at the end. Example wording (illustrative): "If the acceptance criteria are met by 30 June, the customer may convert to a paid subscription at the quoted price within 30 days; if not, or if the customer declines, access is removed within 5 working days and the customer's data is deleted and deletion confirmed in writing." The purpose of a POC or pilot is to reduce the buyer's risk of a purchase to a size they can accept, by testing the highest-risk assumptions first.

Trade-offs and pitfalls

• Success criteria set after seeing results are an opinion; set them before.
• Too many criteria make everything borderline; I limit to 3 to 5 that map to the buyer's real concerns.
• Include what happens on a partial pass; otherwise an 85% result becomes a dispute.

Direct answer

I would recommend a phased approach that still gives the sales rep something to close on. I would not build a production-grade architecture before the contract exists, because that is unpaid engineering against unconfirmed requirements. But I would give the rep a credible production-grade design on paper (a target architecture and plan) and a time-boxed, priced first phase that the customer signs now, with the later phases agreed as options. The speed comes from compressing the first phase and the paperwork, not from skipping the risk work.

What I find out first

Before I tell either side anything, I ask:

• Why the rush? A quarter-end (the date a sales quarter closes, when the rep's sales target is measured), a competing vendor, or the customer's own deadline are three different problems.
• What exactly has the customer asked for? If they asked for a proof, the rep may be overreading them.
• What are the unknowns? Data quality, integrations, security review, performance needs. Unknowns are where delivery risk lives.
• What would a failed delivery cost? The reputation and the reference, not only the deal.

What I recommend

A concrete shape, with illustrative figures only: phase 1 is 5 weeks, fixed price 120,000 dollars, covering the integration and the riskiest data question. Options for phase 2 (rollout to three business units) are priced at agreed day rates or a fixed 300,000 dollars if exercised within 90 days. The speed comes from compressing the first phase and the paperwork: the SOW and security questionnaire go to the customer's procurement team (the buyers who handle contracts and vendor approval) in the same week as the architecture document, rather than after it, which in a typical case saves two to three weeks of sequential waiting (ESTIMATE, depends on the customer). Options at agreed rates means the customer can later buy more work at prices fixed now, without a new negotiation. The rep carries a quota (a sales target they are paid against), so a signed phase 1 plus options counts as a real close.

What I tell each side

To the sales rep:

"You can close a real deal this quarter. It is a paid first phase plus priced options. What I cannot do is commit our engineers to a full production build and date before we know the data and the integration, because if we miss the date, the customer's first experience of us is a failure and the next renewal is harder. Here is the architecture document you can take to their buyers on Friday."

To engineering:

"I agree with phasing. In return, I need phase 1 to be decisive about the biggest unknowns, not a toy, and I need the target architecture drafted this week so sales has something real. Tell me which unknown worries you most and I will put it first in the plan."

Cost and risk, stated plainly

Building production-grade work before signature: costs engineering weeks (for example, 3 engineers for 8 weeks is 24 engineer-weeks; at an illustrative 4,000 dollars per engineer-week that is about 96,000 dollars of unpaid work, which is about 80 percent of the 120,000 dollar phase 1 price above (96,000 / 120,000)) that may be wasted, and the customer may anchor on a scope we did not price. Phasing: risks that a competitor offering a full commitment wins, and costs some deal speed. I accept the second risk because delivery failures cost more than a slower close, and a customer who has paid for phase 1 is more committed than one given a free full proposal. Some of this is judgement rather than measurement.

What would flip my call

• The requirements are well understood, the product is configuration rather than build, and a similar deployment has been delivered before: then skip the proof and go straight to a production plan.
• The customer pays for the production design phase and engineering agrees the unknowns are small.
• Engineering's concern turns out to be capacity, not risk: then the answer is staffing, not phasing.

Pitfalls

Telling the rep "no" without giving a way to win. Telling engineering "just do it" to get the deal. Promising dates in the sales cycle that nobody on the delivery team has seen. Offering a reference (a happy customer a future buyer can call) or a roadmap item (a feature planned but not yet built) as if it proved this deal can be delivered on this date: neither is evidence of that. Put the trade-off, with the risk named, in front of the person who owns the priority call and let them choose.

Direct answer

I show it clearly labelled as a prototype, I separate what is real today from what is a vision, I tie it to the roadmap (the company's plans for future features) as a direction and never as a date, and I leave a short written note that says exactly what was shown and what it is not. The goal is that the customer leaves excited about the direction but with no belief that they have been promised a product, a date or a price. Credibility is worth more than the extra enthusiasm an overclaim would buy.

Before the meeting

• Get internal clearance. Confirm with product management what I can say about status, and ask legal or the deal desk (the team that reviews non-standard terms) what disclaimer language the company uses. I do not invent my own.
• Decide whether to demo at all. If the customer is about to sign and this feature would drive the purchase, a prototype demo is risky. In that case I would show it only as a design-partner conversation (an early, informal collaboration where a customer helps shape a product, with no purchase commitment) and keep it out of the buying decision.
• Prepare an on-screen label. A visible "Prototype, not a released product" banner on the screens, so it is clear in recordings and screenshots too.

What the legal risk actually is

The exposure comes from reliance: a buyer who signs because of something said or shown in a demo, and then does not get it, may claim they were misled, even if the prototype was shown in good faith. Specific, repeated or written assurances ("it will be ready for your January go-live") are the most dangerous, because they look like promises. Contracts usually say that only the signed document counts, but that protection is not guaranteed against clear assurances made during the sale, and rules differ by country, so I do not rely on it. I am not a lawyer; I avoid creating the statements and ask legal for the exact wording.

In the room

1. Open with a plain frame, before showing anything. For example:
   "Before I show this: what you are about to see is an early prototype. It is not generally available, it may change a lot or not ship, and I am not able to commit to a date or to pricing. I am showing it because I want your reaction to the direction."
2. Separate the two parts of the demo. First the released product, doing the job the customer can buy today. Then the prototype, as a clearly marked second part, so nobody blends the two.
3. Say what is faked or hard-coded. "This part uses sample data and a manual step behind the scenes." If it is not real, say it is not real.
4. Connect to the roadmap without dates. Say "this is the direction we are exploring" and "your use case is useful input for it". Avoid "coming in Q3", "soon", "should be easy", "we will have this by your go-live" (the date the customer starts using the system for real work). Any of those can be heard as a promise.
5. Ask for what I want from them. "Does this fit how your team would work? What would make it useful or not?" That turns the prototype into feedback, not a sales claim.

Disclaimer wording I would use verbally, and also put on the final slide (subject to legal's approved language): "Roadmap and prototype content is shared for discussion only. It is not a commitment to deliver any feature, timeline or pricing, and should not be relied on when making a purchase decision."

What I leave behind in writing

A short email the same day, to everyone who attended:

Thanks for the time today. A summary so we are all working from the same facts.
Released and available today: [list of capabilities shown in part one].
Early prototype, not generally available: [one-line description]. It may change or not be released. We did not discuss or commit to a release date or pricing.
What we heard from you: [their use case and what would make it valuable].
Next step: I will share your feedback with our product team and tell you by [date] whether this is something we can discuss further. Any commercial terms will be in the agreement and not in this email.

This does three things: it records the honest status, it shows I listened, and it gives me a dated action that is within my control (feedback shared), instead of one that is not (shipping).

Trade-offs and pitfalls

• Enthusiasm vs exposure. A hedged demo is less exciting but safer. The risk of the opposite is real: a buyer who treats a prototype as a commitment, and a later dispute or churn (the customer cancelling or not renewing).
• Disclaimers are not magic. A verbal or slide disclaimer helps, but it does not undo repeated "we will have it by June" statements. Behaviour matters more than the wording. For anything beyond standard language, ask legal.
• Do not tell the customer it is "basically done" unless product management confirms in writing.
• Do not let the prototype carry the deal. If the customer needs it to buy, say so internally and decide whether to pursue a contractual commitment through the proper channel (the deal desk and legal, with product management's written agreement, putting it in the signed contract), not through the demo.

What would change my call

If the customer pushes for a date, I say I cannot give one and offer to ask product for a status I can describe (for example "in active development" vs "under evaluation"), still without a date. If product is not willing to stand behind even a direction statement, I do not demo it.

Direct answer

The story I would tell has a clear shape: a POC drifting toward failure, a specific diagnosis, a set of concrete changes (technical and stakeholder), and an outcome for the deal I can state honestly, including what I could not fix. Below is a model structure with an illustrative story. Replace the specifics with your own real example, and use your own real numbers; do not borrow these.

Shape of a strong answer

1. Situation (2 to 3 sentences): what the POC was, what the criteria were, what was failing and when you noticed.
2. Diagnosis: how you found out why, not just that it was failing.
3. Actions: what you changed in the technical approach, in the plan and with the people.
4. Winning stakeholders: how you rebuilt confidence, especially with the sceptical one.
5. Result for the deal: outcome, plus what you learned and now do differently.

Illustrative story (composite example; use your own facts)

Situation. A four-week POC (proof of concept, a short trial on the customer's own data) for a data-integration platform at a logistics company. The success criteria (the written pass/fail measures the customer and I agreed on), signed at kickoff, included processing a day of shipment events in under 30 minutes. At the end of week 2 the test took about 70 minutes, the customer's technical architect (the sceptic) had started copying his manager on every status email, and my champion (the person inside the customer who backed our product and pushed for the trial) had gone quiet.

Diagnosis. I stopped adding features and spent a day on the failing criterion. Two causes: the sample data had deeply nested records that the default configuration handled poorly, and the test ran at a smaller scale than the one the customer would see, so we had been tuning the wrong thing. A third, non-technical cause: the criteria were set by my champion and the architect had never agreed to them.

Actions.

• Technical: changed the parsing approach for the nested records, increased the batch size, and brought in our engineering team for a half-day review. Re-ran the criterion after each change and showed the improvement in a simple table, so progress was visible rather than asserted:

  Run	Change made	Time for one day of events
  1	Baseline (default configuration)	70 minutes
  2	New parsing approach for nested records	46 minutes
  3	Larger batch size	31 minutes
  4	Test re-run at the customer's real daily volume, config tuned from our engineers' review	22 minutes (target: under 30)

• Plan: told the sponsor (the senior person at the customer who owns the budget and the decision) in writing what was failing, what I thought the cause was, and what I needed (one more week and a data specialist for two hours). I did not wait for the readout (the final results meeting at the end of the POC) to disclose it.

• Scope: proposed removing one low-value criterion and adding a criterion the architect cared about, so the test measured what mattered to the people deciding.

Winning the stakeholders. I met the architect one-on-one, asked him to define the test he would trust, and ran it with him watching the results live. His own test became the decisive criterion. I also gave the champion a two-line summary she could forward to her boss each week, so she had something to say.

Result. The re-run finished in 22 minutes against the 30-minute target, a margin of 8 minutes, and the architect's own test passed. The deal closed with one open item, a reporting connector, written into the contract as a delivery milestone rather than hidden. The part that did not go perfectly: the extra week meant the deal slipped past the end of the customer's financial quarter (the date their budget and my sales target were both aimed at), so it closed one quarter later than planned.

What a strong story contains

Trade-offs and pitfalls

• Hero stories where you alone saved it sound suspect; credit the colleagues you pulled in.
• No cost in the story (nothing lost, nothing risked) reads as polished fiction.
• Blame on the customer is the most common weakness. Show that you own the criteria and the plan.
• Invented precision: quote only numbers you can defend if asked how they were measured.