iphone-launch-pitch-adapter

name

iphone-launch-pitch-adapter

description

Apply the 2007 iPhone launch's rhetorical product-pitch architecture to create persuasive decks, websites, launch narratives, sales materials, demo scripts, or stories for other products. Use when a product needs sharper category framing, status-quo contrast, mechanism reveal, proof-by-demo, value anchoring, or a more memorable close. Avoid cosmetic Apple imitation; adapt the structure to the target product, audience, proof, and medium.

iPhone Launch Pitch Adapter

Use this skill when the task is to create persuasive product materials by adapting the 2007 iPhone launch as a structural model. The goal is not to imitate Apple cosmetically. The goal is to translate the launch's belief-changing moves into a new product, market, audience, and medium.

This skill is for agent execution. Produce the requested artifact, not just advice, unless the user explicitly asks for analysis only.

Core Principle

The iPhone launch works because it changes what the audience believes before it asks them to evaluate the product. It does this in sequence:

1. Establish permission to claim a category shift.
2. Make the current category feel trapped by a structural constraint.
3. Draw a market gap the product can uniquely occupy.
4. Reveal the mechanism that makes the product feel inevitable.
5. Bridge novelty with familiar behavior, data, partners, or workflows.
6. Prove the claim through concrete verbs and real use.
7. Convert features into category-level claims through repetition.
8. Price, ask, or close against accumulated value.
9. Compress the whole argument into a memorable line.

Adapt the order when needed, but preserve the belief-change logic.

Reference Anatomy

Use these examples as anchors for the structure, not as language to copy:

• Historical permission: Macintosh changed personal computing; iPod changed music; therefore Apple has standing to claim another category shift.
• Three-in-one reveal: iPod, phone, and Internet communicator are named separately, repeated, then collapsed into one product.
• Enemy framing: existing smartphones are trapped by fixed keyboards and buttons that cannot adapt to each application.
• White-space map: regular phones are easy but not smart; smartphones are smarter but hard to use; the new product claims smart and easy.
• Mechanism reveal: a giant screen plus multi-touch makes the interface adaptable, direct, and software-defined.
• Familiarity bridge: iTunes sync makes the new device feel operationally familiar to people who already understand iPods.
• Demo by verbs: unlock, scroll, pinch, call, merge, type, browse, zoom, search, map.
• Objection by demo: the soft keyboard is not defended abstractly; it is shown inside a normal messaging task.
• Category escalation: Safari is framed as the real web, not a reduced mobile substitute.
• Humor after proof: the Starbucks call works because maps, search, calling, and touch have already been demonstrated.
• Value anchoring: price is framed against the combined value of the device, apps, and category breakthrough.
• Slogan compression: "reinvent the phone" lands because the proof sequence has already made that conclusion plausible.

When adapting, translate each example into the target product's own category, mechanism, evidence, and voice.

Transfer Examples

Bank Compliance Exam Prep

• Old world: compliance teams discover gaps during exam season, when every answer is already urgent.
• Structural constraint: requests, controls, evidence, exceptions, and approvals live in separate systems, so no one can see whether an exam response is complete until people manually stitch it together.
• Mechanism: a control-evidence workspace links each examiner request to source documents, ownership, review status, exceptions, and an exportable audit trail.
• Proof verbs: import the request list, map controls, attach evidence, flag gaps, route approvals, export the response packet.
• Familiarity bridge: keeps the bank's existing control framework and approval chain instead of forcing a new compliance taxonomy.
• Close: exam prep becomes a live readiness system, not a quarterly scramble.

AI Research Tool

• Old world: researchers move from papers to notes to code to benchmark tables, losing the reason each experiment existed.
• Structural constraint: literature, hypotheses, runs, failures, and citations are stored in different places, so the research thread breaks whenever the work changes medium.
• Mechanism: a shared research workspace binds papers, claims, experiment configs, results, and writeups into one traceable loop.
• Proof verbs: collect papers, extract claims, compare baselines, launch runs, score results, generate citations.
• Familiarity bridge: exports notebooks, BibTeX, Markdown, and result tables so the workflow still fits existing lab habits.
• Close: the lab remembers why each experiment was run.

Smart Home Hardware Product

