How to Test Product Ideas Inside a Two-Week Sprint in 2026

Most B2B product teams already know which customer request they want to test. What they lack is a way to test it without breaking the sprint. This guide from the BuildBetter team gives you a five-step method you can run inside the two-week Scrum sprint or six-week Shape Up cycle you already use. It covers how to shape a small bet, pick the right test, fit it into your existing cadence, and turn the result into a decision at your next planning session. A worked example follows the steps.

What It Means to Test a Product Idea Inside a Sprint

Testing a product idea inside a sprint means shaping one small, bounded bet, choosing the cheapest instrument that answers the specific question, and running the build-release-observe-decide loop within the cadence your team already uses.

If you run two-week sprints, you know the pattern. Research never quite fits. Discovery loses to the committed backlog every planning session. Nobody wants to rebuild the process just to try something new. The method below works inside the constraints you already have.

The goal is specific: shorten the time from a useful customer signal to a defensible product decision, while protecting the team's ability to finish committed work. A decision is defensible when you can point to what customers did, not only to what they said or what the team guessed.

This approach is not:

• A separate dual-track discovery team running in parallel
• A research phase that has to finish before delivery starts
• A process overhaul that needs leadership sign-off

It is a reserved slice of capacity with named owners for the build, for customer notification, and for evidence review.

This lines up with Teresa Torres's definition of continuous discovery: at least weekly touchpoints with customers, by the team building the product, where that team runs small research activities in pursuit of a desired outcome. A two-week sprint should therefore contain at least two customer touchpoints. The method below keeps those touchpoints tied to a real bet rather than letting them drift into general check-ins.

By the end of this page, you will be able to run this in your next sprint with no new tools.

Why Discovery Keeps Losing to the Sprint Backlog

Discovery loses to the backlog because of a few repeatable failure modes, and each one shows up as a recognizable symptom in standup. If you can name the failure, you can fix the right thing.

• No appetite. Symptom: "That's probably a six-week feature, let's revisit next quarter." The idea never gets a fixed time budget, so it gets estimated as a full feature. Against committed work, it always looks too expensive to start.
• Wrong instrument. Symptom: "We did five interviews and everyone said they'd use it. Nobody does." The team ran interviews when the real question was behavioral, or built a full feature when a click-through would have answered a usability question. The evidence never matches the decision.
• Observation outlives the sprint. Symptom: "It shipped Thursday. Did anyone check?" Code ships on day 8, but the job it supports, such as a Friday report, has not happened yet. The sprint ends and nobody owns the follow-up.
• Collapsing "shipped" into "learned." Symptom: "Ticket's closed, moving on." A change can be merged, deployed, exposed, announced, tried, and adopted on six different dates. Teams treat merged or deployed as the finish line.
• Fixing the wrong constraint. Symptom: "If we could just build faster..." If a build takes two days but waits three weeks for review, generating more code will not fix the main delay. If releases go out immediately but requesters never hear about them, faster deployment will not fix adoption.
• Scope creep mid-test. Symptom: "We're almost there, just need permissions and filters." The slice turns out to need a larger commitment, the team keeps going anyway, and the experiment eats the committed work.

The Method: Shape the Bet, Match the Test, Fit the Loop

The method has five steps, and a team can run all of them manually today with a doc, a feature flag, and a calendar. It comes from Ship First: How to Build Self-Improving Products by Spencer Shulem, a short companion to Customer-Led Development.

1. Understand the job before choosing what to build.
2. Set an appetite and shape a bounded slice.
3. Match the test to the question.
4. Fit the loop into the sprint you already run.
5. Bring evidence to planning and make one decision.

Each step produces a concrete output that feeds the next: a job statement, a shaping note, a chosen instrument, a set of tracked dates, and a recorded decision. None of them requires a purchase, a new role, or a change to your sprint length. The constraint the method works around is attention and capacity, not tooling.

Step 1: Understand the Job Before Choosing What to Build

Before shaping anything, learn what happened the last time the customer needed this, and where their current workflow broke down. Requests describe solutions. Jobs describe the work the solution is supposed to help with.

