Ship First vs Shape Up vs Lean Startup: Pick a Method (2027)

A product method is a repeatable loop that decides four things: what to work on, how big the work is, how customers shape it, and how you learn whether it worked. A method that skips any of the four leaves a gap, and teams fill that gap with opinion. This guide compares six methods in this order: Ship First (Spencer Shulem, cofounder and CEO of BuildBetter), Continuous Discovery Habits (Teresa Torres), Shape Up (Ryan Singer, Basecamp), The Lean Startup (Eric Ries), Customer Development (Steve Blank), and empowered product teams (Marty Cagan, SVPG). It is written for product managers, heads of product, founders, and CS leads at B2B software companies who keep getting conflicting advice from these books. You'll get a side-by-side comparison, a 60-minute decision session you can run this week, a hybrid that combines the methods, and a worked example of a 12-person team's first month.

What a Product Method Is (and the Short Answer)

These six methods answer different questions, which is why they seem to conflict. Most arguments about which one is "right" disappear once you see which question each was built to answer:

• Customer Development and The Lean Startup ask: Should this business or product exist?
• Continuous Discovery and Cagan's empowered teams ask: Which problems should we solve?
• Shape Up asks: How do we scope and deliver work predictably?
• Ship First asks: How do we turn customer requests into working releases that improve themselves?

The rule of thumb: pick by your biggest uncertainty, not by what a well-known company uses. Basecamp designed Shape Up for a small, profitable, mature product company with senior people who could shape work. Lean Startup was distilled from IMVU's search for product-market fit. Copy either one into a different situation and you inherit assumptions that don't hold.

One term needs defining before going further. A self-improving product, in the Ship First sense, is one where each release generates the evidence that decides the next release: whether customers completed the job, whether they came back, and what they asked for next. It does not mean autonomous or AI-driven change, and it has nothing to do with ML personalization. It describes a loop that people run on purpose.

If you came here for Shape Up vs Scrum: Shape Up replaces sprint-and-backlog delivery with six-week bets and no backlog. The FAQ below covers the full comparison.

Why Choosing a Method Is Hard: What Actually Breaks

Conflicting advice is the symptom; the cause is that each book was written for a specific stage and team shape and then read as universal. When teams struggle with a method, the failure usually looks like one of these six patterns:

1. Category error. A Series B team runs Lean Startup MVPs on an existing product and ships half-built features to paying customers who expected finished ones. "Minimum" meant something different when there were no customers to disappoint.
2. Discovery theater. The team adopts weekly interviews, fills a folder with notes, and none of it reaches a cycle, a ticket, or a release decision.
3. Delivery without evidence. Shape Up cycles run smoothly, but the pitches at the betting table rest on the loudest stakeholder rather than on what customers said or did.
4. Lost context. By the time work reaches engineering, the original request, the customer's workaround, and the person who raised it have been stripped away. The team builds the literal ask instead of the job behind it.
5. Shipping and forgetting. Nobody checks whether customers completed the job, came back, or benefited from the next iteration. This matters because most ideas don't work: at Microsoft, Ron Kohavi and colleagues found that only about one-third of tested ideas improved the metrics they targeted, with lower rates on mature products like Bing (Online Controlled Experiments at Large Scale, KDD 2013). Without follow-through, you can't tell which third you shipped.
6. Wholesale adoption. The team switches everything at once, loses a quarter to process churn, and abandons the method before it pays off.

Every method below prevents some of these failures and invites others. The comparison is most useful when you read the "where it breaks" line as carefully as the core loop.

The Six Methods Compared, One by One

Each method below is described with the same six fields (origin, core loop, unit of work, cadence, customer involvement, and where it breaks) so you can compare them directly.

Ship First (Spencer Shulem, BuildBetter)

• Origin: Written by BuildBetter's cofounder and CEO, Spencer Shulem, who started his first software company at thirteen and has nearly twenty years in product and user research. It's a free, short companion to his book Customer-Led Development.
• Core loop: A customer asks for something, you build a small working answer, they try it in their own workflow, and what happens next tells you what to improve.
• Unit of work: A small working answer tied to three things: the real customer request, that customer's current workaround, and the person who raised it. Keeping that context attached is what separates the method from "ship fast and hope."
• Cadence: Continuous and release-driven.
• Customers: They are both the trigger and the test, because evidence comes from use inside their own workflow. Experiments are chosen to fit the question: a conversation, a grounded persona, a survey, a prototype, or a working release.
• Where it breaks: Before any customers are asking (pre-product), in regulated contexts where shipping small working answers is constrained, and on teams that can't actually ship small increments.

