# What makes a small product travel A narrow promise can move surprisingly far when people can understand it in one sentence. Published: 2026-06-04 Canonical: https://therohitdas.com/thoughts/what-makes-a-small-product-travel/ A narrow product can look almost too simple from the outside. One input, one useful result, and very little ceremony. It is easy to confuse that simplicity with a lack of ambition. I think it is often the opposite: a small product is an attempt to make one promise clear enough that it can travel without its maker standing next to it. The products that spread through conversation tend to fit inside ordinary language. Someone can mention them in a group chat, paste the link under a question, or remember the name three weeks later when the problem returns. The explanation does not require a diagram or a new category. ## The sentence is part of the product A good one-sentence description is not just marketing copy added at the end. It exposes whether the product has made a decision. If the sentence needs several clauses, an invented term, and a list of possible users, the product may still be avoiding its sharpest constraint. The useful test is whether a person who did not build it can repeat the promise without editing it into something simpler. People naturally compress products. You can either do that work deliberately or let the market do it inaccurately. > If the product is small enough to explain, it becomes small enough to carry. ## Distribution begins inside the interface We often talk about distribution as something that happens after the product is finished: posts, launches, search rankings, partnerships. But the first distribution decision is whether the result is easy to show another person. A useful output that can be linked, copied, embedded, or understood at a glance contains its own route outward. This does not mean covering every screen with share buttons. It means respecting the moment when a person receives value. Give the result a stable address. Use a title that still makes sense outside the app. Preserve enough context that a pasted link does not become a mystery. ## Small is not the same as unfinished There is a version of minimalism that simply removes work from the maker and hands it to the user. That is not simplicity. A focused product can have a tiny visible surface and still contain a large amount of invisible care: sensible defaults, careful errors, fast responses, and a clear way back when something goes wrong. - The first useful result should arrive before configuration becomes a project. - The default path should reflect what most people actually came to do. - Advanced controls should appear when they become relevant, not before. - The product should be understandable after six months away. YouTubeToTranscript did not need to invent a category. It needed to perform one familiar job with less friction and keep doing it well. That sounds modest, but it creates a demanding standard. When the promise is narrow, every unnecessary step becomes obvious. ## Stay around long enough for usefulness to compound Small products rarely become meaningful through one dramatic release. They improve through accumulated familiarity with the job. The maker learns which inputs are strange, which words confuse people, which shortcuts are actually helpful, and which requests point toward a different product entirely. That knowledge is hard to copy because it does not look like a feature list. It appears as dozens of tiny decisions that make the product feel as though it has seen this situation before. Staying close to the same problem is a form of leverage. A small product travels when the job is real, the promise is memorable, the result can move between people, and the maker stays around long enough for care to become infrastructure. None of those ideas are spectacular. Together they are surprisingly powerful. --- # Building boring products Existing demand is not an uncreative starting point. It is a useful constraint. Published: 2026-04-20 Canonical: https://therohitdas.com/thoughts/building-boring-products/ A boring product has an advantage: people already understand why they need it. You do not have to manufacture desire before you can improve the job. The problem is visible, the existing alternatives are easy to find, and the words people use already belong to them. This can feel less exciting than inventing a new category. It also removes an enormous amount of risk. You are free to spend more of your attention on the quality of the solution instead of the existence of the demand. ![A quiet workbench with a label maker, blank notebook, cable, pencil, index cards, and ceramic cup.](./boring-workbench.webp "Ordinary tools leave more room for extraordinary care.") ## Novelty is loud; usefulness repeats Novelty is excellent at earning a first look. A surprising interaction, a strange premise, or a beautiful demo can move quickly because it gives people something new to talk about. But the product still has to survive the quiet moment after the conversation ends. > Novelty gets a screenshot. Utility gets another visit tomorrow. Boring products are built for that second visit. Their job is usually recurring and unglamorous: convert this, retrieve that, move information from here to there, make a messy thing legible. The opportunity is not to disguise the ordinariness. It is to make the repeated experience unusually good. ## The interesting work moves into the details When the core job is familiar, differentiation moves elsewhere—to speed, reliability, taste, and the hundred small decisions that make the same task feel dramatically better. This is healthy pressure. It asks the product to earn preference through use rather than explanation. A fast tool does not merely finish quickly. It acknowledges input immediately, keeps the interface stable while working, and avoids making the user wonder whether the click registered. A reliable tool does not pretend failures are impossible. It makes them legible and recoverable. Taste matters here because familiar categories accumulate familiar compromises. The opportunity is often not a new feature but a refusal: no unnecessary account, no dashboard before the result, no notification strategy, no twelve-step onboarding sequence for a one-step job. ## Copy the demand, not the product Building in an existing category does not mean reproducing the incumbent. The useful thing to inherit is evidence that the job matters. Everything else is open for examination. Why does the current flow take seven steps? Which constraints are historical rather than necessary? What would the product look like if it were designed for today’s input rather than yesterday’s organization? - Start with the job people already describe without your vocabulary. - Keep the parts that carry real constraints. - Question the parts that only carry organizational history. - Choose one dimension where the improvement will be unmistakable. - Let repeated use decide whether the difference matters. ## Boring products are easier to abandon too The same clarity that makes a boring product easy to understand also makes it easy to replace. People know the job, they know alternatives exist, and switching costs may be low. A familiar category offers demand but not loyalty. That is why the invisible work matters so much. The product earns trust by being ready, remembering sensible preferences, and behaving consistently under pressure. It becomes the default not through captivity but through the absence of reasons to leave. ## Make the ordinary feel considered I have become more interested in products that do not need to be central to a person’s identity or workflow. They can remain small, sit quietly at the edge of a larger process, and become valuable precisely because they do not ask for much. There is creative work in deciding what not to expand. There is ambition in making a narrow promise dependable for a large number of people. Existing demand is not an uncreative starting point. It is a constraint that lets craft become visible. --- # A screenshot is not retention People share what is surprising. They return to what is useful. Those can be the same product, but they are different design problems. Published: 2025-06-07 Canonical: https://therohitdas.com/notes/a-screenshot-is-not-retention/ People share what is surprising. They return to what is useful. Those can be the same product, but they are different design problems. --- # What I mean by product partner I work across product, engineering, design, marketing, and whatever else helps the product succeed. Published: 2024-08-05 Updated: 2026-08-05 Canonical: https://therohitdas.com/thoughts/what-i-mean-by-product-partner/ At Zero Point Studio, my work does not fit neatly inside engineering, design, or marketing. I carry products across all three. I shape the product, its positioning, its user flows, and every public surface around it. I work on pricing, paywalls, websites, documentation, marketing, SEO, distribution, support, and whatever else helps the product succeed. For the last couple of years, I have implemented most of this with agents. I decide what needs to be done, break it into problems, direct the agents, review what they produce, and keep iterating until the result works as one coherent product. That is what Product Partner means to me: I am not responsible for one particular discipline. I am responsible for helping the product work.