Chapter 3: Bundle the Offer

You have scored your solutions and you know which ones to build first. Now you need to turn those solutions into things a customer can actually buy.

This is where most founders make the packaging mistake. They take their best solution and ship it as a single, undifferentiated product. One tier. One price. Take it or leave it. The problem is not that the product is bad. The problem is that the packaging does not match how buyers actually make decisions. Different buyers have different budgets, different risk tolerances, different levels of commitment. A single-tier offer forces every buyer through the same door, and most of them will not fit.

The fix is deliberate bundling. You take your scored solutions, translate them into concrete deliverables, and package those deliverables into bundles that serve different buyer profiles — from the budget-conscious first step to the premium all-in commitment.

Solutions Are Not Deliverables

The solutions from Chapter 3 are design targets. They describe what changes for the customer. Deliverables are the concrete outputs that make the change happen — the things the customer receives, reviews, implements, or uses.

The distinction matters because buyers do not buy solutions. They buy things. A solution is "reduce screening time from 4 hours to 30 minutes per role." A deliverable is "a custom scoring model calibrated to your open roles, delivered in a shared workspace, with a 30-minute walkthrough session." The solution tells them what changes. The deliverable tells them what they get.

Every deliverable needs three properties to be real. First, it must be tangible — a thing, not an activity. "Consulting" is not a deliverable. "A documented go-to-market playbook with target account list, messaging templates, and a 90-day execution calendar" is a deliverable. Second, it must have acceptance criteria — how the customer knows it is done and whether it is good. Third, it must have a realistic time to deliver.

When you translate solutions into deliverables, the offer starts to feel concrete. The customer can see what they are buying. They can evaluate whether the deliverables will actually solve the problem. They can compare your offer to alternatives because the deliverables give them something to hold.

Here is the prompt:

You are a strategy coach. Goal: define deliverables — concrete outputs
that implement the top-scored solutions — in a way the customer
understands and will pay for.

Operating style: Ask one question at a time with an example.
Deliverables must be tangible ("a thing"), not activities ("consulting",
"calls"). Include acceptance criteria (how we know it is done).

Deliverable (draft):

  Deliverables:
  Deliverable: [name]
    What it is: [concrete description]
    Which solution it implements: [from Ch 3 scoring]
    Acceptance criteria: [how the customer knows it is done and good]
    Time to deliver: [realistic estimate]

  (repeat for all deliverables)

  Critique + Simplifications:
  [what is redundant, what can be combined, what is missing]

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

Solution Categories

Before you bundle, it helps to categorize your deliverables. There are three categories that most offers break into.

Core deliverables solve the primary problem — the one you scored highest in Chapter 3. These are non-negotiable. Without them, the offer does not deliver on the promise of progress from Chapter 1. If you remove a core deliverable, the customer cannot get the outcome.

Enabling deliverables make the core work better or faster. Training, onboarding, templates, integrations. They are not the outcome itself but they reduce friction in getting to the outcome. Enabling deliverables are what separate a good offer from a mediocre one — they reduce the whiskers from Chapter 1.

Expansion deliverables solve adjacent problems — the ones that scored well in Chapter 3 but did not make the "build first" cut. These are the upsell. They are valuable, but the customer does not need them to get the primary outcome.

Categorizing your deliverables this way makes bundling straightforward. The starter bundle gets core only. The main bundle gets core plus enabling. The premium bundle gets everything.

Bundling Into Products

Now you package the deliverables into bundles — discrete products the customer can evaluate and buy. The simplest structure is three tiers.

Starter (downsell): The minimum viable version. Core deliverables only. Lower price. Lower commitment. This is for the buyer who is interested but not yet ready to go all-in — the one who needs a first win before committing further. The starter should be scoped so the customer can get a meaningful result fast and decide whether to upgrade.

Core (main offer): The full solution. Core plus enabling deliverables. This is the product you want most buyers to purchase. It delivers the complete promise of progress. Price it at the value of the outcome, not at the cost of delivery.

Premium (upsell): Everything. Core, enabling, and expansion deliverables. This is for the buyer who wants the full transformation — the one who has budget, urgency, and the organizational commitment to go deep. The premium should feel like the obvious choice for someone who is serious.

The three-tier structure works because it gives the buyer a choice that is not yes-or-no. The buyer's decision shifts from "should I buy this?" to "which version should I buy?" — and that is a much easier decision to make.

Here is the prompt:

You are a strategy coach. Goal: bundle deliverables into productized
offers — clear packages with scope, who it is for, what is included
and excluded, timeline, and a price placeholder.

Operating style: Ask one question at a time with an example. Bias
toward 1 primary product + 1 upsell + 1 downsell (keep it simple).

Deliverable (draft):

  Product Bundles:

  Starter (downsell):
    Who it is for: [buyer profile]
    What is included: [deliverables]
    What is excluded: [what they do not get]
    Timeline: [how long]
    Price placeholder: [range or anchor]

  Core (main offer):
    Who it is for:
    What is included:
    What is excluded:
    Timeline:
    Price placeholder:

  Premium (upsell):
    Who it is for:
    What is included:
    What is excluded:
    Timeline:
    Price placeholder:

  Critique + Scope Control:
  [is the starter too thin? is the premium too bloated? does the core
   deliver the full promise?]

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

Bundling in Practice: Real Examples

Case Study 1: How Stripe Got Bundling Right

Stripe is a payments platform. Their primary promise is "accept payments from anyone, anywhere." From the perspective of a developer building a SaaS product, Stripe's job is: "I need to add payments to my product without rewriting payment infrastructure from scratch."

Stripe's bundled approach:

