72-second walkthrough
John Whitman / Proposal for Moder
Fictional case · Proposed product · No live system connection
Buyer to validate: Head of default servicing · User: Mortgage servicing specialist
Video unavailable. Read the illustrated walkthrough below or open the transcript.
A homeowner agrees to a mortgage catch-up plan.
Specialist approval precedes the product. The buyer to validate is the head of default servicing; the user is the mortgage servicing specialist.
The specialist carries the agreement into the mortgage account.
The same approved plan is ready for specialist review.
My proposal: make that work reliable and repeatable.
Proposed offering: approved-plan recording, exception resolution and outcome verification.
The approved plan and recorded date disagree.
First scheduled payment under repayment plan: approved 15 October 2026; recorded 8 October 2026. Fictional SYN-ACCOUNT-014 / SYN-PLAN-014; approved terms v3; record v7.
The specialist authorizes only the recording correction.
AI could prepare fragmented evidence for specialist review. The specialist validates the recording error and authorizes 8 to 15 October to match current approved terms. A governed update is submitted once against exact base record version 7.
Submitted does not mean completed.
Pending verification. Owner SYN-OPERATIONS-OWNER-01 retains the work. If fresh matching readback fails, work remains unverified with an owner.
The recorded plan date now matches.
In this fictional walkthrough the fresh authoritative record is version 8, same account and plan, and 15 October 2026. This is first plan-payment date verification only; it does not make the loan current or prove borrower or commercial value.
Buyer value must survive Moder’s full costs.
Test a packaged servicing offer with the head of default servicing. Include all assigned cases, nonuse, failure, QA and rework. Establish buyer value and Moder delivery, integration, platform, training, support and maintenance cost. Baseline, volume, adoption, quality and willingness to pay remain unknown.
A second customer must buy, use and deploy it.
BUY: a second customer purchases the bounded offer. USE: its specialists use it without bespoke coaching. DEPLOY: a different team deploys from documented configuration. All three tests are not yet run. Reuse of supported connectors, configuration, QA and training is a commercial hypothesis; measure whether it reduces deployment and support effort.
I’d lead the decisions that make this a product.
John proposes to lead buyer, scope, adoption, packaging, price and stop/expand decisions. Architecture leads technical design. John’s account: two product organizations, consumer lending and hands-on Foundry experience. Next discussion: first product and role.
Let’s discuss the first product and role.
Buyer, scope, adoption, packaging, price and whether to stop or expand. Second-customer Buy / Use / Deploy tests: not yet run.
Fictional walkthrough · Proposed product · No live system connection.