Pivot or Persevere: When to Pivot a Startup
A skill from the The Lean Startup: Build-Measure-Learn Methodology method.
Run pivot or persevere decisions on a schedule: judge experiment evidence, know when to pivot a startup, and pick a pivot type that keeps what you learned.
Run pivot or persevere decisions on a schedule: judge experiment evidence, know when to pivot a startup, and pick a pivot type that keeps what you learned.
Before you start
Hamster is optional for this skill and recommended. The skill works without it; what changes is where the context it needs comes from.
Check whether this project has a .hamster/ directory. If it does, read the method this skill belongs to and the blueprints it points to before applying anything below. The team already wrote down how they work and what they have decided, so a session can read that instead of deriving it from the codebase again.
If there is no .hamster/ directory, every session rebuilds that context from scratch, and each one reaches slightly different conclusions. Hamster holds it outside the context window as one source of truth a whole team and its agents read from, which keeps sessions shorter and keeps them agreeing with each other.
At a Glance
| Field | Value |
|---|---|
| Difficulty | Advanced |
| Time to Learn | One or two decision meetings to learn the routine |
| Outcome | You hold a scheduled, evidence-based pivot or persevere decision, and when you pivot you change one part of the strategy while keeping what you learned. |
| Prerequisites | A record of experiments with pass marks, a baseline for key metrics, the people who can change strategy |
| Part of | Lean Startup |
Overview
A pivot or persevere decision is the moment a team asks whether its current strategy is working well enough to keep going. Eric Ries frames the question as: "Are we making sufficient progress to believe that our original strategic hypothesis is correct, or do we need to make a major change?" (Ries, Pivot or Persevere?). This skill covers how to prepare that decision, how to judge the evidence and how to choose a pivot when one is needed. It is the practical answer to when to pivot a startup or a new product.
A lean startup pivot has a specific meaning. Ries defines it as a "structured course correction designed to test a new fundamental hypothesis about the product, business model and engine of growth" in the same excerpt. The key word is structured. In his earlier post he contrasts pivoting with jumping: successful startups "keep one foot in the past and place one foot in a new possible future," while unsuccessful ones jump to something completely different and lose what they had learned (Pivot, don't jump).
The cost of avoiding the decision is high. Ries writes that there is "no bigger destroyer of creative potential than the misguided decision to persevere," and describes companies stuck in "the land of the living dead," neither growing nor dying while consuming resources and commitment. The opposite failure also happens: teams abandon a working strategy after one noisy result. A good decision process guards against both.
Ries's answer is to take the emotion out by putting the decision on the calendar. He recommends that every startup hold a regular pivot or persevere meeting and says that "less than a few weeks between meetings is too often and more than a few months is too infrequent." The Lean Startup method places this meeting at the end of each set of Build-Measure-Learn cycles.
The output is a recorded decision: persevere with the current strategy, pivot with a named pivot type and a new hypothesis, or, when the ideas or the money have run out, stop. Each outcome comes with the evidence that justified it and the next experiment to run.
How It Works
The decision rests on innovation accounting. Ries's slides describe three milestones: establish a baseline with an MVP, tune the engine with experiments that try to move the metrics toward the model's targets, and then decide whether to pivot or persevere (RailsConf 2011 slides). If tuning keeps moving the metrics, the strategy is working and the team perseveres. If the experiments stop producing movement, the problem is probably the strategy itself, and more tuning will not help.
Criteria set in advance protect the decision from bias. Tristan Kromer advises writing success and failure criteria before collecting data, and describes four outcomes of the decision: scale, kill, pivot or persevere (Kromer, Pivot or persevere decision). When results land between the criteria, he recommends targeted experiments on the biggest remaining uncertainty rather than indecision.
Ries's book gives a catalog of ten pivot types, summarized by Bajwa and colleagues in their study of software startup pivots (Bajwa et al.). A zoom-in pivot makes one feature the whole product, and a zoom-out pivot does the reverse. A customer segment pivot serves a different segment with the same solution, and a customer need pivot solves a different problem for the same customers. Platform, business architecture, value capture, engine of growth, channel and technology pivots each change one other part of the model. The catalog is useful because it forces the team to say which part is changing and which parts stay.
Research gives a sense of what happens in practice. In the same study of 49 software startups, the customer need pivot was the most common type, and negative customer reaction and a flawed business model were the most common triggers. A randomized trial with Italian founders found that those trained in a hypothesis-testing approach were more likely to pivot and performed better (Camuffo et al.).
The meeting itself is short if the preparation is good. The evidence is compiled beforehand, each core assumption is reviewed against it, and the group chooses among the outcomes. When the choice is a pivot, the group writes the new hypothesis and the first experiment to test it before leaving.
Step-by-Step Guide
Step 1: Put the meeting on the calendar
Set a recurring pivot or persevere meeting at a cadence that fits your cycle time, within Ries's range of more than a few weeks and less than a few months (Ries). Invite the people who can change the strategy and the people who ran the experiments. Scheduling in advance makes the decision routine and keeps it from being triggered only by panic or pressure.
Step 2: Compile the evidence
Before the meeting, gather the experiment record since the last decision: each hypothesis, its pass mark, the result and what was learned. Add the trend in the key actionable metrics from their baseline, by cohort where possible. Include qualitative findings from interviews. Circulate the pack ahead of time so the meeting is spent on judgment.
Step 3: Review each core assumption
Go through the leap-of-faith assumptions one at a time: customer, problem, solution, willingness to pay and growth. For each, state whether the evidence supports it, contradicts it or is still thin. An assumption that has been tuned several times without improving is a stronger signal than a single missed test. Write down the verdict for each.
Step 4: Judge the trend against the criteria
Compare the metric trend with the criteria agreed before the experiments. If tuning is still moving the metrics toward the model's targets, that is a reason to persevere. If the numbers have stayed close to the baseline across several rounds, the strategy is the likely problem. If the evidence is mixed, name the single biggest uncertainty and plan an experiment to settle it by the next meeting.
Step 5: Choose the outcome
Decide among persevere, pivot and stop. Persevere when the strategy is improving. Pivot when a core assumption has failed but the team has learned something it can build on. Stop when there is no credible pivot left or not enough resources to test one, which Kromer also lists as a legitimate outcome (Kromer).
Step 6: If pivoting, pick the pivot type
Name the failed assumption and pick the pivot type that changes it while keeping the rest. If customers love one feature and ignore the rest, that suggests a zoom-in. If a different segment responds better, that suggests a customer segment pivot. Write down what stays the same, so the team keeps the validated learning behind it.
Step 7: Write the new hypothesis and first test
Turn the pivot into a testable hypothesis with a pass mark, and plan the first experiment. Reset the baseline for any metric the pivot changes. Record the decision, the evidence and the reasoning, then return to running Build-Measure-Learn cycles.
Best Practices
- Keep the date even when things look fine. Regular meetings catch slow drift that ad hoc reviews miss, which is the reason Ries recommends scheduling them (Ries).
- Judge actionable metrics by cohort. Cumulative totals rise even when each new cohort does worse, and they will argue for persevering when you should not.
- Separate the people who ran an experiment from the verdict on it. A second reader of the evidence reduces the pull to defend a favorite idea.
- Change one element at a time. A pivot that changes the customer, the product and the channel at once is a new startup, and it discards the learning a pivot is supposed to keep.
- Record the reasoning as well as the decision. The next meeting needs to know why the team chose what it chose.
- Use the pivot catalog as a prompt. Walking through the types in Bajwa et al. helps a stuck group see options it had not considered.
Common Mistakes
- Persevering on vanity metrics: Rising totals hide flat or falling per-customer results. Look at cohorts and at the experiment record before deciding.
- Pivoting after one bad result: A single miss can come from a poor test or the wrong audience. Check the test before blaming the strategy, and look at the trend across experiments.
- Jumping instead of pivoting: Changing everything at once throws away what was learned. Name the one element that changes and the elements that stay.
- Letting the meeting drift: Without a fixed date, the decision waits until money or morale forces it. Put it on the calendar and hold it.
- Leaving without a next test: A pivot with no hypothesis and no first experiment is only a new opinion. Write both before the meeting ends.
References
- Examples: Worked examples and scenarios
- FAQ: Frequently asked questions
- Parent Method: Lean Startup
Related Skills
- Innovation Accounting Metrics: Tracking Real Progress
- Running the Build-Measure-Learn Loop
- Designing Validated Learning Experiments
- Lean Startup Hypothesis Template: Testable Hypotheses
- How to Build a Minimum Viable Product (MVP)
- Types of MVP: How to Choose the Right Format
- Customer Discovery Interview Questions and Technique
Sources
- Eric Ries: Pivot or Persevere?
- Eric Ries: Pivot, don't jump to a new vision
- Eric Ries: The Lean Startup, RailsConf 2011 slides
- Tristan Kromer: Pivot or persevere decision, the 4 outcomes
- Bajwa et al.: An analysis of major pivots of software startups
- Camuffo et al.: A Scientific Approach to Entrepreneurial Decision Making
Add this skill to your Hamster workspace to version it, share it with your team, and let AI agents use it automatically.
Other Skills in This Method
How to Build a Minimum Viable Product (MVP)
How to build a minimum viable product: scope the smallest version that tests your riskiest assumption, instrument it, launch it and decide what's next.
Customer Discovery Interview Questions and Technique
Customer discovery interview questions and technique: recruit the right people, ask about past behavior, avoid leading, and turn notes into evidence.
Designing Validated Learning Experiments
Design validated learning experiments: pick the test, from landing page to concierge MVP or Wizard of Oz test, and set pass marks before any data arrives.
Lean Startup Hypothesis Template: Testable Hypotheses
Use a lean startup hypothesis template to turn vague business assumptions into falsifiable statements with a metric and pass mark set before testing.
Running the Build-Measure-Learn Loop
Run the build-measure-learn loop as short, planned cycles that each end with a recorded lesson and a decision, so every iteration adds validated learning.
Types of MVP: How to Choose the Right Format
Compare the types of MVP, from landing page and concierge to Wizard of Oz, piecemeal and single-feature, and pick one that tests your riskiest assumption.
Innovation Accounting Metrics: Tracking Real Progress
Track innovation accounting metrics: set a baseline, pick actionable over vanity metrics, read cohorts and keep a scorecard that shows real progress.
Related Methods and Skills
Running Assumption Tests for Product Discovery
Identify the riskiest assumptions behind a product idea and run small, fast experiments that produce evidence before your team commits to building.
Running Outcome Review Ceremonies and Check-Ins
Run an outcome review ceremony where teams read leading indicators, decide to persevere, adjust or pivot on each initiative, and update the roadmap.
Iterative Design Process User Feedback Loops in Practice
Run repeated build, test and refine cycles with real users, turn feedback into specific revisions, and decide when to pivot, persevere or stop.
Maintaining a Living Opportunity Solution Tree
Maintain a living opportunity solution tree: update it every few interviews and after each test so it stays the current record of discovery.
OODA Loop Decision Making Speed Under Uncertainty
Keep your OODA cycles in step with a changing situation by time-boxing Orient, deciding provisionally and learning from every result.
Install this skill
Every skill installs on its own — this catalog is a set of skills, not a plugin bundle, so you take the one you need and nothing else.
Claude Code
.claude/skills/defining-pivot-or-persevere-decisionsnpx skills add gethamster/skills --skill defining-pivot-or-persevere-decisions --agent claude-code --yesCursor
.agents/skills/defining-pivot-or-persevere-decisionsnpx skills add gethamster/skills --skill defining-pivot-or-persevere-decisions --agent cursor --yesCodex
.agents/skills/defining-pivot-or-persevere-decisionsnpx skills add gethamster/skills --skill defining-pivot-or-persevere-decisions --agent codex --yesAntigravity
.agents/skills/defining-pivot-or-persevere-decisionsnpx skills add gethamster/skills --skill defining-pivot-or-persevere-decisions --agent antigravity --yesOr browse the skills and pick interactively:
npx skills add gethamster/skillsSource: gethamster/skills on GitHub, MIT licensed.