What building ScreenshotEdits taught me about feature restraint
Feature restraint means protecting one finished user workflow until repeat use and real friction show precisely which next addition the product must earn.
Niels Kaspers
TL;DR
Feature restraint is not refusing ideas; it is protecting one complete user loop until evidence shows which addition will make that loop meaningfully better.
Feature restraint is the discipline of protecting a finished user workflow from every plausible addition until there is evidence that the addition makes the job meaningfully better. It is not a vow to ship less. It is a way to make sure a small product keeps completing the reason a person opened it.
Building ScreenshotEdits keeps making that distinction concrete. The product begins with a small job: turn a plain screenshot into a polished visual without opening a full design tool. Paste or capture, choose a background and finish, adjust the few visual controls that matter, then copy or export the result. The useful question for every new idea is not “would this be nice?” It is “does this help more people finish that loop with more confidence?”
That question matters more now because making a prototype is cheap. A model can suggest ten adjacent features before lunch. That does not make all ten part of the product. The bottleneck moves from generating possibilities to exercising judgment about which possibility earns a place in the workflow.
Start with the finished job, not the feature list
A small product needs a sentence that describes a completed outcome, not a set of capabilities. For ScreenshotEdits, the promise is not “image editing on macOS.” It is closer to: make a screenshot presentable in seconds. That sentence creates useful constraints.
A feature belongs only if it improves one of four moments: getting the screenshot in, making the intended visual choice, seeing a credible result, or taking that result where it needs to go. A request can be clever, technically feasible, and still be outside the loop.
This is why feature breadth often feels productive while making a product harder to understand. Each extra control asks the user to learn another possibility. Each configuration adds states to test, describe, support, and preserve. If it does not remove a real point of friction from the central job, it turns a fast tool into a smaller version of a general-purpose editor.
The principle is familiar in product strategy, but AI raises the stakes. Anthropic's guidance on agent evals makes a parallel point: teams need concrete tasks and success criteria rather than a vague sense that a system works. A product feature deserves the same treatment. Define the job and the observable success condition before treating an impressive demo as a reason to expand the surface.
Let friction earn the next feature
The right response to a feature request is not automatically yes or no. It is to find out what job the request is standing in for. “Can you add templates?” might mean the person cannot produce a good visual quickly. “Can you add batch processing?” might mean the existing workflow is being repeated successfully at a scale the first version did not anticipate. “Can you add layers?” might mean the current controls are too blunt for the result they need.
Those are three different problems. They deserve different evidence. I look for repeated behavior, a blocked moment in the core loop, and a clear outcome after the change. One enthusiastic request can reveal an opportunity; it should not silently become a roadmap commitment.
This is a first-party operating rule I use across small products: collect the request in the user's language, translate it into the underlying job, then decide whether the job strengthens the main loop or belongs in a different product. It is more useful than voting on a backlog of nouns.
Interactive
Feature restraint check
Run this before expanding a small product beyond its core loop.
Completion
This is the gap between understanding the article and actually using it.
- Use this block as the practical summary, not just the article ending.
- If one item feels vague, the article probably needs sharper guidance.
- A short checklist beats a long recap when the reader needs to act.
Use a proof burden that matches the cost of complexity
Not every idea needs a research project. A reversible copy change, an extra export preset, or a small onboarding clarification can be tested cheaply. A new mode, a new file model, or a sprawling settings area has a larger complexity cost. It changes how the product is explained and what every future user has to navigate.
OpenAI's evals guide for businesses argues for translating a business objective into criteria that can be tested consistently. That is a good product rule too. Before building an addition, write the evidence it must produce: fewer abandoned edits, more completed exports, less time to a usable result, or stronger repeat use for a specific workflow.
If nobody can name that result, the feature is still a possibility—not a priority. This does not reject intuition. It gives intuition a bounded way to become evidence.
The same framing helps avoid feature creep. Nielsen Norman Group's discussion of feature creep warns that added functionality can make products harder to use when it is not controlled by clear user needs. The practical response is not a ceremony-heavy roadmap. It is a short decision rule that keeps the team close to the user job.
Make subtraction visible
Feature restraint only works if the product makes tradeoffs visible. When a new control enters the interface, ask what can become a default, move out of the way, or disappear. When a new workflow is added, ask whether it deserves a separate path rather than a button in the main flow.
That is why workflow-first product design is a better design constraint than a feature checklist. Users do not experience a backlog; they experience a sequence of choices. The product should make the intended sequence easy before it offers every alternate route.
For ScreenshotEdits, that means preserving the feeling that the app is there to finish the screenshot, not invite a design session. The visible controls must stay close to the output a person wants to share. A powerful option that slows down the first successful export has to earn its place especially hard.
A small product can still learn aggressively
Restraint is sometimes mistaken for moving slowly. In practice, it can make learning faster because the team knows what signal it is testing. Instead of shipping a large bundle of improvements and guessing which one mattered, change one meaningful part of the loop and watch the relevant outcome.
A simple build log helps. Record the job, the friction, the smallest change, and the result. That is how a product's real strategy emerges from use rather than from a collection of imagined futures. Build logs as product strategy can turn those small decisions into a durable record of what the team learned and why.
The aim is not to make ScreenshotEdits permanently narrow. It is to let breadth follow proof. If a new workflow helps people create a better result without breaking the promise of speed and clarity, it can become part of the product. If it asks people to become designers before they can finish a screenshot, it belongs on the waiting list.
FAQ
What is feature restraint in product development?
Feature restraint is the practice of deferring plausible additions until there is evidence that they improve a completed user job. It protects clarity, speed, and product maintenance capacity from feature creep.
How do you decide whether a feature request deserves to ship?
Translate the request into the underlying user job, find repeated evidence of the friction, and define an observable outcome the change should improve. Match the depth of validation to the complexity and reversibility of the feature.
Does feature restraint mean ignoring customer feedback?
No. It means taking feedback seriously enough to understand the outcome behind it. A literal request may point to a better fix in the existing workflow, a new mode, or an opportunity that should wait.
Why is feature restraint more important with AI product tools?
AI makes new concepts and prototypes cheap to generate, which increases the number of plausible things a team could build. A clear job and proof burden help a team avoid mistaking cheap creation for product value.