Take a common example. A customer asks for a dashboard. In the interview, you ask them to walk through the last time they needed that information. It turns out they spend Friday afternoon copying data into a report for a staffing meeting. That changes what is worth building. A dashboard they have to visit and interpret may not remove the Friday copying at all.

Torres's interviewing guidance supports this: collect specific stories about past behavior ("Tell me about the last time you...") rather than asking for opinions or feature wishlists. Stories expose the workaround, and the workaround is usually where the value sits.

Start with feedback you already have before scheduling new calls:

• Support tickets show where people got stuck and what they tried.
• Call notes from sales and CS calls often include the workaround in passing.
• Slack threads with customer-facing teams capture context that never reaches a ticket.

Existing feedback gives you context, past behavior, and the workaround, which is often enough to write the job before talking to anyone new.

Output of this step: a one-sentence job statement ("Ops leads need a weekly staffing summary ready for the Friday review without copying ticket data by hand") and the single assumption you are least sure about.

Step 2: Set an Appetite and Shape a Bounded Slice

An appetite is the amount of time a problem deserves, decided before you design the solution. Ryan Singer introduced the idea in Shape Up, Chapter 3, and it reverses the usual estimate-first habit.

"Estimates start with a design and end with a number. Appetites start with a number and end with a design." — Ryan Singer, Shape Up

This is why ideas that get estimated as full features never start. Set the budget first (fixed time, variable scope) and the question becomes "what can we learn in three days?" instead of "how long would the whole thing take?"

Size the budget to the value of the answer. A day or a week may be enough for a small experiment. The budget should then constrain what you build, not the other way around.

Keep the slice focused on the job. A request for a better report might justify testing one report for one recurring decision. Customization, filters, and scheduling wait until the first result gives you a reason to invest.

Shape a slice that produces a result the customer can use, and be explicit about which question it can answer. A frontend simulation tests navigation. A working backend with assisted setup tests the outcome. These are different questions, and the slice determines which one you can answer.

Write the scope down before coding as a short shaping note:

• Job: the one-sentence job statement
• Assumption: the riskiest one you are testing
• Appetite: the fixed time budget
• Slice boundary: what this version does
• Named customers: the specific accounts who will see it
• Out of scope: the list of things you will not build

Circuit-breaker rule: if the slice turns out to need a larger commitment, stop and reconsider the test and its budget. The unexpected work may change which instrument is worth using.

Step 3: Match the Test to the Question

The instrument you choose must match the question you are asking, or the evidence will not support the decision. Interviews cannot prove real-world adoption, and a working release is an expensive way to check whether a button makes sense.

Synthetic personas belong in the exploration row only. Use them to generate questions and surface concerns worth checking. They do not replace evidence from real customers.

Torres's assumption-testing guidance points the same way: test one specific assumption at a time, measure behavior rather than stated intent, and simulate a moment in the customer experience where you can. The rows map to classic product risks. "Can people use the flow?" is usability risk. "Does it fit actual work?" is value risk.

A working release counts as a research activity when it answers the assumption quickly and its consequences are manageable. If the slice sits behind a flag, goes to a handful of named accounts, and can be turned off, it is a test, not a commitment.

Here is the Friday example across the instruments. An interview reveals the copying. A click-through shows whether the flow makes sense. A working version shows whether they use it on Friday and stop copying.

Step 4: Fit the Loop Into the Sprint You Already Run

Reserve capacity for one small experiment in sprint planning, and name three owners: one for the build, one for customer notification, and one for evidence review. One person can hold two roles, but each role needs a name. Unowned notification is where most experiments quietly die.

Shape Up's "get one piece done" idea applies here, with one extension. Don't stop at finishing a piece internally. Put an appropriately bounded piece in front of named customers early enough in the sprint that their behavior can influence the next investment.

Use feature flags to control exposure. A feature toggle lets you show the slice to selected accounts while everyone else keeps the existing experience. Be clear about what this does and does not prove: a variant that is live has not necessarily had a fair test. If customers never heard about it, or the job did not occur, "live" means nothing.

