Feature or product? Telling the difference before you build
The question is not how useful the idea is. It is whether anybody would organise their work around it.
The short answer: an idea is a product if people organise work around it and a feature if they merely pass through it, and the recordings of a workflow tell you which within about a dozen sources. The test is centrality, not usefulness — plenty of extremely useful ideas are steps inside somebody else’s tool.
This is one of the few strategic questions that gets cheaper to answer the earlier you ask it. Answered before building, it costs a week of watching. Answered after launch, it arrives as a pattern of trials that convert well and churn at ninety days, because the thing was genuinely handy and never became anybody’s Monday morning.
Centrality is the test
Watch a full workflow and mark where your idea sits. Products own the beginning and the end of a job: people open them to start, and the artefact they need comes out the other side. Features sit in the middle, entered from somewhere and exited back to it.
The behavioural tell is whether anyone opens a dedicated tool for the step today. If ten sources all perform it inside a general tool without complaint, you are proposing a better version of a step, and the burden of proof is much higher than it feels.
| Signal in the corpus | Points toward | Why |
|---|---|---|
| People open a dedicated tool for it today | Product | The category already accepts a separate destination |
| The job starts and ends in the idea | Product | It can own the workflow rather than borrow it |
| Described as a step, never as a task | Feature | Nobody schedules time for a step |
| “Why doesn’t X just do this?” | Feature | The market has named its rightful owner |
| People expect it bundled and free | Feature | Willingness to pay separately is absent |
The fourth row deserves respect rather than dismissal. When a market repeatedly names the product that ought to own something, it is telling you where the mental model already sits — and mental models are expensive to move.
Absorption risk, judged honestly
The follow-on question is whether the obvious owner will build it. The useful version of that question is not “could they?” — they almost always could — but “does shipping it move a number they are measured on?”
Where the answer is yes and the work is small, assume it arrives, and plan for a window rather than a moat. Where it conflicts with their pricing, their support model or their positioning, that reluctance is durable and often lasts years. Structural reluctance is a far better defence than technical difficulty.
- ✗Performed inside a general tool, without complaint
- ✗Nobody has built a workaround for it
- ✗Requested as an addition to an existing product
- ✗The incumbent gains directly by shipping it
- ✓A dedicated tool already exists and is disliked
- ✓People maintain a separate system for the job
- ✓The job has its own name in the market
- ✓The incumbent has a reason not to touch it
A comment thread full of “I’d use that” tells you the idea is appealing, not that it is central. Appeal is cheap to express and predicts almost nothing about whether somebody restructures their week around a new destination. Weight observed behaviour above stated interest every time.
When feature is the right answer anyway
Concluding “feature” is not the end of the idea. It changes three decisions. Pricing comes down and usually shifts toward usage or a low flat fee, because feature-sized value will not carry a workflow-sized price. Distribution shifts toward the platform’s own marketplace, where the buying intent already exists. And scope collapses to one thing done unusually well, because depth is the only advantage a feature-sized product has.
The realistic growth path is to enter narrow and widen into the surrounding steps once you have users who trust you with the middle. That is a slower story than launching a platform, and it fails far less often.
Sizing what you would actually be entering
Feature-sized markets are not automatically small, but they are sized differently: the ceiling is set by how many people do the step often enough to pay separately for it, not by how many people are in the category. Confusing the two produces a plan built on a number that was never available.
Running the rough arithmetic from the same corpus is quick and worth doing before, not after, the build decision — the sanity check in a market-size sanity check from creator signals. If the honest answer is that the reachable segment is small and the price ceiling is low, that is one of the early signals worth disqualifying an idea on.
When you are holding two ideas
The test is at its most useful in comparison. Two ideas that both look exciting often differ sharply on centrality, and the more central one wins almost regardless of which is more interesting to build.
Running them side by side against the same corpus keeps the comparison honest, which is the method in choosing between two SaaS ideas. It pairs naturally with demand-side evidence such as validating a startup idea with YouTube search and view data and with the workaround patterns in indie-hacker demand signals— centrality tells you the shape, demand tells you the size.
The wedge version of the question
There is a third answer that founders reach for too readily and occasionally deserve: the idea is a feature today and a wedge into something larger tomorrow. It is a legitimate strategy and a dangerous one, because it is indistinguishable from wishful thinking right up until it works.
The evidential test is whether the recordings show the adjacent steps being performed by the same person, in the same session. A wedge only widens into work that your user already owns; expansion into a neighbouring role means selling to somebody new, which is a second company’s worth of effort rather than a roadmap item.
Write the intended second step down before you build the first, with the evidence for it. If the corpus cannot show you who performs that step today, the wedge is an aspiration, and the honest plan is to succeed or fail on the narrow job alone.
What the answer does to your price
Centrality and price are linked more tightly than most early plans assume. A product that owns a workflow can be priced against the outcome of that workflow; a feature is priced against the annoyance it removes, and annoyance has a much lower ceiling regardless of how well it is removed.
This is where the feature-or-product call stops being philosophical. A feature-sized idea priced at workflow rates converts badly and churns at renewal, and no amount of positioning language repairs a mismatch between what the thing does and what it costs. Reading what a market already pays for each shape — the exercise in pricing your SaaS using creator content — is worth doing in the same pass, because the same recordings contain both answers.
What the pass costs
Ten to fifteen recordings of the complete workflow — not clips about your idea, but the whole job around it — is enough to place the idea confidently. As of August 2026 that fits the $19 a month plan with 25 videos and 2 projects; $59 covers 80 videos and 8 projects if you are testing several ideas, and $199 covers 250 videos, 20 projects and 3 seats. See the pricing page.
Map a full workflow from public content and see whether your idea owns the job or lives inside somebody else's, with the evidence attached to every call. 7-day free trial.
Closing thought
The costly version of this mistake is not building a feature. It is building a feature while planning, pricing and staffing as though it were a product — and discovering the difference from a churn cohort a year later.
Frequently asked
How do I tell whether my idea is a product or just a feature?
Look at whether people organise work around it or merely pass through it. If the recordings show the job starting and ending inside your idea, it is a product; if your idea is one step inside a workflow that lives somewhere else, it is a feature of that somewhere else.
Is being a feature automatically bad?
No. Plenty of durable businesses are features that the platform owner is structurally unwilling to build. It becomes dangerous when you charge product prices for feature-sized value, or when the obvious owner has every reason to ship it themselves.
What signals suggest an idea is really a feature?
People describing it as a step rather than a task, never opening a dedicated tool for it, expecting it to be free inside something they already pay for, and comment threads that say some version of why doesn't the main product just do this.
How do I judge the risk that an incumbent absorbs it?
Ask whether shipping it advances the incumbent's own metric. If it does and the work is small for them, assume it arrives eventually. If it conflicts with their business model, their support burden or their positioning, that reluctance is your durable space.
Can a feature-sized idea become a product later?
Often, by widening to the surrounding steps once you have users. The realistic sequence is to enter on the narrow job, earn the workflow, then expand — not to launch broad and hope depth appears later.
How many sources do I need to make this call?
Ten to fifteen recordings of the full workflow, not clips about your specific idea. The whole question is about context, so you need the sources that show what happens before and after the step you care about.
What does this research pass cost?
As of August 2026 plans run $19 a month for 25 videos and 2 projects, $59 for 80 videos and 8 projects, and $199 for 250 videos, 20 projects and 3 seats. This call typically takes ten to fifteen sources and fits the entry tier.