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 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 customers have actually done about it. Stated urgency with no action yet isn't proof. It's a flag to look closer before you build.

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 1 rarely creates demand on its own. A 2 means the struggle is real but you likely caught it early. 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. Blend urgency and evidence into one 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.

On Pivots

Score the struggle, not the solution

Q: 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.

Pivot postmortems almost always blame the offering: wrong price, wrong features, wrong channel. Almost nobody goes one layer deeper and asks whether the struggle underneath was ever strong enough to carry a company.

John GusiffCustomer Centric Solutions LLCSeattle, WA10 min read

The short version

Most stalled products are built on a struggle that was invented or real but mild. The pivot memo blames the solution anyway.
Score any struggle on three things: what's at stake, how urgent it is, and what the customer has actually done about it.
High urgency with no action yet isn't a false alarm. It usually means you caught the struggle early, and that's worth investigating now.

Jump to the rubric See four companies scored

01The problem nobody scores

The same pattern shows up in switching interviews, win-loss calls, and post-launch retros. Founders can describe their customer's problem in perfect detail. What they can't say is why that customer would ever act on it.

That isn't a positioning problem or a GTM problem. It's a struggle problem, and it usually gets baked in before a line of code is written. Someone says "our customers struggle with X," everyone nods, and the team moves straight to solutioning.

Nobody scored the struggle. Everyone just believed it.

02Two ways a struggle fails you

Failure one

It was invented

It came from your last job, a LinkedIn thread, or a competitor's copy. You've never watched a target customer live through it, so you can't say what it costs them, or whether they've already made peace with it.

Failure two

It's real, but mild

Customers agree it exists in every interview. It's just a squeaky door hinge: true, mildly annoying, and not worth doing anything about. This one is more common, and harder to spot.

Both end the same way, 18 to 20 months later: a technically sound product, a deck that says you did "customer research," a shrinking runway, and a pivot memo that blames the solution.

The tellIf your growth plan depends on educating customers that they have a problem, you're not looking at a struggle. You're looking at an opportunity you're excited about. Those are different companies, with very different runway needs, and only one fits inside 18 months of seed capital.

Not sure which one you're building on: a struggle, or an opportunity you're excited about?

Book a discovery call

03What "strong enough" actually means

A struggle worth building on passes three checks. Most founders only ever run the first one.

Check 1

Stake

What it threatens: time, money, risk, or identity.

Not: "It's inefficient."
Instead: "It costs the ops lead four hours every Friday she should spend hiring."

Check 2

Urgency

How bad it is, from what they told you: disruptive, necessary, hard to postpone, consequential.

Score it the moment you hear it. No customer action required.

Check 3

Evidence

What they've actually done: searched, built a workaround, spent money, switched.

This is the check that predicts demand. Behavior, not opinion.

Urgency and evidence are scored separately on purpose. A struggle can be severe and brand new at the same time, caught the week it triggered, before the customer has had a chance to act. Blend the two into one number and that struggle looks identical to a mild one. Keep them apart and it shows up as what it is: real, and early.

04The rubric

Fill this out for any struggle you're considering building the next 12 to 18 months on, before it becomes a roadmap item or the thesis of a pitch deck. It takes about ten minutes if the struggle came from a real interview. 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.

1Write the struggle sentence

Test: why did they start looking now, not six months earlier? No "when" means you're holding a pain point, not a struggling moment.

When , I realized was no longer working well enough, because .

2What is at stake?

Pick the primary stake. Add Identity when someone's standing rides on the outcome, or pick Identity alone.

3Urgency: check all that apply

Disruptive, not just annoying Necessary to resolve, not optional Hard to postpone Significant consequence if ignored

4Evidence: the most they've done

Nothing yet described it, hasn't acted Actively searching for a better way Built a workaround or committed extra time or money Paid for or switched or seriously attempted a replacement

Your score

0 · Weak signal

Low urgency, little action. Unlikely to create demand on its own.

At stakeNot chosen

Impact of DelayNot captured

High urgency means 3 or 4 boxes checked. High evidence means a workaround, spend, or switch. Impact of Delay appears on the result as context; it doesn't change the score.

Notice what the rubric doesn't ask: whether you can build a solution, whether the market is big enough, whether a competitor already serves it. Those are real questions. They're just the second question, not the first. Score the struggle before the team starts solutioning and you'll kill a lot of ideas in ten minutes instead of eighteen months.

