Pricing Without Learning Is Just Guessing
- Brandon Homuth
- Jul 20
- 4 min read
Most early-stage lenders don’t have a pricing problem.
They have a learning problem.
Recently, I worked with a fintech lender that had built a surprisingly sophisticated pricing system:
~600+ pricing cells (term × loan amount × bureau score buckets x customer channel)
~20 distinct price points in one point increments
Strong portfolio performance and risk adjusted returns
On the surface, things “worked.”
But underneath, there was a fundamental issue:
They had never run a single pricing test.
No understanding of:
Price elasticity
Adverse selection
Optimal risk-based pricing spread
And critically, they had just built a better internal risk model… that wasn’t being used in pricing at all.
This created a classic strategic debate.
The Core Question
Should you:
Option A: Simplify and redesign pricing first (e.g., move to model-based pricing), then test later?
Option B: Run a price test on your current system, learn how pricing actually works, and then redesign?
At first glance, both are reasonable.
In practice, only one maximizes value.
The Hidden Risk of “Optimizing First”
Most teams instinctively want to fix the structure:
“Our pricing is too complex”
“We should use our better model”
“We can simplify this and make it cleaner”
All true.
But here’s the problem:
If you redesign pricing before you understand how customers respond to price, you are optimizing in the dark.
You don’t know:
If demand is price sensitive or not
Where you are underpricing vs. overpricing
Whether your segmentation actually aligns with market behavior
Even worse, once you change the system:
You lose your clean baseline
You confound cause and effect
You make future learning slower and noisier
You’ve made the system “better”… but harder to understand.
The More Important Truth
In this case, a few facts stood out:
The lender capped APR at 42%, while customers were refinancing 70%+ debt
Portfolio returns were extremely strong (50%+ IRR)
No prior testing had been done
This points to something very specific:
The business is likely underpricing parts of its portfolio.
That’s not a modeling problem.
That’s a pricing power problem.
And pricing power is not something you infer.
It’s something you measure.
What You Actually Want to Learn
A well-designed pricing strategy answers three questions:
1. Price Elasticity
If you change price:
How does conversion change?
Where are customers sensitive vs. insensitive?
2. Adverse Selection
When you change price:
Do you attract worse borrowers?
Or filter into a better population?
3. Segmentation Quality
Does your pricing variable (bureau vs. internal model):
Actually explain customer behavior?
Or just explain risk?
Most teams skip directly to #3.
That’s a mistake.
The Right Approach: Test First, Then Optimize
The highest-leverage path is:
Run a structured price test first. Then redesign pricing using what you learn.
Not the other way around.
Step 1: Light Simplification
Before testing, clean up obvious complexity:
Collapse excessive score buckets
Remove redundant dimensions
Keep pricing levels broadly intact
The goal is not perfection.
The goal is testability.
Step 2: Run a Meaningful Test (Not a Cosmetic One)
This is where most teams underperform.
They test:
±1% or ±2% APR
That’s not a real test. That’s noise.
Instead, you need meaningful movement, for example:
Control: current price
Treatment A: -5% APR
Treatment B: +5% APR
Treatment C: +10–15% APR (in select segments)
Why?
Because you are trying to map a curve, not estimate a slope.
Step 3: Measure the Right Things
Don’t just look at conversion.
You should track:
Conversion rate
Loan volume
Average APR
Internal model score distribution (early risk signal)
Longer-term: delinquency and losses
This is where it gets powerful.
Even before losses mature, you can see:
Are price changes shifting the risk composition of your portfolio?
That gives you early insight into adverse selection.
A Subtle but Important Insight
You don’t have to choose between:
Learning price elasticity
Validating your internal model for pricing
You can do both at once.
Even if pricing is based on bureau score today:
Within each bureau bucket, customers have different internal scores
When you vary price, you can observe:
How different model deciles respond
How risk distribution shifts
This means:
You can validate whether your model should drive pricing without switching to it yet.
That’s a much safer path.
Why Not Switch to Model-Based Pricing First?
It’s tempting. Especially when the model is better.
But doing so introduces three risks:
1. You Lose Your Benchmark
You no longer know what “normal” looks like.
2. You Confound Learning
Is performance driven by:
Better segmentation?
Price changes?
Selection effects?
You can’t tell.
3. You Risk Mispricing the Market
Markets often anchor to external signals (like bureau scores).
If you price purely on your internal model:
You may overprice some customers (lose volume)
Underprice others (leave money on the table)
Without elasticity data, you’re guessing.
## The Real Tradeoff
This isn’t about:
Testing vs. optimizing
It’s about:
Clean learning vs. noisy learning
If you test first:
You learn in a stable system
Your insights are reliable
Your redesign is informed
If you optimize first:
You learn in a moving system
Your insights are noisy
Your redesign is partially guesswork
Bottom Line
If your pricing:
Is complex
Has never been tested
And your margins are strong
Then your biggest opportunity is not better structure.
It’s better learning.
Run a real price test first. Use it to understand elasticity, selection, and segmentation. Then redesign pricing with confidence.
That sequence is what separates incremental improvements from step-change gains.