The World Taught Us to Fix Problems
In 2019, I consulted a marketplace for children's activities. Liz, the founder, was spending her runway diligently fixing real customer problems.
Parents used the product to find swim, dance, music, and other classes for their kids. The team kept hearing one clear problem: finding the right class was inconvenient. A problem-first roadmap almost writes itself: add more studios, improve search and fix outdated data.
When we finally started proper research, the answer changed, but too late. The loud cohort had built a habit of using the product to find free first classes. They loved the product because it made free sampling easier. The business model made money only when a parent moved from the free class to paid classes and the studio paid commission. Liz's team had been fixing Problems for a segment that fundamentally did not want to pay. The product could not make money on these parents no matter how well it served them. By then, there was almost no room left to maneuver.
The Problems were real. But the team had spent its budget on the wrong segment.
That is the danger hidden inside a sentence every founder learns early: solve customer problems.
It comes from everywhere. Y Combinator's essential advice tells founders to build something people want and solve one problem well. Sequoia's Arc Product-Market Fit framework goes further: it organizes the whole PMF path around how customers relate to the problem your product solves. The same doctrine appears in pitch decks, accelerator office hours, customer interviews, and roadmap meetings.
The advice became dominant because it works. When a migration fails, monthly reconciliation burns six hours, or a security team blocks an enterprise deal because the product lacks audit logs, fixing the failure can create obvious value. The customer wanted a result, the current way failed, and the product that removes the failure earns attention fast.
Problem-first thinking protects founders from fantasy products. After enough wins, the pattern starts to feel like product truth: find the pain, validate the pain, fix the pain.
Then it breaks. Customers buy without naming pain. The old way feels normal until a new Solution makes it look primitive. Several teams may report the same complaint while performing different Jobs. A loud cohort can report real Problems — Liz's cohort did — and still be the wrong segment. At that point, problem only marks where the deeper chain has to be reconstructed.
The Job Comes Before the Problem
The hidden assumption inside the problem doctrine is simple: the Problem is the first cause. AJTBD draws the chain one step earlier — to the Job.
A Job is, for now, just a goal. Something the person wants to get done: get home safely, file the taxes, pass the security review. Goal and Job are the same thing; the next chapter takes the term apart properly.
In AJTBD, a Problem is the consequence of a Solution hired for a Job and performing below that Job's success criteria. The pain and frustration are real; they sit downstream from the cause.
Example: a VP of Sales wants to pass vendor review before the enterprise buyer's budget window closes. The team chooses a promising SaaS tool. The champion likes it, but security rejects it.
The chain is: Job: "I want to pass vendor review" — with the criterion credible enough for security to approve before the deal dies → Solution: the promising SaaS tool → Problem: security blocks the deal because the tool lacks SSO, audit logs, and role-based permissions.
The complaint "we need SSO" appeared only when the chosen Solution failed the Job's success criteria.
One level deeper is enough for this chapter: a Job names the person's situation, the outcome they want to reach, the criteria for good enough, and the higher-level goal it serves. To perform it, the person chooses a way: product, service, spreadsheet, employee, workaround, contractor, habit, manual process, brand, or waiting. That chosen way is the Solution — and the Problem appears when it misses the bar.
When the Old Way Feels Normal
That order matters most when the old way feels normal.
Before Codex, Claude Code, Cursor, Lovable, and similar tools, most founders did not describe software development as a customer problem. They were living inside a constraint: software required engineers, budget, skill, sprint capacity, or compromise.
Then the constraint moved. A solo founder could turn an idea into a working prototype in hours; a PM could make an internal tool without waiting for a sprint; a non-technical operator could build the first rough workflow and learn whether it deserved real engineering.
The value appeared before the clean complaint.
Axios reported that Anthropic passed a $30 billion annualized revenue run rate in April 2026, up from $9 billion at the end of 2025.
A better chain is: Job: "I want to turn an idea into working software" — with the criterion fast enough that I can test it before motivation, budget, or timing disappears → Old Solutions: hire engineers, wait for sprint capacity, use no-code, or code personally → New Solution: vibe coding → Value: the same outcome becomes radically faster, cheaper, and easier to perform.
For an indie hacker, the feedback loop changes. Vibe coding makes a hypothesis cheap to build and fast to test. If the chosen Job or segment is wrong, the mistake shows up faster. Building got cheaper; choosing got more important.
The old way often becomes visible as a Problem only after the new Solution teaches the market that a radically easier way exists.
One Complaint, Three Different Products
A founder says: "Our customers hate manual reporting." Problem-first thinking writes it down as one Problem: manual reporting.
The chain forces a different question: what was each customer trying to get done when they ran into the reporting?
Ask it, and the single complaint splits apart. One customer is preparing a board update: the numbers must look credible before the partner meeting, and the spreadsheet costs two days and breaks easily. Another is deciding where to move ad spend; they need channel data daily, and the manual export from five tools lands after the decision window has closed. A third is defending the roadmap — trying to prove the team does useful work with a hand-assembled dashboard the CEO reads as theater.
The same split exists at solo scale. The indie hacker who hates rebuilding a revenue dashboard every Monday may be performing "I want to see whether the product is growing" — or "I want to show traction in public" — and those are different products too.
Those answers may come from three segments, or from one segment performing three Jobs in the same week. Both versions change strategy. Different segments force a choice of where to compete. Multiple Jobs inside one segment force a choice of depth, bundling, or solving the bigger Job the customer was trying to perform by doing all three.
Sometimes the right move is to refuse the work. The complaint may belong to a segment you are not building for — Part IV unpacks how to choose that segment. Or it may belong to your focus segment, but to a low-priority Job with weak budget while nearby Jobs are more important, more frequent, and easier to monetize.
The product answer changes with the Job: board-reporting workflow, attribution and alerting, or a decision system that links roadmap bets to customer Jobs and business outcomes. The complaint did not contain the strategic move; it only pointed to the current Solution's failure.
The Limits of Problem-First Strategy
Many breakthrough products begin by making a previously expensive, slow, awkward, risky, or identity-threatening transition feel suddenly possible. ChatGPT made writing and analysis Jobs feel reachable; AirPods killed "I want to untangle my headphones"; Apple Watch performs Jobs around health signals, notifications, status, and identity.
Those products contain problem-solving pieces, but their value does not reduce to those pieces.
Problem-first thinking creates three strategic limits.
Fixing problems is available to everyone. Every founder, PM, accelerator, consultant, and VC already knows the sentence solve customer problems. If your strategy is only we found pain and we fix it, you have entered the same game everyone else is already playing.
Problem search rarely discovers breakthrough transitions. It can find broken onboarding, bad support, and painful workflows. It is much worse at finding Claude Code. The world taught us to fix problems — and then a competitor makes a move that blindsides a team that did everything right. The morning after their launch, the move looks obvious, even logical. You could not have imagined it, because it came from a different principle than fixing problems. Breakthroughs usually come from studying Jobs, then finding the ones the product can perform radically more efficiently than the current way.
Problem search narrows strategy. You see the customers articulate enough to complain and the failures visible enough to name. You may miss a better segment, a higher-budget Job, a normalized constraint, a chance to bundle several Jobs into one Solution, or a bigger Job that would leave the current competition behind.
At the company level, this becomes a repair-shop operating system: roadmap reviews ask which Problems were fixed, customer calls hunt for pain, and teams bring complaints because complaints sound evidence-based. The company can fix local failures and still fail to choose the best segment, create radical value, or build a position competitors struggle to copy.
Solving problems is a strong mechanic for creating value. It is not the definition of value, and it is not the only mechanic. The full catalog I work with and teach holds about a hundred mechanics; twenty-five of them are foundational value-creation mechanics, catalogued later in the book. Fixing the Problem is one of the twenty-five.
Once the chain is visible, the Problem becomes useful again. It tells us where the current Solution failed, which criteria the customer cared about, and where the customer may be receptive to a new way. It does not tell enough by itself.
The Diagnostic Before You Fix Anything
Before accepting any backlog item called a customer problem, write five lines:
- Job: what was the customer trying to perform?
- Current Solution: what did they use to perform it?
- Failed criterion: where did the current Solution miss the customer's bar?
- Segment: is this customer in the segment you are building for — or just loud, like Liz's free-class parents?
- Better move: is fixing this Problem the most effective way to create value here — or is there a stronger move?
For a founder, this changes the keep building or stop question: weak product, wrong Job, wrong segment, unfailing current Solution, and unlabeled new transition are different diagnoses. For a PM, the chain becomes a roadmap gate: no problem-ticket enters until the parent Job, current Solution, and failed criterion are named. For a PMM, "Manual reporting sucks" becomes "Prepare a credible board update before the partner meeting without two days of spreadsheet work."
The same applies to positioning. Job-language works across far more segments than problem-language. Problem-language works only when the segment already feels the Problem sharply. If the Problem is weak, normalized, or absent, pain-led positioning has nothing to grip. Jobs still carry motivation: better outcomes, speed, status, identity, control, relief, and new states the customer wants to feel.
This also changes feature requests. A customer asks for CSV export. Problem-first thinking builds the export. Job-first thinking asks what the CSV was hired to do. If the Job is "I want to send a compliance archive", export may be right. If the Job is "I want to prove campaign performance to my agency client", a client-facing report may be stronger. If the Job is "I want to avoid rebuilding the same dashboard every Monday", the strongest move may be deleting the reporting work entirely.
At the feature level, two products can look identical. At the Job level, the winner may be competing for a different Job, different success criteria, or a different segment entirely.
The more useful question is: Which Job is the customer trying to perform, which Solution are they using now, and where does that Solution fail by the customer's success criteria?
Wes Says Problems Really Do Sell
The working rule: the Problem shows the evaluation window, the Job tells you what outcome must land, and success criteria define what the new Solution must outperform. A Problem is one of the strongest triggers into evaluation, but the Job is the first cause of demand.
The Missing Parent Is the Job
The next chapter has to slow down and define the parent we just smuggled into the room: what exactly is a Job?