Chapter 6: The Problem Worth Building Around

I once built a company that tried to solve six problems at once. We had identified our customer — that part was clear. We had done the work of customer selection right. But when we got close to building an offer, we became paralyzed by abundance. Our customer had so many frustrations, so many pain points, so many wishes about how her job could be better. We documented them all. We listed them. We scored them. And then we tried to solve all of them.

The result was a product that did six things moderately well and nothing brilliantly. A message that scattered across six different value propositions. A team that worked twice as hard to ship half the impact. Everything diluted because we never chose.

Then something changed. We picked one problem. Not the most important one — there was no objective "most important." We picked the one problem that was intense enough to drive behavior change, specific enough that we could actually solve it, and aligned enough with our difference that we could win in a way the competition could not. Everything else we were going to ignore.

That single choice reshaped the entire company. The product became focused. The message became sharp. The team became efficient. We were not solving six problems anymore. We were solving one problem so well that customers would accept the tradeoffs of not solving the others.

This is the final piece of strategy before you can build an offer. Not every pain is a business. The strategic act is choosing which problem deserves your full weight.

The Job Already Exists

Before you arrived, your customer had a way of doing this job. That is the foundation of jobs-to-be-done thinking, the insight that has shaped my approach to strategy more than anything else.

The customer is not waiting for you to tell them what job to do. They already know the job. They already have a way of doing it. That way is imperfect — it requires too much effort, money, time, or risk. But it works well enough. They have built it into their routine, their budget, their expectations.

That way of doing the job is your real competitor. Not another vendor. The status quo.

The job is stable over time. Technology changes. What the customer needs to get done does not. A founder in the project management space was tempted to define her job as "use AI to manage sprints." But the job is "move work forward with my team while staying coordinated." AI is just a way of doing it — a way that might not exist in five years.

When you anchor to the job, the problem becomes clear: the current way costs too much, takes too long, or delivers too much variability.

The Job Executor vs. The Job Buyer

Here is a distinction that most founders miss: The person executing the job is not always the person paying for it.

A CTO evaluates engineering tools, but the engineers execute the work. A procurement officer approves a purchase, but the finance manager is the one doing the reconciliation work your tool solves. A CEO sponsors the initiative, but a mid-level manager is doing the daily operational job.

When you define the job, you must be clear about who is doing it and who has authority to approve a solution.

This matters because the pain you address is the executor's pain, but the person who buys is often the buyer. The executor is the one who will adopt the solution, feel the relief, and advocate for it internally. The buyer is the one who must justify the cost and fit it into their budget.

Get this wrong, and you have two separate sales problems: selling the executor on the value (a job they need solved), and selling the buyer on the investment (a cost to absorb).

When you define your problem, specify both. "Recruiting managers spend 40+ hours screening resumes every month and cannot tell if someone can do the job." That is the executor's pain. And "The recruiting manager needs approval from the VP of People, who controls the budget and must see evidence of time savings and improved hire quality." That is the buyer's approval structure.

Your offer has to work for both. Not just functionally for the executor. But it has to create business value that justifies the buyer's investment. Book 2 will show you how to build this into your offer. For now, make sure your Spectrum of Suck includes both the executor's pain and the buyer's approval criteria.

Defining the Job at the Right Level

Not all job definitions are equally useful. Too narrow, and you miss the actual value. Too broad, and your insight becomes useless.

Consider the job of boiling water. "Boil water" is too narrow — it cuts off adjacent value. Maybe your customer needs hot water, not boiling. Maybe she needs it to stay hot.

But "fill belly" is too broad. Boiling water is a tiny step in filling a belly. The definition is true but useless.

The right level is "prepare a hot beverage for consumption." That definition is specific enough that you understand what the job requires. A kettle does it. A thermos does it. A coffee machine does it. A microwave does it. Those are all competitors because they all solve the same job at the right level of abstraction.

The function comes first. The emotional layer comes second. A founder selling a status symbol product wants to start with emotion: "feel like a somebody." That is a desire, not a job. The job is "appear confident in a professional meeting." The emotion follows if you deliver the function well. Book 2 will give you the precise format for writing job definitions — for now, what matters is scoping the job at the right level so you can find where pain concentrates.

The Spectrum of Suck

Here is the diagnostic tool that makes problem selection operational.

When your customer is executing a job, that job does not happen in one step. It is a series of steps. Define the need. Locate options. Prepare a solution. Confirm the choice. Execute. Monitor the results. Modify if needed. Conclude.

