What Top Founders Know About Discovery

Uber was building "Uber Everything" - testing what else the platform could do beyond rides. Most experiments failed. After analyzing why, Jeanette Mellinger, then Head of UX Research, discovered a pattern: the successful ventures had validated three things the failures hadn't.

Not just customer need. But founder fit and behavior change design.

"When we experimented with new businesses that didn't work, I see now they failed because they'd only gotten two of those three things," says Mellinger, who now advises early-stage founders on research methodology. "Usually the two that people focus on are the business case and technical feasibility."

The third element - whether humans would actually change their behavior to use the solution - kept getting overlooked. And it killed otherwise promising ideas.

After two decades coaching hundreds of executives and working with dozens of early-stage teams, Mellinger has identified what separates founders who establish product-market fit from those who burn resources building products nobody wants: systematic discovery validating founder-problem-solution alignment before writing code.

The AI era makes this harder, not easier. Vibe-coding an MVP in minutes offers a tempting shortcut past the difficult work of figuring out why you're building something and how to build it best. "Just as it's easier than ever to ship a product in record time, it's easier than ever to build a product no one wants and a company no one wants to join."

Here's what most founders miss about discovery:

• The silent first step most founders skip: validating whether you're actually suited to work on this problem for 10+ years

• "I've spoken with hundreds of customers" generates less insight than one focused week with five customers in their actual context

• New products must be 9X better than existing solutions to overcome inertia - yet most founders don't design explicit behavior change mechanisms

• The highest-impact breakthroughs follow seemingly unproductive periods, but founders skip incubation to ship faster

The Problem-Solution Fit Reality:

Finding market fit requires intersection of three validations: who you are as a founder, a burning problem you're suited to solve, and a solution that tackles the problem effectively while overcoming behavior change barriers.

Most founders optimize one or two of these. Top founders validate all three systematically before building.

Why founders skip the step that matters most

IDEO describes a good business as the intersection of three requirements: desirable (serves humans well), economically viable, and technically deliverable. Most founders focus on the business case and technical feasibility while underestimating what "desirable" actually means.

"Addressing acute pain points is only one dimension," Mellinger explains. "You can build something that's 'desirable' but not really needed. Or if people can't figure out how to use it, or the inertia of behavior change is too strong, then the product won't go anywhere."

The gap isn't customer validation - most founders conduct interviews. The gap is systematic discovery across three dimensions most founders never consider together:

Founder validation: Do you have the specific capabilities, energy, and motivation to work on this problem for 10+ years? Are you building in your zone of genius or competence?

Problem validation: Beyond stated pain points, what are customers' underlying needs? What behavior patterns must you understand? What workflow integration must you design for?

Solution validation: Is your product genuinely 9X better than existing alternatives? Have you designed explicit behavior change mechanisms, not just features?

"Problem, solution and fit are all different steps, but you can't think about them in isolation from one another," says Mellinger. "And the silent first step is the founder. Before thinking about the problem, you've got to start with the founder."

Most founders skip this entirely. They race to validate market need without validating whether they're actually suited to solve it.

"Founders are constantly being told to change directions. You could run after your tail forever if you don't have a center to come back to."

Three validation systems that establish problem-solution fit

Framework 1: The Founder-Problem Fit Audit

Map Your Zones Before Choosing Your Problem

Before validating customer need, top founders validate whether they're personally suited to work on the problem. This isn't about passion - it's about capability and energy alignment.

Mellinger adapts the four zones framework from "The Big Leap" to help founders assess this honestly:

Genius: Activities you're naturally exceptional at that energize you Excellence: Things you're very good at but don't necessarily love
Competence: Skills you're adequate at but not passionate about Incompetence: Areas you're naturally bad at and dislike

"The stuff that you are naturally bad at and know that you dislike, you might as well stay incompetent," says Mellinger. "I think you can get bitten by the things you're good at but aren't energized by."

A friend considering starting a company worked through this exercise with Mellinger. One question stopped her: "Would you be willing to work on this with this founding team for more than 10 years?"

