Why we build small products.
Small, focused products create faster feedback loops, sharper decisions, and more room to experiment than large ones.
Small products aren’t small ambitions — they’re controlled experiments with a clear problem, a defined user, and fewer places to hide. That makes it far easier to see whether the underlying idea has real value, and far harder to fool yourself into thinking something is working when it isn’t.
Small scope, faster feedback
A focused product creates a faster feedback loop. We can launch, observe real behavior, talk to users, and change the product without a large organization or a complicated roadmap slowing the process down. Every layer of scope you add to a product is also a layer of delay between building something and finding out whether it was the right thing to build.
There’s a subtler cost to scope too: a large product with many moving parts makes it genuinely harder to know which part is responsible for success or failure. If ten features shipped together and usage goes up, which one mattered? A small product doesn’t have that ambiguity. When something changes, you know why.
Why speed matters for a product lab
For a lab, that speed is the whole point. We want to explore several possibilities rather than spend years defending one assumption. Some experiments become businesses. Some become features inside something bigger. Some simply teach us something that shapes the next idea — and all three of those outcomes are legitimate uses of the time spent, not just the first one.
This is a genuinely different posture than running a single large company betting everything on one roadmap. A lab’s currency is the rate of useful discovery, not the size of any individual bet. Small products are how that currency gets earned quickly instead of slowly.
The real purpose of an experiment
That’s a good outcome, not a failed one. The purpose of a lab isn’t to make every experiment succeed. It’s to increase the rate at which useful discoveries happen, including the discovery that something doesn’t work — which is exactly as valuable as discovering that it does, if it arrives quickly enough to redirect the next move.
A small product that clearly fails after three weeks is a better outcome for a lab than a large product that ambiguously underperforms for three years. The first gives you a clean, fast answer. The second gives you a slow, expensive one that’s genuinely hard to interpret.
Common questions
How small is “small” when it comes to a real product? Small enough that one or two people can build, ship, and maintain it without needing a larger team to keep it running. If it requires a dedicated org to exist, it’s no longer a small product regardless of how few features it has.
Doesn’t building small products limit how big any one of them can eventually become? No — many products that scaled significantly started this way. Starting small controls the size of the first bet, not the ceiling of the eventual outcome.
How do you know when a small product should stay small versus grow? Usage tells you. If people keep returning and asking for more, that’s the signal to invest further. If usage plateaus or fades, the small footprint means the cost of finding that out was low.
Takeaway: a small product isn’t a compromise — it’s the fastest honest way to find out if an idea deserves to get bigger.