For each step, problems cluster. Some steps are fine — the customer does them easily. Some steps are awful — the customer struggles, wastes time, spends money, absorbs risk. The awful steps are where opportunity lives.

Let me make this concrete. A founder building for managers who are hiring. The job is "build a team that can execute on a strategy." The steps look like this: Define what skills I need. Search for candidates. Screen resumes and profiles. Interview candidates. Make a decision. Negotiate offer. Onboard. Evaluate after three months.

Now, for each step, where is the suck concentrated?

Define what skills I need? Managers do this okay. It takes time, but they have frameworks.

Search for candidates? Fine for some roles, frustrating for others. Variable.

Screen resumes? This is where it gets bad. Managers spend hours reading resumes that tell them almost nothing about whether someone can do the job. The suck concentrates here.

Interview candidates? Moderately bad. Unreliable predictors of performance. Time-consuming.

Make a decision? Bad. Slow consensus-building, incomplete information.

Negotiate offer? Not usually the core problem.

Onboard? Suck concentrates here too. Chaotic. Unpredictable. Managers cannot tell if the hire is going to work for weeks.

Evaluate after three months? Fine. By then, you know.

So we have identified the steps where the suck concentrates: screening, interviewing, deciding, and onboarding. Four hot spots out of eight steps.

Now the question: which of these problems is worth your full weight? All four are real. All four create pain. But the strategy is not to solve all of them. The strategy is to choose which one problem aligns with your difference and is intense enough to overcome switching cost.

Here is the prompt to do this for your own customer:

You are a strategy coach. Goal: map the steps of a customer's job and
identify where pain concentrates — so the user can choose which problem
to build around.

Operating style: Ask one question at a time with an example. Start by
defining the job at the right level (not too narrow, not too broad).
Then walk through each step. For each step, assess: effort, time, money,
risk, variability, emotional frustration.

Deliverables (draft):

  Job Definition — verb + noun + contextual qualifier, at the right
  level of specificity.

  Job Steps — the full sequence of how the customer executes this job
  today (typically 6-10 steps).

  Spectrum of Suck — for each step, a pain rating (low / moderate /
  high / severe) with a 1-sentence explanation of why.

  Hot Spots — the 2-4 steps where suck concentrates most.

  Current Workarounds — for each hot spot, how the customer is dealing
  with the pain today (tools, hacks, manual effort, avoidance).

Output rules:
  Provide Draft + Critique first.
  When approved, return Final and stop.

When you finish, you should have a clear map of where pain concentrates in your customer's job. Not a vague sense that "hiring is hard." A specific understanding that screening is severe, interviewing is high, deciding is high, and onboarding is severe — while defining skills and negotiating offers are fine. That specificity is what makes problem selection possible.

Value Vectors — How Customers Measure Meaningful Difference

Before you can decide which problem is worth solving, you need to understand how your customer measures whether a solution actually matters. Most solutions fail not because the problem is wrong, but because the solution does not move the needle enough to justify switching cost.

There are four vectors that determine whether a solution creates meaningful difference:

Effort — Does it dramatically reduce the mental or physical labor required to execute the job? If screening candidates still requires hours, just slightly less, the vector is weak. But if it cuts screening from 40 hours to 5 hours per month, the effort vector is strong.

Money — Does it save or make money disproportionately? Not 5% savings. Does it deliver 30% cost reduction or create 50% additional revenue? Meaningful difference on the money vector justifies change.

Time — Does it compress time significantly? Not by 10%. By 50% or more? If your customer is losing market opportunity because hiring is slow, and you cut hiring cycle time in half, the time vector is powerful.

Risk — Does it reduce risk materially? Does a bad hire tank your team? If your solution reduces bad hire rates by half, the risk vector is strong.

The critical test: Your solution must give disproportionate value in at least one of these vectors. If you are solving 10% improvement across all four vectors, switching cost will kill you. If you are solving 60% improvement on one vector, you have a business.

When you define your problem in the Spectrum of Suck, ask: Which value vector does this problem affect most? If the pain is "screening is slow," your solution better cut time dramatically, not by 10%. If the pain is "bad hires are expensive," your solution better reduce hiring failure significantly.

This is the reality check on whether your problem choice is actually worth building around.

The Intersection of Three Things

