Chapter 1: Define the Job and Design the Solution

Book 1 ended with a strategy. You know your customer. You have named the problem worth building around. But you do not have a product — not yet. You have a concept, maybe some feature capabilities, maybe something partially built. That is fine. You do not have a product until a customer tells you it is a product by being willing to pay for it.

Before you can build an offer — before you can promise progress — you need to define the work the customer is actually doing. The job they are trying to get done. Map the steps they take. Find where the friction lives. Design solutions to that friction. The offer comes after this — it is a promise of progress against these jobs. Get the jobs wrong and everything downstream is guesswork.

Every founder can tell you what they are building. Very few can tell you what job their customer is trying to get done — properly scoped, from the customer's perspective, at the right level of abstraction.

The job is the unit of design for everything else in this book. Get it wrong and you will design an offer around the wrong problem, price it against the wrong competitors, and message it in a way that attracts the wrong buyers. Get it right and every subsequent decision gets easier.

What a Job Actually Is

In the strategy phase, you identified your customer's job and used the Spectrum of Suck to find where pain concentrates. Now you need to define it with the precision that offer design requires.

A job is the functional activity your customer performs in pursuit of a goal. Not features they wish your product had. Not outcomes they aspire to. The concrete, observable work they are doing today, from their perspective, given their constraints and situation.

Two properties matter most for offer design. First, jobs are functional first — keep the emotional and social dimensions separate. "Cut a piece of wood in a straight line" is the job. "Quickly and accurately" are outcomes. "Feel like a craftsman" is emotional. Mix them and you lose precision. Second, jobs never come in isolation — when you define your job, you are also defining the related jobs you are explicitly not building around. Niche the job the same way you niched the customer.

The Job Definition Format

A job has a specific format: verb + noun + optional contextual qualifier.

"Listen to music while on the go." "Prepare a hot beverage for consumption." "Move work forward while staying coordinated across a distributed team." "Qualify inbound leads before passing to an account executive."

The qualifier matters when context changes the nature of the job. "Listen to music" and "listen to music while on the go" are different jobs because the constraints are different — pocket size, wireless reliability, battery life, one-handed operation.

Before you draft the job definition, answer three questions. Whose job is it — specifically, which role, in which situation? What triggers them to start? What does done look like? The trigger and the done condition bound the job. Everything between them is the job.

Mapping the Job Steps

Once you have the situation, constraints, and job definition, you map the steps. This is where offer design gets specific.

Every job follows a standard progression: define, locate, prepare, confirm, execute, monitor, modify, conclude. Not every job hits every stage with equal intensity, but the framework gives you a scaffold. For each step, you are building a picture of what the customer actually does: what information they need, what tools they use, what decisions they face, how much time it takes.

This is fieldwork. You are trying to understand the job the way a good engineer understands the system they are about to replace. You need to know which steps people hate, which steps they skip, which steps produce the most variation in outcomes. Because those are the places where your offer can create the most credible promise of progress.

Here is the prompt to map the steps:

You are a strategy coach. Goal: define the Job Steps — the sequence of
actions the customer takes to execute the job they need done.

Operating style: Ask one question at a time with an example. Keep steps
observable (verbs), not vague outcomes. Capture what they do today, even
if it is messy.

Deliverable (draft):

  Job Steps:
  Step 1: [verb + what they do]
    - Resources needed:
    - Output of this step:
    - Tools used:
    - Decisions made:
    - Time required:
    - Effort required:

  Step 2: ...
  (continue for all steps, typically 6-10)

  Critique + Simplifications:
  [what is redundant, missing, or out of order]

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

When you finish, you should have a job definition and a full Job Steps map that shows you exactly how the customer does the work today. This is the raw material for designing the idealized solution in the section below.

The Job Is Not About You

There is a failure mode that deserves its own section: defining the job in a way that describes what your product does rather than what the customer is trying to accomplish.

A founder builds a reporting automation tool and defines the customer's job as "automate their reporting workflows." That is not a job. That is a feature description dressed up as a job statement. The actual job might be "give leadership visibility into deal progress without requiring the sales team to manually update CRM records." When you define the job correctly, you immediately see competitors you had not considered — the VP of Sales who calls a Monday stand-up, the shared Google Sheet someone built eighteen months ago that is technically broken but everyone still uses. Those are the status quo. That is what you are actually competing against.