Let observation continue past the sprint boundary. Bring evidence to the next planning session rather than forcing a verdict into the current review. Many B2B jobs are weekly or monthly, and the sprint calendar does not change when they happen.

Track six separate dates for each experiment:

1. Merged: code is in the main branch
2. Deployed: code is running in production
3. Exposed: the flag is on for named accounts
4. Announced: those accounts were told what changed and what to try
5. Tried: a customer used it at least once
6. Adopted: the customer's behavior changed (for example, the workaround stopped)

The gaps between these dates show where the delay actually lives. For a day-level template, see how to run a 10-day customer-led sprint.

Step 5: Bring Evidence to Planning and Make One Decision

Set an evidence cadence alongside your release cadence, and review experiments at a fixed time, such as the start of sprint planning. Under the Scrum Guide, planning for a two-week sprint runs to roughly four hours at most. Fifteen minutes of that is enough to review one experiment.

Two rules keep this from sprawling:

• Limit unresolved experiments. Cap how many can be open at once. One is a good starting number.
• Assign one person to each next decision. Group consensus delays decisions. A named owner makes one.

Define the possible decisions in advance, so the review is a choice and not a debate:

• Invest further: shape the next bounded slice
• Change the slice: same job, different scope
• Switch instruments: the question needs a different kind of evidence
• Stop: record what you learned and close it

Keep conversations running after release. Usage data tells you what happened. Customers tell you why: they stopped halfway because a permission was missing, they didn't trust the numbers, or a meeting interrupted them. Without those conversations, you will misread the numbers.

The principle behind all five steps: change the constraint you actually have. If the delay is review, fix review. If the delay is notification, fix notification. More code does not fix either.

How This Works in Shape Up's Six-Week Cycles

Shape Up teams can run the same loop by shaping experiments for the next cycle and keeping the committed project team's time untouched. The framework already has the pieces.

As described in Shape Up, Chapter 8, work runs in six-week cycles followed by a two-week cool-down. Teams do small-batch work (projects of one to two weeks, bundled into a cycle) or big-batch work (one project for the full six weeks). A circuit breaker means projects that don't ship within their bet don't get extended by default. They get reshaped and re-bet.

To fit experiments in:

• Shape a small experiment as a pitch for the next cycle, with its own appetite.
• Release a coherent slice to named customers, not a half-finished internal build.
• Bring customer evidence to the next betting table.
• Use cool-down for review or shaping, or deliberately allocate a small-batch team. Never pull time from the committed project team.

For a fuller primer, see our Shape Up summary and how to run it with AI.

For continuous-delivery teams: keep the release cadence and add an evidence cadence. Deploying daily does not mean you can reach a daily-use conclusion about a weekly workflow.

Spencer Shulem writes that at BuildBetter, this learning is woven into regular improvements to the core product, with feature flags exposing UI and UX variants to selected groups. That is Shulem's account of one team's practice, not a benchmark to copy.

Worked Example: One Two-Week Sprint, Day by Day

This example is illustrative. It is a hypothetical team, not BuildBetter data.

Setup. A B2B SaaS team has 4 engineers and 1 PM. Ten working days gives 40 engineer-days. They reserve 3 engineer-days plus about 4 PM hours for one experiment, and the remaining 37 engineer-days stay on the committed backlog. The split is illustrative, not a recommended ratio.

The signal. Several customers ask for a "reporting dashboard." Calls reveal that ops leads spend Friday afternoon copying ticket data into a weekly status report.

The shaped bet. One auto-generated weekly status report for one recurring decision: the Friday staffing review. No filters, no customization, no scheduling UI. Appetite: 3 engineer-days.

The question and instrument. "Does it fit actual work?" Usability isn't the uncertainty, so the instrument is a working release behind a flag to 5 named accounts, with follow-up calls.

