Skip to main content
日本語
Netsujo日本語

Web3 PoC design template

A worksheet for hypothesis, KPIs, and exit criteria, so a PoC does not end as just a PoC.

Available in Japanese only: this template is currently published in Japanese only. The overview below is in English, but the full fill-in template has not yet been translated.

This resource is a fill-in template covering the 7 elements to organize internally before starting a PoC (proof of concept): hypothesis, metrics/KPIs, scope, team structure, timeline, and exit criteria. Filling in these 7 sections clarifies the purpose of the PoC and creates a clear line of sight to production adoption.

We are publishing the framework we use in our own PoC-support work. Use it as a starting point for internal sign-off discussions, aligning requirements with a vendor, or an investor pitch deck.

What a PoC is for, and how to use this template

The goal of a PoC is not "building something that works," but "gathering what you need for the next decision." Success means reaching a state where you can calmly decide whether to move to production, revise the approach, or stop.

Section 2: Putting the hypothesis into words (worksheet 1)

As a rule, narrow the hypotheses tested in a PoC to three or fewer. With four or more, you cannot verify them adequately within the PoC period and the conclusion becomes muddled. Write each hypothesis in the form: "Applying Web3 to ___ would improve ___, because ___." For example: applying an NFT to a tourist stamp rally could improve repeat-visit rates, because only NFT holders receive a next-visit benefit, so holding the NFT itself functions as an ongoing incentive. Or: applying DID/VC to an employee ID badge could reduce the workload of managing access during personnel changes, because a role change is completed by reissuing a VC, removing the need to update multiple systems individually. Before finalizing a hypothesis, check: (1) can this genuinely not be solved with a normal database; (2) is third-party verifiability actually required for the business; (3) does the record need to be shared across multiple organizations?

Section 3: Setting metrics and KPIs (worksheet 2)

Evaluate the hypothesis across three lenses — technical feasibility, user value, and business viability — and turn each into a measurable KPI. Example metrics: for technical feasibility, average execution time, total gas cost, system uptime, throughput (TPS); for user value, retention rate, task-completion time, user satisfaction, wallet-holding rate; for business viability, customer-acquisition cost, LTV/CAC ratio, ROI estimate, competitive advantage. Agree on KPI thresholds before the PoC starts, so results are not open to differing interpretation — for example, setting a "no-go" threshold, a "revisit" threshold, and a "go" threshold for retention rate.

Section 4: Defining scope and deliverables (worksheet 3)

Writing down what is "in scope" and "out of scope" for the PoC prevents misalignment with the vendor. Standard PoC deliverables typically include: a working prototype (on a testnet or a limited environment); the full source code (a GitHub repository); a verification-results report (KPI measurements and a recommendation); a technical-feasibility review (constraints and production requirements at scale); an executive summary (1–2 A4 pages); and a next-phase proposal (if moving to production).

Section 5: Team structure (worksheet 4)

Organize the team on both the client side and the vendor side for the duration of the PoC — an ambiguous structure invites delayed decision-making. Assign, on both sides, who owns: PM/progress management; business requirements; technical decisions; legal/regulatory; audit coordination; and user testing. A standard cadence: a weekly meeting attended by both PMs (30–60 minutes); a milestone meeting attended by the decision-makers at each phase transition (60–90 minutes); and an escalation path via Slack or Chatwork with a same-day response for urgent issues.

Section 6: Timeline and milestones (worksheet 5)

A standard PoC runs 4–12 weeks. Too short and verification stays shallow; too long and it risks becoming "a PoC for the sake of a PoC." A typical structure: Phase 1 (1–2 weeks) — finalize hypothesis and KPIs; Phase 2 (2–6 weeks) — confirm the prototype works; Phase 3 (1–2 weeks) — complete user testing; Phase 4 (1 week) — finish the decision report.

Section 7: Exit criteria and the next-phase decision (worksheet 6)

The most important design element of a PoC is its exit criteria. Agreeing on them in advance helps you escape sunk-cost thinking and limit losses. Typical exit criteria: KPI shortfall (two or more no-go thresholds unmet); schedule overrun (beyond the agreed PoC period); budget overrun (over 150% of the original budget); and external factors. Before deciding to move to production, confirm all of the following: KPIs across all three lenses (technical / user / business) have reached their go threshold; there is a reasonable expectation of securing the operating department and budget for production; legal/compliance review is complete; the security-audit vendor and budget are settled; and there is a reasonable expectation senior management will approve the production budget.

Talk to Netsujo

This template can be used entirely on its own, or alongside Netsujo's PoC-support work. We welcome consultations at the stage of "I'm struggling to narrow down the hypotheses" or "I'm not confident the KPI thresholds are right." Our standard scope of support includes:

Consult us on PoC design