Refract Group2026
Glossary
Product sprint
A product sprint is a short, fixed piece of work on one product problem that ends with a working prototype tested by real users and a plan for what to build next.
- Book test usersDone before the week starts
- Audit what existsProduct, analytics, support
- Prototype the flowIn a browser, on real content
- Test with usersWatch what they do
- Write the build planOrder of work and rough cost
Product sprint in detail
- Also called
- Product design sprint, Prototype sprint
- Topic
- Product
- Updated
What it is
A product sprint has one question, a fixed end date and four parts in order:
- An audit of what already exists, such as the analytics, the support queue and the step where people give up, which narrows the work to one problem.
- A prototype of the flow that addresses it, built to behave like the product.
- A test, with people who use the product trying the prototype while the team watches.
- A plan: what to build, in what order and at roughly what cost.
The term is looser than design sprint, which names one method. Studios and product teams use it in different ways and for different lengths. What makes it one is the single problem, the tested prototype and the plan.
Why it matters
A sprint is worth its cost when a decision is expensive to get wrong and cheap to test first: a feature about to take months of engineering time, or an onboarding step where trial users drop out and the team disagrees about why. For the price of a week, the company sees whether the fix works before it pays for the build. If the test shows the idea is wrong, that is a cheap result too.
How we do it
If you want to try working with us first, we offer a product sprint: one week, $2,500, credited in full against work that starts within 60 days. Before the week, the client books a handful of users, because recruiting is the step that slips. We audit the product, its analytics and its support history, and narrow the problem until it fits the week.
Then we build the flow so it can be clicked through in a browser, on the client’s own content, and watch their users try it. The plan is written by the designers and developers who would build the product, the same team that designed and built Prism, our own product. The prototype and the plan are the client’s, whoever builds next.
An example
Say a payroll product loses new customers at the step where an admin imports their staff. The audit shows most admins leave after downloading the template spreadsheet. The prototype accepts the export they already have from their old system and asks them to match its columns. Five admins try it with their own files, and four finish. The plan puts the column matching first, before the integrations sales had been asking for.
Common mistakes
- Bringing three problems to one week. A sprint with several goals turns into a small, rushed project, so choose the one problem whose answer changes what you build next.
- Booking users once it has started. Recruiting takes longer than anyone expects, and a prototype with nobody to test it has answered nothing.
- Using it on a positioning problem. If buyers cannot tell what the product does or who it is for, a better flow inside it will not help them decide.
- Leaving the decision-maker out. When the person who owns the decision misses the audit and the plan, the result waits for another meeting.
Product sprint vs design sprint
A design sprint is a specific five-day method, developed by Jake Knapp at Google and GV, while a product sprint is a broader label for a fixed piece of work that tests a prototype of one problem and ends in a build plan.
| Product sprint | Design sprint | |
|---|---|---|
| Origin | A general term, used differently | Jake Knapp at Google, 2010, then GV |
| Length | Fixed per sprint; our trial is a week | Five days, Monday to Friday |
| Prototype | The flow, on the product’s real content | A realistic prototype, built Thursday |
| Ends with | Test results and a build plan | Friday’s test with customers |
Questions
What people ask about product sprint.
A design sprint is a five-day method from GV: map the problem, sketch, decide, prototype and test with customers, one step a day. A product sprint is a broader term for a fixed piece of work on one product problem. At Refract it means an audit, a browser prototype on your content, a test with your users and a build plan.
It depends on the size of the problem and how much of the product exists. For teams who want to try us first, we run a one-week product sprint for $2,500, and if more work starts within 60 days, that amount comes off its price. Larger work is scoped and priced before it starts. Either way, you keep the prototype, the account of what your users did and the plan.
Skip a product sprint when the fix is already known, when the open question is pricing or positioning, when the fault is technical, such as performance, or when you cannot reach the people the product is for. A prototype cannot answer any of those, so the week would produce guesses.
Where this shows up in our work
Related terms
Working on this now?
Tell us what you’re building and where it’s stuck. We reply within 12 hours.
Most teams start with a call, then a sprint or an audit.
The people you’d work with, from the first call to launch