• Day 1 (planning): The PM presents a one-page shaping note. Owners are assigned for the build, for notifying the 5 accounts, and for Friday follow-up calls.
• Days 2–4 (build): On day 3, the engineer finds per-team permissions would add 2 more days. The circuit breaker applies: the team drops permissions and limits the slice to admin users instead of growing the bet.
• Day 5 (first Friday): Code is merged and deployed, but the report isn't exposed yet. The team records that no evidence is possible this week.
• Day 6: The flag turns on for the 5 accounts. The PM emails each admin with what changed and what to try.
• Days 7–9: Committed work continues. The PM schedules three 15-minute calls for the day after the next Friday.
• Day 10 (second Friday, sprint review): 4 of 5 admins open the report, 3 use it in the staffing review, and 2 say they stopped copying data manually. One admin stopped halfway because a team lead without admin rights couldn't see it.

The decision at next planning: invest. The next sprint gets a bounded slice adding read-only access for non-admins, and exposure extends to 10 accounts. Customization stays out of scope.

What carried over: observation of the next two Fridays, one named decision owner, and an explicit kill criterion. If fewer than half of the exposed accounts use the report on the next Friday, stop and revisit the job.

How to Split Discovery and Delivery in One Sprint

Run discovery and delivery in the same sprint by treating the experiment as a bounded backlog item with a fixed appetite, a named owner, and its own definition of done: evidence brought to planning, not code merged.

The two kinds of work are judged differently. Delivery work is judged by technical completion: does it meet the acceptance criteria and pass review? Discovery work is judged by whether it produced a defensible decision. A discovery item can "fail" technically (the slice got cut) and still succeed if it produced a clear decision.

Keep both on the same board. A hidden side track is the first thing cut when the sprint gets tight, because nobody can see what is being lost. Visible items get defended in standup.

Put these on the board for each experiment:

• The shaping note (linked from the item)
• The build ticket, with its appetite
• The notification task, with an owner
• The follow-up calls, with dates
• The decision item for the next planning session

This also gives the sprint goal a cleaner shape. The goal can include "get evidence on whether the auto-report replaces Friday copying" alongside delivery commitments, without either one blurring the other.

How Much Sprint Capacity to Set Aside for Experiments

Set experiment capacity by appetite, meaning how much the answer is worth, not by a fixed percentage of the sprint. Run one small experiment at a time until your review cadence is reliable.

There is no official benchmark for discovery capacity.

Use these rules instead:

• Size it so losing the whole experiment would not threaten the sprint commitment. If the slice fails completely, committed work still ships.
• Budget for notification and review, not only build. Teams usually budget only for code. The PM hours spent emailing accounts and running follow-up calls are part of the experiment.
• Watch the open count. If unresolved experiments pile up, reduce new experiments rather than adding capacity. A backlog of undecided tests means the evidence cadence is the constraint, not build time.

What to Do When the Test Is Inconclusive

When an experiment is inconclusive, first check whether the test was fair, then whether the instrument matched the question, and then make one of three moves.

1. Check fairness. Was the variant actually exposed? Was it announced to the named accounts? Did the job occur during the window? A live variant is not the same as a tested one. If the Friday review was cancelled for a holiday, you have no evidence yet, which is different from negative evidence.

2. Check the instrument. Usage data can't tell you why someone stopped halfway. A conversation can. If the open question is "why," more telemetry won't answer it.

3. Choose one move:

• Extend observation for one more occurrence of the job
• Switch instruments to one that fits the remaining question
• Stop and record what you learned

Do not expand scope to "get a clearer signal." That turns a cheap test into an unshaped project, which is the failure the appetite was meant to prevent.

Give one person ownership of the call, with a deadline set at the next planning session.

Common Mistakes When Testing Ideas Inside a Sprint

Most failed in-sprint experiments trace back to one of eight mistakes.

• Estimating the full feature instead of setting an appetite. The idea looks too big and never starts.
• Mismatching instrument and question. Building a working version for a usability question, or prototyping for a real-work question. The evidence can't support the decision.
• Declaring success at merge. Merged, deployed, exposed, announced, tried, and adopted are different events.
• No named customers. Exposing to "some users" makes follow-up conversations impossible.
• Forgetting to tell requesters. Releases nobody hears about can't be adopted.
• Letting the slice grow mid-sprint instead of applying the circuit breaker.
• Borrowing committed time in Shape Up instead of using cool-down or a small-batch team.
• Too many open experiments with no single decision owner. Evidence piles up and nothing gets decided.

