The Product

A few years ago, we worked with a founder building a B2B SaaS product for independent financial advisors. The idea: a client communication platform that would let advisors send personalized updates, track client engagement, and automate compliance-related documentation. The founder had worked in financial advising and knew the domain deeply.

On paper, this was a strong setup: domain expert founder, clear target market, real pain points, a well-funded build.

We built the MVP over 14 weeks. It shipped. And then, over the following four months, it became clear that adoption wasn't happening.

Failure Mode 1: We Validated Interest, Not Behavior

During discovery, the founder interviewed 20 financial advisors. Every one of them said client communication was a major pain point. Every one of them expressed interest in the product. Letters of Intent were signed. Pilots were agreed to.

But when the product launched, the actual adoption pattern was: advisors signed up, sent their first communication, and then didn't come back. Week-2 retention was 15%.

What went wrong: we validated that advisors said they wanted better client communication tools. We didn't validate their actual current behavior — how they were currently communicating with clients, and how entrenched those workflows were.

When we ran post-launch interviews with advisors who hadn't returned, the picture became clear: most of them communicated with clients primarily through their broker-dealer's mandated communication system. Switching to a new tool required either replacing that mandated system (impossible) or running two systems in parallel (too much work).

We had validated intent. We hadn't validated the switching behavior. These are different things.

The lesson: In discovery, ask not just "would you want this?" but "show me how you do this today" and "what would you have to stop doing or change to use this?" The gap between stated intent and actual behavior change is where MVPs fail.

Failure Mode 2: We Built for the Wrong Buyer

The founder's assumption: advisors would adopt the product and expense it themselves. This is a bottom-up adoption model, reasonable for low-priced SaaS tools.

The reality: financial advisors operate under broker-dealer oversight. Any communication tool used with clients needs to be approved and often monitored by compliance. The decision to adopt a new communication tool was not the advisor's to make — it was the compliance team's.

We had built a product for advisors but needed to sell to compliance departments. These are completely different buyers with completely different criteria. Advisors cared about UX and time savings. Compliance cared about audit trails, regulatory certification, and vendor security questionnaires.

The product was strong for the user. It was unprepared for the buyer.

The lesson: In regulated industries (finance, healthcare, legal, education), identify the actual buyer before you define the product. The end user and the buyer are often different people with different criteria. Build for both, or pick one explicitly.

Failure Mode 3: The Market Was Smaller Than It Looked

Financial advisors number in the hundreds of thousands in the US. On paper, a large market. But the relevant segment — independent advisors with enough client volume to justify a communication tool, at the right stage of their practice, using a broker-dealer that didn't already mandate a competing tool — was much smaller.

The founder's TAM calculation had been top-down: "X financial advisors in the US × $Y/month = large market." The actual addressable market was a fraction of this.

We didn't catch this during discovery because we didn't stress-test the market sizing. We took the total market number at face value rather than building a bottom-up model: how many advisors actually fit the profile, how many could we reach through our proposed channels, and what conversion rate could we realistically expect?

The lesson: Scrutinize market size estimates. Top-down TAM figures are useful for investor slides. Bottom-up market sizing — counting actual addressable customers through specific channels — tells you whether you have a real business.

What the Founder Did Right

To be fair to the founder: she made several decisions well. She didn't pour more capital into a failing product — she called it early, before the runway was gone. She did proper post-mortems with advisors to understand why adoption failed. And she pivoted the underlying technology to a new segment (enterprise wealth management firms) where the compliance concern was actually a feature, not a barrier.

The product wasn't bad. The hypothesis was wrong. That's a different situation.

The Meta-Lesson

MVP failures are usually not engineering failures or product quality failures. They're discovery failures — the wrong assumptions about user behavior, buyer dynamics, or market size that weren't surfaced during validation.

The antidote isn't more careful building. It's more aggressive validation before you build. The four questions to stress-test:

1. Have we observed the behavior we're trying to change, not just heard people say they'd change it?
2. Do we know who the actual buyer is, and have we validated with them?
3. Have we counted the actual addressable customers, not just sized the total market?
4. Have we asked "what would have to be true for people to use this every week?" and confirmed those things are true?

A failed MVP, properly learned from, is worth more than a successful one you don't examine. The pattern of mistakes is consistent enough that knowing them in advance can prevent the next failure before it happens.