Product, Service, or Feature: What Are You Actually About to Build?

Three people describe the same idea in the same week and mean three entirely different businesses. One is describing a product. One is describing a service with software attached to make the service faster. One is describing a feature that belongs inside somebody else’s product and will be built by that somebody within about a year.

The confusion is not linguistic and it is not academic. It decides how you price, who you hire, what your website has to do without you in the room, and whether any revenue survives a month in which you take no calls. Three questions separate the three: who pays, what recurs, and what happens when you stop working. All three are answerable today, on paper, before anybody writes code.

This is the product vs feature argument with the third option restored, because the third option is the one that quietly ends companies. Have it now. It is a cheap conversation before the build and an expensive one after the first renewal cycle.

Three different machines, one word

A product is something a stranger can buy, use and get value from without you being present. Its costs are standing rather than per-sale: hosting, support, security patches, documentation, the roadmap, the person who answers on a Sunday. It scales awkwardly at first and then rather well.

A service is expertise applied to one situation. It is bought because of judgement, and it is delivered by named people. Revenue is a function of who is available and what they are working on. Margins are steady rather than compounding, and the ceiling is a hiring problem long before it is a demand problem.

A feature is a capability that only makes sense inside something larger. It has no independent buyer. Ask somebody to pay for it on its own and they will ask what it plugs into, which is the answer arriving in the form of a question. None of the three is ranked above the others. They are different machines with different failure modes, and the damage comes from running one while believing you are running another.

The test: who pays, what recurs, what survives you

Run all three questions. Any one of them alone can be argued away by somebody with a deck. Together they are hard to talk around, which is precisely their value.

Who pays, and what are they buying?

If the buyer is paying for an outcome delivered by particular people, you have a service, however much software sits behind it. If the buyer is paying for access to something that behaves identically for everybody who signs up, you have a product. If nobody would buy it without something else already in place, you have a feature.

The sharpened version of this question is whether a stranger would buy it without meeting anyone from your team. Not should they. Would they, this quarter, with a card, after reading a page. Most founders know the answer immediately and then spend six months avoiding it.

What recurs, and why does it recur?

A retainer recurs because you keep doing work. A subscription recurs because the thing keeps working. On a revenue chart the two lines look identical. Underneath, one is a promise about people and the other is a promise about software, and they break in completely different ways during the month the founder is ill.

What happens when you stop working?

The sharpest of the three. Take four weeks off, on paper, and follow the money. Service revenue stops, or degrades until it stops. Product revenue continues while a pile of support tickets and unpatched dependencies grows quietly behind it. Feature revenue was never separable enough to measure. That difference is the whole argument, and it is why a product is what still earns while nobody is at a desk.

It is also the most useful definition when you are looking at your own software and genuinely cannot tell which side it falls on. A workspace like Acrosite generates the required files, commits them to GitHub and triggers the configured deployment whether or not anybody from the team is awake. Nothing in that loop waits for a person. When your software cannot complete its own loop without somebody stepping in, what you have is a service with a good interface on it.

Held against each other, the three categories answer almost every practical question you were about to ask separately.

The feature that thinks it is a product

This is the expensive mistake, and it is expensive because it works for a while. You build one genuinely good capability, price it standalone, and find early buyers who were annoyed enough by the gap to pay for a separate tool. Then the platform everybody already uses ships the same capability in a routine release, and a business ends inside a paragraph of somebody else’s changelog.

The symptoms are visible long before that changelog arrives, and most teams will recognise at least three of them from their own week.

• Every sales conversation starts with a prerequisite. You cannot describe what you do without naming the other tool first. That other tool is the actual product, and you are an option inside it.
• Your competitors are checkboxes. When the alternative to buying you is a line item on somebody else’s pricing page, you are competing with a rounding error in their budget.
• Churn arrives in clusters. Not steadily, but in groups, a few weeks after a platform release. That is not churn. That is substitution, and no amount of onboarding fixes it.
• Buyers ask about integration before price. Price objections mean somebody is weighing value. Integration questions first mean they are checking whether you fit inside the thing they already bought.

The escape is not always to build more. Being a feature on purpose is a real strategy: sell through the platform’s marketplace, price against the annoyance rather than against an enterprise budget, and keep the team small enough that the arithmetic works. What ends companies is being a feature while spending like a product, with a roadmap, a sales team and a series of hires justified by a market that was never yours.

