hormozi-offer-builder

name

hormozi-offer-builder

description

Use Hormozi's grand slam offer framework as a product discovery and scoping engine for software and SaaS ideas. Run this skill whenever a user wants to find a validated app idea, discover a starving crowd for software, define what to build, scope product features using obstacle mapping, design pricing tiers, or position a SaaS product. Trigger on: "help me find an app idea", "what software should I build", "find me a starving crowd for an app", "validate my SaaS idea", "what features should I build", "how should I price my app", "Hormozi for software", "grand slam offer for SaaS", or any time someone wants to go from a vague niche interest to a research-grounded, scoped product with pricing. The final output is a Product Brief ready to feed directly into the mvp-strategist or project-scaffold skills. Always run Step 0 first — never build on assumptions.

Hormozi Offer Framework → Software Product Discovery

This skill runs Hormozi's 6-rule grand slam offer framework as a product discovery and scoping pipeline for software. Instead of ending with a coaching offer, it ends with: a validated ICP, a core product promise, a feature set derived from real obstacles, a pricing model, and a launch guarantee — all grounded in market research.

Each step feeds the next. At the end you have a Product Brief ready for the mvp-strategist skill.

---

Before Starting

Ask the user for two things:

1. The rough space — what niche, problem area, or type of person interests them
2. Any early hypothesis — do they have a product idea already, or are they exploring?

If they have nothing, that's fine — Step 0 is designed to surface the opportunity.

---

Step 0 — Market Research Sprint

Mine real pain before touching a single line of product thinking.

This is the most important step. Everything that follows is only as good as the evidence gathered here. Run all four passes using web_search and web_fetch.

Pass 1: Pain language mining

Search Reddit, forums, and communities where the target audience hangs out. Use queries like:

• site:reddit.com "[niche] frustrated with"
• site:reddit.com "[niche] I wish there was an app"
• site:reddit.com "[niche] does anyone else struggle"
• site:reddit.com "[niche] manually doing"
• site:reddit.com "[niche] spreadsheet workaround"

The "spreadsheet workaround" and "manually doing" searches are gold for software — they reveal where people are doing painful manual work that a product could automate. Fetch threads and extract verbatim quotes.

Pass 2: Existing software review mining

Find 2–4 apps, tools, or SaaS products already serving this space (even adjacent ones). For each:

• Search for their negative reviews on Reddit, G2, Capterra, or Product Hunt
• Look specifically for "I switched from X because...", "X doesn't let me...", "X is too expensive for...", "I wish X could..."
• Note feature gaps, price complaints, and workflow breaks

These gaps are your product opportunity.

Pass 3: Workaround mapping

Software opportunities live where people build DIY solutions. Search for:

• site:reddit.com "[niche] Notion template"
• site:reddit.com "[niche] Airtable"
• site:reddit.com "[niche] Google Sheets"
• "[niche]" "I use Zapier to" or "I built a script to"

Every workaround is a feature request in disguise. Someone building a custom Airtable base to solve a problem is a validated signal that a purpose-built tool has a market.

Pass 4: Willingness-to-pay for software

Find evidence this audience buys software:

• What tools do they mention paying for?
• Any complaints about pricing tiers?
• "Is there a cheaper alternative to X" threads?
• What are the price ceilings in this category?

Research output format

After all four passes, produce a Market Research Brief:

Pain signals — 10+ verbatim quotes, each with source and URL. Tag each as:

• [MANUAL] — they're doing something manually a tool could automate
• [GAP] — existing software is failing them on something specific
• [WORKAROUND] — they built a DIY solution because nothing exists
• [WTP] — evidence of spending money on tools in this space

Recurring pattern — 2–3 sentences. What is the workflow breakdown everyone keeps describing differently but meaning the same thing?

Software gap — what are existing tools getting wrong? Where is the opening?

Workaround map — list every DIY workaround found (Sheets, Notion, Zapier, scripts, manual processes). Each is a potential feature.

Price ceiling — what does the evidence suggest this audience will pay for software? Cheapest tool, most expensive, billing model (per seat, per month, per use).

Language harvest — 15–20 exact phrases from real people. These become your product copy, landing page headline, and positioning.

Save as RESEARCH_BRIEF.

---

Step 1 — Define the Starving Crowd (ICP)

Hormozi Rule 1: Stop selling to everyone. Find your starving crowd. For software: the user who is in the most pain and will pay to stop doing it manually.

Using RESEARCH_BRIEF, define the Ideal Customer Profile.

