Build something meaningfully different

A product should start from a real problem and a reason it is not just a copy of what is already popular.

A working rule. Not an absolute.

Entry updated 26 Oct 2026

Copying a product that already exists is a way to learn the surface. It is a weak way to decide what to build. I want to understand the problem well enough to see what people still cannot do, and then ask whether my version changes that.

First-principles thinking, for me, means taking the problem apart before I accept the usual shape of the solution. What is actually scarce? What constraint is real, and what is just inherited from the last product in the category?

Shipping features is not the same as creating value. A feature is a change in the software. Value is a change in someone's work or decision. If I cannot name who feels that change, I am still describing the product to myself.

Influences

Zero to One, by Peter Thiel with Blake Masters, is the book I associate with this line of thought.

How I apply it

Before adding a feature, write down the job it replaces and the existing way people already do that job.
Look for a problem that is underserved, not only a market that is loud.
Treat differentiation as a claim I have to support, not a slogan.

What I can actually point to

The public products on this site — Focus20 Labs, Restro20, GrabSaaS, and Own Research — are separate attempts at different problems. I have not published evidence that any one of them is meaningfully different in the market's eyes. That distinction is still open.

Where this could be wrong

A familiar product, executed with care, can be the right choice. Novelty is not the same as usefulness.
The book is an argument, not a method that guarantees a company will work.

What could change my mind?

A case where a close copy, shipped with better distribution and operations, served people more than a clever difference did.
Finding that I am using 'different' to avoid the ordinary work of making something reliable.