07 / PAYMENTS
Designing the path from monthly reimbursement to flexible, auditable payments
How I separated reimbursement calculation from money movement to get a new platform to market faster, while designing Direct Pay and more flexible payment cadence as the next phase beyond MVP.
Ship the financial truth first. Automate the money movement second.
THE PROBLEM
The new platform needed to deliver its core reimbursement value quickly. At the same time, customers were asking for more flexible payment options, and the existing Direct Pay process involved financial workflows that were much heavier than simply calculating what someone was owed.
The first problem was straightforward to state: use daily driving and program data to calculate a trustworthy reimbursement and give the customer what it needed to pay each employee.
Full Direct Pay changed the responsibility boundary. Once the product was responsible for moving money, it also had to account for funding, reconciliation, payout readiness, failures, corrections and auditability.
Putting all of that into the first release would have made the MVP more complete, but also much harder to ship.
The MVP delivered value quickly, but stopped at the handoff. Our next step was to extend the platform without slowing customers down.
DISCOVERY
Understand the operating system before redesigning it
I worked with internal operators closest to the existing payment workflow to map how reimbursement moved from driving activity through calculation, approval and eventual payment. We used workflow mapping and mockups to make the hidden operational steps visible, and we pressure-tested parts of the emerging experience with a small set of selected customers.
Calculating what was owed and moving the money were related problems, but they did not need to ship at the same time.
THE QUESTION WE NEEDED TO ANSWER
How do we deliver trustworthy reimbursement sooner without making full money movement a launch dependency?
Key Decision
Ship the financial truth first. Automate the money movement second.
Full Direct Pay in MVP
- Funding + payout dependencies
- Reconciliation complexity
- More operational risk at launch
- Slower path to core value
Ship calculation + payment-ready summary first
- Fewer launch dependencies
- Faster path to core value
- Preserves future payment architecture
- Direct Pay sequenced beyond MVP
Release sequencing
WHAT I DID
PAYMENT LIFECYCLE: TWO PHASES
We tell customers what to pay.
Direct Pay extends the model into money movement, with controls and auditability.
FLEXIBLE PAYMENT CADENCE: DESIGNED MODEL
Changing cadence changed more than the calendar
The designed model explored multiple reimbursement cadences beyond the monthly cycle. The important product problem was not adding more schedule options. Different cadences changed the surrounding workflow: when a reimbursement was ready, how approvals fit into the cycle, what funding had to be available and how the product moved from calculated reimbursement to payment-ready output. That meant flexible payment cadence had to be designed as part of the payment model, not as a scheduling toggle.
DIRECT PAY: RESPONSIBILITY BOUNDARY
Direct Pay changed the responsibility boundary
In the non-direct-pay MVP, the product calculated what each employee should be reimbursed and generated the information the customer needed to execute payment. Direct Pay extended the workflow further. If the platform was going to receive customer funds and pay employees directly, it also needed a coherent way to understand whether funding was available, whether amounts reconciled, whether payout was safe to proceed, and how failures or corrections would be handled and recorded. The goal was to define the financial control model so future money movement could extend the same source of truth rather than redefine it.
Moving from "tell the customer what is owed" to "execute the payment" changes the product's responsibility boundary.
THE TRADE-OFF
Chose
A smaller first release that stopped at trustworthy reimbursement and payment-ready output
Gave up
The completeness of owning end-to-end money movement on day one
Why
Direct Pay introduced funding, reconciliation and exception dependencies that did not need to block the platform's core value
What Changed
- Reimbursement calculation and payment-ready output could move forward without full Direct Pay as a launch dependency.
- Direct Pay and flexible payment cadence had been explored deeply enough through discovery, workflow design and mockups to be sequenced beyond MVP as next-phase design.
- Internal payment operators helped shape the workflows they would eventually use.
- Selected customer feedback informed the emerging experience.
- The future model accounted for approval, funding, reconciliation and exception states without forcing those requirements into the first release.