thoughtbot: Productizing the Pre-build Phase with a Shaping Sprint
Large software projects are difficult to buy when the problem, first release, and expected value are still unclear. A short shaping engagement creates a smaller first purchase with a concrete decision outcome: what to build, for whom, and why — before the full investment is committed.
Client has an idea, not yet a scoped project
The ambition exists but the target user, first problem, and business case are still unresolved.
Buy a short, structured discovery engagement
A fixed-duration sprint frames the problem, explores options, prototypes a direction, and tests with users.
The sprint delivers a decision, not just artifacts
The output answers: what to build, for whom, why it matters, and whether to proceed.
Build commitment follows evidence
The full implementation is purchased only after the sprint validates the direction — or reveals it should change.
Old: broad idea → proposal → full build commitment → discover problems late New: problem framing → focused sprint → prototype/test → decision → build or stop
- Package discovery with a fixed decision outcome, not just a list of deliverables.
- Make the first engagement small enough to buy without a lengthy procurement process.
- Use prototypes and user evidence to resolve the assumptions the build contract cannot.
- Treat 'do not build yet' as a valid and valuable sprint outcome.
View process and full evidence
Nine sections covering context, ICP, positioning, channels, results, replicability, and next steps
Overview
thoughtbot is a product design and software consultancy that publicly offers strategy, design, and development services and publishes case studies describing early product-definition work before implementation. Its service pages emphasize iterative product development, validation, and strategy alongside engineering — not only delivery against a fixed specification. (Source: thoughtbot; thoughtbot Services; thoughtbot Case Studies)
GTM pattern: productized discovery → lower-risk first engagement → stage-gated full build
Core shift: large uncertain commitment → small bounded first purchase with a decision outcome.
Old model → New model:
| Old model | New model |
|---|---|
| Client commits to a full build before key assumptions are resolved. | Client buys a short sprint to resolve assumptions before committing to the build. |
| Uncertainty is priced into the project — by both sides. | Uncertainty is the product of the sprint; reducing it is the deliverable. |
| Discovery happens informally during the sales process or early in the build. | Discovery is a named, scoped, separately purchased engagement with defined outputs. |
| "Stop building" is an expensive and disruptive outcome. | "Do not build yet" is a valid sprint result — and can save more than the sprint costs. |
| The buyer evaluates the consultancy on proposals and past work. | The buyer evaluates the consultancy on the quality of the sprint decision itself. |
The Shaping Sprint productizes the uncertain front end of a larger software project: a client buys a short engagement to clarify the problem, explore options, prototype, test, and decide what is worth building — before committing to the full implementation.
This entry is a third-party market example based on public materials and the supplied case brief. It does not represent implementation work by this site or endorsement by thoughtbot or Merck.
Context
Custom software is hard to scope when stakeholders agree on the broad ambition but have not yet resolved who the first user is, what the most important problem is, or whether the business case holds. A large build contract forces both sides to embed that uncertainty into the project — adding risk, cost, and the possibility of discovering the wrong answer months into delivery.
thoughtbot's public service and case-study materials emphasize product strategy, validation, design, and iterative development rather than only coding to a fixed specification. Its published case studies describe engagements that include early research, user testing, and strategic framing before implementation begins. (Source: thoughtbot Services; thoughtbot Case Studies)
A bounded shaping engagement converts front-end uncertainty into a separate, purchasable deliverable. Rather than embedding discovery costs into a large contract — where they become invisible and often get cut — the sprint makes the investment explicit and the outcome measurable.
This also changes the sales dynamic: a client can say yes to a short sprint without approving the full build budget. The sprint earns the larger engagement by demonstrating the direction, not by promising it upfront.
Ideal customer
The strongest-fit buyer is an organization considering a meaningful digital-product investment but still carrying one or more unresolved questions about what to build. Relevant signals include:
- Internal stakeholders agree on a general goal but disagree on scope, priority, or the first user.
- The project requires a business case or internal approval that has not yet been secured.
- A previous attempt at a similar product did not succeed, and the team has not fully diagnosed why.
- The organization has the budget and intent to build but lacks confidence in the current direction.
- There is time pressure to show progress or direction to a leadership team or external stakeholder.
The value of a productized sprint is highest when the wrong build decision is meaningfully expensive — in money, time, or internal credibility — and a short validation engagement is plausibly cheaper than that risk.
GTM problem
The GTM problem for a consultancy selling large custom projects is that the buyer's risk is front-loaded: they must commit significant budget before seeing any evidence that the direction is right. That friction slows sales cycles, inflates proposals, and sometimes loses deals entirely.
Old problem definition: "We want to build a developer portal, but the scope is unclear and the stakeholders have different priorities. Can you give us a proposal?"
Reframed problem definition: "Before we commit to the build, we need a clearer answer: which user should this serve first, what problem does it solve for them, and does the concept hold up when tested? A sprint can answer that."
The first framing pushes the consultancy into a scoping and pricing conversation. The second creates a smaller, lower-stakes first transaction with a defined output — and positions the consultancy as a partner in the decision, not just a vendor responding to a brief.
Positioning
The productized-service logic changes four things about how the engagement is bought and evaluated:
1. From project to product: The sprint is not an ad hoc scoping session — it is a named, priced engagement with defined inputs, outputs, duration, and decision criteria. Clients know what they are buying before the work starts.
2. From vague to named deliverables: Rather than "discovery consulting," the sprint produces specific outputs: a problem framing, explored alternatives, a prototype tested with users, and a go/no-go recommendation. Each output is addressable and reviewable.
3. From sales promise to evidence: The case for proceeding with a build is no longer the consultancy's pitch — it is the prototype and the user responses. The client buys the evidence, not the promise.
4. From all-or-nothing to stage-gated: The sprint creates a natural checkpoint before the full build commitment. This reduces the buyer's downside: if the sprint reveals that the direction should change, the cost of that discovery is the sprint, not the build.
The real product being sold is not a workshop, a report, or a prototype. It is decision quality under uncertainty. A buyer who frames the purchase that way is in a fundamentally different evaluation mode than one comparing hourly rates or team size.
Channels
thoughtbot uses its website, service descriptions, case studies, and consulting sales process to explain its approach to product strategy and delivery. Published case studies walk through the problem, the engagement structure, and what the work produced — making the sprint's outputs and decision quality visible to prospective buyers before the sales conversation begins. (Source: thoughtbot Services; thoughtbot Case Studies)
For productized consulting, the channel is inseparable from the proof of concept. Case studies are not just marketing — they are product demonstrations. A buyer reading a thoughtbot case study is evaluating whether this kind of engagement produces the decision quality they need.
A simplified adoption path is:
unresolved internal question → see a case study where the sprint answered a similar question → small sprint purchase → sprint produces direction and evidence → full build engagement follows.
The first transaction is designed to be easy to say yes to. The sprint earns the full project — it does not assume it.
Results & evidence
The supplied Merck brief describes an internal developer-portal concept at Merck with an unresolved strategic question: should the first version primarily serve developers who would use the portal, or should it first demonstrate the cost-saving value of code reuse to management stakeholders? The brief states that thoughtbot used a four-day design sprint to understand the problem space, explore alternative directions, converge on a direction, prototype a solution, and test it with users. （Source: Merck Development Portal; Merck Design Sprint Part Deux）
This case is a strong illustration of the productized-discovery value proposition. The sprint's output is not "four days of consulting time." It is a clearer, evidence-backed answer to a question that the organization could not resolve through internal discussion alone: which user should this product serve first, and what should it actually do for them?
The strategic value of answering that question before build commitment — rather than discovering the answer six months into implementation — is plausibly larger than the sprint cost, regardless of the specific figures.
Because the current source set does not include an independently verified quantitative ROI for the Merck engagement, no savings or adoption figures are stated as fact.
Replicability
Replicability · Medium
Applicable when
- The project contains important assumptions that can be tested before committing to a full build.
- The buyer can provide access to representative users and key decision-makers during the sprint.
- A prototype or structured experiment can materially improve the quality of the investment decision.
- The team has the facilitation skill and domain fluency to compress discovery into a short, structured engagement.
Not transferable
- Sprint quality depends heavily on facilitator experience, domain access, and the participation of decision-makers who can actually act on the output.
- thoughtbot's case-study library, brand reputation, and accumulated delivery knowledge are not replicable through packaging alone.
Risks
- A fixed sprint can become superficial if the problem scope is too broad or the right participants are unavailable.
- Clients may treat the sprint prototype as production-ready scope and skip further validation.
- Teams may continue into implementation even when the sprint evidence suggests stopping or redirecting.
Next steps
When packaging a similar offer, define each of the following before the engagement starts:
- The question the sprint is designed to answer — specific enough that the team will know at the end whether it was answered.
- Fixed duration — short enough to create focus, long enough to produce a testable prototype.
- Required participants — who must be present for the output to be actionable, and what happens if they cannot attend.
- Research inputs — what the team needs to bring in before the sprint begins to avoid losing time on basic context-setting.
- Prototype and test output — what will be built, what questions it will test, and with whom.
- Explicit exclusions — what the sprint will not produce, to prevent scope creep.
- Go/no-go decision gate — a clear statement of what the sprint is recommending, and who is authorized to act on it.
Sources
- thoughtbotthoughtbot · 2026-08-17
- thoughtbot Servicesthoughtbot · 2026-08-17
- thoughtbot Case Studiesthoughtbot · 2026-08-17
- Design Sprint Case Study: Merck Development Portalthoughtbot · 2026-08-17
- Merck Design Sprint Part Deuxthoughtbot · 2026-08-17