Is What You Are About to Build a Product, a Service, or Just a Feature?

Something has arrived that needs building, and the conversation has already moved to how. How long it takes, which of you is free, whether it goes in the existing codebase or somewhere new. The prior question is what class of thing this actually is, and it goes unasked more often than not, because everybody in the room assumes the answer is obvious and nobody checks that they have the same one.

Three answers are available. A product is bought on its own terms, by a buyer who has to be found, through a route you build and then keep open indefinitely. A service is delivered to a named client under an agreement, and the next sale arrives by negotiation rather than by distribution. A feature is bought as part of a decision the customer has already made; nobody chooses it separately, and its route to market is the thing it sits inside. These are not three sizes of the same object. They differ in who decides, who signs, how the second sale arrives, and what you are committed to for as long as the thing exists.

Whatever is in front of you arrived one of two ways. Either it surfaced from inside, as work you keep redoing, a step somebody has to remember, an inefficiency that has quietly become a habit. Or it arrived from outside, as a request from a single buyer with money behind it. Both origins can legitimately end at any of the three answers. Neither origin tells you which, and the frequent mistake is to treat the origin as though it were already an argument.

The origin tells you why the thing is on the table. It tells you almost nothing about what the thing is.

Internal friction is the more flattering origin. It feels like insight rather than like a favour, and it comes with something that looks like proof: you have felt the problem repeatedly, at first hand, and you can describe it precisely. That is genuine evidence, and it is evidence of exactly one thing. It establishes that the problem exists. It establishes nothing whatsoever about whether anyone outside your own operation would pay to have it removed, or would even recognise the description.

Three questions separate friction worth productising from friction worth automating quietly, and from friction that is simply the cost of the work. All three are about the shape of the friction rather than the strength of the irritation, which matters because irritation is a poor instrument. The most annoying recurring task is often the one that recurs least; it is memorable because it is unpleasant, not because it is frequent.

Is the same work being redone, or only work that rhymes

Write down the steps for the last several instances, in the order they happened, and mark each step as either identical across instances or requiring a judgement. The proportion is the finding. If judgement steps dominate, you are looking at expertise applied case by case, which is the definition of a service and does not stop being one because the surrounding steps could be tidied. If identical steps dominate, you have a candidate for something built once and then left alone.

The honest complication is that work sometimes rhymes rather than repeats because you never standardised the inputs, not because the cases genuinely differ. The tell is where the variation comes from. Variation that originates in the client's situation is real, and absorbing it is part of what you are paid for. Variation that originates in your own inconsistency, in how the request is captured or how the brief is written, is manufactured, and standardising the input removes most of it. That is worth doing before you classify anything, because it changes the answer rather than merely improving it.

Would the fix hold if nobody remembered to apply it

A checklist, a template and a convention are all fixes that depend on recall. They work when somebody remembers, and they degrade silently when nobody does, usually under exactly the conditions that made the friction expensive in the first place. A structural fix changes what is possible rather than what is advisable, and it holds whether or not anyone is paying attention. The distinction is the difference between a discipline and a mechanism, and only one of the two survives a busy week.

This does not mean conventions are inferior. They are cheap, immediately reversible, and frequently the correct answer. The argument for building something structural is only strong under two conditions: when the cost of a single lapse is high, or when a lapse is invisible until much later. Where a lapse is cheap and immediately obvious, a convention is not a compromise but a proportionate response, and building a mechanism to enforce it is a way of spending real money to remove an imaginary risk.

Who notices if it is solved once and never again

Solve it permanently, in your head, and then ask who would notice. If the only people who notice are the people who do the work, you have internal tooling. That is real value and it is often worth building, but it has no buyer, and a great deal of confusion is caused by treating internal tooling as a product in waiting simply because it was hard to build and works well.

If the client would notice, the friction was producing a defect they experienced, and the question becomes whether the fix should be visible and priced rather than absorbed. And if the honest answer is that nobody would notice, including the people doing the work, then the friction is not costing what its prominence in conversation suggests, and the correct verdict is likely to be the fourth one rather than any of the three.