Workarounds are the fastest way to find evidence. The Should We Pivot diagnostic calls them 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.

The score is not the research

The rubric tells you which struggles deserve investigation. It doesn't validate them. A team can usually guess what's at stake. What it can't reconstruct from internal knowledge is the event that made the old way unacceptable, why the customer acted then and not six months earlier, and what searching, workarounds, or spending actually followed.

The score is not the research. It is the structure for the research.

That reconstruction is what a Customer Progress Interview does. It isn't a separate method: it's a Switching Interview paired with a Core Jobs Interview, and each one feeds a different part of the rubric.

Rubric question	What the interview reconstructs	Source
What was at stake?	The functional, financial, social, or identity consequence	Core Jobs
Was it disruptive?	What stopped working, and how daily behavior changed	Core Jobs
Was it necessary?	Why tolerating the old way was no longer acceptable	Core Jobs
Hard to postpone?	The "why now" trigger and any deadline behind it	Switching
What did they do?	Searching, workarounds, spending, trial, and switching	Switching

The Switching Interview supplies the evidence: not what the customer said they'd do, but what they actually did. The Core Jobs Interview supplies the stakes, and closes the loop afterward: did real progress follow, or did the workaround just move the problem somewhere else?

Scored a 1 or a 2? That's exactly the range a Customer Progress Interview is built for: real enough to take seriously, not yet proven.

Book a discovery call

05Four companies, scored

None of this requires a Systrom-style rebuild. It applies just as often to companies with a working product and paying customers. Nobody at these four companies filled out a card like this, but run their struggles through the rubric and the shape holds. Two patterns show up.

Pattern A · Gong, Chili Piper

Reframe: same product, sharper struggle

The product already solved a more consequential struggle than the one it was sold on. The fix was recognizing it.

Pattern B · Stripe, Figma

Expand: a new struggle, a new build

The first struggle was strong. Growth surfaced an adjacent one, just as consequential, that the product hadn't answered yet.

Company	Before	After	Stake shift	Pattern
Gong	0 Weak	3 Strong	Time → Risk	Reframe
Chili Piper	0 Weak	3 Strong	Time → Money	Reframe
Stripe	2 Early	3 Strong	Time → Risk	Expand
Figma	2 Early	3 Strong	Time → Risk	Expand

Gong

Records and analyzes sales calls; originally sold as a coaching tool for sales managers. Founded in 2016 by Amit Bendov and Eilon Reshef, with a $6M seed led by Norwest Venture Partners and Shlomo Kramer.

Before · 2016 to 20180 · Weak

Stake: Time

"The sales manager is struggling to coach reps because they can't listen to every call."

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.

DisruptiveNecessaryHard to postponeConsequential

Impact of DelayUncoached reps lose deals their managers never hear about.

They didNothing yet

Why it scores this way

Frustrating for managers, but reps kept hitting quota anyway.
Listening to more calls was a nice-to-have; nobody budgeted for it.
Managers had gotten by on spot-checks for years. No forcing event.
The one real cost: uncoached reps showed up in lost deals.
No workaround beyond occasional spot-checks; no budget or time committed.

→+3

After · 2019 onward3 · Strong

Stake: Risk + Identity

"I'm committing a forecast without knowing what's actually happening in our deals."

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.

DisruptiveNecessaryHard to postponeConsequential

Impact of DelayThe revenue leader commits a number to the board they can't verify, and answers for the miss. Must be addressed this quarter.

They didBuilt a workaround, committed money

Why it scores this way

Leadership stopped trusting the forecast number itself.
A board-facing forecast can't run on guesswork.
The next forecast call was already on the calendar.
Missing the number meant answering for it to the board.
Revenue leaders were building manual deal-risk spreadsheets and paying analysts to reconstruct pipeline health by hand.

What followed: conversation intelligence became revenue intelligence. A $200M Series D at a $2.2B valuation; ARR since past $500M, growing 55%+ year over year.

Chili Piper

Scheduling and lead-routing software that connects inbound leads with a sales rep. Founded in 2016 by Nicolas and Alina Vandenberghe, who bootstrapped past $2M ARR before a $3M seed led by Flashpoint Venture Capital.

Before · 2016 to 20190 · Weak

Stake: Time

