To decide whether to pivot your early startup, write down the one assumption your plan depends on most, then check what the last few months of evidence say about it. If people want the outcome but your build, onboarding or outreach keeps letting them down, fix execution. If you have done a fair job of execution and the core assumption keeps failing (wrong customer, wrong problem, nobody pays), pivot, and pick the smallest change that tests a new version of that assumption. If you cannot name a believable next assumption, or you cannot afford another test, stopping is often the honest answer. The rest of this guide turns that into a dated check, a list of pivot types and a one-week plan.
Last checked: Nov 9, 2026
This is for founders roughly 3 to 18 months in, before product-market fit, who keep asking themselves the same question at 1 a.m.: keep going, change something, or stop? Sources and examples below were checked on 9 November 2026. Any numbers in the worked examples are made up to show the arithmetic, not benchmarks.
Fix execution, pivot, or stop: read the signals first
Most founders who think they need a pivot actually need a better week. Most founders who need a pivot have been calling it "iteration" for six months. The difference is where the failure sits. Execution problems sit in how you deliver. Pivot problems sit in what you assumed. Use the table as a first pass, then look at your own evidence row by row.
What you are seeing | Usually points to | Why |
|---|---|---|
People say yes on calls but drop off during setup | Fix execution | The want is there; onboarding or time to first value is the leak. |
You have talked to fewer than 20 real prospects | Fix execution | You do not have enough evidence to judge the idea yet. |
A small group uses one feature heavily and ignores the rest | Pivot (zoom-in) | The product inside the product may be the real one. |
The wrong kind of customer keeps showing up and sticking | Pivot (customer segment) | The market is telling you who it is for. |
Target customers agree the problem exists but will not pay or switch | Pivot (customer need) | The problem is real but not painful enough to act on. |
Users like it, but every customer costs more to reach than they are worth | Pivot (channel or engine of growth) | The product may be fine; the way you get it to people is not. |
Several honest tests have failed and you cannot name a new assumption you believe | Stop or pause | Another change would be a guess, not a test. |
Runway left is shorter than one more test cycle | Stop, or cut costs first | You cannot learn anything before the money or energy runs out. |
One warning: low numbers alone do not tell you which row you are in. Ten signups from a launch you barely promoted say little. Ten signups from three months of steady outreach to the exact people you built for say a lot.
Three questions to ask before you call it a pivot
Answer these in writing. Short answers are fine; vague answers are a sign you are not ready to decide.
What is the riskiest assumption in my plan right now? Write it as one sentence you could be wrong about, for example "solo accountants will pay monthly to automate client reminders".
Did I give that assumption a fair test? Fair means the right people saw it, enough of them saw it, and the thing they saw actually worked.
What would I have to see to believe it? If no result could change your mind, you are not testing, you are hoping.
If the honest answer to the second question is "no", go back to execution for a fixed period before you touch strategy. If it is "yes" and the result was bad, keep reading.
Set a dated pivot-or-persevere check with thresholds written in advance
Eric Ries frames this moment in The Lean Startup as a choice to pivot or persevere. The practical trick is to make that choice on a date you set in advance, against numbers you wrote down before you saw the results. Without that, every bad week becomes a crisis and every good day becomes a reason to wait.
Put a short note in your calendar, six to ten weeks out, and fill it in today:
Check date: a real day, for example the first Monday of next quarter.
Assumption under test: the one sentence from above.
Persevere if: the result that means "this is working, keep going". Example: at least 5 of the 30 accountants I demo to start a paid trial.
Pivot if: the result that means "the assumption is wrong". Example: fewer than 2 start a trial, or most say the problem is something else.
Grey zone: what you will do in between. Usually: one more cycle with one named change, then decide.
What I will not count: page views, likes, compliments, "send it to me when it's ready".
The example numbers are only there to show the shape. Pick thresholds that fit your price and market, and write them before you look. Share the note with a co-founder, an advisor or a founder friend so you cannot quietly move the line later.
The ten pivot types from Eric Ries's catalogue
The Lean Startup defines a pivot as "a special kind of change designed to test a new fundamental hypothesis about the product, business model, and engine of growth" (quoted in Product Bookshelf's summary of the book's pivot chapter). The book then lists ten kinds. The names below follow Martin Zwilling's Forbes rundown of Ries's ten pivot types. The plain-English descriptions are ours.
Pivot type | What changes | Ask yourself |
|---|---|---|
Zoom-in | One feature becomes the whole product | Is one part used far more than everything else? |
Zoom-out | The whole product becomes one feature of something bigger | Is my product too thin to stand alone? |
Customer segment | Same product, different buyer | Who is actually sticking, and is it who I planned? |
Customer need | Same buyer, different problem | What do my customers keep asking about instead? |
Platform | Application to platform, or platform to application | Do people want a finished tool or a base to build on? |
Business architecture | High margin and low volume vs low margin and high volume | Am I running a few big deals or many small sales? |
Value capture | How you make money from the value you create | Am I charging for the thing people value most? |
Engine of growth | Viral, sticky or paid growth | Which way of growing fits how people use this? |
Channel | How the product reaches customers | Would a different route reach buyers cheaper or faster? |
Technology | Same solution, different technology underneath | Can I deliver the same result much better or cheaper? |
This post deliberately skips the details of changing how you charge. If your evidence points at a value capture pivot, treat it as a pricing project with its own test.
Pick the smallest pivot that tests your riskiest assumption
A pivot is a new bet, and small bets are cheaper to lose. The aim is to change one thing, keep the rest, and learn fast whether the new assumption holds.
Name what failed. Customer, problem, solution, channel or business model. Pick one.
List two or three pivot types that change only that thing. If the buyer was wrong, look at customer segment first, not a whole new product.
Write the new riskiest assumption as one sentence, the same way you did before.
Choose the cheapest test that could prove it wrong. Ten conversations with the new segment, a landing page aimed at the new need, or a fake door test before building the new feature can all come before any real code.
Check the new direction is big enough to matter. If you are switching segments, a quick bottom-up count of how many buyers you could actually reach saves you from pivoting into a market of forty people.
Set a new dated check with thresholds, exactly like the first one.
If you find yourself changing the customer, the problem and the product at once, that is a restart. Restarts are sometimes right, but call them what they are and budget for them like a new company.
What to keep when you pivot
Customers
The people who used your first version are your best source of evidence for the second. Keep the list, keep talking to them, and ask the heaviest users what they would miss if you shut down tomorrow. Some will follow you. Some will not, and that is fine; you are no longer building for them.
Code and assets
Keep anything that still serves the new direction: auth, billing setup, integrations, the parts users loved. Be ruthless with the rest. Old features you keep "just in case" add support load and muddle your message. Kevin Systrom has said that when Burbn became Instagram, they cut everything except its photo, comment and like features; the point is not the specific features but the willingness to cut.
Insight
The most valuable thing you keep is what you learned: which channels reached people, which words they used for their problem, which objections came up every time. Write a one-page "what we know now" before you start the new version, and reread it before every big decision.
Three well-known pivots, briefly
These are famous because they worked. Plenty of pivots do not, so treat them as illustrations of the pattern, not proof that pivoting pays off.
Instagram from Burbn. Mike Krieger, writing in Wired's "Why Instagram Worked", describes Burbn as a location-based social app that people liked but that was not taking off. The founders took the photo updates from Burbn and made them their own product. That is a zoom-in pivot.
Slack from Glitch. MIT Technology Review's interview with Slack's CEO reports that Slack grew out of a chat tool the Tiny Speck team built for itself while making the online game Glitch. After the game was shut down, the company switched its focus to that tool.
Flickr from Game Neverending. TechCrunch's Slack origin story notes that Flickr, too, began as an attempt at a game, Game Neverending, before a big pivot.
The common thread is that each team kept something real that people were already using, and dropped the rest.
How to tell existing users, investors and your waitlist
Tell people early, tell them plainly, and tell them what changes for them. Instagram's founders sent an email to 100 of their Burbn testers when they had the first version ready, according to Krieger's Wired piece, and asked them to try it as something "inspired by" Burbn. That is a good model: honest about the change, specific about what stays.
Here is a weak and a better version of a short email to existing users, for a made-up product.
Weak:
Subject: Exciting news!
We're thrilled to announce a bold new chapter. We've been on an incredible journey and we're evolving to better serve you. Stay tuned for more!
Better:
Subject: We're changing what we build, here's what it means for you
Hi Sam, over the last four months most of you used one thing in our app: the client reminder emails. Almost nobody used the invoicing part. So from 1 December we are focusing only on reminders. Your account and data stay as they are. Invoicing will keep working until 31 January, and you can export it any time from Settings. If reminders are not useful to you, reply and I will help you move your data or close your account. If they are, I would love 15 minutes to hear what is missing. Thanks for using an early version. Priya
For investors, send a short note before the public change, not after: what you tested, what the numbers said against your pre-written thresholds, the new assumption, the next dated check and how much runway it uses. For a waitlist that signed up for the old idea, send one honest email explaining the change with a clear way to leave. A smaller list of people who want the new thing beats a big list of people who wanted the old one.
If you are relaunching after a pivot, rewrite your one-line pitch before you announce anything. The old line will describe the old product, and people only read the first sentence. The first sentence of every announcement, profile and launch page now has to explain the new direction on its own. For examples of the style, Hed Press publishes short product stories built around a sharp opening line (it is run by the same team as EarlyHunt).
Runway math: how many pivots can you afford?
Zwilling's Forbes summary of Ries puts it simply: a startup's runway is really the number of pivots it can still make, not the money in the bank. To turn that into a number, you need three inputs: money left, monthly burn and how long one test cycle takes.
Hypothetical example (all numbers made up): a solo founder has $36,000 in savings set aside for the company and spends $3,000 a month on living costs and tools. That is 12 months of runway. They keep 3 months back as a buffer to wind down or find a job, which leaves 9 months to spend on learning. One full pivot cycle, from choosing a new assumption to reaching the dated check, takes them about 3 months (6 weeks to build a test, 6 weeks to measure). So they can afford about 3 pivots.
If they cut the cycle to 6 weeks by testing with conversations and landing pages before building, the same 9 months covers about 6 tests. The money did not change. Speed of learning doubled the number of bets. That is the main lever most early founders control.
If you have raised money, Paul Graham's essay "Default Alive or Default Dead?" is worth reading alongside this. He suggests asking whether, with current expenses and recent growth, you reach profitability on the money you have left, and writing down a plan B in case you cannot raise again.
A one-week pivot plan
Once the dated check says pivot, do not spend a month debating. Use one week to choose and set up the next test.
Day 1: Write the "what we know now" page. List what failed, what worked and the exact words customers used.
Day 2: Pick the pivot type that changes only what failed. Write the new riskiest assumption in one sentence.
Day 3: Talk to five of your most active users, or five people from the new segment. Ask about the problem, not your idea.
Day 4: Design the cheapest test that could prove the new assumption wrong. Decide what you will not build yet.
Day 5: Write the new one-line pitch and a simple page or message for the test.
Day 6: Send the update email to users, the note to investors and the waitlist email.
Day 7: Put the next dated check in the calendar with persevere and pivot thresholds, then start the test.
When stopping is the honest answer
Stopping is a decision, not a failure of nerve. It is usually right when several of these are true:
You have run two or three fair tests, each with written thresholds, and each one missed clearly.
You cannot name a new assumption you actually believe; every option feels like a guess.
Your runway is shorter than one more test cycle and you are not willing to cut costs or take on outside work.
You dread working on it, and the dread did not lift after a real break.
Your co-founder has already left in spirit, or in fact.
If you stop, stop well. Give users notice and a way to export their data, refund anything prepaid, tell investors directly and early, and keep the domain and your notes. When Glitch closed, TechCrunch reports that Stewart Butterfield told investors he would return the money left, unless they wanted to back the team's next idea. You will not always have money left, but you can always be straight with people about what happened.
If this is a nights-and-weekends project rather than a full-time startup, SideHunt's guide on deciding whether to kill, pause or double down on a side project covers the "pause" option in more detail.
FAQ
How long should I try before deciding to pivot?
There is no fixed number of months. What matters is whether you gave your riskiest assumption a fair test. Set a dated check six to ten weeks out with thresholds written in advance, and decide on that date.
Is a pivot the same as iterating?
No. Iterating improves how you deliver the same bet: better onboarding, clearer copy, a faster feature. A pivot changes the bet itself: a different customer, problem, channel or business model.
How many times can a startup pivot?
As many as your runway and energy allow. Work out how long one test cycle takes and divide your usable runway by it. Shorter cycles mean more chances.
Should I keep my company name after a pivot?
Usually yes, unless the name now describes the old product so precisely that it confuses new customers. A rename costs time and attention you may need for the new test.
What if my investors disagree with the pivot?
Show them the evidence against your pre-written thresholds, the new assumption and the next dated check. Disagreement is easier to work through when the decision rests on numbers you agreed to before you saw the results.