Short answer
A written thesis is a short document, usually four to eight pages, produced collaboratively at the start of an engagement, stating in plain language what we are building, why, and for whom. We still produce one for every project because discovery surfaces the constraints that never appear in a brief: the supplier whose inventory format no standard API handles, the branch that runs a different workflow than the other four, the fulfilment partner whose technical requirement reshapes the checkout architecture. The client reviews and signs off on the thesis before the build quote is issued, and the quote is priced against it.
We call it a thesis. Other studios call it a discovery output, a brief, a product definition, or a requirements document. The name is less important than the artifact: a written statement, produced collaboratively at the start of an engagement, that says in plain language what we are building, why, and for whom.
Every project we take on produces one. This has not changed, even as the tools available for producing and consuming text have gotten significantly more capable. Here is why.
What the Written Thesis Actually Is
The thesis is not a features list. It is not a technical specification. It is a document that answers three questions: what problem does this product solve, who is experiencing that problem, and why does this approach make sense for them.
It is short. Usually four to eight pages depending on the complexity of the engagement. It is written in language a non-technical reader can follow because both the client and the build team need to be able to hold it at the same time.
At the end of a discovery phase, we review the thesis with the client and they sign off on it before the build quote is issued. The thesis is what the quote is priced against. If the thesis changes materially, the quote changes.
The Pressure to Skip It
The pressure to skip or abbreviate the thesis comes from two directions.
Clients who have a clear vision of what they want to build sometimes feel that writing down what they already know is redundant. Why spend a week on a document when you could spend that week building? The answer is that the vision in a client's head is not the same as a shared understanding between the client and the studio. Discovery surfaces the gaps.
More recently, there is a different kind of pressure: clients who have had a conversation with ChatGPT or used another AI tool to generate a product requirements document are arriving with that document and asking us to skip discovery. The document they bring is often impressive looking. It is also often wrong in subtle ways - requirements that are stated as if they were the only option when the problem has multiple valid approaches, features that are included because they appeared in similar product descriptions rather than because this client's users need them.
An AI-generated document is a starting point, not a thesis. It is a useful input to a discovery conversation, not a substitute for one.
What Discovery Finds That the AI Does Not
Discovery finds the constraints that are not in the brief.
The client who wants an inventory management system but has not mentioned that their supplier sends inventory updates via a format that no standard API handles. The healthcare product where one branch operates on a different workflow than the other four. The e-commerce integration where the client's fulfillment partner has a technical requirement that affects the checkout architecture.
These are real things we have found in discovery. None of them would have appeared in a generated document. They appeared because we asked questions and listened to the answers.
Discovery also finds disagreements within the client team. When multiple stakeholders are involved in a product, their ideas about what the product should do are often not identical. A written thesis that all of them read and sign off on is the mechanism for surfacing and resolving those disagreements before they become mid-build conflicts.
Why Written
Writing forces specificity. A spoken conversation can contain agreement that dissolves when both parties write down what they agreed to. A written document that both parties read and sign creates a shared, reviewable record.
In a year when AI tools can generate enormous volumes of text instantly, the discipline of writing something carefully - slowly enough to catch the gaps and ambiguities - is more valuable, not less. Anyone can generate words. The work of a thesis is in the thinking that underlies them.
We are not going to stop producing written theses. We are going to keep doing discovery even when clients arrive with AI-generated documents. And we are happy to explain why to any client who finds the process slower than expected.
Questions · 04
Frequently asked questions
Can I bring my own AI-generated requirements document instead?
Bring it. An AI-generated document is a useful input to a discovery conversation, not a substitute for one. These documents often look impressive and are wrong in subtle ways: requirements stated as if they were the only option when the problem has several valid approaches, features included because they appeared in similar product descriptions rather than because your users need them.
How long is a thesis, and who is it written for?
Usually four to eight pages, depending on the complexity of the engagement. It is written in language a non-technical reader can follow, because the client and the build team both need to be able to hold it at the same time. It answers three questions: what problem the product solves, who is experiencing that problem, and why this approach makes sense for them.
What happens if the thesis changes after we sign off?
The quote changes. The thesis is what the build quote is priced against, so a material change to the thesis means a material change to the price. That link is deliberate, because it makes scope movement visible and priced instead of quietly absorbed mid-build.
Why does it have to be written down rather than just discussed?
Writing forces specificity. A spoken conversation can contain agreement that dissolves the moment both parties write down what they agreed to. A written document that both sides read and sign creates a shared, reviewable record, and it is also the mechanism for surfacing disagreements between stakeholders before they turn into mid-build conflicts.
