When to Pivot vs. When to Keep Going

The worst time to make a pivot decision is when you're exhausted, broke, and the traction isn't there. Which is also when you're always being asked to make it.

Here's the answer up front: there's no clean formula for when to pivot versus when to persist. Anyone selling you one is selling you a heuristic that worked for them, in their context, once. What I can offer is a framework for thinking about it clearly, and a diagnosis of the signals people usually misread.

the signals that actually matter

Users who stay versus users who come. Acquisition is easy to game and expensive to sustain. Retention is harder to fake. If you have 100 users who came, used it once, and left, that's a different situation than 20 users who use it every week and tell other people about it. The second number matters far more.

The quality of the problem feedback. When users tell you what's wrong, are they describing a fixable problem with the current product, or are they describing a need that the current product can't serve in any adjacent version? "The setup is too complex" is fixable. "I don't actually need this to be automatic. I need to be in control of each step" may be telling you the core assumption is wrong.

Your own conviction in the direction. Not confidence: conviction. Confidence fluctuates with traction. Conviction is about whether you genuinely believe the problem is worth solving and the approach is right, independent of current momentum. Building without conviction is brutal. Building with conviction through hard stretches is survivable.

The proximity to the next milestone versus the distance from the last one. If you've been building for six months and you're genuinely close to the thing that would change the traction picture, ship it before you decide. If you've been building for six months and the thing that would change the picture keeps moving further away, that's meaningful signal.

what people usually misread

Silence as rejection. Early silence usually means nobody knows you exist, not that nobody wants what you're building. Lack of traction in the first three months of a product nobody's heard of is not evidence the product is wrong.

Feedback as pivot direction. Users are good at describing what's wrong with what you have. They're not good at designing the solution. "Users said they want X" is a reason to investigate, not a spec.

The wrong comparison set. Comparing your month-three revenue to someone else's year-three revenue is useless. Every product trajectory looks terrible at month three if you compare it to a mature product.

Exhaustion as signal. When you're depleted and the thing isn't working, the urge to change everything is powerful. But the judgment you make from that state is not reliable. Rest before you decide, if you can.

the actual pivot question

The cleanest version of the pivot question is: is the problem I'm solving real, do I believe I'm the right person to solve it, and is the approach I've chosen the best path to the solution?

If the problem isn't real (users aren't actually experiencing it, or experiencing it urgently), that's a fundamental pivot.

If you're not the right person or team (you don't have the specific knowledge, access, or relationships the problem requires), that's also a fundamental pivot.

If the approach is wrong but the problem and team are right, that's an execution pivot, which is cheaper and faster than a direction change.

Most "should I pivot" questions are approach pivots being framed as direction pivots. That distinction matters because the evidence and the cost are different.

from my own bench

I've pivoted projects and I've persisted through hard stretches. The decisions I regret most are the ones I made when I was too tired to think clearly and the ones I made based on other people's timelines rather than my own read of the situation.

The most useful thing I've found: write down clearly what I believe to be true about the problem, the user, and the approach, and then compare it to what the evidence actually says. When those are in close alignment, persist. When there's a clear gap between what I believe and what the evidence shows, that gap is worth taking seriously.

Try it today

Step	What you do	Why it pays off
1. Separate the problem signal from the execution signal	Is traction low because the problem isn't real, or because the product hasn't reached the right people yet?	The answer determines whether you change direction or change execution
2. Find one retained user and talk to them	Not a churned user: someone who stayed. What are they actually using it for? Does that match what you thought you were building?	Your retained users are your ground truth about what the product actually is
3. Write your conviction case	In 200 words: why is this problem real, why are you the right person to solve it, and why is this approach right?	If you can write it convincingly, you have something to persist with. If you can't, that's the signal.

The bottom line

Pivot decisions made at low energy from inadequate evidence are usually wrong. The signals that matter are retention, quality of problem feedback, and the proximity of the next meaningful milestone.

When in doubt: ship the thing that would change the picture, and then decide.

Dru Edwards