A request with money behind it is the most persuasive input a small company receives, and its persuasiveness has nothing to do with its evidential weight. One buyer asking is one buyer asking. The pressure it applies is real, and it is commercial pressure rather than product evidence, which is worth separating explicitly because the two feel identical in the moment and behave very differently afterwards.

Ask first whether they requested the thing or the outcome. Buyers frequently arrive having already designed the solution, and what they are asking you for is execution of a shape they chose. Say the words back to them as an outcome and see whether they accept the restatement. If they do, you have latitude, and there is a reasonable chance the outcome is reachable with something you already ship. If they insist on the shape, you are being asked to build to a specification, which is a service whatever the artefact looks like at the end.

Ask next what they compared you against. A buyer who evaluated three options before arriving is telling you that a category exists in their mind and that other people are competing for the same budget line, which is weak but genuine evidence of a market. A buyer who came to you because you already work for them is telling you about the relationship rather than the market. Both are good reasons to do the work. Only one of them bears on the classification.

The most useful single question to put to a buyer with a request is whether they would still want it if it were available to their competitors. If the answer is no, the request is inherently a service, because part of what they are buying is exclusivity, and exclusivity is the direct opposite of what a product needs in order to work at all. If the answer is yes, they have just told you they see the thing as infrastructure rather than as advantage, which is the more product-shaped of the two responses.

The two origins are strong in exactly the places the other is weak, and that symmetry is the most useful thing about them. Internal friction gives you a demonstrated problem and no demonstrated buyer. A single buyer's request gives you a demonstrated buyer and no demonstrated generality. Each supplies half of what a product verdict requires, and no quantity of the half you hold converts into the half you do not.

The practical consequence is that the same four tests decide differently depending on where the thing came from. Work originating in internal friction almost always sails through the standalone value test, because you can describe the value fluently and from experience, and then fails on the buyer and distribution tests, which nobody has yet had a reason to run. Work originating in a single buyer's request passes the buyer test trivially, at least for one signature, and fails on standalone value, because it was shaped to a situation rather than to a category.

So the tests you apply are the same in both cases. The tests that will actually decide are not, and knowing in advance which one is likely to be load-bearing tells you where to spend the effort. If the thing came from inside, spend it on establishing whether a second buyer exists in a different organisation. If it came from outside, spend it on describing the thing without reference to the buyer who asked for it, and see whether the description survives the removal.

The order is deliberate. Each test is cheaper to run than the one after it, and each can end the enquiry on its own, which means a disciplined sequence usually saves you from ever having to run the expensive ones. Running them out of order is how teams end up building a distribution plan for something that turns out, on inspection, to have been a feature all along.

The standalone value test

Describe the thing to somebody who knows nothing about anything else you own, and see whether the description holds together. Not whether they are impressed, which measures your delivery, but whether the value survives the absence of your other work. The failure signal is specific and easy to hear: the description keeps needing a clause that begins with the name of something else you ship. If the value only exists once the listener has already adopted something of yours, that is not a small caveat, it is the definition of a feature.

The counter-case is worth stating, because this test produces false negatives. A genuine product may still be easiest to sell to people who already know you, and early buyers drawn from existing relationships do not disprove standalone value. That is a fact about distribution, not about worth. The test is not whether your first buyers happen to be existing customers. It is whether the thing would still be wanted by a buyer who had never heard of you and never would.

The buyer test: who signs off, and is it the same person twice

Name the person who signs. Then name a second one, in a different organisation, with no relationship to the first. If you cannot produce the second name, you do not have a product; you have a service with one client, and no amount of building changes that until the second name exists. This test is unpopular precisely because it is answerable immediately, before anything has been built, which removes the option of deferring the question until the work has too much momentum to stop.

There is a subtler version of the same test, which is whether the two signatures belong to the same role. A thing bought by operations in one organisation and by marketing in another is not one product being sold twice. It is two propositions that happen to share an implementation, and each will want a different description, a different route and eventually a different shape. That is survivable, but it should be a decision rather than a discovery, because the cost of the discovery lands on whoever has to write about the thing.

