From Feature Flood to Foundation: Building Products Users Love

Building a product that truly sticks—especially in the competitive world of financial services—is no easy feat. Many promising ideas burst onto the scene with a flurry of features, only to fade into obscurity. Why? Because piling on capabilities without a core anchor often leads to bloated, confusing experiences. The key is to identify your product's bedrock—the fundamental element that delivers lasting value. In this Q&A, we explore the pitfalls of feature-first thinking, the power of a Minimum Viable Product, and how to build foundations that keep users coming back.

1. Why does the “feature-first” approach often backfire in financial product development?

When teams rush to add endless features, they often overlook the core needs of users. Financial products deal with real money and high stakes—users expect reliability and clarity. A feature-first mindset leads to a cluttered interface where each new button or screen solves a specific problem but confuses the overall experience. Worse, this approach ignores security constraints (the “narcs” in the security team) and unexpected complexities. For example, a hard-fought feature might break under unforeseen loads or prove unpopular, wasting resources and eroding trust. The result is a “feature salad”—a mix of unrelated functions that feel more like internal politics than customer care. Instead of building loyalty, you create a product that users tolerate but never love. The antidote is to start with a clear, valuable core and only add features that reinforce it, not ones that clutter the journey.

2. What is a Minimum Viable Product (MVP) and how does it prevent failure?

An MVP is the simplest version of your product that still delivers enough value to keep users engaged. It’s not half-baked; it’s laser-focused on solving one essential problem well. This concept, championed by thinkers like Jason Fried, helps teams avoid overbuilding. By launching early with a small set of features, you gather real-world feedback and iterate based on actual needs—not assumptions. In financial products, an MVP might mean offering basic transaction tracking before adding investment tools. This approach reduces the risk of pouring time into features users don’t want. It also fights the temptation of the “Columbo Effect”—that nagging desire to add “just one more thing.” With an MVP, you have the discipline to say no, keeping the product lean, usable, and adaptable. The result? A stronger foundation that can evolve organically as you learn what truly matters to your customers.

3. What is the “Columbo Effect” and why should product teams be wary of it?

The “Columbo Effect,” named after the detective who always asked for “just one more thing,” refers to the relentless urge to add additional features before launch. In product development, it’s seductive because each new idea seems valuable in isolation. But this mindset derails focus. For example, while building a banking app, you might think, “If I just add bill-splitting, users will love it!” That one addition leads to another, and soon the original core—say, checking balances—gets buried under a pile of extras. The Columbo Effect stretches timelines, increases complexity, and often results in a product that tries to do everything but excels at nothing. Teams become prisoners of their own ideas, losing sight of the user’s primary need. Staying alert to this trap is critical. A strong product owner must ruthlessly prioritize, asking: “Does this feature strengthen our bedrock, or is it just another distraction?”

4. How do internal company politics create “feature salad” in apps?

Internal politics often hijack product roadmaps. Different departments—marketing, compliance, customer support—each push for features that serve their own agendas. Marketing may want a flashy referral program, compliance demands endless disclaimers, and support insists on a chatbot. Without a unifying customer vision, the product becomes a compromise: a jumble of disconnected capabilities that satisfy internal stakeholders but confuse users. This “feature salad” lacks a clear value proposition. In financial apps, the result is a bloated interface where a user trying to check their balance wades through loan offers and widgets for budgeting tools they never asked for. The product reflects the company’s structure, not the customer’s journey. To avoid this, teams must align around the customer’s core need—the bedrock—and treat every feature request through that lens. When internal politics are loud, a strong product manager becomes the voice of the user, vetoing anything that doesn’t strengthen the fundamental experience.

5. What does the term “bedrock” mean in product design?

Bedrock is the core element of your product that delivers lasting and meaningful value to users. It’s the one thing your product does that people rely on again and again—something that remains relevant despite market changes or feature additions. In product design, bedrock isn’t just a feature; it’s the foundation on which everything else is built. For example, in a banking app, the bedrock might be the ability to securely view transaction history and manage everyday money flows. This function is used daily, forms the basis of trust, and supports future enhancements like savings tools or investment insights. Identifying your bedrock requires asking: “What is the single most important thing our product must do for users to consider it essential?” Once you isolate that, you can resist feature bloat and focus on perfecting that core experience. Bedrock makes your product stable, user-friendly, and—most importantly—something users can’t easily give up.

6. How can you identify the bedrock for a retail banking product?

In retail banking, the bedrock often lies in regular servicing journeys—the tasks users perform most frequently. Think about how people interact with their bank: they rarely open a new account (maybe once every few years), but they check their balance, review recent transactions, or transfer money almost daily. These routine touchpoints form the product’s bedrock because they deliver constant value. To identify yours, study user behavior: What actions do users repeat? What pains emerge if those actions are broken? In a banking app, secure login plus a clear dashboard of recent activity may be the bedrock. Everything else—credit card offers, loan calculators—should reinforce or extend that foundation, not distract from it. Teams should also consider emotional needs: trust, speed, and simplicity. The bedrock is rarely glamorous; it’s the boring part that works flawlessly. By pinpointing it, you ensure that your product remains sticky—users stay because they rely on that one essential function day in and day out.