Here is the pattern I keep seeing in switching interviews, win-loss calls, and the "why didn't this land" retros founders run after a launch underperforms: you can describe your customer's problem in perfect detail. You just can't say why that customer would ever act on it, not to an investor, and not to yourself at midnight.
That's not a positioning problem. It's not a GTM problem. It's a struggle problem, and it usually got baked in before a single line of code was written, back when you or a cofounder said some version of "our customers struggle with X" in an early founding conversation, and everyone nodded and moved straight to solutioning.
Nobody scored the struggle. Everyone just believed it.
Two ways a struggle fails you
The first is the one nobody wants to admit to: the struggle was invented. It came from your last job, a LinkedIn thread, a competitor's marketing copy, an assumption dressed up as a customer insight. You haven't actually watched a target customer live through it, so you can't say what it's really costing them, or whether they've already made peace with it.
The second is subtler, and more common among founders who did talk to customers: the struggle is real, and customers will agree to it in an interview, but it's mild. It's a real problem the way a squeaky door hinge is a real problem. True, mildly annoying, and not worth doing anything about. You can validate that a struggle exists in every discovery call you run and still spend a chunk of your seed round building on ground that can't hold a company.
Both failures produce the same symptom eighteen to twenty months later: a technically sound product, a deck that says you did "customer research," a shrinking runway number, and a pivot memo that blames the solution.
Not sure yet which one you're building on, a struggle or an opportunity you're excited about?
Book a discovery callQuestions founders ask before they build
How do I know if my customer's problem is a real struggle, or an opportunity I'm excited about?
Check whether your growth plan depends on educating the customer that they have a problem. If it does, you're looking at an opportunity, not a struggle, and those two need very different amounts of runway. The struggle rubric below scores the difference in about ten minutes.
Why did my product validate in every customer interview but still fail to grow?
Validation and strength are different questions. A struggle can be real and still be mild, true the way a squeaky door hinge is true, and not worth anyone acting on. Score its urgency against four signals, disruptive, necessary, hard to postpone, consequential, then separately check what they've actually done about it. Stated urgency with no evidence of action yet isn't proof, it's a flag to look closer, before you build, not after.
What's the difference between a pain point, a job story, and a struggling moment?
A struggling moment is dated: it names when the customer's old way stopped working well enough, and why they started looking now instead of six months earlier. A pain point or a job story usually can't answer that "why now" question, which is the fastest way to tell them apart.
How do I score a customer struggle before I spend a quarter of runway building for it?
Name what's primarily at stake, time, money, risk, or identity. Then score two things separately: how urgent it is, based on what they described, and what they've actually done about it, searched, worked around it, spent money, switched. A 0 or a 1 rarely creates demand on its own, a 2 means the struggle is real but you likely caught it early, and a 3 means you have both the stakes and the proof.
Why does the rubric score urgency and evidence separately instead of one number?
Because a struggle can be severe and brand new at the same time, caught the week it triggered, before the customer has had any chance to search or act. Score urgency and evidence as one blended number and that struggle looks identical to a genuinely mild one. Score them separately and it shows up as what it is: real, and early.
Should I change who I sell to, what I solve for them, or both?
Pick one door. Door One changes the executor and keeps the job the same, Door Two keeps the executor and sharpens the job. Changing both at once turns your pivot into an accidental new company, with no way to tell which change did the work.
What "strong enough" actually means
A struggle worth building on has two independent properties, and most founders only ever check the first one.
The first is what's at stake. Every real struggle threatens something specific: time the customer can't get back, money that hits revenue or budget, risk of failure or exposure, or identity, meaning how they see themselves or how they're seen by people who matter to them. Naming which one is primarily at stake forces a level of precision most discovery calls never reach. "It's inefficient" is not a stake. "It costs the ops lead four hours every Friday she's supposed to be spending on hiring" is.
The second, and the one that actually predicts demand, is strength, and it has two parts that need to be scored separately. The first is urgency: is it disruptive rather than just annoying, does it have to be resolved rather than sitting on a someday list, is it hard to postpone past the next planning cycle, does ignoring it have a consequence the customer can point to. Urgency is what the customer told you, and you can score it the moment you hear it. The second is evidence: what they've actually done about it, searched, worked around it, spent money, switched. A struggle can score high on urgency and still be new enough that no evidence has shown up yet. That's not a false alarm. It just means you caught it early, and the rubric below is built to say so instead of quietly scoring it the same as a struggle nobody will ever act on.
Score all three, stake, urgency, and evidence, and you get something a lot more honest than a persona doc: a number that tells you whether you're looking at a real problem, an interesting one, or a company worth spending your runway on.
The rubric
This is the version I now ask founders to fill out for every struggle they're considering building the next twelve to eighteen months on, before it becomes a roadmap item, or worse, the thesis of a pitch deck. It takes about ten minutes if the struggle came out of a real interview, and considerably longer, tellingly, if it didn't.
Working Tool
Score One Real Customer Struggle
A specific moment when a target customer said their current way of getting something done was no longer working well enough.
The test: why did they start looking now, and not six months earlier? If you can't point to the "when," you're probably holding a pain point or a job story, not a struggling moment.
1What is primarily at stake?
2How strong is it?
Urgency · score this the moment you hear it
No action required from the customer yet, this is about what they described, not what they've done. 0–2 checked: low urgency. 3–4 checked: high urgency.
Evidence · the highest thing they've actually done
Notice what the rubric does not ask: whether you can build a solution for it, whether it's a big enough market, whether a competitor already serves it. Those are all real questions. They're just the second question, not the first. Score the struggle before you let your team start solutioning, and you'll kill a lot of ideas in the first ten minutes instead of eighteen months of runway.
Evidence of a workaround or spend, the top of that Evidence axis, is also the fastest way to find what the Should We Pivot diagnostic calls the fingerprints of struggle: the spreadsheet with eleven tabs nobody wants to touch, the contractor hired just to duct-tape two tools together, the manual process someone is already paying to avoid. If you can point to one of those, you're not stuck at emerging, you already have demonstrated evidence.
The score is not the research. It is the structure for the research.
You can identify a plausible struggle in a workshop. You need a Customer Progress Interview to determine whether it actually created demand. A team can usually hypothesize what's at stake. What it cannot reliably reconstruct from internal knowledge alone is the specific event that made the old way stop feeling acceptable, why the customer acted then and not six months earlier, whether the problem was truly hard to postpone, and what searching, workarounds, spending, or switching actually followed.
| Rubric question | What the interview reconstructs |
|---|---|
| What was at stake? | The functional, financial, social, or identity consequence |
| Was it disruptive? | What stopped working, and how daily behavior changed |
| Was resolution necessary? | Why tolerating the old way was no longer acceptable |
| Was it hard to postpone? | The "why now" trigger and any deadline behind it |
| What did they do? | Searching, workarounds, spending, trial, and switching behavior |
Switching Interview
Reconstructs the trigger, the "why now" timeline, and the switching behavior itself, what they searched for, worked around, spent on, or replaced. This is where the Evidence axis comes from.
Core Jobs Interview
Establishes the full functional, social, and emotional job the customer is hiring a solution for, including what happened after they switched. This is where the Urgency axis, and the check on whether progress actually followed, comes from.
Run both together and you have what a Customer Progress Interview actually is: not a separate, seventh method, but a Switching Interview paired with a Core Jobs Interview. The Switching Interview supplies the evidence this rubric asks for, not what the customer said they'd do, but what they actually did. The Core Jobs Interview supplies the stakes, and closes the loop after the fact: did real progress follow, or did the workaround just move the problem somewhere else.
Scored a 1 or a 2 just now? That's exactly the range a Customer Progress Interview is built for, real enough to take seriously, not yet proven. Let's look at what one would surface.
Book a discovery callThis doesn't require a Systrom-style rebuild
Everything above can sound like it only applies pre-seed, when you're deciding what to build in the first place. It applies just as often to companies with a working product and paying customers, where the fix isn't a pivot at all, just a sharper version of the same struggle, found without changing the customer, the workflow, or the product underneath it.
Run each one through the same rubric from above. Nobody at either company filled out a card like this, but the shape holds.
Gong
When headcount grew past what one manager could shadow, I realized sitting in on live calls was no longer working well enough, because most reps went uncoached for weeks at a time.
"The sales manager is struggling to coach reps because they can't listen to every call."
When forecast calls started running on rep-reported updates, I realized trusting what a rep said about a deal was no longer working well enough, because the revenue leader was committing a number to the board with no way to verify it.
"I'm committing a forecast without knowing what's actually happening in our deals."
Chili Piper
When inbound volume outpaced manual scheduling, I realized emailing back and forth to find a time was no longer working well enough, because reps were losing hours a week just landing on a meeting slot.
"The sales team is struggling to schedule meetings because coordinating calendars takes too long."
When a form-fill sat in a queue waiting for a rep to notice it, I realized following up whenever someone got to it was no longer working well enough, because every hour of delay was pipeline quietly going to a faster competitor.
"A high-intent prospect just filled out our form, and we might lose them while sales is still getting to it."
Sources: Gong Series D announcement, Gong ARR update, Chili Piper revenue estimate, Latka
Same customer base in both cases. Same call data, same workflow, same product underneath. Neither company needed a new customer or a rebuild to do this, they needed the exercise on this page, run honestly, against a struggle they'd already convinced themselves they'd validated. The growth followed the stake, not the other way around.
That's one of exactly two doors. This is a Door Two move: same executor, a sharper job. Door One runs the same exercise on the other variable, same job, a different executor, the way ConvertKit stalled for over a year building generic small-business email software and only moved once Nathan Barry narrowed it hard to professional bloggers, whose actual struggle was tagging and segmenting an audience to sell to later, not "send a newsletter." Either door can hold a company. What the rubric on this page won't forgive is walking through both at once: change who you sell to and what you solve for them in the same swing, and you've made a new company by accident, with no way to tell which change did the work. Score the struggle for whichever side of the door you're on before you commit to it, that's the full framework, and it lives on the Should We Pivot diagnostic. Door One and Door Two are the two moves that show up most often, but they're not the only ones; if neither fits what you're looking at, the other eight are mapped out in Every Pivot Has a Required Input.
Sometimes the fix is what you build, not what you say
The Gong and Chili Piper moves didn't require rebuilding the product around a new customer or workflow, they began by recognizing the product already resolved a more consequential struggle than the one it was being sold on. Sometimes the honest answer to the same exercise is different: a company builds something real on one strong struggle, then later runs into an adjacent struggle, just as consequential, that the product hasn't answered yet. That's not a correction of a mistake, the first struggle was never weak, it's expansion: same customer, same core product, but this time the fix is something you build.
Run each one through the same rubric below. Neither struggle needed a new customer to be real, just a company far enough along to run into it.
Stripe
When integrating payments required weeks of engineering work, I realized building and maintaining our own payment stack was no longer working well enough, because every week spent on it was a week the business couldn't launch or collect a dollar of revenue.
"We need to start accepting payments without building the infrastructure ourselves."
When fraudulent transactions began rising with payment volume, I realized manually reviewing suspicious payments was no longer working well enough, because every decision either exposed us to losses or rejected a legitimate customer.
"We're losing money to fraud, but tightening the rules is also blocking good customers."
Figma
When designing meant installing desktop software and passing files back and forth, I realized save-and-send editing was no longer working well enough, because every handoff risked opening the wrong version or overwriting someone else's work.
"I need a design tool that just works in the browser, without me juggling which file is the current one."
When multiple designers began editing separate copies of the same file, I realized passing files back and forth was no longer working well enough, because nobody could tell which version was current before a release went out.
"I can't tell which file is the real one anymore, or whether the feedback even made it in before this ships."
Sources: Stripe Radar 2.0 announcement, Figma, Multiplayer Editing in Figma, Figma/Adobe deal coverage, Crunchbase News
Notice what didn't change in either case: the customer stayed the same, and so did the core product category. What changed was which struggle had earned a roadmap slot instead of a release note, and in both cases that struggle was already strong before the company built anything for it, the rubric just confirmed it was strong enough to justify the engineering time.
Gong, Chili Piper, Stripe, and Figma didn't guess their way to a 3. If you want a second set of eyes on your own struggle sentence, bring it to a call.
Book a discovery callWhere the sentence has to come from
The rubric only works if the opening sentence comes out of a real customer's actual words during a switching interview, not out of a whiteboard session:
All three blanks have to trace back to something specific: a moment you can point to, an old way you can name, a stake you can defend. If you're filling this out from memory of a sales call, or worse, from what you assume must be true of "customers like this," you're scoring your own belief and it will score however you want it to.
That's the whole reason the Customer Progress Interview (a Switching Interview paired with a Core Jobs Interview) exists as an interview method: it walks a customer back through the First Thought and Passive Looking stages in chronological order, before the Hiring Moment, specifically so the sentence, all three parts of it, gets built from what they actually said, not from what you asked them to confirm.
You don't pivot the offering. You pivot the struggle, and the offering follows.
Once you've scored a struggle a 2 or a 3, the interesting part of the work is still ahead of you: what pushed them to start looking, what almost stopped them from switching, what they were afraid of getting wrong. But you're now spending your effort, and your runway, on ground that can hold a company. That's the difference between a pivot and a rewrite.