Continuous Discovery Habits (Teresa Torres, 2021)

• Origin: Torres defines continuous discovery as "at a minimum, weekly touchpoints with customers by the team building the product, where they conduct small research activities in pursuit of a desired product outcome." She was writing about the opportunity solution tree around 2016, before the book.
• Core loop: The product trio (PM, designer, tech lead) maps a desired outcome to opportunities (needs, pain points, desires), then to solutions, then to assumption tests, all on an opportunity solution tree. Torres recommends comparing several solutions per opportunity (often three) and testing assumptions rather than whole ideas.
• Unit of work: An opportunity plus the assumption tests that de-risk it. Assumption types: desirability, viability, feasibility, usability, and ethical.
• Cadence: Weekly.
• Customers: Story-based interviews ("Tell me about the last time you…") captured in one-page interview snapshots. Torres stresses that what customers say they'll do and what they actually do often differ.
• Where it breaks: No recruiting pipeline, trios without decision authority, and trees that keep growing but never feed delivery.

Shape Up (Ryan Singer, Basecamp, 2019)

• Origin: Basecamp's internal process, built on 37signals' philosophy from Getting Real (2006) and Rework (2010).
• Core loop: Shape work at the right level of abstraction using breadboards and fat-marker sketches ("wireframes are too concrete, words are too abstract"), set an appetite instead of an estimate, bet at the betting table, build in a six-week cycle, then take a two-week cool-down.
• Unit of work: A shaped pitch.
• Cadence: Six weeks plus two.
• Customers: Implicit in shaping; there's no prescribed discovery ritual. Progress is tracked with hill charts, there is no backlog, and small teams carry full responsibility.
• Where it breaks: No senior shaper, urgent customer commitments that don't fit a cycle, and shaping inputs that aren't grounded in evidence.

The Lean Startup (Eric Ries, 2011)

• Core loop: The build-measure-learn loop: ship a minimum viable product, measure, reach validated learning, then decide to pivot or persevere. Progress is judged through innovation accounting.
• Unit of work: A hypothesis plus an MVP.
• Cadence: As fast as you can run experiments.
• Customers: Subjects of experiments and the source of metrics.
• Where it breaks: On mature products where "minimum" damages trust, and when vanity metrics (signups, page views) stand in for actionable metrics and validated learning.

Customer Development (Steve Blank)

• Origin: The Four Steps to the Epiphany (2005) and The Startup Owner's Manual (2012, with Bob Dorf). It underpins the NSF I-Corps program, where teams are expected to run roughly 100+ customer discovery interviews over about seven weeks.
• Core loop: Customer discovery, customer validation, customer creation, company building. "Get out of the building."
• Unit of work: Hypotheses about customers, problem, channel, and business model.
• Cadence: Stage-gated.
• Customers: Direct conversations that test business hypotheses.
• Where it breaks: After product-market fit. It is a search process, not a delivery process.

Empowered Product Teams (Marty Cagan, SVPG)

• Origin: Inspired (2008; 2nd ed. 2017), Empowered (2020, with Chris Jones), Loved (2020, Martina Lauchengco with Cagan), Transformed (2024). Cagan argues that at least half of product ideas won't work, a practitioner claim consistent with Kohavi's experiment data.
• Core loop: Discovery addresses four risks (value, usability, feasibility, business viability) with prototypes. Teams are given problems to solve, not feature lists.
• Unit of work: A problem or outcome assigned to a team.
• Cadence: Not prescribed. Often paired with dual-track agile.
• Customers: Tested through discovery prototypes.
• Where it breaks: It's a product operating model, not a set of rituals, so it fails without leadership change. Teams often stall waiting to be "empowered."

Summary Comparison Table

How to Choose: A 5-Step Decision Method You Can Run Today

You can pick a method in a 60-minute session with a whiteboard and no tools. Bring the PM, a designer or tech lead, a CS lead, and whoever makes final roadmap calls.

1. Name your biggest uncertainty. Pick one: Should this business exist? Which problem matters most? Will this solution work for users? Can we deliver it predictably? Did what we shipped actually help?
2. Place your stage: pre-product, searching for fit, post-fit and growing, or mature/multi-product. CB Insights found "no market need" in 35% of startup post-mortems (2021, self-reported), which is why the search-stage methods exist.
3. Count your team and decision-makers. Does a product trio exist? Is anyone senior enough to shape work?
4. Audit your evidence flow. How many customer conversations happen per week? Where do requests live: calls, tickets, Slack? Does the original request survive until build?
5. Pick one primary method and borrow at most one practice from another. Set a 6-8 week trial with explicit success checks written down before you start.

