How I got here. The approach story walks from the prompt to this pick: what I sized, what I cut, and what I kept as a follow-on. Start there if you want the path in order.
Explore. Pre-approval estimate architecture, experience, and practice funnel lift, in this workbench.
Optional deep notes: architecture prose · partner copy · lift assumptions
Optional jump list navigation
Read the ask
Own the roadmap. Win = more businesses get funded through partners. Pick one thing to build and go deep.
Learn how it works
Partners show financing. Kanmon lends. Path: apply, get an offer, accept, and get paid. Examples make that real.
First AI idea, then set it aside
The assistant suggested “show financing at the right moment.” I set it aside: that pitch is common, and for this case I assume financing is already visible enough on live partners.
Working constraints I am using
One product manager. Low volume. Little or no A/B testing. Credit and data teams own approval models. Texting is blocked for now.
Where to focus
Get more people through the steps on live partners, not hunt new logos first. Assume financing is already visible enough. Lead with a pre-approval estimate and a shorter application so more people finish applying; don’t try to own credit models.
Rough size of the problem
Example month: ~51 funded. ~288 people start and quit before submitting. Flow chart shows where they leave.
Landed on the idea
A pre-approval estimate and a shorter application, so people who started can finish in the form more often, and good-fit customers get better invites. Recovery and preventable-decline fixes were seriously considered and ranked below.
A pre-approval estimate and a shorter application
Partner-held facts can shorten the form and support a light fit check. The same direction also helps invite more of the right people into the funnel. Soft language only, not a hard loan promise.
Still to do
Walk it end to end.” pre-approval estimate screens live under Experience; Screens page still shows the old “right moment” archive.
More small businesses get funded through a partner’s product, not more traffic to Kanmon’s website. Pick one idea and go deep on it.
- Small company, one product manager, low volume, little or no A/B testing
- For this case: financing is already visible enough on live partners (reopen if that is wrong)
- Credit and data teams own who gets approved; product can invite softly, not promise dollars
Companion files
- Live idea, reasoning · abandon sizing · pre-approval estimate notes · partner types · checklist
- pre-approval estimate package, · · · optional notes: prose · copy · lift math
- Funnel, simulation · number sheet · · standalone
- Case core, writeup · framing · priorities
- Partner paths, · summary
- Process, · map · changelog
We care about how you think, not whether you arrive at one specific answer. Specifically, we’re paying attention to:
| Looking for | Where in this workbench | |
|---|---|---|
| How you structure an ambiguous, open-ended problem | Solve → Ideas → Frame (lever equation before feature lock) | |
| Your product judgment and instincts | Solve → Bet (hyp + kill criteria + alternatives cut) | |
| How you prioritize when you can’t do everything | Frame levers ranked · Bet picks one · Constraints 4–6 wk MVP | |
| How you reason about metrics and trade-offs | Constraints + Prove (conversion ↔ risk; funded vs holdout) | |
| How clearly you communicate your thinking | Whole path: Case → Ground → Solve (Ideas→…) → Show; hour beats on Show | |
| Any mockups, wireframes, prototypes to convey your thoughts on the feature | Solve → Design (SMB · offer · partner admin) | |
| Your AI workflow, what you prompted, where the model helped vs where you pushed back, what you threw away | Show / AI → #effort process log (narrative beats) | |
| On-the-fly: financing funnel (apply → offer → accept → fund) | Ground → Space (#guide-funnel) · Journeys E2E · Prove funnel | |
| On-the-fly: conversion vs risk tension | Constraints (#conv-risk) · Prove trade-off cards | |
| On-the-fly: distribute via partners, not only direct | Plain (origination callout) · Space · Journeys (Cleo / PingPong / Cin7) |
Also from guide (format): show thinking as mockups / Loom / prototype / wireframes · AI costs covered if needed.
Your annotations on the what the brief lists list, use these while framing in Solve → Ideas. Do not overwrite the brief above.
- Structure ambiguous problem → grounding on the space, how the business works
- Product judgment → levers in UI/UX, visibility, incentives for different parties, credit risk models, constraints on capital Kanmon uses to fund, regulatory constraints
- Prioritize → high leverage × relative risk for impact, back into sizing; effort and complexity; sequencing and gradual unlocks + growth
- Metrics / trade-offs → value, effort + time, regulatory complexity (plus conversion↔risk from the brief)
Also: clear communication while presenting · mockups. Work the lens in .
- Up to 1 hour, live, conversational working session
- They share a short prompt; discuss your proposal on the call
- Use AI freely (Claude / GPT / Gemini), they’ll cover cost if needed
- Show thinking however it lands: mockups, Loom, prototype, wireframes
- For a product role here, how you work with these tools is as interesting as the conclusions
It will help to be comfortable reasoning about:
- Financing funnel: a business applies, receives an offer, accepts it, and gets funded
- Conversion vs risk: approving the wrong borrower is expensive, growth and credit quality pull against each other
- Partner distribution: embed on the partner’s platform, not selling financing only as a direct Kanmon channel
Ground these in Plain + Space (+ E2E companions). Constraints locks the trade-off for solutioning.
- Kanmon = embedded lending infrastructure for vertical SaaS, marketplaces, FIs
- Products: term loans, LOC, invoice financing, purchase-order financing
- Origination = SMB on a partner platform takes financing
- More originations ≈ more partners live · better surface · more eligible converting · broader product set
- I can structure levers without jumping to a feature
- I can say why I cut logos / new products / ML day one
- I can walk apply → offer → accept → fund inside a partner
- I can name the conversion↔risk tension without Credit owning my UX
- Wireframes + AI pushback + thrown-away are one click away
Working capital inside partner software
- Partner (SaaS / marketplace / payments) keeps the relationship and brand
- Kanmon underwrites, funds, complies, services, lender of record
- SMB gets cash for invoices, suppliers, growth, without leaving the partner tool
- Public live examples: PingPong · Cleo InvoicePay
- Products: term · line of credit · invoice · AP / PO-style financing
Grow funded loans that start inside partners
Success metric = originations through partner platforms, not traffic to Kanmon.com.
- Map the big levers that move that number
- Pick one feature and go deep (judgment > laundry list)
- Show how you’d measure it, and not blow up credit quality
- Bring visuals + how you used AI to get there
- Partner, wants revenue + retention, afraid of looking spammy
- SMB, wants cash at the moment of need, low friction
- You can’t optimize one and ignore the other
Concrete journeys: Journeys stage · E2E HTML (Cleo · PingPong · Cin7) · Ecosystem extension · Revenue + when lending happens.
A pre-approval estimate and a shorter application, makes finishing the application easier while people are still in the form, and helps invite more of the right people into the funnel. Soft ≠ a hard loan amount. “Right moment” ads are set aside for this case.
Open · ·
The loan lives inside software the SMB already trusts. Partner is the storefront; Kanmon is the balance-sheet lender.
- FACT Capital + credit risk on Kanmon’s books (their positioning)
- FACT Partner monetizes via rev-share / bps pitch (LinkedIn; take rate unpublished), not a kanmon.com FAQ line
- FACT Payments data helps underwriting when present, not required to start
Depth: Revenue + partner model · summary (who pays · when lending happens · Cleo path). Incentives: deep dive · summary (SMB · partner · gaps).
Guide’s on-the-fly comfort: a business applies → receives an offer → accepts → gets funded.
Origination equation adds upstream discovery: Eligible → See / surface → then the guide funnel. Don’t confuse “clicked CTA” with funded.
- Term, lump sum, fixed payback (growth / inventory)
- LOC, ongoing draw for working capital
- Invoice, get paid on AR sooner (Cleo InvoicePay)
- AP / PO, pay suppliers / purchase orders, preserve cash
- Gross yield from interest / fees on funded book
- Credit losses + cost of funds sit on Kanmon, scale with originations
- HYP Spiking apps without soft eligibility can look good on volume and bad on losses
- Growth PM owns invite timing/UX; Credit owns who gets an offer
- Direct-ish: Parafin, YouLend, Liberis
- Adjacent: Pipe, Capchase, Clearco, eCapital, Lendflow
- Platform wallets: Stripe Capital, Amazon/Shopify lending, Brex, compete for SMB wallet
- Kanmon angle (self-report): multi-product + licensed balance-sheet lender + no payments prerequisite
- Partner: monetize + retain; brand-safe surfaces; insights for QBRs
- SMB: cash without leaving the tool; clear offer; fast fund
- Quiet partner problem: integration shipped, financing rarely seen → originations stall
- BRIEF Distribute through partners rather than selling only direct
Incentive map + gaps: incentives summary · full. Walk a real path: Journeys stage · E2E summary (Cleo InvoicePay · PingPong · Cin7).
Table stakes vs rare · source-check Moments
Table stakes
- White-label embed + provider holds risk/capital/compliance
- Pre-approved-style offers · marketing kits · category rev share (Kanmon bps = LinkedIn pitch)
- Integration ladder · progressive limits / renewals
Rare / Kanmon-relevant FACT
- Multi-product portfolio (term + LOC + invoice + AP)
- No payments prerequisite underwriting path
- Workflow invoice/AP surfaces (live partners)
- Liberis leads publicly on contextual offer APIs (Adverts + webhooks). Kanmon site does not
Capital Moments narrative
- COMMODITIZED Liberis, Parafin, Stripe, Defacto, Pipe all sell capital-in-platform / at the right moment
- Don’t claim invention of contextual offers
- Differentiate via vertical workflow objects + product routing and/or quiet-partner ops, after funnel diagnosis
Top research questions (P0)
- See → start → fund for 2–3 partners; where quiet partners stall
- Offer/trigger APIs already behind kanmon.dev?
- Hole = placement vs GTM/CS vs credit?
Peers: Parafin, Pipe, YouLend, Liberis, Stripe Capital, Defacto, finmid. Depth: kanmon-feature-landscape-summary-20260729.md
Series A · ~21 · sole PM today
- 4–6 week MVP = one wedge + one partner pattern.
~$360–660k/mo OpEx · base ~$500k
- Fully loaded people + overhead @ ~21 FTE
- Excludes cost of funds, credit losses, warehouse
- Series A dollar amount not public, don’t invent
- Bias to high-learning wedges; don’t growth-hack apps Credit can’t fund safely
- Surface at cash-need · lower start friction
- More eligible SMBs entering apply
- Partner intensity that actually gets seen
- Wrong borrower is expensive (guide)
- Soft invite; Credit owns offer/fund
- Holdout + credit band on same scoreboard
- Win originations inside an agreed credit-quality band
- Refuse victory on clicks / starts alone. Prove uses incremental funded
- Partner controls intensity / brand feel
- Moments need reliable partner events (invoice aging), data review gates rollout
- Disclosures / marketing copy Legal-gated
- 1 moment: invoice overdue → invoice financing
- Inline CTA + partner intensity + soft eligibility rules
- Full moment catalog · ML ranking · $-teases
- Multi-vertical marketplace
- Say: after proof + event volume + credit capacity
8 solutioning guardrails
- FACT CA CFL #60DBO-144925 cited; multi-state claimed; KYC/KYB/AML on Kanmon
- ECOA still applies to business credit; UDAAP risk on in-product marketing claims
- MVP stack: event → soft eligibility → CTA → existing apply → funnel events + holdout
- Not realistic yet: ML ranking, cross-partner experimentation platform
Deep dive files: kanmon-market-research-20260729.md §§11–16 · kanmon-market-summary-20260729.md
Earlier framing and pointers notes
Organized notes: numerator/denominator, funnel drop-off, recovery, partner show-logic, pre-auth.
- Ambiguous, ground how the business works (partner distributes, Kanmon lends, funded = originations)
- Judgment. UI/UX, visibility, incentives, credit models, capital, regulatory. PM feature vs Credit/Capital/Legal?
- Prioritize, impact vs risk, sizing, effort, gradual unlocks and growth
- Metrics, value, effort/time, regulatory complexity (plus conversion vs risk)
Working constraints: sole PM, low volume, little or no A/B, UW+DS own models; factoring/BNPL later, not default MVP. Case what the brief lists stays on Case.
Not “we think this feature is good.” Fill: problem, lever, outcome metric, counter-metric/risk, effort, sequence, Feature or Product-line, money touch.
Low volume: save N potential funded per period, not “+X% at scale.”
Where I would focus first
In the simulation: about 51 funded per month; about 40% of starters submit (about 288 quit mid-form). A roughly ten-point finish-rate lift is on the order of fourteen extra funded / about $230–250k financed that month. · simulation
A pre-approval estimate and a shorter application
Easier to finish while still in the form
Preventable decline plugs
Decision experience (no model change)
Simple ledger: completes, preventable vs true-risk declines, funded in-box
Risk model / credit box changes
Partner show-logic / “right moment” ads
What I would do first, and what waits
| Order | What it is | Where in the funnel | Impact | Effort | Risk |
|---|---|---|---|---|---|
| P0 | Pre-approval estimate, and an application short enough to finish the one I chose. Also helps bring people in. |
Start to submit | High | Medium | Medium |
| P1 | Fix declines caused by bad or missing information people who finished, then got turned down for a fixable reason |
Submit to approve | Medium to high | Low to medium | Low |
| P2 | Bring back people who dropped out mid application save their progress, invite them back |
Start to exit | Medium | Low | Low |
Why this order: P0 moves the biggest number and also helps the top of the funnel. P1 rescues people who did all the work and were turned away for something fixable, so they are closest to funded. P2 helps too, but those people are further away and less committed.
The same thing, said plainly
Working theories (rough, earlier) archived
Partner-only GTM; originations = funded via partners
Capability vs incentive, diagnose first
Portal ≈ downstream CVR; leverage often upstream
Funnel × credit box × capital
Biggest fight: volume vs risk vs partner brand
Invoice/AP = embedded-native core
Upstream object CTAs can move see→start, falsifiable; not default under A2
Originations = move numerator or denominator
Partner show-logic, if I don’t need funds, do I see Kanmon?
Kanmon owns customer from *.kanmonhq.com land
Every opportunity counts (low volume)
Goal = funnel throughput, not new logos
Visibility assumed solid (partners incentivized)
Open questions archived
- Where does each quiet partner stall: see / start / offer / fund?
- Is *.kanmon.com portal eligibility-gated or open educate/apply?
- Partner admin intensity / rev-share, felt or pitch-only?
- Capital capacity vs credit-box tightness, which binds first?
- Offer/trigger APIs already behind kanmon.dev?
- What particular project is planned for a new hire? Factoring/BNPL timing vs live-partner originations?
- Impression / CTA / click-to-convert data from partners? Recovery campaigns for abandoned apps?
- Non-risk declines, holes to plug? Multi-product eligibility + cross-partner apply awareness?
- Soft pre-auth / partner-data share / pre-fill?
- Share of stalls = identity / KYB data quality? Entity-resolution vendor today?
Lead cards
The two lead cards below are the proposed stack behind My pick. “Right moment” and other demotions sit under Thrown away.
A pre-approval estimate and a shorter application
Smoother submit, and better invites for good-fit customers
A pre-approval estimate and a shorter application so more people finish while still in the form
One capability that helps finishers finish and invites the right starters
Other feature areas archived
Identity resolution to raise complete KYB and cut preventable identity rejects
SMB pays fees for speed / soft pull / stay-in-workflow / invoice·AP control. Partner gets rev-share pitch (% unpublished) + retention / no credit risk. Kanmon gets yield − losses − share; assumes credit risk.
priorities · framing · incentives · exploration park
Education: KYB = Know Your Business vs KYC. Soft pull + bank + KYB leads to a decision.
My raw notes
These are my working notes on the problem, straight from when I first read the prompt. I only added the section headings and put like thoughts together. The words, and the half-formed bits, are mine. Everything in the case traces back to something here.
What the interview is assessing
- How you structure an ambiguous, open-ended problem – grounding on the space, how does the business work
- Your product judgment and instincts – there are levers in UI/UX, there are levers in visibility, there are incentives for different parties, there are credit risk models, there are maybe constraints on the capital that Kanmon uses to fund, regulatory constraints
- How you prioritize when you can’t do everything – identify high leverage x relative risk for impact – back into sizing; consider effort and complexity, consider sequencing and gradual unlocks + growth
- How you reason about metrics and trade-offs – value, effort + time, regulatory complexity
- How clearly you communicate your thinking
- Any mockups, wireframes, prototypes to convey your thoughts on the feature
What Kanmon is / how the business works
Kanmon offers embedded lending - basically they enable businesses that benefit from their customers having funds, to extend funds to those customers for liquidity
- I.e. a business needing to purchase stock or supplies ahead of the funds they have on hand
- The existing product set spans term loans, lines of credit, invoice financing, and purchase-order financing.
The prompt (single success metric = originations)
If you owned Kanmon's product roadmap and your single success metric was originations driven through our partner platforms, how would you think about the biggest levers?
"An origination happens when an SMB on a partner's platform takes financing. More originations come from some mix of: more partners live, partners surfacing financing more effectively, more eligible SMBs converting, and a broader product set that fits more needs.”
- The existing product set spans term loans, lines of credit, invoice financing, and purchase-order financing.
- An origination happens when an SMB on a partner's platform takes financing. More originations come from some mix of: more partners live, partners surfacing financing more effectively, more eligible SMBs converting, and a broader product set that fits more needs.
Framing: numerator / denominator
How I understand this is that we need to understand what levers we have to net an increase in originations
We can change the numerator or the denominator-
Denominator is top of funnel (this can be defined as candidate customers for application, candidate customers that clicked through - or wider, all customers that use the partner platforms) - this is a function of partner customer volume; customers that see the opportunity; customers that are good candidates + have the opportunity/need to apply
Presumably some people click but abandon (due to UX friction - [patterns, clear copy], was just curious, time commitment, don’t have necessary info on hand)
Numerator is any SMB sourced from a partner that is issued funds - this is really a function of [UX + application recovery] + the credit risk model
- Really interested in recovery campaigns; you didn’t finish (abandon cart); as well as any tooling that can streamline the application experience
- Really interested in application drop off
- Really interested in the logic partners have for showing Kanmon - if I don’t need funds, do I see Kanmon?
For exercise purposes I will consider Kanmon the owner of the customer from that point that the customer lands on [*partner specific portal].[kanmonhq.com](http://kanmonhq.com)
Funnel drop off
Funnel drop off
See -> Click - anyone that doesn’t click
Click -> Abandon before starting - anyone that bounces
Start application -> exit - anyone that didn’t complete for some reason
[unsure of pickup where you left off recovery campaigns]
Application submission -> rejection - I assume people get denied for various reasons but fr any reason thats not risk related, thats an opportunity to plug a hole
Also, need to consider that the funnels may be shaped slightly differently by product line - and customers may have optionality on product they choose (more than one product to choose from)
Also, curious about eligibility for multiple product lines at once - and then applying through different partners for the same or different product lines - obv Kanmon can detect internally but the customer may not know early in the funnel
Areas of opportunity
So there are a few areas of opportunity that make sense to explore
What leverage we have within the partners - this can be funding a campaign, this can be
From a low hanging fruit standpoint - who’s attempting and not converting? Do we receive success reporting from the partner? Do we know how many people land? Do we have impressions of CTA views?
- Do we have data on the business segments that are clicking -> converting and can we see who’s not converting?
- When a partner wants a customer to be successful, how do they leverage Kanmon? And are there any post engagement follow up from partners to their customers proposing Kanmon or lending as a solution?
- Can SMBs independently engage Kanmon with attribution from a partner?
Can we pre-authorize SMBs based on their relationship with the partner? Can we roll out a pre-check program that enable customers to authorize partners to share their info to Kanmon for pre-auth? For lending, like a soft check or at least pre-fill applications
Cut first: hunting logos, launching a brand-new product on day one, treating “right moment” as the whole answer, or leading with email chase-back.
Wait on changing who gets approved, and on fixing every decline reason with one tool.
Do now: a pre-approval estimate and a shorter application so people who already started finish the form more often, and good-fit customers get clearer invites.
Finish rate by partner, and the top reasons people quit mid-form.
Which customer fields partners already have for prefill.
If almost everyone already finishes, this is the wrong lead.
·
In the simulation, only about four in ten people who start an application finish it. These are people who already showed interest. They leave because the form asks for things they have to go and find, and because nothing tells them whether it is worth the effort.
A real number answers "is this worth my time". The data behind that number then removes most of the form. Two problems, one piece of work.
It is an estimate, not a promise. Underwriting and data science decide who gets approved and on what terms. A firm offer of credit carries extra obligations, so the wording stays honest: "you could be eligible for up to", never "you are approved for".
Success is more funded originations through partner platforms. For this case I assume financing is already visible enough on live partners, so I set aside “show it at the right moment” as the main bet. I am also treating the company as small-PM and low-volume: little or no A/B testing, and underwriting plus data science own credit models.
In the simulation, about 51 loans fund in a month, and about 288 people start then quit before submitting. That mid-apply quit pool is the largest product-owned group of people who already expressed interest. The flow chart on the Numbers page shows those drop-offs by partner and product.
A pre-approval estimate and a shorter application is the feature I would ship first. People who start have already raised their hand; shortening the form and a light fit check is the strongest product move under the visibility assumption.
In the simulation, if the share who finish after starting rises by about ten percentage points, that is on the order of thirteen to fourteen extra funded loans in a month, or about two hundred thirty to two hundred fifty thousand dollars more financed volume that month. That is a medium-size estimate, not a promise.
The same work also supports better upstream invites for good-fit customers, so a pre-approval estimate and a shorter application helps both finishing and starting well.
I would diagnose the top reasons people quit mid-form: handoff or login friction, long or confusing forms, bank-link problems, business-identity stuck points, and “save for later” with no return.
I would confirm which partner fields can be shared for prefill, with consent, starting with one rich partner type such as invoice or wallet workflows.
If almost everyone already finishes applications, or if most quitters were never eligible, I would stop leading here.
Application recovery (email and one-time code to resume). I took this seriously. It can still bring back people who leave with a partial application. I did not make it the lead because, in the simulation, most starters never finish. When finish rates are that low, preventing quit while someone is still in the form is the better first move. Recovery stays as a follow-on for people who still leave after in-form improvements.
Preventable declines after submit. I took this seriously too. Some declines come from bad or missing data rather than true credit risk, and those are worth fixing with validation and clearer data capture. I did not make it the lead because that pool is smaller and later than mid-apply quit. There is also no single fix for every decline reason. I would diagnose decline reasons after the finish-rate work, not before.
“Show financing at the right moment.” That was the assistant’s early suggestion. I set it aside for this case because I am assuming visibility is already solid enough, and because a generic “right moment” story is widely used by peers. If visibility turns out to be weak, I reopen that lane.
If nearly everyone who starts already finishes, the opportunity is too small to lead with.
If most people who quit were never going to be eligible, polishing the form will not help enough.
If financing is barely seen on partner platforms, I would fix visibility before finishing-the-application work.
Changing who gets approved (underwriting and data science own credit models). Launching brand-new loan types such as factoring or buy-now-pay-later as the first few-week project. Treating the old “right moment” wireframes under Screens as the answer, those are an archive.
Information the partner already has, turned into a per-customer answer: eligible or not, and for roughly how much. Kept up to date, and handed back so the partner can show the flow to the customers who qualify. Everything after that is the normal application, just much shorter.
4 · End-to-end sequence
Partner calls soft; soft returns state + token; apply still goes to UW for the hard path.
sequenceDiagram
actor SMB as Merchant
participant Partner as Partner app
participant Soft as pre-approval estimate service
participant Apply as Kanmon apply
participant UW as Underwriting
SMB->>Partner: Works in product
Partner->>Soft: SoftCheck with partner customer id and context
Soft-->>Partner: Soft state plus prefill token
alt Soft strong or weak
Partner-->>SMB: Soft invite or quiet check CTA
SMB->>Apply: Open apply with prefill token
Apply-->>SMB: Prefill form
SMB->>Apply: Finish and submit
Apply->>UW: Hard decision path
UW-->>Apply: Offer or decline
else No need or not now
Partner-->>SMB: Dismiss without shame
else Soft exclude or data unavailable
Partner-->>SMB: No soft claim or standard apply only
end
1 · Systems and trust boundary
pre-approval estimate ranks invite and hydrates apply. It does not mint a hard approval amount. UW and credit models own the hard decision after submit.
flowchart TB
subgraph PartnerZone["Partner trust zone"]
PApp["Partner app"]
PData["Partner features and events"]
end
subgraph SoftZone["Kanmon soft layer - design assumption"]
SoftSvc["pre-approval estimate service"]
Prefill["Prefill token store"]
end
subgraph HardZone["Kanmon hard credit - UW owns"]
Apply["Kanmon apply"]
SoftPull["Soft bureau pull on apply"]
UW["UW and credit models"]
Fund["Fund and service"]
end
PApp -->|"customer id plus context"| SoftSvc
PData --> SoftSvc
SoftSvc -->|"soft state plus prefill token"| PApp
SoftSvc --> Prefill
PApp -->|"open apply with token"| Apply
Prefill --> Apply
Apply --> SoftPull
SoftPull --> UW
UW --> Fund
SoftSvc -.->|"does not set hard amount"| UW
2 · Who enters pre-approval estimate
Program eligibility decides who gets a soft check. Cash need decides when to nudge, not whether soft runs.
flowchart TD
Start["Partner surface in financing program scope"] --> Prog{"Program eligible?"}
Prog -->|no| Quiet["No soft UI or quiet unavailable"]
Prog -->|yes| Run["Run pre-approval estimate for everyone in set"]
Run --> NeedNote["Need cash is for timing only - not a soft gate"]
NeedNote --> Soft{"Soft state?"}
Soft -->|strong| Invite["Invite plus prefill path"]
Soft -->|weak| Careful["Careful check CTA or quieter invite"]
Soft -->|unavailable| Std["Invite without soft claim - more fields later"]
Soft -->|exclude| Suppress["Suppress campaign - no eligibility promise"]
Invite --> NoNeed{"Merchant needs financing now?"}
Careful --> NoNeed
NoNeed -->|yes| ApplyPath["Open apply with prefill"]
NoNeed -->|no| Dismiss["Dismiss snooze or no-need - no shame"]
3 · Where soft plugs into the funnel
Bird 2 helps See and Start. Bird 1 shortens Apply via prefill. Offer and Fund stay on hard UW.
flowchart LR See["See"] --> Start["Start"] Start --> Apply["Apply"] Apply --> Submit["Submit"] Submit --> Offer["Offer"] Offer --> Fund["Fund"] SoftInv["Soft invite Bird 2"] -.-> See SoftInv -.-> Start Prefill["Prefill shorter form Bird 1"] -.-> Apply HardUW["Hard UW unchanged"] -.-> Offer HardUW -.-> Fund
5 · Data flow overview
Partner sends features and events, not a raw ledger. Soft returns coarse state, never hard score or approve amount.
flowchart LR
subgraph In["Partner to Kanmon"]
ID["Identity seed"]
Perf["Performance features"]
Obj["Object cash context"]
Risk["Partner risk flags"]
Cons["Consent"]
end
Soft["pre-approval estimate service"]
subgraph Out["Kanmon to partner"]
State["Soft state codes"]
Tok["Prefill token"]
Evt["App lifecycle events"]
Supp["Campaign suppress"]
end
ID --> Soft
Perf --> Soft
Obj --> Soft
Risk --> Soft
Cons --> Soft
Soft --> State
Soft --> Tok
Soft --> Evt
Soft --> Supp
6 · Product overview
Same soft contract; the trigger object and partner moment change by archetype.
flowchart TB Soft["Pre-approval estimate plus shorter application"] Soft --> A["A Invoice EDI"] Soft --> B["B Wallet"] Soft --> C["C ERP PO"] Soft --> D["D Payments"] Soft --> E["E Staffing"] A --> ObjA["Object: unpaid invoice"] B --> HubB["Hub: Financing tab plus volume spike"] C --> ObjC["Object: PO or stock risk"] D --> VolD["Volume plus boarding flags"] E --> PayE["Payroll vs unpaid client invoice"]
A · Invoice / EDI
Object CTA on the unpaid invoice; dismiss leaves invoice work intact. Partner never shows approved advance $.
sequenceDiagram
actor SMB as Supplier ops
participant Cleo as Invoice EDI partner
participant Soft as pre-approval estimate
participant Apply as Kanmon apply
participant UW as Underwriting
SMB->>Cleo: Open unpaid invoice
Cleo->>Soft: SoftCheck with invoice context
Soft-->>Cleo: Soft state plus prefill token
alt Soft strong or weak
Cleo-->>SMB: Finance CTA on this invoice
SMB->>Apply: Start with prefill
Apply-->>SMB: Entity and invoice prefilled
SMB->>Apply: Submit
Apply->>UW: Hard path
UW-->>Apply: Offer or decline
else No need for this invoice
Cleo-->>SMB: Dismiss - invoice work continues
end
More product sequences · wallet, ERP, payments, staffing
B · Wallet
Financing tab or volume-spike moment; AP vs term picked after soft invite. Cooldown if they leave.
sequenceDiagram
actor Seller as Seller
participant PP as Wallet partner
participant Soft as pre-approval estimate
participant Apply as Kanmon apply
participant UW as Underwriting
Seller->>PP: Open Financing or hit volume spike
PP->>Soft: SoftCheck with wallet tenure and volume
Soft-->>PP: Soft state plus prefill token
alt Soft strong or weak
PP-->>Seller: Check if you qualify CTA
Seller->>Apply: Start with KYC seed prefill
Note over Apply: Product pick AP vs term after soft invite
Seller->>Apply: Submit
Apply->>UW: Hard path
UW-->>Apply: Offer or decline
else Not now
PP-->>Seller: Leave Financing - cooldown on campaign
end
C · ERP / PO
PO-tied soft invite into Capital hub. Soft UI must not imply stacking products.
flowchart LR PO["PO approved or stock risk"] --> Soft["pre-approval estimate"] Soft --> Hub["Capital hub CTA on that PO"] Soft --> Skip["Not now"] Hub --> Prefill["Prefill entity plus PO"] Prefill --> Submit["Submit"] Submit --> UW["Hard UW"] UW --> Fund["Fund AP"]
D · Payments processor
Volume + boarding features; chargeback or reserve → soft exclude. Less object-tied than invoice/PO.
flowchart TD Board["Boarding complete"] --> Soft["pre-approval estimate"] Vol["Rolling volume features"] --> Soft CB["Chargeback or reserve flag"] --> Soft Soft -->|exclude| Quiet["No soft claim"] Soft -->|strong or weak| CTA["Hub CTA - less object-tied"] Soft -->|unavailable| Std["Standard apply only"] CTA --> Prefill["Prefill entity plus volume context"] Prefill --> UW["Submit then hard UW"]
E · Staffing
Soft still runs in program scope during quiet weeks; dismiss is normal when there is no cash pressure.
sequenceDiagram
actor Agency as Staffing agency
participant Vert as Staffing partner
participant Soft as pre-approval estimate
participant Apply as Kanmon apply
participant UW as Underwriting
Note over Vert,Soft: Soft still runs if in program scope - even in quiet weeks
Vert->>Soft: SoftCheck with unpaid client invoice and payroll calendar
Soft-->>Vert: Soft state plus prefill token
alt Soft strong or weak and cash pressure
Vert-->>Agency: Bridge payroll CTA
Agency->>Apply: Prefill employer entity
Agency->>Apply: Submit
Apply->>UW: Hard path
else Quiet week - no need
Vert-->>Agency: Dismiss is normal
end
Optional deep notes: architecture prose · standalone diagrams HTML
Open the demo full screen for presenting. Arrow keys move between screens, and pressing T switches between the two versions.
| Customer | Amount | Status | |
|---|---|---|---|
| Northside Dental INV-2041 · due 18 days ago |
$12,400 | Overdue | |
| Bright Path LLC due in 4 days |
$3,850 | Open | |
| Harbor Goods | $7,200 | Paid |
Moment on the object (overdue invoice), not a global Capital tab.
The message
When AR ages, cash need is explicit. CTA partner-branded; Kanmon is the rail.
- Threshold + cooldown + never block core workflow
- Holdout never sees CTA
Invoice financing Get paid on this invoice now
Soft pull, no personal score impact (their claim).
MVP: no fake pre-approved $ unless credit supports it.
Intensity
Future concept mock, not a published Kanmon/partner admin console today.
Moment: Invoice overdue
Partner why
- Helpful AR tool, not spam
- Configurable = brand-safe
- Quiet-partner playbook: one moment → 30 days → expand
- Main move: a pre-approval estimate and a shorter application, raise the share who finish after starting, so more complete apps and more funded loans.
- Pre-fill: less time in the form; later, better return paths for people who still quit.
- Bonus: better invites only for customers who look like a fit.
- Stay inside the approval band. Don’t loosen who can get a loan.
- Invite softly. Never say “you’re approved for $X” without Credit.
- Don’t spam partners or over-promise if the light check is too loose.
Simple scoreboard
Why people quit (guess mix): login/handoff about 22%, long form about 28%, bank link about 20%, business ID about 18%, “later” and never return about 12%. I’d fix in-form blockers first.
Clicks alone don’t count. Approval quality still matters.
Three things to see at a glance: new people enter from soft invite, existing starters finish (thinner abandon), and funded count / financed $ rise vs the simulated baseline.
Callouts track the size selected in the chart (Small / Medium / Large). Math: lift assumptions.
How I approached this case
The brief asks how I would own Kanmon’s product roadmap if success means more originations funded through partner platforms. I structured the problem first, then picked one idea and went deep. Here is the path I took.
- Clarify the win. An origination is a business on a partner’s platform taking financing and getting funded, not traffic to Kanmon’s own site.
- Map the big steps before picking a feature. More live partners, more visibility, more people finishing the form, more offers accepted, and capital to fund them; new loan types come later.
- Test “show financing at the right moment,” then set it aside. It was the AI’s early idea, but it is a common pitch and assumes people already finish applying, which the numbers say they do not.
- Fold in how the company runs. One PM, a wide funnel, low volume, little A/B, and underwriting owning credit, so the feature grows volume without changing who gets approved.
- Size the problem with a simulation. In it, about 51 loans fund a month while about 288 people start and quit before submitting, and a flow chart makes the drop-offs visible.
- Choose the lead feature: a pre-approval estimate and a shorter application. People who start already want it, so I cut friction in the flow instead of chasing cold demand; the estimate stays soft, never a promised amount.
- Show how it works. Data partners already hold shortens the form and powers a light “you look like a fit” check; credit and legal gate anything stronger.
- Name the second payoff. The same estimate makes an honest, low-effort invite for good-fit customers, so it helps new starters too, not only those already in the form.
- Rank recovery second. Email and a resume link can bring some people back, but when most never finish, fixing the form beats chasing people after they leave.
- Rank preventable declines later. Some declines are bad or missing data rather than real credit risk; worth fixing, but a smaller and later pool than mid-apply quit.
Where this stands now: the live answer is a pre-approval estimate and a shorter application, so finishing apply is easier in flow. The “right moment” screens are kept only as an archive of an earlier idea, not the pitch.
Detailed process beats are below if you want the full work log. Simulation numbers are illustrative, not Kanmon disclosed data.
Optional timed walkthrough notes private prep
| Minutes | Phase | Where | Cover |
|---|---|---|---|
| 0–3 | Open | Prompt | Restate success: funded originations through partners |
| 3–12 | Grounding | Business basics and examples | How lending works inside partners; company limits |
| 12–20 | Steps | Big picture | Which steps matter; assume visibility is solid enough for this case |
| 20–30 | My pick | My pick | pre-approval estimate and shorter application; finish-in-flow job; alternatives weighed |
| 30–42 | Sizing | Numbers and flow chart | Simulated quit pool; upside; credit quality guardrails |
| 42–52 | Process | Show | Approach story; what was thrown away |
| 52–60 | Open questions | , | Where do people quit mid-form? What partner data can be shared? |
If the conversation jumps to “show the feature,” spend about a minute on why, open My pick, then the flow chart. Drawings under Screens are an archive of an earlier idea, not the live answer.
- Live idea: a pre-approval estimate and a shorter application
- Job: easier to finish while still in the form; also better invites
- Recovery and preventable declines were seriously considered
- Simulated sizing; “right moment” was set aside
They already started, so interest is there, but in the simulation most never finish. I would ship a pre-approval estimate and a shorter application so the application is easier to complete while they are still in it. That same work also helps bring more of the right people into the funnel. Recovery and preventable-decline fixes matter, but they are not my lead.
How the work was executed
Chronological story beats. Tap a beat for full prompt, workbench autonomy, tools, and thrown-away notes.
All process beats (expand/collapse individually)
Secondary: swimlanes · judgment scorecard · time-in-stage
Dense lanes kept for completeness, not the primary read.
Judgment scorecard
| Decision | AI tendency | My intervention | Why |
|---|
Time-in-stage EST
Relative efficiency = autonomy hits per user prompt. Costly minutes = judgments (which lever, what to cut, what not to claim).
- Full changelog · open any prior version
- v013a · pre-docx-alignment
- v013b · e2e-in-workbench
- v014 · docx-alignment
- v015 · e2e-ui-mocks
- v016 · log-fold-exploration
- v017 · log-ideas (Ideas under Ground)
- v018 · ideas-in-solve · Ideas = Solve main scratch · source-check logged (b37–b38)
- v019 · back-to-live-banner · sticky ← Back to live
- v020 · framing pass · b42 · label only, no frozen folder
- v021 · Anthony raw notes → Solve · Notes · T15–T17 / F14–F15 · b43
- v022–v029 · leverage → Sankey beats b44–b52 · labels only, no frozen folders
- v030 · clarity-approach-b56 · catch-up freeze through b56–b57 · openable snapshot. LIVE ahead (architecture / experience / funnel lift embeds, b58–b63)
- LIVE · this file · pre-approval estimate and shorter application · Architecture / Experience / Funnel lift embeds · process log through b63
Changelog: kanmon-case-snapshots/changelog.html · Last freeze v030; LIVE includes post-v030 embeds (b58–b63). No capture script, copy live into a new vNNN-…/ folder before the next freeze.
Loading…