Here is the honest version of how I scope a new product: I spend roughly one week doing structured thinking before I open a code editor, and that week covers five distinct activities, in order. The output is a single document I call the scope brief, which gives me a shippable build plan, a clear definition of what version one actually is, and a list of everything I am explicitly not building yet. That document is the only thing that stands between a good idea and a month of building the wrong thing.
This guide describes my actual process for products I have shipped, including Scarab HQ, Minipod, Legworker and IntentLift. It is a prescription, not a theory. Adapt the timings to your situation, but do not skip the order.
Why Scoping Before Development Is the Work, Not the Delay
Most founders treat scoping as a hurdle between the idea and the fun part. That framing is wrong, and it is expensive. The build phase is where bad assumptions become sunk costs. The scoping phase is where those assumptions are cheap to challenge. A week of structured thinking before development routinely saves weeks of rework. It also produces something underrated: a bias toward cutting scope rather than adding it, which is the only way small teams ship anything.
The Five-Stage Scoping Process I Use Every Time
- Day 1: Write the problem statement in one sentence
- Day 2: Map the person who has the problem
- Day 3: List every possible solution, then eliminate
- Day 4: Define version one by cutting, not adding
- Day 5: Write the scope brief and pressure-test it
Day 1: Write the Problem Statement in One Sentence
The constraint is one sentence. Not a paragraph, not a bullet list. One sentence that names the person, the situation, and the cost of the problem. "Freelance event producers in the UK waste hours chasing speaker confirmations by email because there is no lightweight tool built for the admin around small-scale events." That is a problem statement. "Help people manage events better" is not.
If you cannot write one sentence, you do not understand the problem yet. That is useful information. Spend the day talking to people in the situation rather than drafting features. The sentence forces precision. Precision exposes gaps. Gaps are what kill products in month three.
Day 2: Map the Person Who Has the Problem
I do not write a formal persona document. I write answers to four specific questions: What does this person do on the day the problem bites them? What have they already tried? What would they accept as a good-enough fix right now? And what would make them tell someone else about a solution? Those four answers reveal more than any persona template, because they are situational rather than demographic.
For UK-based products this step also forces you to think about context that often gets skipped: whether the user is a sole trader or an employee affects how they buy, how they justify a purchase, and how price-sensitive they are. A tool aimed at a UK SME owner is a very different product from one aimed at someone buying software inside a company on a procurement process.
Day 3: List Every Possible Solution, Then Eliminate
I write down every plausible way to solve the problem, including the non-software ones. A spreadsheet template. A Notion setup. An existing product with a workflow tweak. A one-page PDF guide. I list them all before I list any software features. This is not a creativity exercise. It is a pressure test for whether building software is actually the right answer at all.
After the list is complete, I eliminate anything that already exists and works well enough. What remains is the design space for the product. Often it is much narrower than the original idea suggested, and that is good. A narrower design space means a clearer product, a smaller version one, and a faster path to something real people can use.
If you cannot identify at least one thing on your list that a determined person could do today without your product, your problem statement probably needs tightening. Real problems have makeshift workarounds. That is where you look for the wedge.
Day 4: Define Version One by Cutting, Not Adding
This is the hardest day, and also the most valuable. I take the narrowed design space from day three and list every feature that would make the product genuinely useful. Then I cut everything that does not directly address the one-sentence problem. Not "this would be nice". Not "users might want this later". The test is: does this feature make the product work for the person described in the problem statement, for their specific situation?
What survives the cut becomes the version one feature set. I also write a separate list titled "Not in version one", and I keep it visible throughout the build. That list is as important as the feature list. It is what you say when someone asks why you have not built a thing yet. It is what keeps scope from creeping back in during the build itself.
| In version one | Not in version one (yet) |
|---|---|
| The core workflow that addresses the problem | Integrations with every tool imaginable |
| One clear way to do the main job | Settings and customisation options |
| Manual or simple automation where needed | Advanced reporting and dashboards |
| A way for the user to see that it worked | Mobile app alongside the web version |
| Enough UI to not embarrass you | Polished onboarding flows and tooltips |
Day 5: Write the Scope Brief and Pressure-Test It
The scope brief is a single document, usually two to four pages, that contains: the one-sentence problem statement, the person description from day two, the version one feature list, the explicit not-in-version-one list, and a rough estimate of how long the build should take. That last number is not a promise. It is a forcing function. If the estimate looks like three months of solo work, the scope has not been cut enough.
The pressure test is simple: I read the scope brief to someone who was not involved in the process and ask them two questions. First, does the problem feel real? Second, does version one obviously address it? If the answer to either question is uncertain, the brief goes back for revision before any code is written. This takes an hour. It is consistently the highest-return hour in the whole week.
What a Good Scope Brief Actually Contains
- Problem statement: one sentence, names the person, situation and cost
- User description: four situational answers, not a demographic profile
- Design space: what you considered and why you ruled it out
- Version one features: only what directly solves the stated problem
- Not-in-version-one list: explicit and visible throughout the build
- Build estimate: rough, honest, used as a scope check not a deadline
- Open questions: things you do not know yet and plan to learn during build
If your scope brief does not have an open questions section, you are probably overconfident about what you know. Every real product has things you cannot resolve before you start building. Name them explicitly so they do not quietly drive decisions later.
The Mistakes That Derail This Process
The most common failure is starting day three before finishing day one. Feature thinking is more comfortable than problem thinking, and most founders drift into it early. The second most common failure is treating the not-in-version-one list as a polite suggestion rather than a hard constraint. Scope creep rarely announces itself. It arrives as a reasonable-sounding exception on a Tuesday afternoon.
The third failure is doing this process alone in a document and never saying it out loud to anyone. The pressure test on day five is not optional. You need to hear your own brief through someone else's ears. The gaps you have been unconsciously papering over become obvious in the first thirty seconds of explaining it.
How This Connects to Building With Modern Tooling
If you are using AI coding tools, language models or any of the current generation of builder tools to accelerate development, a tight scope brief matters even more, not less. These tools are good at generating code quickly. They are not good at knowing what code to generate. The tighter your scope, the more useful the acceleration. Loose scope plus fast generation produces a lot of code that solves the wrong problem very efficiently.
How long should the scoping process take for a solo founder?
One focused week is the right target for most products. Some simpler tools can be scoped in three days. More complex products with unclear problem spaces might need ten days. The constraint is not time, it is completion: you need a finished scope brief, not a partial one. An incomplete scope brief is worse than no brief, because it creates false confidence.
What if I learn something during the build that changes the scope?
That happens on every real project, and it is fine. The scope brief is a starting position, not a contract. When something material changes, update the brief explicitly and consciously. The discipline is not rigidity. It is making sure that every scope change is a deliberate decision, not something that just drifted in because someone had a good idea in a Slack thread.
Do I need to talk to users before I scope, or can I scope from my own experience?
If you are the person with the problem, your own experience is legitimate data. But it is not sufficient on its own. At minimum, find two or three other people in the same situation and ask them the day-two questions. What you discover will either sharpen your brief or reveal that your experience is not as representative as you assumed. Either outcome is useful.
How detailed should the version one feature list be?
Detailed enough that a developer who has never heard of the product could build a rough version without asking you a question. That means specific enough to describe behaviour, not just intent. 'User can add a speaker to an event' is a feature. 'Better speaker management' is not. The detail level also serves as a natural scope check: if a feature is hard to describe specifically, it probably needs breaking down or cutting.
Is this process different for B2B versus B2C products?
The process is the same. The day-two user description changes significantly. For B2B products, you need to think about who feels the problem, who decides to buy a solution, and whether those are the same person. In UK SMEs they often are not. A tool that saves a developer time might need to be sold to an operations manager. That gap between user and buyer affects what version one needs to do to get over the line.