One paid week
Product definition
Turn an uncertain brief into a focused, buildable plan.
- Duration
- 1 week
- Best for
- Ideas with unresolved scope or technical risk
- Leaves you with
- A clear recommendation and, when ready, a fixed price
What you get.
- 01
Decision brief and product promise
- 02
Primary journey and failure states
- 03
First-release scope and exclusions
- 04
Technical approach, risks and recommendation
How it works.
- 01Clarify the goal
Define the user, business outcome and decision the week must unlock.
- 02Map the journey
Trace the customer, operator, data and integration states.
- 03Cut the scope
Separate the first useful release from later ideas.
- 04Make the call
Recommend a build, a smaller proof or no build yet.
What it does not cover.
- No compulsory build follows.
- We do not hide unresolved risks behind a polished prototype.
Questions, answered.
- Do we have to use QDev for the build?
- No. The decision pack is yours and another capable team can use it.
- Will we get a clickable prototype?
- When interaction is the risk. We prove the hardest unknown—whether it sits in the interface, data or an integration.
- What do you need before the week starts?
- The people who know the problem, access to existing work and authority to make decisions.
- What happens at the end?
- You receive the decision pack, recommendation and, when scope is ready, a fixed price.
Related work and thinking.
Related Note
What a one-week product definition sprint should leave you with
A useful definition sprint does not end with a wall of workshop notes. It ends with decisions a team can price, build, and defend.
Read the NoteRelated case
MTCC Diagnostics
A configurable diagnostics product where tenancy, scoring and output rules had to become explicit enough for interface, data and reporting to agree.
Read the case studyIs this a fit?
Tell us what exists, what is blocked and what needs to change. We'll tell you if this is the right engagement.