She thought about it. "Absolutely not. I definitely don't want to think about this topic that long."

That alone saved who knows how much time down the road.

The zones audit reveals patterns about where you actually spend energy, not where you think you should. One founder realized through daily observation that she worked best with stable routines. This led her to reconsider pursuing a customer base requiring extensive, frequent travel - before committing resources to building for that market.

Implementation protocol:

Conduct 2-4 weeks of daily observation tracking activities across four zones. Note which tasks energize versus drain you, regardless of skill level. Don't rely on memory - document in real-time.

Create a zones map showing:

• 5-7 activities clearly in your genius zone (energizing + exceptional)

• Activities in excellence zone (great at but don't love)

• Tasks in competence/incompetence zones to delegate or avoid

Cross-reference your zones with problems you're considering. If solving the problem requires spending 60%+ of time in competence/incompetence zones, reconsider the problem choice.

Use this audit quarterly to assess whether your current work aligns with your zones as the company evolves.

Framework 2: The Three-Phase Discovery System

Incubate, Immerse, Integrate

Top founders alternate between three distinct research modes, each serving a specific purpose in validating problem-solution fit.

Phase 1: Incubation (1 day to 1 month)

Fight the urge to build. The best ideas often arrive during seemingly unproductive periods - which is why top founders build in deliberate incubation time.

"When you move without ever stopping, it's less likely that truly original ideas will emerge," says Mellinger.

Spend time where your target customers congregate. Subscribe to their newsletters. Lurk in Reddit and Discord communities. Attend their conferences. Listen to their podcasts. Don't pitch or survey - just observe and take notes on patterns.

For Uber Eats, this meant ordering delivery repeatedly and watching others do the same. For enterprise software, it might mean joining industry Slack groups and following LinkedIn discussions. The format doesn't matter - being present in customer contexts does.

Document patterns you notice: "Restaurant selection takes 15+ minutes even when hungry - decision paralysis." "People order delivery when cooking feels like too much effort, not just when they lack time."

Phase 2: Immersion (1 focused week)

Go physically where your customers are. Conduct in-depth interviews in the places where they experience the problem you're exploring.

Mellinger traveled to India, Colombia, Saudi Arabia, UK, China and the US for Uber Eats research. Not for months - for focused week-long sprints. Five in-context interviews in a week generated more insight than hundreds of dispersed conversations.

One founder building for restaurant managers conducted interviews during dinner service - not in offices. She discovered the real problem wasn't the scheduling software interface. It was that managers couldn't access scheduling while moving through the kitchen. This single observation changed the entire product architecture from desktop-first to mobile-native.

"A focused week in the market with your customers can get you there faster than hundreds of disparate conversations," she says.

The key: conduct interviews where customers actually encounter the problem. If building for restaurant managers, interview them in restaurants during service. If building for parents, observe morning routines in homes. Context reveals details customers won't think to mention.

Document three elements from each interview:

• Stated problem ("Scheduling is difficult")

• Observed behavior (spends 20 minutes manually checking availability)

• Underlying need (wants to avoid double-booking, not just speed)

After 3-5 interviews, patterns emerge clearly. After 10, you're often seeing repetition rather than new insights.

Phase 3: Integration (1 day to 1 week)

Design for the behavior change your solution requires. This is where most founders fail - they build for the problem without designing for adoption.

Map your customer's complete journey: awareness, consideration, purchase, first use, ongoing use, discontinued use, reuse. At each critical moment, apply the Fogg Behavior Model:

B = MAP (Behavior happens when Motivation, Ability, and Prompt collide)

Does your customer want to use your product? Is it easy for them to use? Do they have a reason or reminder to start?

Research shows new products must be 9X better than existing solutions to overcome inertia. "Inertia is a powerful force, and building a product people want to use more than the thing they already use is an uphill battle," says Mellinger.

If you're not clearly 9X better, either redesign the solution or reconsider the problem choice.

Implementation protocol:

Incubation phase deliverable: 10-15 documented patterns from customer community observation. Example: "Noticed 8 forum posts about workaround for X problem - suggests acute pain worth exploring."

Immersion phase deliverable: 5-7 in-depth interview summaries capturing stated problem, observed behavior, and underlying need for each customer. Include specific quotes and behavioral details.

Integration phase deliverable: Complete behavior change map showing:

• Customer journey with 7 key moments (awareness through reuse)

• Motivation-Ability-Prompt assessment at each critical moment

• 9X better analysis comparing your solution to incumbent

• Specific behavior change mechanisms designed into solution

Review this complete discovery package with your team before writing any code. If gaps exist in founder fit, problem understanding, or behavior change design, return to appropriate research phase.

Framework 3: The Behavior-Centric Solution Design

Design for Adoption, Not Just Desirability

Building something people want is necessary but insufficient. Top founders build something people will actually change their behavior to use.

Stanford professor BJ Fogg's behavior model provides the formula: B=MAP. Behavior happens when Motivation, Ability and a Prompt collide simultaneously.

Your product might be desirable (motivation exists) but if it's not easy to use (low ability) or customers lack a trigger to start using it (no prompt), adoption fails. And new products must be 9X better than existing solutions to overcome inertia.

At Uber Eats, this meant understanding not just that people wanted food delivery, but what made them actually open the app. Hunger wasn't enough - people had existing solutions (calling restaurants, cooking, going out). The trigger had to be strong enough to overcome the inertia of these defaults.

"You can come up with a great idea, but if you don't honor the basics of behavior change, the product might not take off—because it wasn't super easy to incorporate into their already-full lives."

Top founders design behavior change mechanisms explicitly:

For initial adoption: What specific trigger prompts first use? Is the first action easier than the incumbent solution? What immediate reward demonstrates value?

For habit formation: What prompt brings users back? What variable reward maintains engagement? What investment increases likelihood of return?

For overcoming inertia: In what specific ways is your solution 9X better than what customers use today? Not just "faster" or "easier" - quantifiably, demonstrably, obviously better.

Implementation protocol:

Create a behavior change design document with three focused sections:

Motivation Assessment: List 5 specific reasons customers want to solve this problem. Rate intensity (1-10 scale). Identify which motivations your solution addresses and which you're not addressing.

Ability Optimization: Map every step required to use your solution. Count clicks, decisions, and time for each step. Compare to incumbent solution step-by-step. Design simplifications for friction points.

Prompt Engineering: Define initial prompt triggering first use and ongoing prompts triggering repeat use. Design both external triggers (notifications, emails) and internal triggers (emotions, situations).

Validate through prototype testing with 5-10 target customers. Have them walk through complete flow while thinking aloud. Document where they pause, express confusion, or abandon.

If more than 30% of test users fail to complete the desired behavior, redesign before building. Behavior change barriers only increase with real products in real contexts.

Why this approach works when speed fails

The research is clear: thoughtful upfront discovery doesn't slow you down. It prevents building in the wrong direction, which is infinitely slower than taking time to validate first.

"Thoughtful upfront research helps train your intuition—so you can move faster and with more intention as you scale," says Mellinger. "It's even easier to speed in the wrong direction really fast with AI. I want to help founders build velocity, which is speed in the right direction."

The founders who establish product-market fit aren't necessarily the ones who ship fastest. They're the ones who validate founder-problem-solution fit systematically before building.

This isn't about taking a year before launch. "I'm not telling people to take a year," Mellinger clarifies. "Doing research in a product context is a balance of the stakes, your resources and what you need to achieve. You can do so much in a focused week, month or quarter."

The three validation systems provide the structure:

• 2-4 weeks for founder-problem fit audit

• 1-2 months for complete three-phase discovery (incubation, immersion, integration)

• 1-2 weeks for behavior-centric solution design

Total investment: 2-4 months of research before building. Compare that to 12-18 months building a product nobody wants, then starting over.

The choice isn't speed versus thoroughness. It's 2-4 months validating direction versus 12-18 months building products nobody wants. Top founders choose velocity over motion.