marketing-driven-development

name	marketing-driven-development
description	Use when a user is creating, evaluating, or implementing a product, app, feature, startup idea, repo, demo, landing page, launch plan, or vibe-coded project and wants development to be led by marketing, distribution, positioning, audience pull, memeability, or the user's experience of discovering the thing before code.

Marketing Driven Development

MDD treats attention as the scarce resource and code as the cheap resource.

Use this skill before writing implementation plans, feature lists, tickets, prototypes, or architecture.

Also use it after a user has already arrived.

In MDD, arrival is not a precondition to using the product. Arrival may be the product.

The job is to make the agent ask: "What experience caused someone to get here, and why might they pass it on?"

Core Rule

Do not start with what can be built.

Start with what can travel.

If the user has already clicked, opened, cloned, starred, shared, or argued with the artifact, treat that behavior as part of the artifact.

Workflow

1. Define the audience in one sentence.

   • Who has the pain, aspiration, status anxiety, curiosity, or inside joke?
   • If the audience is "everyone," narrow it until it can be named.

2. Write the hook before the spec.

   • Produce 3 to 5 hooks as if they were post titles, repo taglines, launch headlines, or demo captions.
   • Prefer hooks that create tension, surprise, identity, or disagreement.

3. State the distribution bet.

   • Where would this spread first?
   • Who would share it, and what would sharing it say about them?
   • What existing conversation does it hijack?

4. Identify the arrival experience.

   • What did the user see before they arrived?
   • What curiosity gap, joke, argument, status signal, or promise caused the click?
   • What realization should happen after arrival?

5. Derive the minimum product from the experience.

   • Build only what makes the hook true.
   • Cut any feature that cannot be explained through the hook.
   • If a README, repo name, screenshot, demo video, empty folder, or one-line CLI output can create the reaction, start there.

6. Define a market-facing test.

   • Choose a signal: clicks, stars, replies, waitlist joins, forks, comments, demos booked, reposts, screenshots, or "people got mad but kept talking."
   • Specify what result would justify building more.

7. Then implement.

   • Now write code, docs, mockups, or automation.
   • Keep the work shaped by the hook and signal.

Output Pattern

When using MDD, respond in this order:

1. Audience
2. Hook
3. Distribution Bet
4. Arrival Experience
5. Minimum Product
6. Market Test
7. Build Plan

If the user asks for implementation, still include a short MDD pass first, then execute.

Anti-Patterns

• Building because the stack is interesting.
• Adding features to avoid launching.
• Treating a README as documentation only, instead of as packaging.
• Measuring success by completeness before measuring curiosity.
• Calling something "MVP" when it has no market-facing test.
• Forgetting that the user's path to the artifact is part of the artifact.

Mantra

If the product cannot earn attention before it is done, finishing it may only make the silence more expensive.

If the user has arrived, the product has already begun.