• Old world: smart home devices promise automation but make ordinary households manage pairing, scenes, firmware, and failure states.
• Structural constraint: each device has its own app, permissions, and setup logic, so the home never feels like one system.
• Mechanism: a room-aware hub discovers devices, infers routines, and exposes a single physical control for the actions people repeat every day.
• Proof verbs: plug in, discover, name the room, tap to run a routine, adjust once, recover automatically.
• Familiarity bridge: setup happens through the phone, but daily control works like a light switch.
• Close: the smart home becomes a home again.

Required Inputs

Before creating, gather or infer:

• Product: what it is, who uses it, and what outcome it creates.
• Category: what buyers currently compare it against.
• Status quo constraint: the old-world flaw that competitors cannot easily escape.
• Mechanism: the specific invention, workflow, model, design, or business model that makes the new behavior possible.
• Proof: demos, screenshots, metrics, case studies, examples, testimonials, or prototype flows.
• Audience: buyer, user, investor, partner, employee, press, or public audience.
• Desired action: buy, sign up, invest, approve, share, learn, believe, or remember.
• Medium: deck, website, product page, launch post, sales one-pager, demo script, video outline, founder story, investor narrative, or other artifact.

If key inputs are missing, make the smallest reasonable assumptions and mark them briefly. Ask questions only when the missing input would materially change the strategy.

Positioning Preflight

Before creating a deck, website, narrative, or sales artifact with ambiguous positioning, briefly lock these choices:

• Sold object: what the buyer is actually being asked to adopt, purchase, approve, or believe in.
• Demo object: the concrete thing that makes the product easy to picture.
• Mechanism: the invention, workflow, substrate, model, or system that makes the claim true.
• Audience mental model: what familiar category the audience will compare this against first.
• Category collision: what the product could be mistaken for, and why that would weaken the pitch.
• Scariest objection: the doubt the artifact must answer through proof, not reassurance.
• Positive reveal: the familiar nouns, jobs, actions, or objects used before abstract architecture.
• Forbidden lead: wording that would create the wrong mental model.

If the positioning is high-stakes or the user is still debating the category, do not rush into artifact creation. First propose a short narrative spine with rejected framings and why they were rejected. Proceed once the spine is coherent, or make clearly marked assumptions if the user wants speed.

Positive Object Test

The iPhone was not first made graspable as a software-defined mobile interaction substrate. It was first made graspable as an iPod, a phone, and an Internet communicator. Use the same discipline:

• Lead with something the audience can picture: a job, object, workflow moment, physical action, before/after state, or familiar bundle of things.
• Introduce abstractions like platform, layer, protocol, substrate, infrastructure, rails, engine, graph, operating system, or network only after the audience has a concrete handle.
• Use negation to weaken the old world, not as the product reveal. "Not X, not Y" is a setup. The reveal must name the new positive thing.
• If the best strategic category is abstract, create a more tangible audience-facing reveal first, then explain the architecture underneath it.

Adaptation Workflow

1. Name the old world.

   • Identify the accepted compromise users tolerate today.
   • Frame the issue as structural, not merely that competitors are bad.
   • Show why incremental fixes cannot solve it.

2. Draw the white space.

   • Create a simple contrast or map: not enough of X, too much of Y, smart but hard, powerful but inaccessible, fast but untrusted, personal but unscalable.
   • Position the product as the missing quadrant or new rule.
   • Check whether the proposed category accidentally sounds like a familiar incumbent, a new product category the audience did not ask for, or a consulting wrapper.

3. Reveal the mechanism.

   • Explain the product's core breakthrough as the natural answer to the constraint.
   • Use plain-language causality: because this changed, that old tradeoff disappears.
   • Avoid leading with a feature list.
   • Separate the audience-facing object from the underlying mechanism when needed: first what it is like to use or buy, then why it works.

4. Bridge the unfamiliar.

   • Pair every radical claim with something the audience already knows: an existing workflow, trusted institution, installed behavior, familiar metaphor, or common daily job.
   • Reduce perceived switching cost.

5. Prove by verbs.

   • Build demos around actions, not nouns: touch, search, approve, reconcile, underwrite, generate, compare, invite, deploy, recover, close.
   • Sequence proof from the smallest credible action to the highest-value workflow.
   • Put risky objections into the demo instead of hiding them.
   • Name the scariest objection before planning the demo. The demo should make the objection visible in context and answer it through successful action.

