Patient Installment Payments Launch
I led the cross-functional launch of a patient installment-payments feature: instead of settling a "Pay Now" balance in one go, patients could split it into smaller payments over a few months. It spanned the Provider Portal and Patient Portal and integrated a third-party installment-payment provider. Because launching payments touches compliance, support readiness, and provider flows, a big-bang release was too risky, so I staged it through QA, an internal release, a beta, and GA. My job was to align Engineering, Product, Support, Sales, Legal, and Marketing and sequence the rollout so GA landed as a non-event.
A payments feature is a launch problem, not just a build
For patients: a "Pay Now" balance had to be paid in full in one transaction. For larger bills that was a barrier, and patients needed a way to break the balance into smaller payments over a few months without leaving the portal.
For the business: standing up installment payments touched far more than the checkout screen. It involved a third-party installment-payment provider, legal and compliance review, support readiness, and the provider-facing flows that could not be allowed to regress. Shipping it all at once to everyone would have exposed compliance gaps, an unprepared support team, and any provider-flow disruption to the entire customer base at the same moment.
The task: stage the rollout so each function was ready before the next audience saw the feature, every phase had a clear entry and exit gate, and the release stayed reversible the whole way to GA.
The launch charter
Before any rollout, I set a charter so every function was working toward the same launch and the same bar. Goal, scope, and success criteria were agreed up front and used to settle trade-offs as phases progressed.
Goal
One safe, staged path to GA for patient installment payments, with each function ready before the next audience, and no disruption to existing provider flows.
Scope
In: the patient-facing installment flow, provider-side visibility, support enablement, and the phased rollout mechanics across both portals.
Out: the third-party provider's internal underwriting, and any rework of the core billing system.
Success criteria
- check_circleClean QA pass before release
- check_circleSupport ready before customers
- check_circleNo provider-flow disruption
- check_circleReversible at every phase
The stakeholder map & RACI
Six functions touched the launch, and their ownership shifted by phase. I mapped a RACI so it was always clear who was responsible, who was accountable, and who needed to be consulted or kept informed at each gate.
| Function | QA | Internal | Beta | GA |
|---|---|---|---|---|
| Engineering | R | R | R | R |
| Product | A | A | A | A |
| Support | I | R | R | C |
| Legal | C | A | C | I |
| Sales | I | C | C | I |
| Marketing | I | C | C | R |
The phased rollout
The launch ran in four phases, each with an explicit entry and exit gate. Nothing advanced until the prior phase exited cleanly, so every audience saw the feature only once the function behind it was ready.
<2 mo
Launch to GA
20+
Internal pilot users
150+
Beta users
6
Functions coordinated
Phase 1
QA pass
Phase 2
Internal release
Phase 3
Beta
Phase 4
GA
Phase 1 · QA pass
The feature was hardened against the payment-flow edge cases before anyone outside the build team touched it.
Entry: feature-complete build across both portals.
Exit: test suite green, edge cases and error states covered.
Phase 2 · Internal release
20+ usersSupport, Sales, Legal, and Marketing dogfooded the feature and built the knowledge base and help articles, with screenshots, before any customer saw it.
Entry: QA exit met.
Exit: KB and help articles published, internal sign-off secured.
Phase 3 · Beta
150+ usersOpt-in through account settings, plus an ongoing beta list I piloted, so real patients used it while the blast radius stayed small and reversible.
Entry: KB live and support trained.
Exit: beta feedback triaged, no open blockers.
Phase 4 · GA
General availability was deliberately anticlimactic: every function was already ready, so turning it on for everyone was a non-event.
Entry: Go/No-Go all green.
Exit: monitored and stable, rollback on standby.
The Go/No-Go checklist
GA did not happen on a hunch. The launch cleared one gate, and every item had to be green to call it a Go. It made "are we ready?" an objective decision instead of an argument.
Risks & mitigations
IllustrativeI ran a living risk log and worked it every cadence. The point was not to list risks, it was to name an owner and a mitigation that the phased rollout actually enforced.
| Type | Item | Severity | Mitigation | Owner |
|---|---|---|---|---|
| Risk | Payment-flow edge cases (partial pays, failures) | Hardened error and edge-case handling, gated behind a clean QA exit before any release. | Engineering | |
| Risk | Provider-flow disruption from the new feature | Provider-flow regression in the Go/No-Go gate; feature-flagged so it could be disabled per portal. | Product + Engineering | |
| Risk | Support not ready when customers arrive | Internal release built the KB and trained support before beta; support-ready was a GA gate. | Support | |
| Dep. | Legal and compliance sign-off timing | Brought Legal in at the internal release as an accountable party so sign-off was not a last-minute surprise. | Legal | |
| Assum. | Adoption depends on clear patient messaging | Marketing owned GA messaging, drafted and reviewed during internal release and beta. | Marketing |
The rollback plan
Reversibility was a charter success criterion, not an afterthought. At every phase there was a clear way to turn the feature off and a documented decision for who made the call.
Feature-flagged: the feature could be disabled per portal without a deploy, so a problem in one surface did not force a full rollback.
Opt-in beta: participation was reversible from account settings, keeping the blast radius small while real usage was observed.
Trip-wires: monitoring thresholds defined ahead of time what "going wrong" looked like, so the call was based on signal, not vibes.
In-flight balances: documented how a patient already mid-plan was handled if the feature was disabled, so no one was left in an undefined state.
A launch that landed quietly
Non-event
GA, by design
Support-ready
KB shipped before customers
No regressions
provider flows intact
Representative outcomes; specific figures can be confirmed and added.
Qualitative outcome: patients gained a way to split a "Pay Now" balance into smaller payments, GA shipped without a fire drill because every function was ready, and support fielded fewer surprises because the knowledge base went live before the feature did. The phased approach meant any issue surfaced to a small, reversible audience first.
What I'd do differently
- check_circleInstrument adoption from day one. The phased rollout was sound, but adoption and funnel telemetry should ship with the beta, not after GA, so opt-in, completion, and drop-off are measurable while the audience is still small enough to act on.
- check_circleTighten the legal sign-off loop earlier. Bringing Legal in at the internal release worked, but pulling compliance review forward to the charter stage would have de-risked the timeline further and removed a dependency from the critical path.
- check_circleTemplatize the KB-before-beta playbook. The "internal release builds the knowledge base before any customer sees it" pattern was reusable. I would package the phase gates, RACI, and Go/No-Go checklist into a launch template so the next feature starts from a proven scaffold.