Core: Payment processing API (process cards, handle failures, return success/failure signals). Acceptance criteria: accept a credit card, charge it, get a response. Stripe built this first because it solves the fundamental job.

Enabling: Webhooks (real-time notifications of payment status changes). Documentation. SDKs in 10 languages. Test mode. Stripe Dashboard for visibility. These reduce friction — the developer doesn't have to poll the API or write their own notification system.

Expansion: Billing (recurring charges, subscription management). Reporting. Fraud tools. Payouts to connected accounts. These solve adjacent problems (a SaaS business doesn't just need to charge; it needs to manage subscriptions, revenue, and the money moving out). But they're not required to accept a payment.

The bundles:

• Starter (payment processing): API + basic dashboard + documentation. A developer can go live immediately. Cost: per-transaction fee only.
• Core (full payments): API + webhooks + SDKs + webhooks + test mode + basic dashboard. A production SaaS company. Cost: per-transaction fee + monthly platform fee.
• Premium (platform): Everything above plus billing, recurring charges, fraud tools, payouts, reporting, phone support. A company that wants Stripe to be their entire payments infrastructure. Cost: per-transaction fee + monthly platform fee + premium support.

Why this works: A solo developer and a Series B SaaS company have different needs. A solo developer can ship with just the API. The Series B company upgrades to billing and fraud tools because they need to manage subscriptions and revenue. Neither is paying for features they won't use. Each bundle matches a real customer need at a real stage of business.

What went wrong: Early Stripe competitors (SimpleCharge, others) bundled differently. They included "recurring charges" in the base offering. This created friction for single-transaction use cases (higher pricing for features not needed) and didn't provide an upgrade path. Stripe won because their bundling matched how business actually scales.

Case Study 2: How a Recruiting Agency Got Bundling Wrong

A boutique recruiting agency served B2B SaaS companies. Their promise: "Find the right engineering talent in 2 weeks instead of 3 months."

Their single-tier offering included:

• Sourcing (hunting candidates)
• Screening (phone interviews)
• Interviewing (technical assessment)
• Reference checks
• Offer negotiation support
• Onboarding support

They bundled everything into one package at a single price ($25K per placement).

The problem: Not all hiring managers needed all of this. Early-stage founders often had a CTO who did technical screening themselves — they just needed sourcing and reference checks. Series B companies had a full hiring team — they wanted screening, tech interviews, and everything else. Mid-market companies had different needs entirely.

By bundling everything, the agency:

1. Priced out the founders (who didn't need full service)
2. Couldn't upsell (the offer was already complete)
3. Built service for customers who didn't need it (expensive delivery, unhappy customers when the value didn't match the price)

What they should have done:

Starter (sourcing + reference checks only): For founders with in-house technical interviewing. $8K per placement. Solves: "Find the right person; I'll interview them."

Core (sourcing + screening + technical interview): For growth-stage companies without a full hiring infrastructure. $18K per placement. Solves: "Give me a pre-vetted candidate ready to talk to leadership."

Premium (everything, including offer negotiation and onboarding support): For companies that want to hand off the entire hiring process. $28K per placement. Solves: "We have a role; you give us a person who says yes and is ready to start."

Why this works: Different founders and companies in different stages have different hiring maturity. By bundling appropriately, the agency could serve all three markets instead of only the ones who needed full service.

What Went Right and Wrong

In both cases, bundling worked when it matched reality:

Stripe got it right because:

• Each bundle solved a real stage of business maturity
• The starter tier could deliver a meaningful outcome (process a payment)
• The premium tier offered genuine expansion value (billing, fraud)
• Each tier had a price that matched its value

The recruiting agency got it wrong because:

• They assumed all customers had the same job
• They bundled based on their capabilities, not customer need
• They had no upgrade path from starter to premium
• Different customer types (founders vs. Series B) needed fundamentally different offers

The Discipline of Exclusion

Bundling is an exercise in exclusion as much as inclusion. The starter bundle works because of what is excluded — it forces the customer to upgrade if they want the full outcome. The core bundle works because the expansion deliverables are excluded — it stays focused on the primary promise. The premium works because it includes everything, which justifies the higher price.

The most common mistake in bundling is making the starter too generous. If the starter delivers the full outcome, there is no reason to upgrade. The second most common mistake is making the premium too bloated — stuffing it with deliverables the customer did not ask for to justify a higher price. Both mistakes come from the same instinct: the fear of saying no.

You already practiced this discipline in Book 1 when you chose one problem over all the others. The same applies here. Each bundle is a choice. Each choice excludes something. That exclusion is what makes the offer clear.

What You Have When You Are Done

After this chapter, your offer has shape. You have:

• Deliverables — concrete things the customer receives, with acceptance criteria and timelines
• Categories — core, enabling, and expansion, so you know what goes in each tier
• Three bundles — starter, core, and premium, each with clear scope, audience, and price anchors

This is not a feature list. It is a packaged commitment. The customer can look at any bundle and understand: what they get, what changes, how long it takes, and what it costs.

The next chapter takes these bundles and prices them — not based on cost, but based on the value of the outcome.

Chapter Takeaways

• Solutions are design targets. Deliverables are what the customer actually buys — tangible things with acceptance criteria and timelines.
• Every deliverable must be tangible, have acceptance criteria, and have a realistic delivery time.
• Three categories: core (solves the primary problem), enabling (reduces friction), expansion (solves adjacent problems).
• Bundle into three tiers: starter (core only, fast first win), main (core + enabling, full promise), premium (everything).
• Three-tier structure shifts the buyer's decision from "should I buy?" to "which version?" — a much easier decision.
• The discipline of exclusion applies to bundling just like it applies to strategy. Each bundle is a choice.