The service that thinks it is a product

The tell is that nobody can use the software without your team. Onboarding is a project with a kickoff call. Every account has a configuration somebody built by hand. Support is not support; it is delivery, arriving in a queue with a different name on it. The company describes itself as software and staffs itself like a studio.

The consequences compound quietly. You price like software, so the margin has to come from somewhere, and it comes out of the team. The roadmap becomes a queue of client requests, each perfectly reasonable and none of them shared by more than one account, which is exactly the situation publishing your non-goals exists to prevent. Two years later the codebase holds eleven customers’ opinions and no product.

Here is the concession, and it matters. Almost every product worth having began as a service with a spreadsheet behind it. Doing the work by hand for the first ten customers is how you learn which parts are genuinely repeatable, and skipping that stage produces software nobody asked for. The mistake is never passing through this stage. The mistake is settling into it while telling the market, the team and yourself that you are already past it.

The product hiding inside a service

The reverse error is quieter and considerably more common. A team delivers the same engagement for the eleventh time, rebuilding an artefact they have built ten times before, charging full price for the rebuild and calling the repetition experience. The thinking genuinely does vary between clients. The deliverable stopped varying around the fourth one.

That gap is where margin goes to die, and eventually somebody else productises the engagement and sells it for a fraction of the price. Our parent company has written on both sides of this: on telling a product from a service from a feature, and, more usefully before you commit, on the standing cost of a product.

The deliverable that stopped varying three clients ago is the product. You are simply still charging by the hour for it.

What the classification changes about everything else

This is not a filing exercise. Pick one of the three and a dozen other decisions resolve themselves. Refuse to pick and every one of them stays open, which is what most stalled early-stage plans actually are underneath the deck.

Pricing goes first. A product carries a public number and tiers that map to how much of it somebody uses. A service is priced on scope and judgement, and publishing a fixed price for it usually costs you the work you most wanted. A feature is priced against the host product’s price, whether you like that anchor or not. Getting this wrong is how positioning and pricing strategy ends up being redone eighteen months later at considerably greater expense.

Then the website, which has a different job in each case. A product site has to sell to somebody who will never speak to you, which makes the first ten minutes after signup the most important part of the business and makes why users sign up and never come back the piece to read before the pricing page. A service site has a different task entirely: prove judgement to somebody deciding whether to have a conversation at all.

Brand investment follows the same split. A product needs enough brand to be trusted by a stranger holding a card, and not much more, which is roughly the argument in how much brand an early-stage company actually needs. Measurement diverges hardest of all: a product watches activation and retention from week one, while a service watches utilisation, repeat work and referral, which is why what you can honestly measure in ninety days looks different depending on which machine you are running.

How to settle it this week

None of this needs a strategy offsite. It needs an hour, a document, and a willingness to write down the answer you have been avoiding since the second month.

1. Write the sentence. "This buyer pays us this amount so that this happens." Then check whether the buyer could be a stranger. If the sentence only works with a particular name in it, you are describing a service.
2. Run the four-week test on paper. Nobody works for a month. Which invoices still go out, which conversations stop, and what has quietly broken by week five?
3. Look at your last five deliveries. Mark what varied and what did not. The unvarying part is the candidate product, and it is usually smaller and duller than the one on the whiteboard.
4. Price the standing cost of the product version. A real annual figure covering hosting, support, security and the roadmap. Set it against what the repeatable part could plausibly earn in a year.
5. Decide, then publish what follows. Write the non-goals, tell the team, change the pricing page. A decision nobody outside the room can see is not a decision. It is a preference.

The classification is not permanent, and that is the reassuring part. A service that productises one artefact each year becomes a product business inside four years, with no dramatic pivot and no announcement. A product that keeps needing implementation help is telling you something honest about its onboarding rather than about its ambition. Both paths work. What does not work is holding both stories at once, because the hiring plan and the pricing page will eventually disagree in public.

If the honest answer is product, the next decisions are launch sequencing and what the first ninety days have to prove, which is what a product launch programme exists to settle. If the answer is that you already have a product and it is held back by the parts customers cannot get through alone, that is product improvement work rather than a positioning problem. If you are genuinely unsure, describe the last five things you delivered and we will tell you which of the three you are running.