Ask the user to confirm or sharpen:

1. Which sub-group from the research is in the most acute pain?
2. Can they afford software? (Freelancer, small business, SMB, enterprise?)
3. Where do they hang out? (Which platforms were most active in research?)
4. Is this problem growing? (Regulatory changes, market trends, new workflows?)

Produce:

ICP statement — one sentence:

"[Job title or type] at [company size/context] who currently [manual workaround from research], spending [time/money estimate] on something that should take minutes."

Use exact language from the Language Harvest. If a word didn't appear in research, question whether it belongs.

ICP score — rate 1–10:

• Pain intensity: [score + evidence]
• Budget for software: [score + evidence]
• Reachability: [score + where they gather]
• Market growth: [score + tailwinds]

Why this ICP — 2–3 sentences. Why this is the right crowd to build for, grounded in what the research actually showed — not intuition.

Save as ICP.

---

Step 2 — Define the Core Product Promise

Hormozi Rule 2: Nobody buys a gym membership. They buy the body. For software: nobody buys a SaaS subscription. They buy the outcome it delivers.

Using ICP + RESEARCH_BRIEF, define what the product actually delivers.

1. The transformation — one sentence. What does their workflow look like after they use this? Before/after framing. Pull from the research — what did people say they wished their situation looked like?

2. The time/effort saved — be specific. "Goes from 4 hours to 15 minutes" beats "saves time". Look for any time/effort signals in the research.

3. The status shift — how does this change how they're perceived professionally? Does it make them look more competent, more organised, more professional?

4. The emotional relief — what stops keeping them up at night? Use exact emotional language from pain signals.

Then write:

Core product promise — 1–2 sentences that could be the hero headline on a landing page. This is the emotional contract the product makes with the user.

Product positioning line — complete this sentence:

"[Product name] is the only [category] that [differentiator], so [ICP] can [dream outcome] without [biggest frustration from research]."

Save as PRODUCT_PROMISE.

---

Step 3 — Obstacle-to-Feature Mapping

Hormozi Rule 3: The more problems you solve, the more your offer is worth. For software: every obstacle is a feature. Map them all before scoping anything.

Using ICP + PRODUCT_PROMISE + RESEARCH_BRIEF, list every obstacle between the user and their outcome. This becomes the product's feature universe.

For each obstacle, map across 4 dimensions AND name the potential software feature:

#	[R/I]	Obstacle	Friction level	Frequency	Value if solved	Potential feature

• [R] = directly from research. [I] = inferred. Target: 10+ [R] tagged.
• Friction level: how painful is this obstacle on a scale of Low/Medium/High?
• Frequency: Daily / Weekly / Per project / Occasional
• Value if solved: what is removing this obstacle worth to the user?
• Potential feature: name the software feature that eliminates this obstacle

Aim for at least 15 obstacles.

After the table:

Top 5 deal-breakers — the obstacles that, if the product doesn't solve them, the user won't switch from their current workaround. These define the must-haves.

Feature universe summary — group all potential features by category (data input, processing, output, collaboration, integrations, reporting, etc.)

Save as OBSTACLE_FEATURE_MAP.

---

Step 4 — MVP Feature Scope

Hormozi Rule 4: One unsolved problem can cost you the sale. For software: one missing must-have feature kills the switch. Scope ruthlessly, but make sure the core job is 100% solved.

Using OBSTACLE_FEATURE_MAP, scope the product into build tiers.

Apply Hormozi's solution mapping + lean MVP thinking together:

For each obstacle in the feature universe, decide:

• PROBLEM → FEATURE (name it)
• Build tier: Core (must ship) / V2 (post-launch) / V3+ (future)
• Build complexity: Low / Medium / High
• User impact: Low / Medium / High

Only features with High user impact AND Core build tier belong in v1.

Produce:

Core loop — the 3–5 features that deliver the core transformation. Without these, there is no product. Written as user actions, not technical specs:

"User [does X] → system [does Y] → user gets [outcome Z]"

Must-have feature list (v1) — everything in Core tier

Won't-have list (v1) — explicitly name what's NOT being built. This is as important as the must-have list. Features that will tempt the founder but should wait.

The riskiest assumption — one sentence. If this assumption is wrong, the product fails. Name it. The MVP exists to answer this question.

Save as MVP_SCOPE.

---

Step 5 — Pricing & Packaging

Hormozi Rule 5: Stack value until saying no feels stupid. For software: stack the plan tiers until the paid plan is obviously the right choice.