Tiebreaker: if two methods fit, choose the one that shortens the time between a customer request and evidence from real use.

Combining Methods: A Hybrid That Works

The methods combine well because each one sits on a different layer of product work. Strategy and search belong to Blank and Ries. Product discovery belongs to Torres and Cagan. Product delivery and scope belong to Shape Up. Release and learning belong to Ship First.

A working stack for a post-fit B2B team looks like this:

• Torres's weekly story-based interviews feed the opportunity solution tree.
• The strongest opportunities become Shape Up pitches, each with an appetite.
• Each cycle ships small working answers following Ship First's release loop.
• Release follow-through (job completion, return use, benefit from the next iteration) becomes input to the next betting table.
• Cagan's four risks (value, usability, feasibility, viability) act as a checklist on every pitch.

Hand-offs are where hybrids fail, so set rules for them:

• Every pitch links back to specific customer requests and the people who raised them.
• Every release has a named follow-up check with an owner and a date.
• Cool-down weeks include a review of release evidence before the next betting table.

Two conflicts need explicit handling. First, Shape Up's "no backlog" vs. a growing opportunity tree. Torres describes the tree as a thinking tool, not a roadmap, and says pruning matters as much as growing. Keep the tree, but never treat it as a commitment queue. Second, Lean Startup's "minimum" vs. B2B customer expectations. Ship small, but ship working. A paying customer will forgive a narrow feature; they won't forgive a broken one.

Worked Example: A 12-Person B2B Team's First Month on a Hybrid

This is an illustrative scenario, not a case study. It shows the decisions and trade-offs, not results.

Setup: A post-fit B2B workflow SaaS with 1 PM, 1 designer, 7 engineers, 1 CS lead, 1 founder/CEO, and 1 sales lead. Two pains: roadmap whiplash from sales requests, and shipped features that nobody checks on.

Diagnosis (the 5 steps): The biggest uncertainty is "which requests matter, and did our releases help?" The stage is post-fit. A trio exists (PM, designer, tech lead). Evidence flow: about 15 customer calls a week across sales and CS, plus tickets and Slack threads, with no shared record.

Decision: Ship First's release loop as the primary method, Torres's weekly interviews as the discovery input, and a Shape Up-style cycle shortened for the trial.

Week 1: Collect and map

The PM pulls the last 30 days of requests into one spreadsheet with four columns: request, workaround, customer, and who raised it. The trio groups them into five or six opportunities on a simple opportunity solution tree and schedules three story-based interviews. Trade-off: the spreadsheet takes most of a day, time the PM would normally spend on specs.

Week 2: Shape and bet

The trio shapes two pitches with appetites: one big bet and one small batch. The founder, PM, and CS lead hold a betting table. They kill one sales-driven request because no customer conversation or ticket supports it. The sales lead objects; the agreement is that the request returns if evidence appears.

Weeks 3-4: Build and release

Engineers build small working answers. The first goes to the four customers who requested it, inside their own workflow. Before release, the team writes down three follow-through checks: Did they complete the job? Did they return within two weeks? What did they ask for next?

End of month: Review

The team reviews what happened against those checks and decides whether to iterate, expand, or drop each release. They note what to change before the first full six-week cycle, such as handing interview recruiting to the CS lead, who already talks to customers daily.

Common Mistakes When Adopting a Product Method

Most method failures come from adoption choices, not from the method itself. Watch for these:

• Copying a company instead of matching your uncertainty and stage.
• Interviews with no route into a cycle or ticket, so evidence dies in notes.
• Treating appetite as an estimate. Singer is clear that appetite comes first and the solution is shaped to fit it. Using it as a forecast lets scope creep back in.
• Calling a broken release an MVP when you have existing B2B customers.
• Stripping customer context (the request, the workaround, the requester) from tickets.
• Measuring shipping instead of outcomes, with no follow-through on job completion or return use.
• Waiting for permission to be "empowered" instead of starting with one weekly customer habit that the trio owns together. Torres warns that splitting discovery to a researcher and delivery to engineers recreates the hand-off problem.
• Changing everything at once instead of running a time-boxed trial with explicit checks.

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

Spreadsheets and a whiteboard are enough while one person can read every request. A rough threshold: past about 200 pieces of feedback a month, or more than about 10 customer calls a week spread across sales, CS, and product, manual tagging falls behind and request context gets lost. Other signs you've outgrown manual work: interview snapshots get written days late, betting-table pitches can't cite sources, and nobody can tell which customers to notify when a release ships.

