A feature is not a product

If you’ve just described your product idea to someone and the sentence was a capability — “AI-powered competitor monitoring,” “automated pre-call briefs,” “PDF to structured data” — I want you to try something.

Ask yourself five questions about what you just said.

Who is this actually for? Not “marketers” or “sales teams” — a specific buyer with a budget and a reason to listen. What event makes them care right now? Not a general pain point — a trigger. Something that just happened or is about to happen that creates urgency. What artifact or result do they receive? Not “insights” — a concrete deliverable they can hold, forward, or act on. Where does that result land in their existing workflow? Not “it saves time” — a specific place it fits between things they already do. And why would they switch from whatever they’re doing today?

If those answers come easy, you might have a product. If they don’t — if the answers are vague or circular or “we’ll figure that out once we build it” — you have a feature.

A feature is a capability. Capabilities can be real, technically sound, and even impressive. But a product is a capability placed inside a buyer context, tied to a trigger, embedded in a workflow, delivered as an artifact, and backed by a reason to switch. Until those pieces exist, what you’re holding is a technology demo with a one-liner.

Why this keeps happening

Smart teams fall for this constantly, and it’s not because they’re dumb. It’s because the capability is the exciting part. You discover that your system can do something — generate a brief, monitor a signal, transform a file format — and the sentence practically writes itself. The one-liner sounds like a product because it’s crisp and specific. But it’s specific about the wrong thing. It’s specific about what the technology does, not about who needs it and when and why.

I’ve watched this happen in my own evaluation work. An idea scores well on technical feasibility and differentiation but falls apart on buyer clarity and workflow fit. The instability isn’t in the capability — it’s in the product definition around it. The team has something it can build but not yet something it can sell, place, or prove.

“PDF to JSON” is technically clear. It describes a real transformation. But it doesn’t say who cares, what event triggers the need, what workflow it fits inside, or why someone would change their behavior to adopt it. “Automated invoice processing for fintech ops teams” starts behaving like product language — not because it’s more complex, but because it names a buyer and a workflow outcome, not just the raw capability.

The cost of getting this wrong

Product mistakes often start in language. The wrong one-liner sends the team toward the wrong evidence, the wrong roadmap, and the wrong definition of done.

When a team optimizes around a capability, the roadmap fills up with capability extensions — more formats, more signals, more outputs. When a team optimizes around a buyer outcome, the roadmap fills up with workflow integration, artifact refinement, and trigger accuracy. Those are very different products even if the underlying technology is identical.

This is especially dangerous right now. AI makes capabilities cheap to build. You can prototype a capability in a weekend. That speed is genuinely useful — but it also means teams are generating more “products” that are actually features, faster than they ever could before. The ratio of capability-excitement to product-definition has never been more skewed.

Before you build

I’m not arguing that every idea needs a business plan before you write a line of code. I’m arguing for one step: before you build, know whether you’re looking at a capability or a product-shaped proposition.

If it’s only a capability, the next move isn’t necessarily implementation. It might be defining the workflow, sharpening the buyer, or finding the trigger that makes the capability urgent. Those are product decisions, and they’re cheaper to make before the build than after.

So here’s the test. Say your one-liner out loud. Then run it against those five questions — buyer, trigger, artifact, workflow, switch reason. If three of them come back fuzzy, you’ve got more product work to do. Not more engineering. Not more features. More clarity about who this is for and why they’d change what they’re doing today.

The capability might be real. The product might not be. Yet.