Products

There’s a pattern I keep noticing: the products I use most are small. Not in ambition, but in scope. They do one thing well, stay out of the way, and respect my attention.

Building small products means making hard choices about what not to build. Every feature request is a trade-off. The goal isn’t to please everyone — it’s to be indispensable to someone.

What “small” actually means

Small isn’t a line count or a feature count. It’s a posture. A small product has a sharp answer to the question what is this for? — and that answer guides every decision after.

The tools I keep reaching for share a few traits:

• They finish their thought. You don’t have to bring your own missing piece. The auth works, the export works, the edge case was handled. The product is complete on its own terms.
• They have a point of view. A small product can’t be everything, so it takes a stance. It picks a default and commits. That stance is what turns a user into a fan.
• They leave when the job is done. The best tools don’t try to own your whole workflow. They do their thing and get out of the way.

The opposite of small isn’t big. It’s vague. A vague product tries to serve everyone and ends up indispensable to no one.

The discipline of subtraction

The hard part of building small isn’t the building — it’s the saying no. Every user who emails with a reasonable feature request is describing a real need. The temptation is to add it.

But every addition has a cost that doesn’t show up in the changelog:

• The interface gets a little harder to scan.
• The mental model gets a little harder to hold.
• The next feature gets a little harder to build, because it has to fit around the last one.

A product’s surface area is a debt you pay forever. Add features like you’re taking out a loan — only when the return is clear and you can carry the cost.

The products that endure are usually the ones that kept subtracting long after it stopped being comfortable.

Being indispensable to someone

“Useful to many” is a safe goal. It produces products that are fine. Indispensable to some is a riskier goal — you’ll alienate people, you’ll get one-star reviews that say “this doesn’t do X,” and you’ll have to explain your choices a lot.

But the people you’re indispensable to will tell others. They’ll forgive rough edges. They’ll stick around when a shinier alternative appears, because the shiny alternative is built for everyone and yours is built for them.

A small product that five thousand people love is worth more than a large product that fifty thousand people tolerate. The math on attention works that way.

The practical version

If I had to compress the whole thing into advice I’d give myself starting out:

1. Pick a single job and do it noticeably well. Not a category — a job.
2. Default to shipping the smaller version. If you’re unsure whether a feature belongs, it doesn’t.
3. Write the one-line description before you build. If you can’t explain it in a sentence, the scope is already wrong.
4. Listen to every user and act on almost none of the requests. Hear the need underneath the request; ignore the request itself.

Small products aren’t a stepping stone to big ones. For a lot of us, they’re the destination — and a perfectly good one.