Method
How I run programs
A stablecoin program is a lifecycle: discovery, POC with success criteria, validation, then a scale or no-scale business case. Here is CryptoPos run through that lifecycle as if it were a funded program — gates, dependencies, risks, KPIs, governance. Diagrams over paragraphs.
Planning artifact — illustrative program, real method
Milestone map
Four gates. Each has a door that closes.
Entry criteria stop a stage starting on vibes; exit criteria stop it ending on momentum. Durations are illustrative planning values, not a record of anything that ran.
Discovery
≈ 4 weeks (demo)
- Entry
- Named merchant segment where card economics pinch (small-ticket, high-frequency)
- Problem hypothesis written before any solution work
- Exit
- 20+ merchant interviews synthesised; acceptance blockers ranked by cost, not anecdote
- Success criteria for the POC agreed before the POC exists
Kill here if: the pain ranks below #3 for the segment.
POC
≈ 6 weeks (demo)
- Entry
- Success criteria signed; dependency owners named (see graph below)
- Compliance review scheduled, not assumed
- Exit
- Working prototype covering charge, settle, refund — the unhappy path included
- Unit economics modelled per segment against the card benchmark
Kill here if: modelled all-in cost can’t beat cards for any real segment.
Validation
≈ 8–12 weeks (demo)
- Entry
- Pilot cohort sized for signal, instrumented for the KPI tree
- Risk register mitigations in place for every high-likelihood row
- Exit
- North-star read at day 90 with confidence intervals, not anecdotes
- Dispute & refund incidents documented with resolution times
Kill here if: repeat acceptance decays past week 6 despite incentives off.
Scale / no-scale
Decision, not a phase
- Entry
- Validation data complete; costs restated with pilot actuals
- Exit
- A business case that survives finance review — or a written no-scale memo with what we learned and what would change the answer
A well-argued no is a success outcome. Zombie pilots are the failure mode.
Dependency graph
The POC is the easy node.
The sequencing insight most POCs miss: the compliance review is the longest pole, so it starts first and its findings feed partner selection — not the other way round. Chain finality and tax reporting don’t block the build, but they bound what the pilot may promise merchants.
Risk register
Six ways it dies, owned in advance.
| Risk | Likelihood | Blast radius | Mitigation | Owner |
|---|---|---|---|---|
| Stablecoin depeg during pilot | Merchant trust — unrecoverable for the cohort | Auto-sweep thresholds on by default; depeg circuit-breaker pauses acceptance | Treasury PM | |
| Off-ramp partner outage | Settlement delays across all merchants | Second ramp contracted at pilot start; failover drilled, not documented | Partnerships | |
| Compliance finding lands late | Program pause; credibility with legal | BSA review is gate-1 entry criterion; findings tracked as blocking work items | Program lead | |
| Dispute volume exceeds refund design | Merchant losses; support load | Refund reserve sized at 2.5× expected disputes (demo multiple); weekly incident review | Risk PM | |
| Merchant key compromise | Single merchant, total loss | Qualified custody default for pilot; self-custody requires explicit opt-in + limits | Security | |
| Rewards economics invert | Quiet margin bleed per merchant | Margin-floor cap in configurator; redemption cost surfaced weekly to merchants | Product |
Likelihoods are planning judgments for an illustrative pilot, not measurements.
KPI tree
One north star, four drivers, named events.
Every leaf carries its instrumentation — a metric without an event name is a wish.
- Activation onboarded → first live charge; friction diagnostic merchant_onboarded · first_charge_settled · time-to-first-charge
- Settlement mix share kept as stablecoin vs auto-converted — revealed trust settlement_policy_set · sweep_executed{policy, threshold}
- Rewards loop health redemption rate inside margin floor = the incentive is working and affordable reward_accrued · reward_redeemed · margin_floor_hit
- Dispute & refund load leading indicator of the missing rail hurting; rises before losses do refund_requested{unit} · dispute_opened · resolution_time
Governance
Seven gates, humans at every one.
This is the review process I actually run — applied across four platform initiatives and 104 acceptance criteria. Nothing advances to the next gate without a named human signing the previous one. It is deliberately boring; boring is what makes speed safe.
The same discipline runs this site’s honesty rules: every number on every page is either sourced or labelled illustrative, and the gaps are logged openly in the repo rather than papered over. Process is portfolio.