For a feature, the buyer test resolves instantly and favourably: the buyer is the buyer of the product it belongs to, and no new signature is required. That is the entire economic advantage of the feature verdict, and it is the reason the feature verdict is so much cheaper than either alternative even when the engineering involved is identical.

The distribution test: would you have to find these buyers again

This is the test that most often reverses an otherwise confident product verdict, and it is the one teams skip, because it asks about work that has not started yet and feels like somebody else's department. A product commits you to reaching buyers who do not know you exist, repeatedly, for as long as it remains on sale. Ask by which route the second buyer arrives, then ask who maintains that route and out of whose week the maintenance comes.

If the honest answer is that the second buyer arrives the same way the first one did, because somebody already knew you, then the route is your reputation, and a reputation is not a distribution channel you can plan against. It is limited by the capacity of the people who carry it and it does not scale with the thing you built. A business can live very well on that. What it is living on is a service practice, and calling it a product does not change the mechanics of how the next sale arrives.

The counter-case matters here too. A product with a narrow and enumerable buyer population may need no marketing engine at all, because the buyers can be approached directly and there are not many of them. The test is not whether the route operates at scale. It is whether a route exists, whether you can name it, and whether somebody will keep it open after the launch enthusiasm has been spent elsewhere.

Reversibility, and which direction is cheaper to unwind

The last test asks which mistake you can afford. The two misclassifications are not symmetrical in cost, and under genuine uncertainty that asymmetry is the tie-breaker. Calling a product a service is usually cheap to unwind. You deliver to one client, you learn the real shape of the problem from a case rather than from an inference, and you generalise afterwards, subject to whatever you agreed about ownership. Very little of that is visible to anybody who was not party to it.

Calling a service a product is expensive to unwind. You have built for a general case you inferred rather than observed, put it on a public surface, given it a name, and probably attached a price to it. Withdrawing it is visible to everyone who saw it, and the withdrawal is read as a failure signal whether or not it was one. That asymmetry argues, under uncertainty, for taking the service verdict first and earning the product verdict later on evidence you did not have at the start.

The argument has a limit, and it should be stated rather than hidden. It reverses wherever the general version can only be reached by building generally from the beginning. Some structures cannot be generalised after the fact without being rebuilt, and where that is true the cheap reversal you were counting on does not exist. In that case reversibility stops being an argument for caution and becomes an argument for deciding properly now, with the buyer and distribution tests carrying more weight than they otherwise would.

The feature verdict is skipped because it is the least interesting outcome in the room. It creates no new remit, gives nobody a thing of their own to own, and produces no launch. It is also, very often, the cheapest correct answer available: no second buyer to find, no route to build, no separate agreement, no new surface to keep alive. Every standing obligation the other two verdicts create is one the feature verdict inherits from something that already carries it.

The verdict is right when three conditions hold together. The value depends on the context the surrounding product supplies, the buyer is the buyer you already have, and the route to that buyer is already open and already maintained. When all three hold, calling the thing a product is not ambition; it is a decision to pay again for infrastructure you already own a working copy of.

It is worth saying plainly that a feature verdict is not a demotion, because it is almost always received as one. The right question about a feature is not how large it is but whether it strengthens the decision the customer has already made. A feature that makes the surrounding product harder to refuse is doing more commercial work than a separate thing that nobody has found yet, and it is doing it without a second route to maintain.

The feature that quietly forks the product

The feature verdict has its own characteristic failure, and it is slower and harder to see than either of the others. A capability built to suit one customer's situation enters the shared codebase carrying a condition. The condition is small and entirely defensible. Later it acquires a second condition, then a setting to control it, then a path that only one customer ever exercises. Nothing has been declared a fork. Everybody is nonetheless now maintaining two things while budgeting for one.

There are two reliable tells. The first is when a change to shared behaviour cannot be assessed for safety until somebody has established which customers it is switched on for; at that point the behaviour is no longer shared, whatever the directory structure says. The second is when the documentation cannot describe what happens without describing the condition, because documentation is where an undeclared fork becomes undeniable. If the sentence needs an unless, the fork already exists and has simply not been named.

