How do I describe what my product actually sells?

Describe the thing your customer pays to get, not the thing you built. Answer two questions in one sentence each, what customers concretely buy from you and what your product takes care of for them, and you have it. That answer matters more than it looks, because it decides whether your market is counted in subscribers, in projects or in something else.

What you build is not what they buy

Founders who build with AI tend to describe their product from the inside: the stack, the model, the features, the clever part. That is what you did. It is not what the customer pays for.

Take a tool that reads a shop's product data and writes descriptions with a language model. From the inside, it is "an AI copywriting engine for e-commerce". From the outside, a shop owner buys one of two very different things:

• Access to a tool they use themselves, every month, to write new product pages.
• A finished catalogue, rewritten once, delivered by you, with the tool as your private shortcut.

Same code. Two different products. And the customer, not you, decides which one they are buying.

This has become the thing that separates projects. Lovable says it creates more than 200,000 projects a day (Mezha, citing TechCrunch, 2026). When anyone can build, "what I built" stops being a description that sets you apart. "What my customer gets" still does.

The two questions

You do not need a framework. You need two sentences.

1. What do your customers concretely buy from you? Name the thing that changes hands: a monthly subscription to a tool, a one-off file, a delivered project, a seat for a team. If you cannot name it, you do not know yet what your price is attached to.
2. What does your product take care of for them? Name the job they no longer do themselves: writing product pages, chasing unpaid invoices, preparing a tax return. Write it in their words, not yours.

A quick test for each answer: could a stranger count how many people buy it? "Peace of mind for merchants" fails. "Shopify stores paying a monthly fee for a tool that writes their product pages" passes.

If your site already exists, start from it. Read your homepage and write down what it says the customer gets. Then correct it against what customers actually pay for. If you are not sure your page says it at all, check whether your landing page is clear enough first.

A worked example: why the answer sets your counting unit

Software is counted in subscribers. A service is counted in projects. That sounds like a detail until you put numbers on it. Go back to the description tool. Suppose, as a hypothesis for the example, that you have identified 2,000 shops in your niche that could use it.

Answer A: "They buy a subscription to the tool, €29 a month." The unit is a shop that pays every month. The ceiling, if every one of them subscribed for a full year:

2,000 × €29 × 12 = €696,000 a year

Answer B: "They buy a rewritten catalogue, €300 per project." The unit is a project. A shop does not rewrite its catalogue every month. Say it does so once every two years on average. The ceiling becomes:

2,000 × €300 ÷ 2 = €300,000 a year

Now the trap. Imagine the founder describes the product as Answer A, because that is how it was built, while customers actually behave like Answer B: they want it done once, then leave. The founder sizes the market at €696,000 a year when the real ceiling is €300,000. That is 696,000 ÷ 300,000 = 2.3 times too big, and nothing in the spreadsheet says so.

The error does not stay in one cell. Every number built on the market figure inherits it: the share you think you can win, the revenue target, how much you can afford to spend to find a customer. You will not see the mistake where you made it. You will see it three steps later, when the forecast and the bank account stop agreeing.

Both answers can be legitimate businesses. The point is not that one is better. The point is that you have to pick the one your customers are actually buying, because the rest of the math changes with it. If you have not yet written down how money comes in at all, start with the revenue model; this description is the step just before it.

Common ways the description goes wrong

• Describing the technology. "An AI agent built on a large language model" tells nobody what they get. The model is your cost, not their purchase.
• Describing the dream. "The operating system for small retailers" is where you hope to be in five years. Describe what someone would pay for this month.
• Listing every feature. Twelve features is not a description. Pick the one job customers would miss if you switched it off.
• Mixing shapes without saying so. A tool plus optional setup is fine, but say which one carries the revenue. That is the one you count.

What this method does not cover

It does not tell you whether anyone will pay. A sharp description of something nobody wants is still something nobody wants. Only real buyers settle that.

It does not tell you who pays, either. The person who uses the product and the person who hands over the money are not always the same, and that is a separate question with its own consequences.

And it does not size your market. It gives you the unit to count in, not the count. The 2,000 shops above are a hypothesis for the example, not a figure you can reuse. Finding a reliable number is its own piece of work.

How Banast does it

The first chapter of a Banast report asks exactly these two questions: "What do your customers concretely buy from you?" and "What does your product take care of?" Both are prefilled from your site. You correct them, you do not type them from scratch.

An earlier version asked twelve labels at once on that first screen. Only two remain. The others moved further into the report, to the point where they can actually be decided: the size of your customers is chosen once you look at a specific segment, and the way you sell once you look at a specific persona. The free text you write here is then used as it stands when the report searches for market figures, which is why it pays to describe what is bought, not what is built.