Product scope
One signed document that says who the product is for, what v1 does, what it connects to and what waits, so every quote and every developer works from the same plan.
Software runs late when nobody ranked the feature list before the build. We sit with the people who will use the tool, list every system, spreadsheet and manual step it replaces, and check API access to each. From that we write the roles, screens and data model, rank every feature and give each v1 feature a test your team can run. The build starts once you sign it off.
For Founders, COOs and heads of operations about to commission a web app, CRM or internal tool, or holding quotes that don’t agree on what is being built.
You need this when
- 01
You have three quotes for the same tool, and each one describes a different product.
- 02
Everyone agrees the spreadsheets have to go, and nobody has written down what replaces them.
- 03
The wish list grows at every meeting, and nothing has been ranked.
What’s included.
Sessions with users
We sit with the people who will use the tool every day and record how they work now, step by step.
Systems audit
Every current tool, spreadsheet, data source and manual step listed, with API access checked for each.
Roles and screens
Who uses the product, what each role needs to see and do, and the screens that follow from it.
Data model
The records the product holds, how they relate, and which system is the source for each figure.
v1 and later
Every feature ranked, with a line drawn between what ships in v1 and what waits.
Acceptance checks
For each v1 feature, a plain test your team can run to confirm it works.
How it runs.
A Sprint of 1–4 weeks on its own. Inside a Build, the scope is signed in week 2.
- 01 · Watch the work
We interview and watch the people who will use the tool, one role at a time.
- 02 · Map what exists
We list every system, spreadsheet and manual step, and request API access to each.
- 03 · Draft and rank
Roles, screens, data model and integrations go into one document, with every feature ranked.
- 04 · Sign off v1
We go through it with you line by line, move items between v1 and later, and you sign it off.
Deliverables
- Scope document: roles, screens, data model, integrations, v1 and later
- Map of current tools, data sources and manual steps
- Role matrix: who sees and does what
- Screen list with rough flows for each role
- Integration list with API access status
- Acceptance checks for each v1 feature
- Risks and open questions, each with an owner
- Dated plan to v1
Works with
What buyers ask.
Can’t we go straight to building?
You can. The same decisions still have to be made, only later and in code, where changing them means rewriting work. The scope makes them on paper first.
Do we have to build with you afterwards?
No. The Sprint ends with the scope and a recommended next step. It is written in plain language, so your board and any developer you brief read the same plan.
What if we don’t know yet what we need?
That’s a normal place to start. We begin from the problem, such as a weekly report that takes a day to assemble, and work back to the smallest tool that fixes it.
Pairs well with
Core screens designed in Figma and tested by your team before the build.
Let’s build your pipeline.
Tell us what you sell, who buys it and roughly what a customer is worth to you. We reply with questions, then a written proposal.