Not every hot spot is worth building around. The problem that deserves your full weight sits at the intersection of three criteria.

Intense enough to drive behavior change. If the pain is mild, switching cost will kill you. Budget, internal alignment, training, risk — your customer has to believe the pain justifies all of that. A manager frustrated with hiring but still filling roles will not change. A manager whose hiring is delaying the product roadmap and losing market opportunity? That is intense enough.

Specific enough that you can actually solve it. If the problem is vague, your offer will be vague. "Screening candidates is taking managers hours per week and revealing nothing about job performance" is specific — you can measure it. "Make hiring better" is not. Anyone can claim that.

Aligned with your difference. The problem worth building around has to sit where your capabilities give you an unfair advantage in solving it.

If you are a founder who understands data and you can build a model that screens candidates better than a human, your problem might be "screening takes forever and tells you nothing." If you are a founder who understands team dynamics and has a method for predicting interview performance, your problem might be "interviews are unreliable predictors." If you are a founder who understands process, your problem might be "deciding between candidates is slow and consensus-driven."

All three could be right. The question is which problem, when solved by you with your difference, becomes worth the switching cost.

The Four Questions Pitch — Testing Your Problem Definition

There is a sharp way to test whether your problem definition is actually specific enough and whether your solution creates meaningful difference. It is the Four Questions Pitch framework.

This is not how you will eventually pitch your solution to customers — that comes in Book 2. This is how you test your problem choice before you spend months building.

Question 1: What does it increase? Your solution must increase something the customer values. Productivity. Revenue. Quality. Predictability. Confidence. Be specific. Not "efficiency" — that is vague. "Time spent on revenue-generating work" is specific.

Question 2: What does it decrease? Your solution must decrease a concrete cost or pain. Hours per month. Error rate. Churn. Risk. Again, be specific. Not "frustration" — measurable decrease.

Question 3: What do they currently use? You need to name the status quo. What is the customer using today to solve this problem? Spreadsheets? Recruiting agencies? Manual process? Gut feel? Be honest about what you are competing against. Remember: you are not competing against other vendors. You are competing against the current way.

Question 4: What is the negative of that current approach, and what do you do without that downside? This is the key question. Every current approach has downsides. Recruiting agencies are expensive. Spreadsheets are error-prone. Gut feel is unreliable. Manual processes are slow.

Your solution removes one or more of these downsides without introducing new ones. You deliver the benefits of the current approach (it works well enough) without the downsides (it is expensive / slow / unreliable / manual).

When you can answer all four questions clearly and specifically, you have defined a problem worth building around. If you cannot answer them, or if your answers are vague, you have not yet sharpened your problem enough.

There is also a fifth layer that makes this pitch move from logic to belief:

The Zeitgeist Layer (Optional but Powerful): Connect your pitch to a broader macro inevitability so that your solution is not just "better," but "where the world is going."

Example: "We used to hire based on resume reviews and gut feel (current approach). But the market has shifted — companies are competing on speed, and traditional hiring is too slow. We deliver fast hiring without the downsides of speed (reckless decisions). This is not just better. It is where hiring is heading."

The zeitgeist layer transforms a pitch from "this solves a problem" to "this aligns with where the market is moving."

Non-Consumption Is the Real Competitor

Here is the hardest part: the problem worth building around has to be painful enough that it forces behavior change. Non-consumption — the decision to do nothing different— is the real competitor.

I know a founder selling into customer success teams. CS leaders feel constant pressure to reduce churn, but they are drowning in reactive work — fighting fires, dealing with angry customers, struggling to find time for proactive work. The pain is real. But many do not change because they believe the fires will settle, or that hiring more people will solve the problem.

The founder had to find the subset whose pain was acute — churn spiking, customers leaving publicly, credibility in question. Those are the customers where switching cost is justified because the current way is obviously failing. Your job is to find the specific customer, in the specific circumstance, where the problem is intense enough to drive change.

Problem Selection and the Idealized Solution

Once you have your Spectrum of Suck and you understand the three-criteria intersection, you can make the choice. And once you name the problem worth building around, you can imagine the perfect solution to it. Not your actual product yet. The idealized solution — the one that is impossible to say no to.

This is the bridge from strategy to offer design. This is where Book 1 hands off to Book 2.

For the founder selling into customer success, the idealized solution is: a system that takes the reactive fire-fighting and transforms it into structured, scalable, proactive work that prevents churn before it happens. Customers stop leaving. Time is freed up. Leadership gets evidence of proactive work. No overhead. No complexity. Pure value.

