Make Something People Want, Then Make It Just Work
Solve a real problem and remove every obstacle to using the solution.
- Difficulty
- Moderate
- Time to result
- ~weeks to results
- Steps
- 5
- Confidence
- 97%
The framework combines Y Combinator's demand test with Dropbox's productization discipline. First, identify a concrete problem that people already want solved rather than inventing demand around an interesting technology. Then build a solution whose value is obvious from the first interaction. The implementation may be technically difficult, but that complexity should disappear behind a dependable workflow that feels natural to the user. Dropbox exemplified the mechanism by turning file synchronization into a familiar folder rather than asking customers to configure FTP, mounted filesystems, or version-control tools. The final discipline is strategic: preserve that clarity as the company grows, because unrelated products and confusing extensions can undermine the experience that created adoption in the first place.
Origin
Ben Gilbert and David Rosenthal derived the framework by connecting Y Combinator's product mantra with Dropbox's defining product characteristic during their analysis of the company's IPO.
Core principles
- 01Start with a real and widespread problem
- 02Prove that users actively want the solution
- 03Make the core experience immediately understandable
- 04Hide technical complexity from the user
- 05Protect the simple experience as the product expands
How to run it
- 1
Find a real problem
Look for a recurring frustration that users already attempt to solve. Confirm that the problem is meaningful before designing the product.
Pro tip Observe existing workarounds because effortful workarounds reveal genuine demand.
Watch out Do not mistake enthusiasm for a technology with demand for its application.
- 2
Build the essential solution
Create the smallest product that completes the core job from end to end. Defer adjacent workflows until the primary one is dependable.
Pro tip Describe the product in one concrete sentence centered on what the user can do.
Watch out A collection of features is not a complete solution.
- 3
Make the value immediately legible
Show users how the product works through a familiar interaction or concise demonstration. The desired outcome should be apparent without extensive explanation.
Pro tip Use the user's existing mental model rather than teaching a new technical model.
Watch out Do not rely on documentation to rescue a confusing first experience.
- 4
Hide implementation complexity
Automate configuration, synchronization, and recovery so the product behaves reliably by default. Users should receive the outcome without managing the underlying machinery.
Pro tip Treat every required configuration step as a candidate for elimination.
Watch out Technical users tolerating complexity does not prove mass-market usability.
- 5
Defend the core experience
Evaluate every expansion against the simplicity and dependability of the original workflow. Remove products or features that create duplication, ambiguity, or distraction.
Pro tip Ask whether the addition makes the original job easier before approving it.
Watch out Success can encourage expansion into products that nobody clearly wants.
In the wild
Drew Houston forgot the thumb drive containing his files before a bus trip. Dropbox transformed that recurring access problem into a folder that synchronized automatically across devices, eliminating the need for users to operate storage infrastructure themselves.
→ The instantly understandable workflow drove viral adoption and remained the company's core product through its IPO.
A Hacker News commenter argued that a Linux user could reproduce Dropbox with an FTP account, curl FTPFS, and version control. The workaround could perform parts of the job, but Dropbox packaged synchronization into an experience ordinary users could understand and trust.
→ Productization expanded the addressable market far beyond people able or willing to assemble technical tools.
Common mistakes
Solving an imagined problem
Teams begin with an exciting capability and assume users will care, rather than verifying an existing problem and demand for a solution.
Shipping a technically complete workaround
The product technically performs the job but leaves configuration, maintenance, or conceptual complexity with the user.
Expanding away from the magic
The company adds unrelated products that make the original workflow harder to understand without establishing comparable user demand.
Is it for you?
Best for
It is best for founders and product teams developing a new product around a clear customer pain point.
Not ideal for
It is not ideal for regulated or intrinsically complex systems where essential controls cannot be hidden or simplified.
From the transcript
“Make something people want you know exactly make something people want is how they phrase it.”
“And then on the Dropbox side, their moral of the story is is make it just work.”
From the episode
The Dropbox IPO