1. BuildBetter — Best for keeping the original request attached from call to release

BuildBetter captures calls, Slack threads, support tickets, and survey feedback as evidence in one place through 100+ integrations, including Zoom, Slack, Jira, Zendesk, HubSpot, and Intercom. It turns that evidence into PRDs, Jira or Linear tickets, and loop-closure emails, so the request, workaround, and requester travel with the work and the right customers hear back when you ship. Honest caveat: teams that need a dedicated research-repository workflow with detailed tagging and highlight reels, or enterprise survey distribution at scale, may want a specialist tool alongside it.

2. Vistaly

Built specifically for maintaining opportunity solution trees across multiple teams.

3. Looppanel or Aurelius

Lighter-weight interview analysis and research note-taking for small research functions.

The rule: tooling should shorten the request-to-evidence loop, not add a new ritual.

FAQ

Shape Up vs Scrum: what's the difference?

Scrum runs short, fixed-length sprints (one month or less, usually two weeks) pulled from a continuously refined product backlog, with defined roles (Product Owner, Scrum Master, Developers) and events. Shape Up runs six-week cycles followed by a two-week cool-down. Senior people shape work into pitches, leadership bets on pitches at a betting table, teams get fixed time with variable scope (appetite), and there is no central backlog. Scrum optimizes a steady flow of backlog items. Shape Up optimizes for finishing meaningful, well-scoped projects with fewer interruptions.

Can a team switch from Scrum to Shape Up gradually?

Yes. Keep your sprint mechanics but introduce appetite and shaped pitches for one project, then run one full six-week cycle with a cool-down as a trial. The biggest adjustment is letting go of the backlog and task-level estimates, so plan that conversation with stakeholders before the trial starts.

Continuous Discovery vs Lean Startup: which should I use?

Lean Startup tests whether a product or business should exist, using build-measure-learn, MVPs, and pivot-or-persevere decisions. Continuous Discovery helps an existing product team decide which opportunities to pursue toward a desired outcome, using weekly customer touchpoints and an opportunity solution tree. Use Lean Startup while searching for product-market fit and Continuous Discovery once you have a product and customers. Many teams keep Lean-style experiments as one tool inside Continuous Discovery's assumption tests.

Can you combine Shape Up and Continuous Discovery?

Yes. Continuous Discovery supplies evidence-backed opportunities and tested assumptions. Shaping turns the strongest opportunity into a bounded pitch with an appetite, and the betting table decides. Keep the opportunity solution tree as a living map, not a commitment queue, to respect Shape Up's no-backlog principle.

What is the Ship First method?

Ship First is a customer-led loop from Spencer Shulem's free book Ship First: How to Build Self-Improving Products, a short companion to Customer-Led Development. A customer asks for something, you build a small working answer, they try it in their own workflow, and what happens next tells you what to improve. Its three themes are starting with the customer's job, choosing the right experiment, and following the release through.

Which method is best for an early-stage startup?

Before you have a product, use Customer Development and Lean Startup to test whether the business should exist. Once customers are actively asking for things, add Ship First's release loop.

How long should we trial a new method?

One full cycle, about 6-8 weeks, with success checks defined before you start.

Sources and Further Reading

• Ship First: How to Build Self-Improving Products, Spencer Shulem (free)
• Customer-Led Development, Spencer Shulem (Kindle)
• Shape Up, Ryan Singer (free online)
• Teresa Torres, Product Talk
• Lean startup (Wikipedia)
• Customer development (Wikipedia)
• Silicon Valley Product Group (Marty Cagan)
• The Scrum Guide
• Kohavi et al., "Online Controlled Experiments at Large Scale," KDD 2013; Kohavi, Tang & Xu, Trustworthy Online Controlled Experiments (Cambridge University Press, 2020)
• CB Insights, "The Top 12 Reasons Startups Fail" (2021)

Get Ship First Free

Ship First is a free book by Spencer Shulem with 24 chapters and 6 illustrations, available in PDF and EPUB. It covers the case for a working answer, building with better evidence, and making the next release better, as a short companion to Customer-Led Development. Get your copy here.

Make churn optional.

BuildBetter keeps every customer request, its workaround, and the person who raised it attached to the work, from the first call to the release email that tells them you shipped it. That is the Ship First loop, running on your real calls, tickets, and Slack threads. Make churn optional. Book a demo.