What is a product sprint, and when should you run one?

A product sprint is a short, fixed-length piece of work that takes one product problem and ends with a working prototype in front of real users. You finish with evidence of what people actually did, and a plan for what to build next, instead of another round of opinions about what they might do.

How long one runs, and what it costs, depends on the size of the problem and how much of the product already exists. Reworking a single onboarding flow in a live product is a different job from testing whether a new product should exist at all. The shape stays the same, though: one question, a fixed end date, a prototype and the people it is for.

1. What actually happens in a product sprint?

Every version worth running has four parts. The names vary between studios. The order shouldn’t.

1. Audit. Pull apart what already exists (the analytics, the support queue, the step where people give up) and agree the single problem the sprint will answer.
2. Prototype. Build a clickable version of the real flow, in a browser, on your own content, so it behaves like the product rather than a picture of it.
3. Test. Put it in front of actual users and watch what they do, not what they say they would do.
4. Plan. Turn what you saw into a build plan: what to make, in what order, and roughly what it costs.

The prototype is where most of the value sits, and where most sprints cut corners. A static mockup tells you whether people like the look of something. A working flow on real content tells you whether they can use it, which is the question you are paying to answer. This is why we build to think at Refract: get a working screen into the browser early, and let it take the arguments.

Real content matters more than people expect. Placeholder text and tidy sample data hide exactly the problems that sink a product: the name too long for the field, the account with four hundred records, the error state nobody designed.

Why one problem, and only one

A sprint with three goals becomes a small, rushed project. Choosing the problem is the hardest part of the audit, and it is worth arguing about. Good sprint problems are narrow enough to prototype end to end and important enough that the answer changes what you build next. “Why do trial users stall before connecting their data?” is a sprint. “Improve the dashboard” is a wish.

2. How is a product sprint different from a design sprint?

The design sprint is a specific method created by Jake Knapp at Google and developed with the team at Google Ventures. The book Sprint describes a five-day process for framing a problem, choosing a direction, prototyping and testing with customers. “Product sprint” is a broader label; different teams use it differently.

At Refract, the scope is one problem, a prototype of the real flow in a browser on your content, testing with users and a plan for the next build. We agree a fixed duration for that scope. The distinction is in the agreed outputs, not a claim that other sprint formats cannot test real interactions or produce useful plans.

Choose the format by the uncertainty you need to resolve. A realistic mock-up can be enough to test a proposition. A flow that depends on messy data, integrations or error states may need a different prototype. Both formats need representative participants and a clear decision at the end.

3. When should you run a product sprint?

A sprint earns its cost when a decision is expensive to get wrong and cheap to test first. In practice that usually looks like one of these.

• You are about to commit engineering time to a feature and nobody has watched a user try it.
• A key flow, such as onboarding, setup or checkout, loses people and the team disagrees about why.
• You are moving upmarket and the product was designed for a different buyer.
• An internal tool has grown by accretion and the people who use it every day have built workarounds.
• You need something concrete to show investors or a launch customer, and slides have stopped working.

A working screen settles an argument a deck would drag out for a month.

Products with a lot of edge cases benefit most. Keeyu helps large retailers manage everything that can go wrong after an order is placed, and when we were embedded in Keeyu’s team we designed from the real product rather than from idealised flows. In software like that, the edge cases are the product, and a prototype built on clean sample data tests very little.

The same goes for anything that works on a user’s own information. Atrium is a CRM that watches email, LinkedIn, WhatsApp and Slack for founders and salespeople and drafts the follow-ups. Whether a drafted follow-up is useful depends on whose conversations it came from, which is the kind of thing you only learn by watching someone use it with their own.

4. When is a product sprint the wrong tool?

Sprints are popular, which means they get used for problems they can’t answer. Skip one if any of these is true.

• The problem is already clear and the fix is known, so the right move is to build it.
• The real question is positioning or pricing, which sits with buyers rather than users.
• You have no access to the people the product is for, so the test would be guesswork.
• The issue is technical, such as performance or reliability, and a prototype can’t reproduce it.
• Nobody has the authority or the budget to act on the result.

The second is easy to miss. If prospects aren’t converting because they can’t tell what the product does or who it is for, a better onboarding flow won’t help. That is a positioning problem, and it needs a different kind of sprint: one that agrees who you are for and what you stand for before anyone redesigns a screen.

5. How long should a product sprint take?

Set the duration after defining what needs to be tested. Include time for access to the existing product, prototype work, user recruitment, testing and a decision. A contained interaction and a flow with several integrations need different schedules. Agree a fixed end date and reduce the scope if the work will not fit.

What you have ready matters more than the number of weeks. Before the first day, line up these.

• One decision-maker who will be there for the audit and the plan.
• Access to the existing product, its analytics and its support history.
• Real content to build on, with anything sensitive anonymised.
• A handful of real users booked for testing before the prototype exists, because recruiting is the step that slips.

6. How we run product sprints at Refract

Our entry offer for product work is a product sprint: one problem, a fixed length, a working prototype in front of your users at the end. We audit what you have, prototype the real flow in a browser on your content, test it in front of actual users and hand you a plan for what to build, in what order, with a rough cost.

The people who design the prototype are the people who would build the product, in the same room and the same week, so the plan is written by people who know what the code will take. The plan is yours whether or not we build it, as is everything else we make: designs, code and files.

Projects start at A$15k and scale to A$100k+, depending on what you need. Scope is fixed and the price agreed before work starts. Our founders also hold equity in a set of ventures, and our team does the work on them, which keeps the method honest. If something doesn’t hold up in our own businesses, we won’t sell it to you.

7. Questions

What is the difference between a product sprint and a design sprint?

A design sprint is a defined five-day method for prototyping and testing an idea. Product sprint is a broader term. At Refract it means one problem, a browser prototype on your content, user testing and a build plan, with a fixed duration agreed for the scope.

Who should be involved in a product sprint?

A decision-maker from the company, someone who knows the product’s data and history, and the designers and engineers doing the work. The users in the test matter most, and they should be booked before the sprint starts.

What do you get at the end of a product sprint?

A working prototype of one flow, what was learned from watching real users try it, and a plan for what to build, in what order and at roughly what cost. The prototype and the plan should be yours to keep, whoever builds the product.

Can a product sprint work for an internal tool?

Yes, and internal tools are often the best candidates. The users are easy to reach, and the workarounds they have built show exactly where the tool fails them.

How much does a product sprint cost?

It depends on the size of the problem and how much of the product exists already. At Refract, projects start at A$15k and scale to A$100k+, depending on what you need, with the scope fixed and the price agreed before work starts.

Is a prototype the same as an MVP?

No. A prototype exists to answer a question and can cut every corner the question doesn’t depend on. An MVP is used as a real product and needs production-appropriate reliability. Both need appropriate security and data handling: use synthetic or anonymised data where possible, and protect any real user information used in testing.