That idealized solution is probably not what you will build. Your actual product will require compromise. But the idealized solution is the north star — the measure of how good your actual offer needs to be. It is also how you test your problem definition: if you cannot imagine a clear idealized solution, the problem is not specific enough. If the idealized solution is too complex, the problem is too broad.

Here is the prompt to work through problem selection and arrive at both the chosen problem and the idealized solution:

You are a strategy coach. Goal: help the user choose the ONE problem
worth building their company around, and define the idealized solution
that becomes the north star for offer design.

Operating style: Ask one question at a time with an example. Force the
user to choose — do not let them keep multiple problems alive. Push on
switching cost: is the pain intense enough that the customer will
actually change behavior?

Inputs needed (ask for these):
  The customer avatar (from Chapter 5)
  The Spectrum of Suck output (from this chapter's first prompt)
  The user's key capabilities and difference (from Chapter 3)

Deliverables (draft):

  Problem Worth Building Around — one sentence. The specific pain, for
  the specific customer, in the specific circumstance where it is acute.

  Three-Criteria Check:
    Intensity — why this pain is severe enough to overcome switching cost
    Specificity — how you will know if you solved it (measurable)
    Alignment — why your difference gives you an unfair advantage here

  Rejected Problems — the other hot spots you are NOT choosing, with a
  1-sentence reason for each rejection.

  Idealized Solution — 2-3 sentences describing the perfect solution
  to this problem. No compromises. No constraints. The version that is
  impossible to say no to.

  Reality Bridge — 1-2 sentences on the gap between the idealized
  solution and what you can realistically build first.

Output rules:
  Provide Draft + Critique first.
  When approved, return Final and stop.

When you come out the other side, you should have one problem statement, a clear reason why it passes all three criteria, a list of problems you are deliberately ignoring, and an idealized solution that becomes the north star for everything you build in Book 2.

The rejected problems matter. Writing them down is what makes the choice real. If you cannot name what you are saying no to, you have not actually chosen.

From Strategy to Offer

You have now completed the strategic work of Book 1. Along the way, you have built a set of strategic artifacts:

• Aspiration and Playing Field (Chapter 3) — where you will and will not compete
• How We Win and Capabilities (Chapter 3) — your theory of winning and what must be true
• Truth Statements and Market Positioning (Chapter 3) — your honest assessment and competitive frame
• Purpose Statement (Chapter 4) — why you exist and for whom
• Target Segments and Customer Avatar (Chapter 5) — who you serve and how to qualify them fast
• Spectrum of Suck and Problem Selection (Chapter 6) — where pain concentrates and the one problem worth your full weight
• Idealized Solution (Chapter 6) — the north star for offer design

These are not decorations. They are decision filters. Every question you face from here — what to build, what to charge, what to say, who to hire — gets tested against these artifacts.

Now you are ready to build an offer. Not a feature list. A promise of progress on the specific job your specific customer is trying to do, built around the one problem worth solving so well that the status quo becomes unacceptable. That is what Book 2 explores.

Chapter Takeaways

• Not every pain is a business. The strategic act is choosing which problem deserves your full weight.
• The job already exists. Your real competitor is the current way your customer does the job — the status quo — not another vendor.
• Distinguish between the job executor (who does the work) and the job buyer (who approves the investment). Your offer must create value for both.
• Define the job at the right level: specific enough to shape your offer, general enough that you understand the real competition.
• The Spectrum of Suck diagnostic maps each step of the job and identifies where pain concentrates. Use the prompt to do this systematically.
• Value vectors determine meaningful difference: Effort, Money, Time, Risk. Your solution must move the needle disproportionately on at least one vector.
• Test your problem definition using the Four Questions Pitch: What does it increase? What does it decrease? What do they currently use? What is the negative of that, and what do you do without that downside? Add the Zeitgeist Layer for power.
• The problem worth building around sits at the intersection of three things: intense enough to overcome switching cost, specific enough to solve and measure, and aligned with your difference.
• Non-consumption — the decision to do nothing — is the real competitor. Your problem has to be painful enough to break through that inertia.
• The idealized solution is your north star. If you cannot imagine a clear one, your problem is not specific enough.
• Use the Problem Selection prompt to force the choice, document what you are rejecting, and define the idealized solution that bridges to Book 2.