We rewrote the one-page product definition eleven times. I know it was eleven because the file names went to eleven, and because somewhere around the seventh I stopped believing we would ever finish it.

Version one described a technology. It used the word platform twice and named three model capabilities. It was accurate and it was useless, because it did not say what anybody would stop doing if they bought it.

Version eleven described a job. Who does it today, how long it takes them, what goes wrong when it goes wrong, and what the company takes responsibility for. It was shorter, less impressive to read aloud, and it was the first version an engineer could build against and a salesperson could sell from.

The Monday test

There is one question that should be asked before any serious money or time is committed, and it is uncomfortable enough that most teams avoid it until an investor asks it for them.

If the model provider shipped your headline feature natively on Monday, what would you still have?

Not what would you do. What would you still have. The answer is usually one of five things, and only four of them are a company.

The fifth answer, the one that is not a company, is: a better interface. Interfaces are real work and they are genuinely valuable, but they are also the layer that gets absorbed first, because the party whose feature you are wrapping has every incentive to wrap it themselves and a much lower cost of doing so.

It is worth saying plainly that wrapper is not an insult. Every application in history is a wrapper around something: a database, an operating system, a payment network. The question was never whether you wrap. It is whether the wrapping is the part that carries the value.

The four places value actually sits

Workflow depth. The product does not answer a question. It completes a job that has steps, state, handoffs and an approval somewhere in the middle. A model answers. A workflow remembers what happened last Tuesday, knows who has to sign off, and behaves correctly when somebody is on holiday. That accumulated correctness is not something a raw capability replaces, because the capability was never the hard part.

The test is simple. Can a user get most of the value by pasting their problem into a general purpose assistant? If yes, you are selling convenience. Convenience is a real business and it is a thin one.

Data you accumulate by operating. Not data you licensed, which your competitor can also license. Data that exists only because your product ran: which suggestions were accepted and which were rejected, what the correction was, what the outcome turned out to be six weeks later. This is the asset that compounds, and it is the one most teams forget to capture because capturing it is not on the critical path to the demo.

Decide on day one what you log. It is nearly free to record and impossible to backfill.

Integration surface. Work happens where work already lives. A product that reaches into the systems of record, reads the real state, and writes back is doing something a general capability cannot do without the same integration work. That work is unglamorous, slow, and it is a moat precisely because it is unglamorous and slow.

Accountability. This is the least discussed and it may be the strongest. Model providers are explicit that output correctness is not guaranteed. Somebody has to stand behind the result. When you sell into a function that has consequences, whether financial, clinical, legal or operational, a large part of what the customer is buying is that a company exists which will answer for the output being wrong.

That has a cost. It means evaluation, monitoring, human review paths and insurance. It is also the reason a serious buyer will pay you rather than use a general tool that is free to them, and it is not a position an interface can occupy.

Write down what you are not

The most useful half of a product definition is the exclusions.

A definition that only says what you do will be stretched by every customer conversation, because saying yes is pleasant and saying no is not. Six months later you have four half-products, a roadmap nobody believes, and an engineering team that has stopped asking what the priority is because the answer keeps changing.

The working test for a product definition is this: can somebody on your team decline a customer request without asking you? If they have to ask, the definition is a description rather than a decision, and you are the bottleneck on every conversation the company has.

Write both columns. What this does. What this does not do, and where those requests go instead. Put a date on it and revisit it deliberately rather than continuously.

Three ways this goes wrong

You build the demo that impresses other builders. There is a specific kind of demo that gets applause from engineers and produces no purchase orders. It shows capability rather than completion: look what it can do, rather than look what it finished. Buyers do not buy capability. They buy the absence of a problem they currently have, and the demo that sells is often visually dull because it ends with a task being finished and a person going home.

You define the product as a capability rather than a job. Any sentence of the form we use artificial intelligence to improve something is not a product definition. It contains no user, no current alternative, and no way to tell whether it worked. Rewrite it as: this person spends this long doing this thing, it goes wrong in this way, and afterward they do not have to.

You confuse novelty with demand. That nobody else does this is not evidence that anybody wants it. Sometimes it is evidence that several people tried and discovered why not. When you find genuinely empty space, spend a day asking who else has stood here before assuming you are the first to arrive.

The eleven versions were not wasted, although at the time it felt like avoidance. Each rewrite removed something we had been carrying because it was impressive rather than because it was true. What was left was smaller than what we started with and considerably harder to argue with.

A feature is not a company. A workflow somebody is afraid to change is.

Tomorrow: the ten-name customer list, and why a market is not a segment.