Proof of Concept and Demonstrations Questions

Direct answer

In a 20-minute demo I would show three things, each in the prospect's own pipeline tool if they will let me. (A CI/CD pipeline is the automated chain that builds, tests and deploys their code. Here "the product" is a code-scanning tool, the usual thing demoed into a pipeline; the same shape works for a test tool.) The three are: (a) the product acting as a gate, a check that must pass before a change may continue, on a pull request (a proposed code change that teammates review before it merges), the moment a developer sees it; (b) a failing run and how a developer finds and fixes the cause; and (c) configuration kept as code in the same repository as the pipeline. In the table below these are scenarios 2, 3 and 4; scenario 1 is the quick setup that leads into them and scenario 5 is a swap-in. I choose them because each answers a different fear of a large organization: "will developers actually act on it" is answered by (b), "can we govern it at our scale" by (c), and "will this slow our builds" by (a), because the same run summary shows how little time the step added. The point of every step is to show fit with what they already have, not to tour features.

Why those three, and what each proves

I would show scenarios 2, 3 and 4 for a platform team (the team that runs the shared build and deployment tooling for the other engineers), opening with the 30-second setup in scenario 1. I would swap scenario 4 for scenario 5 if the room is mostly engineering managers worried about speed, and I keep the run time visible on the run summary during scenario 2 either way. Further scenarios worth keeping in reserve for questions: rollback on a failed deployment (automatically returning to the previous version), artifact promotion between environments (moving the same built package from test to staging to production), and reporting for audit.

What the demo looks like on screen

"ExampleScan" is a placeholder name for the product. Scenario 1 is this added step in a GitHub Actions workflow:

name: ci
on: pull_request          # run on every pull request
jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - run: npm test
      - name: Scan
        run: examplescan check --config .examplescan.yml   # non-zero exit on a violation fails the check

Scenario 4 is the policy file next to it:

fail_on: high             # block the merge on high-severity findings
exceptions:
  - rule: weak-hash
    path: legacy/**
    expires: 2026-12-31   # exceptions expire and need an approver
    approved_by: security-team

Scenario 2 is the comment the failing pull request receives (illustrative):

examplescan: 1 high finding blocks this merge. src/auth/login.js line 42: user input is joined into an SQL query. Suggested fix: use a parameterised query. Step time: 38 s (pipeline total 6 min 10 s).

Scenario 3 is the developer opening that finding, applying the suggested change, pushing, and watching the check turn green.

How I prepare

1. Ask in advance which pipeline tool, branch strategy (how they organise parallel lines of work, for example short-lived feature branches merged into main) and deployment target they use, and who is attending (platform engineers want depth, managers want outcomes).
2. Rebuild their stack in a sandbox with a realistic sample repository, so the flow looks like theirs.
3. Script the demo with a fallback recording for each step, and keep the live run under 20 minutes so there are 10 minutes for questions.
4. State the success condition up front: "By the end you should see how this adds one stage and gives developers fast feedback, and then we decide whether a trial is worth doing."

Trade-offs and pitfalls

• Showing everything dilutes the message; three scenarios and one clear outcome beat ten features.
• Demonstrating on a toy repository invites the "toy data" objection. Use data shaped like theirs (a monorepo, one repository holding many projects, or many small services, as they described).
• Never skip the failing case. A pipeline demo where nothing fails does not show a gate.
• If their pipeline tool is one I have not integrated, say so and show the generic command-line path, rather than faking a native integration.

Direct answer

I would build a self-service "POC factory": a catalogue of versioned environment templates, deployed by pipeline into one isolated cloud account (or project) per POC, so each customer's resources sit in a separate container with its own boundary and billing, with an owner, an expiry date (TTL, time to live) and a budget attached at creation. Isolation, expiry and cost caps are enforced by the platform, not by people remembering. A POC (proof of concept: a time-boxed trial of the product on a customer's problem) is requested in a form or ticket and is ready in minutes, not days. It guarantees four things: no customer data leaks across POCs, nothing outlives its expiry unnoticed, spend cannot exceed a cap, and teardown leaves proof it happened.

Pipeline stages

In words: request (with a TTL, time to live, meaning the expiry date after which the environment is destroyed), then provision, validate, run the customer tests, collect results, tear down and verify, and finally keep an evidence record.

flowchart LR
  A[Request: owner, template, TTL, budget] --> B[Provision: account, network, IAM, template]
  B --> C[Validate: smoke tests, baseline]
  C --> D[Run customer tests]
  D --> E[Collect logs and results]
  E --> F[Teardown and verify]
  F --> G[Evidence record]

1. Provision. Infrastructure as code (describing servers and networks in files that a tool applies, so every environment is built the same way; Terraform and CloudFormation are interchangeable examples of such tools) from a versioned template, in a dedicated account or project per POC (a tenant is one customer's isolated slice of a system), with network isolation (a private network with no peering to other POCs) and least-privilege IAM (AWS Identity and Access Management roles scoped to that POC: each role gets only the permissions its job needs and nothing more).
2. Validate. An automated smoke test (a quick check that the basics work) confirms the environment matches the template before the customer sees it.
3. Run customer tests. The agreed test specs run from scripts, so results are repeatable.
4. Collect. Logs, metrics and test output are copied to a store the account team owns, before anything is destroyed.
5. Tear down. Destroy resources, then verify with an inventory check that nothing tagged to that POC remains; keep the audit record (a log of who created, changed and destroyed what, and when).

The guarantees

Illustrative cost: an environment at $30 per day with a default 14-day life plans for 30 x 14 = $420. A $600 cap equals 20 days of runtime, so the alarm at 80% ($480) fires at day 16 of runtime. That is after the default 14-day life ends, so the alarm only matters once an extension has been granted; an environment that is never extended finishes at $420, under the alarm. Extensions require a named approver.

Demo variant (about 100 live demos a week)

Live demos need fast, tolerant setups rather than long-running ones. Keep a warm pool of pre-built, pre-loaded environments with session isolation (each demo gets its own tenant and synthetic data, reset after use). Arithmetic with illustrative numbers: 100 demos x 55 minutes (45 minutes plus a 10 minute reset) is about 92 environment-hours per week. If they cluster into 3 busy days of 8 hours, that is about 4 demos in flight at once, so a pool of 10 gives roughly 2.5 times headroom. Have a fallback library of recorded demos for each scenario, and a one-page failover runbook: if the live environment misbehaves for more than 60 seconds, switch to the recording, say so, and offer a live follow-up.

Trade-offs and pitfalls

• Account-per-POC is safest but adds account-vending work (automatically creating and configuring a new cloud account for each request). A shared cluster with namespaces (logical partitions inside one cluster) is cheaper and faster but weaker isolation, so reserve it for demos, not customer-data POCs.
• Over-automation of exceptions is a trap: let 5% of POCs (unusual hardware, on-premises) go through a manual path with the same guardrails.
• Teardown is the step teams skip. Treat an unverified teardown as a failed POC, not a finished one.

Direct answer

I decide before the meeting by choosing the one or two workflows that match the buyer's top pain and that I can show working with certainty. For a security-focused buyer, I lean toward one deep dive, because they want to see one control (a security safeguard such as an audit log or an access rule) tested properly, and I use a short tour of related modules (separately packaged parts of the product) mainly if they are evaluating a consolidation of tools (replacing several separate products with one). In a 25-minute slot I still keep a few minutes of tours, as in the worked example below, to show where the product can grow, but the deep dive carries the decision. If I cannot name their top pain, I am not ready for a 20 to 30 minute demo, and I ask for a short discovery call first.

How I choose workflows

I score each candidate workflow on four questions, 0 (no), 1 (partly) or 2 (clearly yes) on each, and show the highest scorers. A 0 on the reliability question is a veto whatever the total.

Example scoring for the security-focused buyer below (columns: named pain, differentiation, reliable in the time, sets up next step):

Deep or wide: the signals

Worked example for a 25-minute security-focused meeting

The buyer said in discovery that their problem is slow investigation of suspicious logins. Plan:

3 + 14 + 6 + 2 = 25. The 14-minute deep dive on screen: (1) an alert fires for a sign-in from a new country, 2 minutes; (2) open the investigation timeline for that user, with device, location and the last 30 days of sign-ins, 4 minutes; (3) pivot to related sign-ins from the same address, 4 minutes; (4) respond by forcing sign-out and resetting the second login factor, 3 minutes; (5) show the audit record of that response, 1 minute (2 + 4 + 4 + 3 + 1 = 14). The tours exist so the buyer sees where it can grow, but the deep dive carries the decision.

What changes for a mid-market buyer

Mid-market buyers (smaller companies, often with one or two people covering all of IT and security) care less about testing one control to destruction and more about time to value and effort: how long setup takes and how many hours a week it saves. I would still pick one workflow, but the one that saves the most hours, show setup effort in it, and give the tours more room. A 25-minute plan: 3 frame, 10 main workflow including setup, 9 for three tours of 3 minutes, 3 next step (3 + 10 + 9 + 3 = 25).

What I would not show

Anything unrelated to the named pain, anything newly released that I have not rehearsed, and any feature that depends on setup I cannot do in the room.

Trade-offs

Going deep risks missing a need the buyer has but did not mention; I mitigate this with a closing question ("what did I not show that you expected?"). Going wide risks that nothing is convincing. When the evidence is balanced, I prefer depth for security buyers, and I would switch to wide if the discovery notes show the buyer is comparing platforms rather than single controls (weighing whole products against each other, not testing one security feature).

Direct answer

In the room I stay calm, thank the person, do not argue or reassure with something I cannot verify, ask exactly what they saw, and commit to a specific follow-up from our security team. In the next hour my team reproduces the issue and decides whether it is a real vulnerability (a genuine security weakness) or an artefact of the demo set-up (a side effect of how the demo account is configured that would not exist in the real product). Afterwards I send a short, factual written response and offer a session with our security people, so the customer sees a competent, honest process, which is often more persuasive than a flawless demo.

In the room (the next 2 to 3 minutes)

1. Acknowledge, do not defend. "Thank you for raising that. I want to understand exactly what you are seeing."
2. Get precise. "Which step, and what looks wrong to you? Is it the token in the URL, the data shown, the missing prompt?" Write it down, ideally with the screen still up so I can note the exact view.
3. Do not dismiss it with a guess. Never say "that is just demo data" or "that cannot happen" unless I know. If I do know it is a demo-only configuration, I say it carefully: "I believe that is how this demo account is set up, and I will confirm that with our security team and tell you."
4. Do not go deep on details of a possible real vulnerability in front of the room, and do not speculate how it could be exploited.
5. Commit to something concrete. "Our security team will look at this today. I will write to you by end of day tomorrow with what we found." Then continue with the rest of the demo, avoiding that flow, or ask whether they prefer to pause on it.

The next hour (internal)

If it is a real flaw, it follows the company's vulnerability handling process (the agreed steps for triaging, fixing and disclosing security flaws). I do not discuss exploit details (the exact steps someone could use to abuse the flaw) in broad email threads. If it is a demo artefact, I fix the demo environment so it does not come up again.

Worked classification: the reviewer says "I can open another user's record by changing the number in the address." Product security tries it. In the demo tenant both users share one seeded account, so the record is the same user's own (bucket b, demo artefact). Had it shown a different customer's record in a production-like environment, it would be bucket (a), a real flaw, and the serious-case path below applies.

What I send afterwards (within a day)

A short, factual note, copied to the AE and with security looped in:

Thank you for raising the [description] in yesterday's demo. We took it seriously and our product security team reviewed it the same day.
What we found: Worked example, for a customer who saw a session token (a login key) in the web address: "The demo account runs with a relaxed setting that puts the token in the address bar. That setting does not exist in production, where the token is sent in a protected header. Here is the production configuration page." Other possible outcomes: [one of: it was a demo-environment setting that does not exist in production, with the production behaviour described; or it is an issue we have confirmed and are addressing through our standard process, with an honest status; or it is intended behaviour, with an explanation of the control that applies].
What this means for you: [the customer-relevant point].
Next step: We would be glad to set up a call between our security team and yours to walk through this and answer anything else your reviewer needs. Here are our security documentation and the contact for your reviewer.

I do not claim "we have no vulnerabilities". I describe the process and the evidence.

Keeping the deal moving

• Offer a technical security session with their reviewer within the week.
• Share the documents they are likely to need next (security overview, architecture and data-flow diagram, a penetration test summary, meaning the report from a hired team that tries to break in to find weaknesses, if the company shares it under NDA, meaning a non-disclosure agreement).
• Keep other workstreams going (the proof-of-concept plan, commercial discussions), so the issue is one thread, not a standstill.
• Tell the AE early, so the commercial conversation is consistent with the technical one.

Pitfalls

• Getting defensive or minimising: this reads as dishonest even when you are right.
• Confirming or denying a vulnerability from memory in the room.
• Letting the follow-up slide. The customer is testing how you behave when something goes wrong.
• Promising a fix date I do not control.

What would change my call

If the issue is clearly serious (for example, access to another customer's data), I pause the demo, tell the customer a follow-up will come from our security lead, and escalate immediately instead of continuing the agenda.

Direct answer

Demos break because the product changes under a demo that nobody else is protecting. I would treat the demo as a small production service with an owner, a test suite and a release gate (a checkpoint a release must pass before it goes out): a separate, pinned demo environment (locked to one specific product version); automated checks that replay the standard demo scenarios against every release candidate (a build proposed as the next release); a notice window for risky changes; and a metric for how often a release breaks a scenario. Sales engineering (SE, the pre-sales technical people who run demos) owns the scenarios, engineering owns the gate, and the release manager (the person who coordinates what ships when) owns the calendar.

The process

1. Pin the demo environment. Demos run on a stable version, upgraded deliberately a few days after a release proves itself, never automatically from the main branch (the shared line of code that everyday changes are merged into, so it can change several times a day).
2. Codify demo scenarios as tests. The 5 to 8 click-paths used most often in live demos become automated end-to-end tests (a browser or API test that runs the same flow, with the same synthetic data). They run on every release candidate in the pipeline (CI, continuous integration: the automated build-and-test system that runs on every change). Example of one click-path as a test: log in as the demo user, open the Invoices page, click "Approve" on the first invoice, and assert that its status reads "Approved" and the approval appears in the audit list within 2 seconds. If the button moves, the label changes or the data shape breaks, the test fails and the release is held.
3. Canary and verify. New builds go first to the internal canary (a small slice of traffic or one internal tenant, a canary being an early test group that warns before everyone is affected). A person from SE signs off after the scenarios pass, before wider rollout.
4. Release windows and notice. No release to the demo environment in the 48 hours before a flagged strategic demo or a customer's POC review. Engineering posts breaking UI or data-shape changes in a shared channel at least 5 working days ahead. Sample notice (illustrative): "Release 7.3, due Tuesday: the Approve button moves into a menu and the invoice export gains a new column. Demo scenarios 2 and 5 will need updating. Contact: platform on-call."
5. Rollback plan. Every release keeps the previous version deployable in minutes. If a scenario test fails after promotion, rollback comes first, diagnosis second.
6. Feature flags. Unfinished features stay hidden behind flags (on/off switches in the code) in the demo tenant, so demos only show what works.

Who owns what

How I would know it is working

Primary metric: demo-breaking releases per quarter, counted as releases after which a scenario failed or a live demo had to be changed. A break is detected by the scenario suite failing on a release candidate, or by an SE reporting that a live demo had to change, and the count is taken over a fixed window such as the last 10 production releases. Illustrative baseline: 4 breaking releases in those 10 (40%); target at most 1 in 10 (10%) within two quarters. Supporting signals: scenario-suite pass rate on release candidates, time from report to fix, and the number of demos that fell back to a recording. Review monthly with SE and engineering together.

Trade-offs and pitfalls

• Pinning means demos lag the product, and prospects miss new features. Compensate with a small "preview" tenant for rehearsed new-feature demos.
• Scenario tests rot. Assign an owner and review the scenario list each quarter.
• Do not ask engineering to freeze releases for sales; ask them to make demo impact visible. A freeze is the first thing dropped under pressure, while an automated gate persists.