"The sales team is struggling to schedule meetings because coordinating calendars takes too long."

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.

DisruptiveNecessaryHard to postponeConsequential

Impact of DelayReps lose hours every week to scheduling back-and-forth.

They didNothing yet

Why it scores this way

Annoying back-and-forth, but meetings still got booked eventually.
Tedious, but nobody was escalating it.
Teams had lived with the scheduling shuffle for years.
The one real cost: reps burned hours a week landing on a time.
Reps lived with it; nobody had built a fix or paid to avoid it.

→+3

After · 2020 onward3 · Strong

Stake: Money

"A high-intent prospect just filled out our form, and we might lose them while sales is still getting to it."

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.

DisruptiveNecessaryHard to postponeConsequential

Impact of DelayHigh-intent pipeline goes cold and lands with a faster competitor. Must be addressed this month.

They didBuilt a workaround, committed money

Why it scores this way

Sales stopped trusting that inbound leads got followed up at all.
A lead that goes cold is pipeline that doesn't come back.
Every hour of delay favored whichever competitor responded first.
Lost meetings meant lost revenue leadership could point to directly.
Sales ops cobbled together manual round-robin sheets and paid for basic scheduling links to keep leads from going cold.

What followed: scheduling was reframed around converting inbound demand. Reported near $43M ARR at a roughly $625M valuation, about 14x revenue: priced like pipeline infrastructure, not a calendar tool.

Sources: Gong Series D announcement · Gong ARR update · Chili Piper revenue estimate, Latka

Same customers in both cases. Same call data, same workflow, same product underneath. Neither company needed a rebuild. They needed this exercise, run honestly, against a struggle they'd already convinced themselves they'd validated. The growth followed the stake, not the other way around.

Pick one door, not both

Gong and Chili Piper walked through Door Two. There's one other common move, and the rule is to choose between them.

Door One

Same job, different executor

ConvertKit stalled for over a year selling generic small-business email software. It moved once Nathan Barry narrowed hard to professional bloggers, whose real struggle was segmenting an audience to sell to later, not "send a newsletter."

Door Two

Same executor, sharper job

Gong and Chili Piper kept their buyers and their product. What changed was which struggle they were sold on.

Never walk through both at onceChange who you sell to and what you solve for them in the same swing, and you've built a new company by accident, with no way to tell which change did the work. The full framework lives in the Should We Pivot diagnostic. If neither door fits, the other eight moves are in Every Pivot Has a Required Input.

When the fix is what you build, not what you say

Stripe and Figma are the other case. Each built something real on one strong struggle, then ran into an adjacent struggle, just as consequential, that the product hadn't answered yet. That's not correcting a mistake. It's expansion: same customer, same core product, and this time the fix is something you build.

Stripe

Payments infrastructure that lets businesses accept and manage online payments. Founded in 2010 by Patrick and John Collison, with a $2M seed in 2011 from investors including Sequoia, Andreessen Horowitz, Peter Thiel, and Elon Musk.

Before · 2010 to 20152 · Early

Stake: Time

"We need to start accepting payments without building the infrastructure ourselves."

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 revenue.

DisruptiveNecessaryHard to postponeConsequential

Impact of DelayEngineering weeks go to payments instead of product, and revenue waits on launch. Must be addressed this quarter.

They didActively searching

Why it scores this way

Blocking rather than disruptive: there's no ongoing operation yet to disrupt.
A business can't accept payments at all without solving this.
It blocks launch and revenue entirely until it's built.
No payments infrastructure means no revenue, full stop.
Developers had spent weeks evaluating banks and legacy processors, with no workaround in place yet.

→+1

After · 2016 onward3 · Strong

Stake: Risk

"We're losing money to fraud, but tightening the rules is also blocking good customers."

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.

DisruptiveNecessaryHard to postponeConsequential

Impact of DelayFraud losses and chargebacks grow with every transaction, while good customers get declined. Must be addressed this month.

They didPaid for a replacement

Why it scores this way

Fraud review became a constant operational drag on the team.
Payments can't scale safely without catching fraud automatically.
Every transaction processed was live exposure.
Chargebacks, lost revenue, and legitimate customers blocked.
Businesses were already paying for bolt-on fraud tools and eating chargebacks as the cost of staying live.

What followed: as volume scaled, Stripe built Radar directly into the payment flow. It reported preventing $4B in attempted fraud in 2017 alone.