When You Need Tooling (and When You Don't)

For one experiment and a handful of customers per sprint, the manual method works with a doc, a feature flag, and a calendar. Don't buy anything until the manual version is running.

Manual tracking starts to break when you have more than 2–3 open experiments, more than roughly 15–20 customer conversations per sprint, or feedback spread across calls, Slack, and tickets that someone has to re-read before every planning session. At that point, these tools help.

1. BuildBetter — best for keeping the evidence for a bet in one place

BuildBetter unifies call recordings, Slack threads, support tickets and surveys, so the job statement, the follow-up calls, and the post-release feedback for each experiment sit together instead of across five tabs. It also turns conversations into deliverables: PRDs, Jira or Linear tickets, and loop-closure emails, which covers the notify-and-follow-up steps that teams usually drop. Caveat: if your main need is research-repository tagging and highlight reels, specialist research tools have more mature workflows for that.

2. PostHog Session Replay

Watch how named accounts actually move through the released slice, including where they stop. See PostHog's guide to watching recordings.

3. An open-source feature flag tool (Unleash or GrowthBook)

Expose the slice to selected accounts while others keep the existing experience, and turn it off if the test goes wrong.

4. A general LLM assistant with file upload

Upload interview notes and ask for a draft job statement and assumption list. See OpenAI's guide to uploading files. Review the output against the original notes before you shape anything.

FAQ: Testing Product Ideas in Two-Week Sprints

Can you do product discovery inside a two-week sprint?

Yes. Shape one small bet with a fixed appetite, pick the instrument that answers the specific question, and bring the evidence to the next planning session. Observation can run past the sprint boundary when the customer's job hasn't recurred yet.

What is an appetite in Shape Up?

An appetite is the amount of time a problem deserves, decided before designing. The solution is then shaped to fit that budget, instead of estimating the cost of a fully specified design.

Should you prototype or ship a working version?

Prototype when the question is whether people can use the flow. Ship a bounded working version behind a flag when the question is whether it fits their actual work and they come back when the job recurs.

How do you test ideas in a Shape Up cycle without disrupting the team?

Shape the experiment for the next cycle, release a coherent slice, and use cool-down or a deliberately allocated small-batch team. Never use the committed project team's time.

When is an experiment actually done?

An experiment is done when a named person has made a decision based on customer evidence: invest, change the slice, switch instruments, or stop. Merged or deployed code does not mean the experiment is done.

What should you do if the slice turns out bigger than planned?

Stop and reconsider both the test and its budget. The extra work may mean a different, cheaper instrument is worth using.

Sources and Further Reading

• Ryan Singer, Shape Up, Chapter 3 "Set Boundaries": basecamp.com/shapeup/1.2-chapter-03
• Ryan Singer, Shape Up, Chapter 8 "The Betting Table": basecamp.com/shapeup/2.2-chapter-08
• Ryan Singer, Shape Up, Chapter 11 "Get One Piece Done": basecamp.com/shapeup/3.2-chapter-11
• Teresa Torres, Product Talk, getting started with continuous discovery: producttalk.org/getting-started-with-discovery
• Teresa Torres, Product Talk, assumption testing: producttalk.org/assumption-testing
• Wikipedia, Scrum (software development): en.wikipedia.org/wiki/Scrum_(software_development)
• Wikipedia, Feature toggle: en.wikipedia.org/wiki/Feature_toggle

Make Churn Optional

The method above runs on a doc and a calendar. When your experiments outgrow that, BuildBetter keeps every call, ticket, and Slack thread behind each bet in one place, then turns the evidence into PRDs, tickets, and follow-ups for the customers who asked.

Make churn optional. Book a demo.

Get Ship First

This method comes from Ship First: How to Build Self-Improving Products by Spencer Shulem: 24 short chapters on going from a customer request to a working release. Get the free PDF or EPUB, or read it on Kindle.