Using MVP_SCOPE + RESEARCH_BRIEF (price ceiling evidence), design the pricing model.

First: what is the right pricing model for this product and audience?

• Per seat / per month?
• Usage-based?
• Flat monthly?
• One-time + updates?
• Freemium or free trial?

Justify using the WTP signals from research.

Then design 2–3 pricing tiers:

FREE / TRIAL tier (if applicable)

• What's included: [features]
• What's excluded: [hooks that drive upgrade]
• Strategic purpose: [what this tier is designed to do]

CORE tier — $[Price]/month

• What's included: [feature list]
• Dollar value of each component (what would they pay for this separately?)
• Total stack value vs. price
• Who this is for: [specific ICP sub-segment]

PRO / GROWTH tier — $[Price]/month (if applicable)

• Additional features
• Who upgrades: [triggers for upgrade]

Annual incentive: [discount % and framing]

Price anchoring statement — how to frame the price on the landing page. What does their current manual workaround actually cost them in time × hourly rate? Show the math.

Save as PRICING.

---

Step 6 — Launch Offer & Risk Reversal

Hormozi Rule 6: If you believe in your offer, guarantee it. For software: remove every reason to delay. Make the first yes feel obvious.

Using PRICING + ICP + research trust signals, write the launch offer.

Early access offer — what do early customers get that later customers won't? Options: lower price locked in forever, direct founder access, feature input, priority support, extended trial. Choose 1–2 maximum. More than 2 feels desperate.

Guarantee — write 3 versions:

Version 1 — No-risk trial "Try [product] free for [N] days. No credit card required. If it doesn't [specific outcome], you owe nothing." Name: [creative name]

Version 2 — Results guarantee "If you [specific action], and you haven't [specific outcome] within [timeframe], [what you do — refund, extend, work with them personally]." Name: [creative name] Qualifying actions: [what they must do — this filters serious users]

Version 3 — Done-with-you "If after [timeframe] of using [product] you're not [outcome], we'll personally [X] until you are." Name: [creative name]

Recommendation — which guarantee converts best for this product, this price point, this audience. Use trust gap findings from competitor research to justify. If reviews showed trust is low in this category, lean harder on risk reversal.

---

Final Output — Product Brief

After all 6 steps, compile into a Product Brief ready for mvp-strategist:

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
PRODUCT BRIEF — [Product Name]
Generated via Hormozi Product Discovery Framework
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

RESEARCH FOUNDATION
  Pain signals found:       [N] ([breakdown by type: MANUAL / GAP / WORKAROUND / WTP])
  Recurring pattern:        [one sentence]
  Software gap:             [one sentence — what existing tools miss]
  Price ceiling evidence:   [$X–$Y/month based on WTP signals]

ICP
  Who:                      [one-sentence ICP statement]
  Current workaround:       [what they do today]
  ICP score:                [X/40]

PRODUCT CORE
  Core promise:             [one sentence]
  Positioning line:         [full positioning statement]
  Transformation:           Before → After

MVP SCOPE
  Core loop:                [user action → system action → outcome]
  Must-have features (v1):  [list]
  Explicitly won't build:   [list]
  Riskiest assumption:      [one sentence]

PRICING
  Model:                    [pricing model]
  Core tier:                $[X]/month
  Stack value:              $[Y] in value for $[X]
  Price anchor:             [cost of status quo argument]

LAUNCH OFFER
  Early access:             [what early users get]
  Recommended guarantee:    [name + one-line]

NEXT STEPS
  → Feed this brief into: mvp-strategist (scope the build)
  → Then: project-scaffold (set up the project structure)
  → Stack: [Laravel / React / Anthropic API or as appropriate]

---

Skill Behaviour Rules

• Research first, always. Never let the user skip Step 0. Generic ICPs produce generic products that nobody pays for.

• Use their words. If a phrase from the Language Harvest fits, use it. If the positioning line uses words nobody in the research used, rewrite it.

• Tag what's validated. The [R] tag on obstacles tells the user what's evidence vs. what's assumption. Be honest about the difference.

• Connect to the build. This skill feeds mvp-strategist. Keep the MVP Scope in a format that can be handed off directly — user actions, not feature labels.

• Call out weak signal. If Step 0 research is thin (few results, mostly weak signals), say so before continuing. A weak research brief produces a weak product. Offer to search different angles before proceeding.

• Price with evidence. Never invent price points. The pricing recommendation must reference the WTP signals from research. If there's no price evidence, say so.