Figma

Browser-based design tool for creating and prototyping interfaces. Founded in 2012 by Dylan Field and Evan Wallace, with roughly $4M in seed funding in 2013.

Before · 2013 to 20162 · Early

Stake: Time

"I need a design tool that just works in the browser, without me juggling which file is the current one."

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.

DisruptiveNecessaryHard to postponeConsequential

Impact of DelayDesign hours lost to version conflicts and overwritten work.

They didActively searching

Why it scores this way

Switching tools and passing files around broke workflow constantly.
Designers needed real access without installs or platform lock-in.
Teams had lived with file-based handoffs for years; it was an accepted cost.
Version conflicts meant real work got lost or overwritten.
Teams were asking around for a better handoff, without a fix that stuck.

→+1

After · 2017 onward3 · Strong

Stake: Risk + Identity

"I can't tell which file is the real one anymore, or whether the feedback even made it in before this ships."

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.

DisruptiveNecessaryHard to postponeConsequential

Impact of DelayA wrong version ships, and the design team loses credibility with engineering and leadership. Must be addressed this quarter.

They didPaid for a replacement

Why it scores this way

Designers stopped trusting that the open file was the real one.
A shared source of truth wasn't optional once more than one person touched a file.
The next handoff or release was already coming.
Shipping the wrong version meant reverted work or a broken release.
Teams paid for separate version-control tools bolted onto their design software.

What followed: multiplayer editing shipped in 2017, with shared components, comments, and version history. It became the product's defining difference, drew a $20B Adobe offer in 2022 (later terminated), and Figma went public in 2025 above an $18.8B valuation.

Sources: Stripe Radar 2.0 announcement · Figma, Multiplayer Editing in Figma · Figma/Adobe deal coverage, Crunchbase News

In both cases the customer stayed the same, and so did the product category. What changed was which struggle earned a roadmap slot instead of a release note. Both struggles were strong before the companies built anything for them. The rubric just confirms they were strong enough to justify the engineering time.

Gong, Chili Piper, Stripe, and Figma didn't guess their way to a 3. Want a second set of eyes on your own struggle sentence?

Book a discovery call

06Where the sentence has to come from

The rubric only works if the opening sentence comes from a real customer's words in a switching interview, not from a whiteboard session.

When ___, I realized ___ was no longer working well enough, because ___.

Every blank has to trace back to something specific: a moment you can point to, an old way you can name, a stake you can defend. Fill it from memory of a sales call, or from what must be true of "customers like this," and you're scoring your own belief. It will score however you want it to.

That's why the Customer Progress Interview walks a customer back through First Thought and Passive Looking in order, before the Hiring Moment. The sentence 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 a struggle scores a 2 or a 3, the interesting work is still ahead: what pushed them to start looking, what almost stopped them from switching, what they were afraid of getting wrong. But now your effort and your runway go into ground that can hold a company. That's the difference between a pivot and a rewrite.

FAQQuestions founders ask before they build

How do I know if it's 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 the two need very different amounts of runway. The rubric scores the difference in about ten minutes.

Why did my product validate in every 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. Score urgency (disruptive, necessary, hard to postpone, consequential), then separately check what customers have actually done. Stated urgency with no action yet isn't proof. It's a flag to look closer before you build.

What's the difference between a pain point, a job story, and a struggling moment?

A struggling moment is dated. It names when the old way stopped working well enough, and why they started looking now instead of six months earlier. A pain point or job story usually can't answer that "why now" question, which is the fastest way to tell them apart.

How do I score a struggle before I spend a quarter of runway on it?

Name what's primarily at stake: time, money, risk, or identity. Then score urgency and evidence separately. A 0 or 1 rarely creates demand on its own. A 2 means the struggle is real but you likely caught it early. A 3 means you have both the stakes and the proof.

Why score urgency and evidence separately?

Because a struggle can be severe and brand new at the same time, caught before the customer has had any chance to act. Blended into one number, it looks identical to a mild one. Scored separately, 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. 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.

Not sure if you have a struggle problem or a solution problem?

The Should We Pivot diagnostic walks through both. The Switching Interview guide has the full question set for pulling a struggle sentence out of a real customer. Or skip straight to talking it through.

Book a discovery call Run the pivot diagnostic Read the interview guide