Getting the job right also prevents you from building a solution to a problem no one is actively trying to solve. Never create the role. The job has to be pre-existing and acknowledged. When you try to get someone to do something new — create a role, add a responsibility, take on a new process — the sale almost never happens. There is too much to do already. What you need is a job they are already doing, already frustrated by, and already motivated to do better.

From Job Definition to Idealized Solution

You now have a job definition and job steps. The next move is design: mapping the problems your customer faces at each step, and designing solutions for the most critical ones. That is the work of the idealized solution — the version of solving this job that would be impossible to say no to.

Designing the Idealized Solution

Now you need to figure out where the customer is struggling and what "solved" looks like.

This is where most founders make their first design mistake. They jump from the job to the product. They skip the step where you map the problems in granular detail, imagine the perfect solution unconstrained, and then score those solutions against what the customer actually values. The result is a product shaped by what the founder can build rather than what the customer needs solved.

This section walks through three moves: surface the problems at each job step, design the idealized solution for the ones that matter, and score them so you know what to build first.

Problems Live Inside the Steps

In Book 1 Chapter 6, you used the Spectrum of Suck to find where pain concentrates. That was strategic — it helped you choose which problem to build the company around. Now you go operational. You are not choosing a problem anymore. You are cataloging the problems inside the job you already chose, at each step, so you can design solutions for the worst ones.

For each job step from Chapter 2, you want to identify the specific problems your customer faces. Not generic pain — specific friction. How much time does this step waste? How much effort does it require? What is the risk of a bad outcome? What anxieties does it trigger? What habits or inertia make it hard to change?

Three problems per step is the right depth. Fewer and you are not being honest about the friction. More and you are mapping noise.

A concrete example. If the job step is "screen resumes and profiles," the three problems might be: (1) takes 3-4 hours per role per week reviewing applications that tell you almost nothing about job performance (time), (2) no reliable way to distinguish between someone who can do the job and someone who can write a resume (risk), (3) managers defer to gut feel and end up with inconsistent evaluation criteria across the team (variability).

Each of those is specific, tied to the step, and points toward a solvable problem. That is the level of detail you need.

Here is the prompt:

You are a strategy coach. Goal: define the Job Problems — where
customers struggle inside each job step — so we can design solutions
that remove friction.

Operating style: Ask one question at a time with an example. Tie each
problem to a specific step from the Job Steps output. Rank by pain +
frequency + cost of failure.

Deliverable (draft):

  Job Problems (Ranked):
  Problem: [specific friction]
    Step: [which job step]
    Impact: [what happens when this goes wrong]
    Frequency: [how often]
    Cost of failure: [what it costs in time/money/risk]

  (repeat for top 10-15 problems across all steps)

  Critique + Where We Can Win Fast:
  [which problems are most solvable given our capabilities]

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

When you finish, you will have a ranked list of specific problems tied to specific steps. This is your design brief. Not a vague sense that "hiring is hard" — a precise understanding that screening wastes 3-4 hours per role, evaluation criteria are inconsistent, and the risk of a bad hire concentrates at the decision step.

From Problems to Idealized Solutions

Now comes the design move. In Book 1 Chapter 6, you imagined the idealized solution as a north star — the version that would be impossible to say no to. Here you build it for real. For each of the top problems, you ask: what does perfect look like?

Not what you can build today. Not what your technology supports. Perfect. If this problem were solved completely, what would the customer's world look like?

This is not a product spec. It is a design target. The idealized solution defines the requirements (what must be true for the problem to be solved), the outcome (what changes for the customer), and what the customer values about that change.

The distinction between requirements and features matters here. A requirement is "the manager can evaluate a candidate's ability to do the job in under 10 minutes." A feature is "AI-powered skills assessment." The requirement is on the customer's side. The feature is on yours. Design to requirements first. Features follow.

This is also where you define customer value explicitly. The Growmance framework breaks value into four dimensions: the result achieved, the perceived likelihood of achievement, the time delay to getting the result, and the effort and sacrifice required. Your idealized solution should maximize the first two and minimize the second two. When you can articulate the value in these terms — "this solution delivers X result with Y likelihood in Z time requiring W effort" — you have a clear design target.

Here is the prompt:

You are a strategy coach. Goal: turn the top Job Problems into Ideal
Solutions — what "perfect" looks like — expressed as solution
requirements and outcomes the customer values.

Operating style: Ask one question at a time with an example. Do not
jump to features too early. Define the requirement and the value first.

