Build for Your Best User

Design for users who will get it immediately, not edge cases

Eeke de Milliano
How to foster innovation and big thinking

Build for Your Best User

"Build for your best user, not your worst user. I think it's actually really easy to get stuck, or to focus on, 'What if there's abuse of this product?' Or think about all the ways in which the product won't be used well. And then you end up sort of shaping the product in these really weird funky ways to make up for that. Whereas in reality, the worst users, they should be a fraction of your users anyway." - Eeke de Milliano

What It Is

This framework challenges the common tendency to over-engineer products for edge cases, abuse scenarios, or users who aren't ideal fits. Instead, it advocates for optimizing the experience for users who will immediately understand and get value from your product.

The insight is particularly relevant during early product development, where teams often waste time building guardrails, extensive onboarding flows, and abuse prevention for scenarios that may never materialize at meaningful scale. If abuse becomes a significant problem, that's actually a sign of success—you can deal with it then.

As Retool's founder David Hsu put it when the team was worried about potential abuse in a new product: "Wouldn't that be an amazing problem to have?"

How It Works

The Anti-Pattern:

  • Focus on what could go wrong
  • Build extensive safeguards for abuse
  • Create onboarding designed to educate unsuitable users
  • Shape the product around worst-case scenarios

The Better Approach:

  • Design for users who will jump in and get it immediately
  • Optimize the happy path relentlessly
  • Trust that worst users will be a small fraction of your total
  • Address abuse if and when it becomes a real problem at scale

How to Apply It

  1. Define your best user - Who will understand your product immediately? Who will get value fastest?

  2. Audit your product decisions - Are you making choices based on edge cases or abuse scenarios that may never materialize?

  3. Simplify onboarding - Instead of collecting lots of data or educating marginal users, design for users who don't need explanation

  4. Defer abuse prevention - Don't over-invest in preventing abuse until you have evidence it's a real problem

  5. After PMF, broaden thoughtfully - Once you've proven the core experience, you can expand to serve adjacent users

When to Use It

  • During early product development when resources are constrained
  • When designing onboarding flows
  • When debating whether to add guardrails or restrictions
  • When product reviews drift toward hypothetical abuse scenarios
  • When optimizing funnels (once you have PMF, different rules apply)

When NOT to Use It

  • When you have strong PMF and are actively optimizing conversion funnels
  • When abuse is already a demonstrated problem at scale
  • When regulatory requirements mandate certain protections
  • When the worst-case scenario involves significant harm to users

Source

  • Guest: Eeke de Milliano
  • Episode: "How to foster innovation and big thinking"
  • Key Discussion: (00:45:45) - Build for your best user, not your worst user
  • YouTube: Watch on YouTube

Related Frameworks

Back to Product Strategy