The remedy is to decide at the first condition rather than the fifth, while the decision is still small enough to take calmly. Either the behaviour becomes generally available, justified on its own merits for every customer, and the condition disappears; or it lives outside the shared codebase, is understood as bespoke, and is priced as the service it is. What should not happen is the third option, which is to keep the condition and stop counting.

A fork is rarely declared. It accumulates, one defensible condition at a time, until nobody can say whether a change is safe without first asking who it is switched on for.

Most cases resolve cleanly once all four tests have been run honestly, and the clean patterns are worth naming so that the difficult ones are recognisable as genuinely difficult rather than as failures of nerve.

• All four pass. Standalone value holds without you, a second buyer exists in an unrelated organisation, a route to strangers can be named and staffed, and the unwind cost is bearable. That is a product, and the remaining questions are about sequencing rather than classification.
• Standalone value passes and the buyer test fails. One buyer, one signatory, no second name available. That is a service, whatever the artefact resembles when it is finished, and calling it anything else only delays the point at which you price it correctly.
• Standalone value fails. It is a feature, and the remaining three tests do not need running, which is the entire reason this test goes first rather than last.
• The buyer and distribution tests pass but standalone value is marginal. This is the genuinely difficult case. It usually means the value is real but bundled, and that the thing is a feature of somebody else's product rather than a product of yours.
• Everything passes except reversibility. The classification is probably right and the timing is probably wrong, which is the fourth answer rather than a verdict against the thing itself.

When the tests disagree, the buyer and distribution tests outrank the standalone value test, and it is worth being explicit about why. Value that cannot be reached is not value in any sense that pays for itself. A thing that stands alone beautifully, has no second buyer and no route to one, is a service at best. The standalone value test measures whether the thing is worth something. The other two measure whether that worth is collectible, and only one of those questions has a bank account attached to it.

The exception is a distribution test that has not so much failed as never been attempted. If the buyer population is obvious, enumerable and simply unapproached, distribution is untested rather than absent, and the correct response is a cheap test rather than a verdict. The distinction is between being unable to name a route and merely never having walked one. Those two states sound similar in a meeting and are entirely different findings.

Where two tests genuinely disagree and no further cheap evidence is available, the disagreement is itself the finding. It does not mean the answer lies somewhere in the middle, and averaging the tests produces a verdict that describes nothing. It means the thing is not yet classifiable, which is a legitimate result and points directly at the fourth answer.

A misclassification almost never announces itself as one. It presents as an operational complaint from somebody who has no reason to connect their irritation to a decision taken before the first version existed. Learning to hear the complaint as a classification symptom rather than as a process problem is most of the skill, and it is the part that is never written down.

A product that requires a conversation before every sale is a service with a price list. The conversation is not a sales inefficiency to be optimised away; it is the negotiation a service requires in order to establish scope, and its persistence is the diagnosis. The corresponding tell in the other direction is a service whose delivery has quietly become the operation of software you maintain, where the effort per client has stopped scaling with the client and the economics no longer resemble a service's. That is a product being sold one client at a time, which is an expensive way to sell a product and a poor way to run a service.

A feature that has acquired its own roadmap, its own name in internal conversation, and requests addressed to it rather than to the product it belongs to has already drifted. Naming is the leading indicator here and it costs nothing to observe. When people inside the business begin referring to it as a thing rather than as part of a thing, the classification has moved without anybody minuting the change, and the obligations that come with the new classification have moved with it whether or not anybody has accepted them.

Support traffic is the other diagnostic worth reading, because it tells you who is arriving and what they already assume. If people who never bought the surrounding product are asking questions about the feature, they have found a proposition you did not know you were making, and the buyer test may now answer differently from how it answered originally. That is the good version of drift. It is worth acting on deliberately rather than absorbing quietly, because it is the only one of these signals that argues for more rather than less.

The fastest exposure of all is pricing, because a misclassified thing is difficult to price without discomfort. If you cannot state a price without first knowing which customer is asking, you are pricing a service and describing a product. If you can state a price but every sale renegotiates it, the conclusion is the same and the price list is doing decorative work. Discomfort at the point of pricing is not a confidence problem; it is the classification asserting itself.

