Build for Your Best User, Not Your Worst
In early product development, design for the user who gets it instantly, not the edge-case abuser
- Difficulty
- Easy
- Time to result
- ~weeks to results
- Steps
- 3
- Confidence
- 88%
It's easy to fixate on abuse cases and users poorly suited to your product, then contort the product to accommodate them. But worst-case users should always be a fraction of your base, so early on you should design for the user who jumps in and gets immediate value. Optimize for edge cases and worst users only later, once you're maturing the funnel.
Origin
A mental model articulated by Eeke de Milliano, Head of Product at Retool; reinforced by a moment where Retool founder Anthony reframed an abuse worry as 'wouldn't that be an amazing problem to have.'
Core principles
- 01Worst-case and abusive users should be a fraction of your base — don't shape the whole product around them
- 02Designing for edge cases warps the product into weird, funky shapes
- 03Early-stage focus belongs on the user who gets immediate value
- 04Worst-user optimization is a late-stage funnel activity, not an early one
How to run it
- 1
Identify the user who gets immediate value
Define the user who will jump into your product and understand it right away, and treat them as the design target for early product development.
- 2
Resist contorting the product for worst-case users
Notice when you're shaping onboarding or features around abuse cases or poorly-suited users, and stop — building an onboarding to collect tons of data or rescue ill-suited users warps the experience for the users who'd otherwise succeed.
Pro tip When an abuse worry surfaces early, ask whether that scale of abuse would actually be 'an amazing problem to have' — if so, put it on the back burner.
Watch out Don't ignore abuse forever — once the product is big and you're optimizing the funnel, worst-user handling becomes worth it.
- 3
Defer edge-case optimization to the maturing stage
Once the product is established and you're genuinely optimizing the funnel, then invest in edge cases and worst-user flows.
In the wild
In a product review for a new product, the team spiraled into worrying that if it got really big there would be tons of abuse. Founder Anthony responded that a product big enough to attract that abuse would be an amazing problem to have, so they put the abuse concern on the back burner.
→ The team stopped over-engineering for a worst case that only exists if the product succeeds, freeing them to build for the users who'd actually adopt it.
Common mistakes
Warping onboarding around ill-suited users
Building onboarding to collect lots of data or rescue users who aren't a fit shapes the flow in funky ways that hurt the users who would otherwise jump in and get value immediately.
Solving abuse problems you don't yet have
Designing early product around large-scale abuse assumes a success you haven't reached, burning effort on a fraction of users at the expense of your best ones.
Is it for you?
Best for
Product teams in early development of a new product deciding where to focus design effort
Not ideal for
Mature products at funnel-optimization stage, or products where abuse is an existential/safety risk from day one
From the transcript
“build for your best user not your worst user”
“the worst users are always like they should be a fraction of your users anyway so like you shouldn't really really be building for them”
“really should just be building an onboarding process for the user who's like gonna jump into your product and get it immediately”
“Anthony or founder was like wouldn't that be an amazing problem to have”
“in that sort of early product development stage it's like that's just not worth it to to be too focused on that”
From the episode
How to foster innovation and big thinking
Eeke de Milliano (Retool, Stripe)