Deliverable (draft):

  Ideal Solutions (for Top Problems):
  Problem: [from Job Problems output]
    Ideal outcome: [what the customer's world looks like if solved]
    Requirements (must be true): [what has to happen]
    What the customer values here: [result, likelihood, time, effort]

  (repeat for top 5-8 problems)

  Critique + Tightening Suggestions:
  [which solutions are redundant, which can be combined, which are
   unrealistic even as ideals]

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

Scoring: What to Build First

You will have more ideal solutions than you can build. That is the point — the idealized solution is expansive by design. Now you need to cut.

Scoring forces the prioritization. For each ideal solution, you evaluate it on six dimensions:

Willingness to pay — will the customer actually spend money on solving this? Some problems are real but not worth paying for. Others are so acute that the customer would pay before you finish the sentence.

Urgency — is this a "someday" problem or a "this quarter" problem? Urgency determines whether the customer will act now or put you in a future pipeline that never closes.

Frequency — how often does the customer encounter this problem? A problem that happens once a year is less valuable than one that happens every week, even if the annual one is more painful.

Cost of failure — what happens when the problem goes unsolved? If the cost is low, switching cost will kill you. If the cost is high — missed deadlines, lost deals, compliance risk, team churn — you have leverage.

Competitive differentiation — can you solve this in a way the status quo cannot match? If every competitor can solve the same problem the same way, solving it earns you no advantage.

Time to deliver — how quickly can you deliver a solution? Faster is better. A solution you can ship in 30 days beats a superior solution that takes six months, because the first one proves the promise while the second one tests the buyer's patience.

Score each dimension 1-5. The highest-scoring solutions are what you build and sell first. The rest goes on the roadmap or gets cut entirely.

Here is the prompt:

You are a strategy coach. Goal: score the Ideal Solutions by customer
value so we know what to build and sell first.

Operating style: Ask one question at a time with an example. Keep
scoring simple and comparable across solutions.

Scoring rubric (1-5 for each):
  Willingness to pay
  Urgency
  Frequency
  Cost of failure
  Competitive differentiation
  Time to deliver (lower time = higher score)

Deliverable (draft):

  Solution Scores:
  Solution: [name]
    Scores: [WTP: _, Urgency: _, Freq: _, CoF: _, Diff: _, TTD: _]
    Total: [sum]
    Notes: [why this scored the way it did]

  (repeat for all ideal solutions)

  Recommendation:
    Build/sell first: [top 2-3 solutions]
    Defer: [the rest, with 1-sentence reason each]

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

The scoring is not science. It is structured judgment. The value is in forcing the comparison — holding your solutions side by side and asking which one earns its place in the offer versus which one is interesting but not urgent, or useful but not differentiated.

The solutions you defer are not dead. They are the roadmap. But they do not go in the first offer. The first offer must be focused enough that the customer can understand it in one conversation and believe you can deliver it in a realistic timeframe.

The Design Discipline

Here is the thread that runs through this chapter: design the offer from the customer's problems, not from your product's capabilities.

When you start from problems, the offer is shaped by what the customer needs. When you start from capabilities, the offer is shaped by what you happen to have built. The first approach produces something the market pulls toward. The second produces something you have to push.

The idealized solution is the design target — the version that would be impossible to say no to. The scoring tells you which piece of that ideal to build first. The gap between the ideal and what you actually ship is your roadmap. That gap is not a failure. It is a strategy.

The next chapter takes the scored solutions and turns them into concrete deliverables and bundles — the things the customer actually buys.

Chapter Takeaways

• The job is the unit of design for the entire offer. Get it wrong and everything downstream is off.
• Jobs are defined by the customer's perspective, not the product's capabilities.
• Jobs are stable over time. Build around the stable thing.
• Job format: verb + noun + optional contextual qualifier. Define at the level where outcomes are meaningful.
• Jobs have steps. Map them to understand the full sequence of how the customer does the work today.
• Never create the role. The job must be pre-existing and acknowledged.
• Problems live inside job steps. Map three specific problems per step: time, effort, risk, anxiety, variability.
• Rank problems by pain, frequency, and cost of failure. The worst ones become your design brief.
• The idealized solution defines what "perfect" looks like — unconstrained. Design to requirements, not features.
• Customer value has four dimensions: result achieved, likelihood of success, time to result, effort required. Maximize the first two, minimize the second two.
• Score solutions on six dimensions to decide what to build first: willingness to pay, urgency, frequency, cost of failure, differentiation, time to deliver.
• The first offer must be focused enough to explain in one conversation and deliver in a realistic timeframe.
• The gap between the idealized solution and what you ship is your roadmap, not a failure.