From MVP to Bedrock: Building Financial Products That Truly Stick

Overview

Building a financial product that survives beyond the initial launch is a formidable challenge. In over a decade of product management in the financial sector, I’ve watched promising ideas rocket from zero to hero in just weeks, only to crash and burn months later. Financial products are especially unforgiving: users trust you with their hard-earned money, expectations are sky-high, and the market is crowded. The default reaction is to throw as many features at the wall as possible, hoping something sticks. But that approach almost always leads to a bloated, confusing, and ultimately unlovable product. This guide will show you a better way—focusing on the bedrock of value, using Minimum Viable Product (MVP) thinking, and avoiding the pitfalls of feature-first development.

Prerequisites

• Basic product management knowledge: Understanding of user stories, backlog management, and sprint cycles.
• Familiarity with financial products: General awareness of banking, payment, or investment services.
• Access to user research: Ability to gather customer feedback (surveys, interviews, usage analytics).
• A cross-functional team: At minimum, a developer, a designer, and a stakeholder who can make decisions.
• Optional: Read Jason Fried’s Getting Real or listen to the Rework podcast for amplification of these concepts.

Step-by-Step Guide

Step 1: Identify Your Bedrock

The first and most crucial step is to discover what we call the bedrock—the one thing that truly matters to your users. In retail banking, for example, the bedrock rarely lies in flashy new loan calculators or investment gimmicks. It’s found in the day-to-day servicing journeys: checking balances, reviewing recent transactions, and transferring money. These are the actions people perform every day, even if they open a new account only once in a blue moon. The bedrock is the single most valuable, sticky feature that makes users keep coming back.

Step 2: Define Your Minimum Viable Product (MVP)

Once you have your bedrock, build the smallest possible version of it that delivers real value. This is your MVP. It must be viable—meaning it solves a core problem—but not feature-packed. Use the Columbo Effect as a filter: every time someone says “just one more thing,” pause and ask whether that addition truly serves the bedrock or just adds complexity. Your goal is to launch something that provides immediate value and validates your foundation, without overwhelming your users or your engineering team.

Step 3: Resist the Feature Salad

As you build, you will face relentless pressure from internal stakeholders—“the narcs” (security, compliance, marketing) who each want their own pet feature. This leads to what I call a feature salad: a mishmash of unrelated functionalities that satisfy internal politics but confuse users. The antidote is ruthless prioritization. For every proposed feature, ask: Does this strengthen the bedrock? Will it make the daily user experience smoother? Is it essential for launch? If the answer isn’t a clear yes, defer it to a later iteration.

Step 4: Validate with Real Users (Not Internal Meetings)

Many financial products fail because they reflect the business’s internal dynamics rather than customer needs. Break this cycle by testing your MVP with real users early and often. Use A/B testing, prototype walkthroughs, and usage analytics to see if the bedrock actually delivers value. Ignore the noise from internal committees; listen to the people who will pay with their money.

Step 5: Iterate and Expand on Bedrock

After your MVP proves its worth, add features incrementally—but only those that enhance the core experience. For a banking app, that might mean adding instant notifications, fraud alerts, or a simple savings goal tracker after the basic checking/balance feature is solid. Never lose sight of the bedrock. Each new capability should make the user’s daily interaction easier, not just add another row to your product backlog.

Common Mistakes

• Feature-first development: Starting with a list of features instead of a single core value proposition. This leads to the feature salad mentioned above.
• Ignoring security early: The “narcs” (security teams) can block your launch if you haven’t addressed their concerns. Involve them from day one, but don’t let them drive the product design.
• Bowing to internal politics: Building features to satisfy competing departments creates a product that delights no one. Stay user-centered.
• Overconfident launch: Releasing a full-blown product with too many features at once makes it hard to know what’s driving engagement. Start with the bedrock and measure.
• Confusing MVP with “crappy”: An MVP is not a half-finished mess. It’s a focused, polished experience around the core value.

Summary

Building a financial product that sticks requires shifting from a feature-first mindset to a bedrock-first mindset. Start by identifying the single most valuable user journey (the bedrock), then craft a minimal viable product around it. Resist the urge to add “just one more thing” (the Columbo Effect), and avoid letting internal politics turn your product into a feature salad. Finally, validate with real users and expand only in ways that strengthen the core. This approach turns a short-lived beta into a lasting bedrock.