01 / Established prerequisite
Agreed repayment plan
Qualified specialist approval and borrower agreement already exist.
Outside the proposed productChapters · 1 of 5
Mortgage repayment plans
The plan is agreed. Get it recorded correctly.
A homeowner has agreed a plan to catch up on mortgage payments. A servicing specialist needs the record to reflect that agreement.
I’d choose what to build, prove its value with operators, and decide what becomes a repeatable product.
Buyer to validateHead of default servicing
Daily userServicing specialist
The work recordFictional example
Proposed product begins
02 / Specialist workspace
Check the servicing record
Inspect agreed terms. Resolve the exception. A human verifies and separately authorizes the exact correction.
Verified correction
Fresh exact readback required.
OR
Assigned follow-up
Keep an owner and next check.
Proposed outcomes—not completed work.
Does recording agreed plans create enough recurring checking, exceptions and rework to justify a product?
Volume, current cost and alternatives remain to be measured. This fictional example does not establish a Freedom defect.
The product hypothesis and where it begins
Approved-plan recording, exception resolution and outcome verification.
Homeowner seeks help → qualified specialist approves a plan → our proposed product begins. Borrower agreement and qualified approval are established fictional prerequisites. The product does not choose relief or approve a plan.
Test whether existing software or simple rules already solve the job economically. AI may help assemble fragmented evidence; a date discrepancy alone does not establish that AI is needed.
One fictional exception inside the whole job
Check the plan. Authorize the correction. Verify the record.
The original fictional case starts with a specialist-approved, borrower-agreed repayment plan. A recording discrepancy needs human verification before any correction.
Approved source→Exact proposed change→Fresh readback or assigned follow-up
Where AI could earn its cost: help specialists assemble fragmented plan evidence. Compare it with existing software and rules. This fictional demo illustrates proposed correction controls; AI evidence assembly remains a proposal.
Measure before calling it a business
Account for the whole job.
Measure every assigned case—not only the ones that use the product or end successfully.
Quality and adoption
Include already-correct records, nonuse, rejection, failure, escalation and manual resolution. Track false completion and unauthorized changes, not just click-through.
Time and full cost
Include specialist work, QA, rework, support, integration, platform, training and maintenance. Separate external waiting from labor.
Baseline, volumes, adoption and outcomes: Unknown · To measure.
Packaged offer · Hypothesis to test
Test a packaged servicing offer with the head of default servicing: approved-plan recording, human-authorized correction and verified results. The commercial opportunity is to reuse supported connectors, configuration, QA and training across customers. Measure whether that actually reduces deployment and support effort, leaves buyer value and covers Moder’s full costs.
Operator adoption and quality, all assigned cases and willingness to pay remain separate tests. A verified fictional field correction is not proof of broader borrower or business outcomes.
Then test a price: does it leave a credible benefit for the buyer and cover Moder’s full delivery and support cost?
Test a price · Optional first-year model
Can this deal work for both sides?
Assumptions only · First-year model. Blank inputs are unknown, not zero.
A cost corridor is not willingness to pay. Required returns and service commitments may narrow it. This model does not recommend a price or an investment decision.
Product leadership, with explicit decisions
Make the commercial and operational choices.
I’d turn selected servicing jobs into products Moder can sell and deploy repeatedly: choose the buyer and scope, test where AI earns its cost, and own adoption, packaging, price and stop-or-expand decisions. Architecture leads the technical design.
No decision made
Choose a decision to explore.
The evidence decides whether to stop, narrow, improve or expand. No economic input automatically selects one.
Two product organizations · Consumer-lending experience · Hands-on Foundry work John’s account
At Rockfish, commercial opportunities were grounded in technical scope, estimates, costs and program plans. John’s account
John’s relevant experience
I’ve built two product organizations and a full technology PMO. I bring consumer-lending experience and hands-on Foundry work. At Rockfish, our TPM group connected commercial opportunities with technical expertise, scope, estimates, costs and full program plans.
John’s account; no claimed outcome metrics are supplied here.
Architecture discovery dependencies
Architecture must establish the authoritative plan schema, writable API, permissions, conditional update and fresh readback semantics. This prototype’s exact-version-plus-one rule is synthetic, not an assertion about a live servicing system.
Foundry, Ontology and governed Actions are proposed implementation possibilities; AIP may assist evidence assembly. AI FDE/Pilot support is proposed where available. Architecture verifies entitlements and technical fit before committing.
Later portfolio hypotheses
Investor delivery-data exceptions and an insurance repair next-step product are separate hypotheses. Each needs its own buyer, bounded scope, evidence and economics.
Test without the original team
Can another customer buy, use and deploy the same product?
BUY
Not yet tested
Independent demand
A second independent customer chooses and pays for the same bounded product.
USE
Not yet tested
Independent adoption
Its specialists use it without bespoke coaching from the original sponsor or builder.
DEPLOY
Not yet tested
Independent implementation
A different team deploys the same version through documented supported configuration, meeting the same quality and economics tests with normal support.
Reusable core: agreed-plan representation, comparison, review, action, readback, exceptions, metrics and documentation.
Supported configuration may cover plan/investor templates, mappings, connectors, roles and calendars within tested bounds. A fundamentally new state machine for each customer is evidence against reuse.
Let’s discuss the first product and the role.
No second-customer test has run. A copied demo or logo would not establish repeatability.