6. Add rhetorical texture.

   • Use questions to keep the audience mentally active.
   • Use tricolons and repetition when they clarify the structure.
   • Use contrast, callbacks, and simple slogans.
   • Use humor or delight only after proof has earned trust.

7. Close with compression.

   • The closing line should summarize the belief the audience has already accepted.
   • Good closes sound inevitable, not decorative.

Output Patterns

Decks

Build a deck around belief changes, not a product tour:

• Title: category-shift thesis.
• Old world: current compromise and why it persists.
• White space: market map or contrast, including the incumbent category the product must avoid being mistaken for.
• Positive reveal: the concrete object, job, or action bundle the audience can grasp before the architecture is named.
• Mechanism: why the new product can break the tradeoff.
• Proof sequence: demo verbs, screenshots, metrics, or examples.
• Objection demo: the risky objection handled inside a normal user or buyer workflow.
• Adoption bridge: why this is usable now.
• Value/ask: price, action, or decision framed against accumulated value.
• Close: compressed slogan or thesis.

Each slide should usually make one move. Use visuals as proof objects, not decoration.

Websites and Product Pages

Make the first viewport state the category shift or core offer plainly. Then structure the page as:

• Old-world tension.
• Product mechanism.
• Interactive or visual proof.
• Use cases expressed as verbs.
• Credibility and adoption bridges.
• Pricing or CTA after value is established.

Do not make a generic marketing page that starts with vague benefits and buries the mechanism.

Launch Posts, Founder Stories, and Narratives

Use a narrative arc:

• What changed in the world.
• Why current tools cannot keep up.
• The insight that makes the product possible.
• The first concrete moment where the product proves itself.
• What this lets people do now.
• Why the timing matters.

Keep the story specific. The iPhone pattern depends on concrete constraints and concrete proof.

Sales Materials

Translate the pitch into buyer logic:

• Current operational drag.
• The hidden cost of the old constraint.
• The new mechanism and why it changes the economics.
• Proof in the buyer's workflow.
• Objection-handling by demonstration.
• Decision ask.

Avoid over-stylized launch drama when the buyer needs procurement clarity.

Demo Scripts and Video Outlines

Write the demo as a sequence of verbs:

• Start with the smallest action that makes the product feel different.
• Repeat the action if it teaches the new interaction grammar.
• Move into a realistic high-value workflow.
• Surface and answer the obvious objection live.
• End with an integrated moment that shows why the parts belong together.

Quality Bar

Strong adapted work should:

• Make the target product feel inevitable for its category, not merely attractive.
• Name a real old-world constraint the audience recognizes.
• Give the audience a positive object to picture before asking them to understand an abstract mechanism.
• Avoid category collisions that make the product sound like a weaker incumbent, a confusing new product class, or a generic services wrapper.
• Explain a mechanism that actually supports the claim.
• Prove with actions, visuals, evidence, or examples.
• Alternate novelty with familiarity.
• Use repetition to upgrade features into a larger thesis.
• Fit the medium instead of copying keynote pacing blindly.
• Preserve the product's own brand voice and visual language.

Weak adapted work:

• Copies Steve Jobs' wording, cadence, or black-stage aesthetics without adapting the argument.
• Starts with a feature checklist.
• Claims a revolution before earning permission.
• Treats competitors as foolish instead of constrained.
• Defines the product mainly by what it is not.
• Leads with abstract category language before the audience has a concrete object.
• Blurs sold object, demo object, and mechanism.
• Uses a slogan that was not proven by the artifact.
• Hides the riskiest objection instead of demonstrating through it.

Verification

Before delivery, check:

• The artifact has a clear belief-change sequence.
• The status quo problem is structural and specific.
• The sold object, demo object, and mechanism are distinct when they need to be.
• The positive reveal is concrete enough for the audience to picture.
• Category-collision risks have been checked and either avoided or explicitly handled.
• The product's mechanism is visible or explainable.
• Proof appears before the strongest claim, price, ask, or slogan.
• The scariest objection is answered by a proof moment, not just a claim.
• The output matches the requested medium and audience.
• Any borrowed iPhone launch concepts are structural, not cosmetic.

For code-based websites or decks, also run the repo's relevant build or preview command and visually check the result when feasible.