Each verdict creates one obligation that belongs to the classification itself, as distinct from the general upkeep any shipped thing accumulates. These three deserve attention at the moment of the decision, because they are what make a verdict either true or merely aspirational.

The product verdict obliges you to find the buyer again, indefinitely. That is a standing commitment with an owner and a budget, and it is the obligation most often assumed to be somebody's spare-time responsibility. The test of whether the product verdict was real is whether a name is against that work in the same way a name is against the building. If nobody is named, the verdict was an aspiration expressed in the vocabulary of a decision, and it will be corrected later by circumstances rather than by judgement.

The service verdict obliges you to put the boundary into the agreement. What is being delivered, what is bespoke to this client, who owns what is built, and whether you are free to generalise it afterwards. That last clause decides whether this service can ever become a product. It costs almost nothing to negotiate before the work starts and a great deal to revisit once the work exists and the client has formed a view about who owns it. It is the single most valuable sentence in the document and the one most often left out of it.

The feature verdict obliges you to decide whether the work enters the shared codebase. If it does, it is generally available and has to be justified generally, for every customer, including the ones who never asked for it. If it does not, you are maintaining a variant, and the right response is to say so where the cost is visible to whoever is paying it, rather than leaving it to be discovered later by whoever inherits the code.

Beyond these three, every verdict except the fourth creates a standing inventory: a pricing surface, documentation, a release cadence, a name, a support path and, eventually, legal pages. That inventory is largely the same whichever verdict produced it, which is why it is treated separately in the standing cost of a product rather than restated here.

Not yet is a verdict rather than an evasion, but only when it is written down with its condition attached. An undated, unconditioned not yet is a refusal that nobody has to own and that nobody can be held to, which is exactly why it is so popular. It ends the meeting without ending the argument, and the argument returns in the same shape a few meetings later, with the same people holding the same positions and no new evidence between them.

The form that works has three parts: the classification you currently believe, the test that failed, and the observation that would change the answer. Stated hypothetically, and attributed to nobody: we believe this is a product; the distribution test failed, because we cannot name a route to a buyer who does not already know us; we will revisit it if enquiries arrive from organisations we have never worked with. That is falsifiable, it names what would move it, and anybody can check later whether the condition was met.

Note what separates not yet from no. Not yet obliges you to watch for something, which is a real obligation even though it is a small one, and it therefore needs an owner and a point at which somebody actually looks. A not yet with nobody watching is a no that has been made to sound more collaborative, and everyone eventually works that out, which costs more credibility than the plain refusal would have.

Saying no to one buyer, and not yet to your own team

The two refusals are different and they fail in different ways. To an external buyer, not yet is frequently worse than no, because it invites them to wait on something you have not committed to, and their patience is a cost you are spending without asking permission. The better answer stays inside the classification: not as a product, but we will do it as a service under these terms; or a clean no with the reason stated. Both let the buyer plan around you. A vague not yet does not, and it damages the relationship it was intended to protect.

Internally, the shape of the honest refusal is different again. A flat no on an internal friction item is corrosive, because the friction is real, continues to cost the people who raised it, and has now been officially declared not worth fixing. The truthful version names precisely what is being declined, which is productising it, and accepts that the friction still needs a cheaper answer: a convention, a checklist, a script somebody maintains, or an explicit decision that this is simply part of the cost of the work. Declining to build a product is not the same as declining to solve a problem, and conflating the two is how teams learn to stop reporting friction at all.

Zealsync develops its own products and also operates Intense Path, its brand, growth and technology agency, so the classification question arrives from both directions here as well: as friction inside delivery work, and as a request from a buyer who wants a particular thing built. The things classified as products went through the same four tests, and the tests were no more comfortable for having been written down in advance.

None of this is permanent. A classification is a statement about what is true now: who signs, how the second buyer arrives, what the thing is worth in isolation, and which mistake you can afford. Any of those can change, and the verdict should be restated when they do. What should not happen is a thing operating for years under a classification nobody has revisited since the first version shipped, while the complaints it produces are handled one at a time as separate operational problems with no common cause.