app-marketplace-launch-marketing

{
  "skill_name": "app-marketplace-launch-marketing",
  "evals": [
    {
      "id": 1,
      "prompt": "I run partner marketing at Kelvinly, a B2B workflow automation SaaS. We've had a public \"integrations directory\" for three years - 412 listings, most built either by us or by partners who filled in a Google Form and sent a logo. Next month we relaunch it as the Kelvinly App Marketplace with the same 412 listings carried straight over. Engineering says a real security review process is \"on the roadmap for Q3.\" My draft press release opens with \"412 curated, security-vetted apps available on day one\" and our CMO loves that line. Can you sharpen the announcement copy and tell me what else the release should include?",
      "expected_output": "A refusal to polish the copy as written: the 412 listings are a migrated catalog, not a vetted cohort, and with no live review gate the curated/vetted language has to go or the gate has to be built first. Includes the precedent that press counts launch numbers independently, and offers a tiered or subset framing that carries an honest quality claim alongside the breadth number.",
      "files": [],
      "expectations": [
        "Identifies the 412 listings as a migrated pre-existing catalog rather than a curated launch cohort",
        "Refuses to keep \"curated\" and \"security-vetted\" in the announcement copy while the review gate is still unbuilt",
        "States that a cohort's credibility claim is only as strong as the review gate behind it",
        "Offers exactly two honest paths: stand up the review gate before launch, or drop every curated/vetted claim from the launch language",
        "Routes the review-gate work to the sibling skill samber/developer-platform-skills@app-marketplace-review, or names designing that review process as a prerequisite step owned elsewhere",
        "Warns that press counts launch-day app numbers independently instead of accepting the operator's figure",
        "Cites monday.com's marketplace launch as precedent: the operator claimed over a hundred apps and press counted 78",
        "Cites Atlassian Marketplace's 2012 \"~1,000 add-ons\" as a migrated plugin catalog rather than a curated cohort",
        "States that catalog migration buys a large headline number cheaply and near-zero vetting credibility",
        "Does not propose inflating, rounding up, or re-describing the 412 figure to sound vetted",
        "Proposes tiering inside the cohort - a smaller vetted subset named separately from the 412-listing breadth claim - citing HubSpot's 2017 split of 65 launch integrations into 30 beta integrators and 35 certified partners",
        "Asks its clarifying questions one at a time rather than delivering a single batched list of questions"
      ]
    },
    {
      "id": 2,
      "prompt": "Nessforth is a 40-person API-first billing platform. We just announced at our all-hands that the Nessforth App Marketplace debuts at our user conference, Nessforth Connect, 10 weeks from now. Today we have zero third-party apps - nobody has built anything against our API yet. Our VP Marketing wants \"at least 50 partners on stage.\" We have a review checklist drafted in a doc but no reviewer hired and no pipeline running. What's the plan?",
      "expected_output": "A design-partner micro-cohort of roughly 3-6 partners instead of 50, justified by supply recruited from zero plus a review pipeline that is not live, with partner selection on urgency/capability/representativeness and the reveal anchored to the Nessforth Connect keynote.",
      "files": [],
      "expectations": [
        "Rejects the 50-partner target as unachievable from zero supply in 10 weeks and says so plainly rather than hedging",
        "Recommends a design-partner micro-cohort of roughly 3 to 6 launch partners",
        "Cites Notion's 2021 integrations debut with 3 launch partners as the micro-cohort precedent",
        "Selects the partners on the a16z design-partner criteria: urgency, capability, and representativeness",
        "States explicitly that selection is not made on logo size alone",
        "Notes the a16z framework advises 5-10 high-quality design partners over a large day-one cohort",
        "Ties the step down to the two conditions actually present: supply must be recruited from zero, and the review pipeline is not live",
        "Names the default cohort shape being stepped down from - a curated vetted cohort of roughly 15-65 apps anchored by 3-6 marquee logos",
        "States that the hard conference date promotes fast-acting options and demotes slow compounding ones",
        "Flags that with no live reviewer the cohort cannot honestly be marketed as vetted",
        "Anchors the reveal to the Nessforth Connect keynote rather than a standalone quiet-week press moment"
      ]
    },
    {
      "id": 3,
      "prompt": "Draycott, customer-support platform. Our marketplace launches with 22 partner apps and I own announcement week. Current plan: we email every partner the logo pack and approved boilerplate on launch morning, and tell them \"post sometime during launch week, whenever works for your team.\" Our own blog post goes live Tuesday at some point that day. Two of the 22 apps touch payment data so those partners have security teams in the loop. Sanity-check this plan before I send the partner email.",
      "expected_output": "A rewrite of announcement week around one canonical embargo time with an explicit timezone, kits shipped ahead of the lift carrying the embargo notice, pre-approved quotes embedded in Draycott's own release, a ~15-minute social window, and 1-2 weeks of lead for the payment-data partners.",
      "files": [],
      "expectations": [
        "Rejects shipping the co-marketing kit on launch morning and requires it to reach every partner before the embargo lifts",
        "Requires the kit to ship carrying the embargo notice itself rather than the notice arriving separately or later",
        "Replaces \"post sometime during launch week\" with one single canonical announcement time",
        "Requires that canonical time to state an explicit timezone",
        "States that no partner release publishes before Draycott's own reveal",
        "Recommends coordinating social posts within roughly 15 minutes of the wire time",
        "Recommends 1-2 weeks of embargo lead specifically because the payment-data apps make this a security-sensitive launch",
        "Requires partner quotes to be pre-approved by each partner's comms team and embedded in Draycott's own release",
        "States that the operator release is drafted first so both sides reuse the same pre-cleared language",
        "Specifies the kit contents: approved boilerplate for both brands, the pre-cleared quote, and logo and banner assets",
        "Explains the kit's purpose as removing the partner's extra approval round-trip on launch day",
        "Labels the embargo mechanics as inferred from standard PR practice rather than operator-disclosed"
      ]
    },
    {
      "id": 4,
      "prompt": "Hollowmere runs an app marketplace for retail ops software - 240 listed apps, roughly 15 new ones added a month. We're launching a quality badge called \"Hollowmere Verified\": minimum 50 net paid installs, minimum 5 reviews, plus a four-part quality checklist reviewed by our app team. Marketing wants the launch blog to say badged apps see a 49% install lift in 14 days and rank higher in marketplace search. Separately, our long-tail developers keep complaining nobody ever finds them. Does the badge fix that, and is the blog copy safe to ship?",
      "expected_output": "No on both counts: an install/review-gated badge structurally cannot surface apps that have neither, so a time-boxed editorial rotation is added alongside it; and the 49% figure must carry its operator-published label while the search-ranking claim is dropped as contested.",
      "files": [],
      "expectations": [
        "Answers no to the long-tail question: a badge gated on 50 installs and 5 reviews structurally cannot surface apps that have neither",
        "States that always-on quality-gated badges are the mechanic structurally worst at surfacing new apps",
        "Recommends adding a time-boxed editorial rotation alongside the badge rather than replacing the badge with one",
        "Specifies the rotation selects explicitly not on existing install base",
        "Gives the rotation a cadence of roughly weekly, citing Shopify Staff Picks",
        "Notes the badge and the rotation compose, and that Shopify runs both in parallel on one marketplace",
        "Identifies the 49% new-installs-in-14-days figure as operator-published and requires that label to travel with it",
        "Rejects the search-ranking claim because independent developer rank-tracking found no organic keyword-rank change from the badge, making the effect contested",
        "Frames the badge as buying eligibility, a trust signal, and an install bump - never a guaranteed rank boost",
        "Requires any lift figure Hollowmere publishes to be baselined against each app's own prior period first",
        "Warns that partners run their own rank trackers and will call out an overclaim publicly",
        "Requires the badge eligibility gates to be published and re-audited on a cycle, with badge loss dropping the endorsement rather than the listing"
      ]
    },
    {
      "id": 5,
      "prompt": "At Brimhollow we're under revenue pressure and want to monetize marketplace merchandising. The idea: a \"Featured App of the Month\" hero slot on the marketplace homepage, sold each month to whichever partner bids highest, with no badge and no disclosure - we present it as our editorial pick so it carries more weight with buyers. Partner marketing here is two people total. Our top 8 partners would probably all bid every month. Poke holes in this.",
      "expected_output": "A rejection of the undisclosed auction: paid placement gets labeled as paid, pricing gets published as a menu rather than bid, fulfillment capacity is named as the binding constraint for a two-person team, and a non-paid merchandising surface stays separate from the paid slot.",
      "files": [],
      "expectations": [
        "Rejects presenting a sold slot as an editorial pick and requires paid placement to be labeled as paid",
        "States that an undisclosed paid slot spends the trust the marketplace's review gate bought",
        "Rejects highest-bidder pricing in favour of published price points, because unpublished pricing reads as pay-to-play favoritism",
        "Cites Salesforce's AppExchange Marketing Program as the menu-priced paid-catalog precedent with operator-published price points",
        "Reproduces at least two AMP price points accurately from: ~$4K industry e-books, ~$14K webinar promotions, $5K-$7.5K paid-media extensions",
        "Recommends capping partners at one application per quarter, as AMP does",
        "Identifies the menu-priced paid catalog as the highest-fulfillment-effort option, which loses every efficiency ranking",
        "Names the two-person partner-marketing team as the binding constraint on fulfillment rather than treating partner demand as the constraint",
        "States the condition that would promote a paid catalog anyway: partner co-marketing demand outstripping team capacity even after tier-gating",
        "Keeps at least one non-paid merchandising surface - an editorial rotation or a quality badge - clearly separate from the paid slot",
        "Does not recommend running the auction as designed"
      ]
    },
    {
      "id": 6,
      "prompt": "Quillane has 130 apps in its marketplace. Every single partner emails us asking for a joint webinar, a case study, or MDF. Right now we say yes to whoever shouts loudest, and the ones we turn down accuse us of playing favorites - one wrote it up on LinkedIn last month. Finance just gave us $900K for partner marketing next year. My instinct is to divide it evenly: about $6,900 of MDF per partner, everybody treated exactly the same, nobody can complain. Design the allocation for me.",
      "expected_output": "A two-motion budget design: a non-rival marketplace-wide demand-gen baseline funded for all 130 partners, plus a rival per-partner co-marketing layer rationed on a published partner-tier ladder with an invitation cohort for partners too new to have climbed it.",
      "files": [],
      "expectations": [
        "Rejects the even per-partner split of the $900K",
        "Splits marketplace marketing into two structurally different motions rather than treating it as one budget",
        "Identifies marketplace-wide demand generation - marketplace SEO, curated collections, category pages, keynote launches - as non-rival, where one partner benefiting costs the others nothing",
        "Identifies per-partner co-marketing - MDF, co-sell, custom campaigns, spotlights - as rival, consuming operator staff time or budget per engagement",
        "Funds the non-rival demand-gen baseline broadly, for all 130 partners by default",
        "Rations the rival layer rather than offering it broadly",
        "Makes a partner-tier ladder the default rationing mechanism for the rival layer",
        "Requires the allocation rule to be published so a partner can self-assess against it without asking",
        "States that an unpublished rule is what makes every grant read as favoritism, and that transparent rationing is what makes a \"no\" survivable",
        "Cites Atlassian's stated posture of focusing on general promotion of the marketplace rather than individual co-marketing with partners",
        "Adds an invitation cohort for partners too new to have climbed the tier ladder, citing HubSpot's Partner Growth Accelerator or Salesforce's Builders Initiative",
        "Specifies objective tier thresholds a partner can read - an ARR band or a trailing-12-month sales bar - citing monday.com unlocking MDF and lead sharing from Silver up, or Microsoft tiering benefits by trailing-12-month marketplace sales"
      ]
    },
    {
      "id": 7,
      "prompt": "Vantreel's marketplace has been live for just over two years - 310 apps, steady growth, nothing dramatic. Our new CMO joined last month and has asked me for \"a marketplace launch plan\" by Friday. She's also told the whole marketing org that next year every partner-marketing dollar has to show attributable pipeline inside the quarter it's spent or it gets cut. And the mandate she gave me is to build something that still compounds three years from now. Where do we start?",
      "expected_output": "A program that starts at the ongoing featuring/spotlight design rather than founding-cohort sizing, plus an explicit callout of the efficiency ratchet: quarterly attributable-pipeline gating starves exactly the compounding investments the three-year mandate requires.",
      "files": [],
      "expectations": [
        "Does not produce a founding-cohort sizing exercise for an already-live marketplace",
        "Starts the program design at the ongoing featuring and spotlight program rather than at cohort sizing or reveal planning",
        "Names the contradiction between a quarterly attributable-pipeline funding rule and a three-year compounding mandate",
        "Names the efficiency ratchet: funding only what measures well starves new-app surfacing and technical enablement",
        "States that partner programs funding only what ranks well over-serve sales-adjacent co-marketing",
        "Deliberately promotes the high-value, high-effort options because the mandate is a compounding asset rather than a one-off win",
        "Requires re-promoting the starved options on a schedule, not only when metrics demand it",
        "Warns that non-rival demand-gen spend cannot show per-partner attributable pipeline by construction, so that metric is the wrong gate for it",
        "Proposes measuring the share of partner-marketing spend on non-rival demand gen versus rival co-marketing, plus the count of partners touched by each motion",
        "Reframes the CMO's \"launch plan\" request as an ongoing program and states plainly which debut-launch steps do not apply here"
      ]
    },
    {
      "id": 8,
      "prompt": "Post-launch readout time at Sedgewood. Our marketplace went live 6 weeks ago with 28 apps and 2,100 day-one installs. The board deck my analyst drafted benchmarks us against Salesforce AppExchange, which she has at \"575 apps, 250 ISVs,\" and against Atlassian's 1,000 add-ons - we look terrible in that table. Separately, our biggest partner had one great week after we featured them and wants us to publish that being featured \"doubles installs.\" What should this readout actually say?",
      "expected_output": "A readout that drops the operator benchmark table as non-comparable (both figures are misread), refuses the unbaselined \"doubles installs\" claim, and reports launch-moment, featuring, and budget-split measures against Sedgewood's own baseline.",
      "files": [],
      "expectations": [
        "Rejects benchmarking a 6-week-old marketplace against the Salesforce AppExchange and Atlassian Marketplace figures",
        "Identifies Salesforce's \"575 apps / 250 ISVs\" as a fiscal-year-end snapshot months after the 2005 launch, not a launch-day figure",
        "Identifies Atlassian's ~1,000 add-ons as a migrated plugin catalog rather than a launch cohort",
        "States that operator anchors are context rather than targets, and that the baseline is Sedgewood's own first quarter",
        "Refuses to publish the partner's \"doubles installs\" claim on the evidence of a single week",
        "Requires any feature-window lift to be baselined against that app's own prior fortnight before any average is publicized",
        "Reports press pickup and partner same-day posts relative to the 28-app cohort size, alongside the 2,100 day-one installs",
        "Reports the split of partner-marketing spend between non-rival demand gen and rival per-partner co-marketing",
        "Reports the count of partners touched by each of the two motions",
        "States that the rival co-marketing layer touching only the top tier is by design, while the demand-gen layer touching only some partners is a bug",
        "Notes that no industry pass-standard exists for a marketing-program artifact, so the program's pass gates are self-set"
      ]
    }
  ],
  "trigger_queries": [
    {
      "query": "Our app marketplace goes live at our user conference in June - how many launch partners do we actually need?",
      "should_trigger": true
    },
    {
      "query": "Twenty partners all want to post about our launch on the same day. How do we coordinate that?",
      "should_trigger": true
    },
    {
      "query": "Design our featured apps program - badges, staff picks, or something else?",
      "should_trigger": true
    },
    {
      "query": "Partners keep asking for co-marketing and we're drowning. How do we decide who gets MDF?",
      "should_trigger": true
    },
    {
      "query": "We're opening our integrations directory to third-party developers next quarter. What does the reveal look like?",
      "should_trigger": true
    },
    {
      "query": "Should we charge partners for placement on our app store homepage?",
      "should_trigger": true
    },
    {
      "query": "How many marquee logos do we need co-signing the press release?",
      "should_trigger": true
    },
    { "query": "app of the month program design", "should_trigger": true },
    {
      "query": "We want a partner spotlight every month. How do we pick without it looking rigged?",
      "should_trigger": true
    },
    {
      "query": "What's a fair way to ration marketing development funds across our ISV partners?",
      "should_trigger": true
    },
    {
      "query": "Our first 12 integration partners all ship in March. How do we make a moment out of it?",
      "should_trigger": true
    },
    {
      "query": "Write the embargo plan for our ecosystem announcement",
      "should_trigger": true
    },
    {
      "query": "We have 300 apps in our store and nobody knows the store exists. What should marketing fund?",
      "should_trigger": true
    },
    {
      "query": "How do I say no to a partner asking for a joint campaign without torching the relationship?",
      "should_trigger": true
    },
    {
      "query": "Plan the go-to-market for our new developer app store",
      "should_trigger": true
    },
    {
      "query": "Our partners think featuring decisions are favoritism. How do we fix that?",
      "should_trigger": true
    },
    {
      "query": "We're migrating our old plugin directory into a new storefront. How should we announce it?",
      "should_trigger": true
    },
    {
      "query": "launch cohort sizing for a b2b marketplace",
      "should_trigger": true
    },
    {
      "query": "One big launch or stagger it across two events six months apart?",
      "should_trigger": true
    },
    {
      "query": "Our platform team built an app store. Now what is marketing supposed to do with it?",
      "should_trigger": true
    },
    {
      "query": "How do other B2B platforms decide which partner apps get homepage placement?",
      "should_trigger": true
    },
    {
      "query": "We told partners the badge would boost their installs. Was that a mistake?",
      "should_trigger": true
    },
    {
      "query": "Need help structuring tiers so the co-marketing budget goes to the right partners",
      "should_trigger": true
    },
    {
      "query": "Our launch partners want to publish their own press releases. How do we keep it coordinated?",
      "should_trigger": true
    },
    {
      "query": "What should our own release say about the partners who built on us?",
      "should_trigger": true
    },
    {
      "query": "Give me a program for surfacing new apps that nobody has installed yet",
      "should_trigger": true
    },
    {
      "query": "We have zero partners and a keynote in ten weeks. Help.",
      "should_trigger": true
    },
    {
      "query": "Design the ongoing partner marketing program for our integrations ecosystem",
      "should_trigger": true
    },
    {
      "query": "How much of our partner marketing budget goes to the marketplace itself versus individual partners?",
      "should_trigger": true
    },
    {
      "query": "Our CEO wants \"500 apps at launch\" in the press release. We have 40 that passed review.",
      "should_trigger": true
    },
    {
      "query": "What goes in the kit we send launch partners before announcement day?",
      "should_trigger": true
    },
    {
      "query": "Is a paid featured slot a good idea for our app directory?",
      "should_trigger": true
    },
    {
      "query": "We're relaunching our integrations page as a real marketplace. Announcement plan?",
      "should_trigger": true
    },
    {
      "query": "My exec keeps asking why we fund the marketplace at all. What's the argument?",
      "should_trigger": true
    },
    {
      "query": "How do I pick the first three partners to build on our new API before we go public?",
      "should_trigger": true
    },
    {
      "query": "Our partner program has no tiers yet and everyone wants the same marketing help",
      "should_trigger": true
    },
    {
      "query": "app store launch announcement checklist",
      "should_trigger": true
    },
    {
      "query": "How should we sequence the marketplace beta and the GA announcement?",
      "should_trigger": true
    },
    {
      "query": "We want a recurring \"partner of the quarter\" thing. How do other platforms run it?",
      "should_trigger": true
    },
    {
      "query": "Our app directory has 80 listings and zero merchandising. Where do we start?",
      "should_trigger": true
    },
    {
      "query": "How do we review third-party apps for security before they go live on our marketplace?",
      "should_trigger": false
    },
    {
      "query": "What should we require in every listing - screenshot sizes, description length, category rules?",
      "should_trigger": false
    },
    {
      "query": "What revenue share should we take on marketplace transactions, and who is merchant of record?",
      "should_trigger": false
    },
    {
      "query": "Should we build our own marketplace or just get listed on Zapier and Workato?",
      "should_trigger": false
    },
    {
      "query": "How do we onboard partner developers into a sandbox before they submit their first app?",
      "should_trigger": false
    },
    {
      "query": "We're listing our product on AppExchange - how do we improve our view-to-install rate?",
      "should_trigger": false
    },
    {
      "query": "Optimize our Shopify App Store listing title, tagline, and screenshot order",
      "should_trigger": false
    },
    {
      "query": "Which technology partners should we integrate with first, and how deep should each go?",
      "should_trigger": false
    },
    {
      "query": "Design our outbound webhook retry, backoff, and dead-letter policy",
      "should_trigger": false
    },
    {
      "query": "How should we version our public API and communicate deprecations?",
      "should_trigger": false
    },
    {
      "query": "Our API error messages are useless. Redesign the error-code taxonomy.",
      "should_trigger": false
    },
    {
      "query": "What rate limits should we publish for our free tier versus our enterprise tier?",
      "should_trigger": false
    },
    {
      "query": "Do we need a GraphQL API or is REST plus webhooks enough for now?",
      "should_trigger": false
    },
    {
      "query": "Which language SDKs should we ship first, and generated or handwritten?",
      "should_trigger": false
    },
    {
      "query": "Design our OAuth consent screen and scope taxonomy for third-party apps",
      "should_trigger": false
    },
    {
      "query": "Set up a sandbox mode with magic test values and simulated events",
      "should_trigger": false
    },
    {
      "query": "Our developer portal has no search and signup-to-first-call takes an hour. Fix the onboarding path.",
      "should_trigger": false
    },
    {
      "query": "Audit our API reference for undocumented endpoints and missing error codes",
      "should_trigger": false
    },
    {
      "query": "How do we run a public status page for API incidents and postmortems?",
      "should_trigger": false
    },
    {
      "query": "Design idempotency keys and replay windows for our payments API",
      "should_trigger": false
    },
    {
      "query": "Should we expose a JDBC endpoint so customers can query their own data?",
      "should_trigger": false
    },
    {
      "query": "Plan our source connector on Fivetran and Airbyte",
      "should_trigger": false
    },
    {
      "query": "Build an MCP server for our SaaS so agents can operate it",
      "should_trigger": false
    },
    {
      "query": "How do partners see why their integration deliveries are failing?",
      "should_trigger": false
    },
    {
      "query": "Design our bulk Parquet export and partitioning contract for enterprise customers",
      "should_trigger": false
    },
    {
      "query": "We're hiring an API product manager. What does the interview loop look like?",
      "should_trigger": false
    },
    {
      "query": "I want to move into partner engineering. What's the path from backend dev?",
      "should_trigger": false
    },
    {
      "query": "Review our REST URI naming, status codes, and pagination pattern",
      "should_trigger": false
    },
    {
      "query": "Design our API key format, prefix, and rotation policy",
      "should_trigger": false
    },
    {
      "query": "Should our public gRPC surface stream or stay unary?",
      "should_trigger": false
    },
    { "query": "Plan our Product Hunt launch day", "should_trigger": false },
    {
      "query": "How do we get our iPhone app featured on the App Store?",
      "should_trigger": false
    },
    {
      "query": "Our mobile game needs a launch plan for Google Play, including paid installs",
      "should_trigger": false
    },
    {
      "query": "Draft a co-marketing agreement with our reseller - who owns the leads?",
      "should_trigger": false
    },
    {
      "query": "Plan a joint webinar with Acme Corp for next month",
      "should_trigger": false
    },
    {
      "query": "Build the launch strategy for our v2 product release",
      "should_trigger": false
    },
    {
      "query": "How do we sponsor DevOpsDays and get the best booth position?",
      "should_trigger": false
    },
    {
      "query": "Set up an affiliate program with commission tiers and cookie windows",
      "should_trigger": false
    },
    {
      "query": "Design a customer referral program with double-sided rewards",
      "should_trigger": false
    },
    {
      "query": "How do we run a hackathon to get developers building on our API?",
      "should_trigger": false
    }
  ]
}

# Co-marketing allocation and partner-tier gates

## The two-motion split

Marketplace marketing is structurally two motions, and every operator studied runs them differently:

- **Platform-level demand generation** - marketplace-wide campaigns, SEO and semantic search, curated collections, category pages, keynote-anchored launches. Non-rival; one partner benefiting costs the others nothing. Funded broadly, scales without per-partner labor.
- **Per-partner co-marketing** - custom campaigns, Marketing Development Funds (MDF), paid/menu-priced assets, field co-sell, individual spotlights. Rival and high-touch; each engagement consumes operator staff time or budget. Every operator studied deliberately rations it by price, tier, or invitation.

The underlying logic: the platform's own dollars go where they compound across every partner at once, because that spend doesn't have to be re-earned per partner. Rival dollars go to partners who have already demonstrated revenue, quality, or strategic fit.

## Operator rationing mechanisms

- **Atlassian - tier-gated, with a default-no baseline.** From its "Attract new customers" developer docs: "In general, Atlassian prioritizes marketing support in favor of supported, paid via Atlassian apps and focuses on general promotion of the Atlassian Marketplace, rather than individual co-marketing with partners. However, we're always on the lookout for new opportunities." Formal co-marketing requires a support-ticket request; "prioritized co-marketing" is reserved for higher partner-program tiers. Atlassian instead pushes vendors to self-serve: listing SEO, a landing page on their own site, social with the `#atlassian` hashtag, paid search, and vendor-run sales promotions (self-service discount codes via the vendor account, restricted to paid-via-Atlassian apps; after launch only the end date can be extended).
- **Salesforce - rationed by price.** The AppExchange Marketing Program (AMP) is a menu-priced à-la-carte catalog (operator-published price points): customer testimonial videos, industry e-books ~$4K ("100+ opt-in contacts"), webinar promotions ~$14K ("100 webinar registration contacts"), paid-media extensions $5K-$7.5K; partners apply for one per quarter, and Salesforce publishes "historical metrics (a guide, not a guarantee)" per product. A free/reimbursed layer (Partner Marketing Center: co-branded templates, Digital Marketing Program/Services) sits underneath. The $50M AgentExchange Builders Initiative adds a cohort-inclusion lever aimed at early-stage ISVs - capital, engineering support, lead referrals, MDF.
- **HubSpot - rationed by tier and invitation.** MDF is selective and prioritized toward higher tiers of the Technology Partner Program (four tiers: Partner / Rising / Leading / Premier, assigned at developer level, evaluated quarterly on trailing-12-month customer value, influenced revenue, and quality/readiness). The Partner Growth Accelerator is a cohort-based 6-week program pairing solutions partners with app partners specifically for co-marketing development funds.
- **monday.com - rationed by ARR tier.** Four tiers from Bronze ($5K ARR) to Platinum ($1M+ ARR); Silver and above unlock MDF and lead sharing; higher tiers add prioritized placement, roadmap access, and business reviews. Re-evaluated quarterly.
- **Microsoft - rationed by trailing sales.** Marketplace Rewards (folded into ISV Success) tiers benefits by trailing-12-month marketplace billed sales: featured placement, internal solution spotlights to field sellers, featured blog posts, executive endorsements. Microsoft publishes: "the average marketplace transacted sales are five times higher for those who used at least one Marketplace Reward than those who don't participate" - vendor-published, and a selection effect (stronger partners opt in) is not controlled for; cite it as directional, not causal.

Cross-operator pattern: tier admission criteria are revenue/installs/quality-readiness, never a flat fee - and the same tier usually gates featured placement and co-marketing budget as one bundle. Shopify's Built for Shopify is the exception that gates only featured placement, on a pure quality/installs bar with no attached co-marketing fund.

## Publishing the allocation rule

Default every partner to the same non-rival demand-gen baseline, then publish the rationing rule for the rival layer - tier thresholds, a price list, or cohort criteria. A published rule lets a partner self-assess ("hit 50 net installs and 5 reviews," "reach Silver," "budget $14K") and makes a "no" survivable; an unpublished rule makes every grant read as favoritism. For a partner asking how to earn co-marketing, the honest answer is the ladder: hit the published thresholds before applying to cohort programs or buying menu-priced assets.

## Named practitioners for the skeptical-executive conversation

Cite ecosystem-specific voices, not generic product-launch authors - this task is a recurring operator program, not a launch-day checklist:

- **Scott Brinker** (VP Platform Ecosystem at HubSpot, chiefmartec): frames ecosystem strategy as "creating a sandbox where the other kids want to come to build their castles," and sized HubSpot's ecosystem opportunity publicly (chiefmartec, March 2021): "$2.1 billion in add-on software that will be purchased from our ecosystem in 2021. In 2024, that number will be $4.2 billion." Useful for justifying broad demand-gen funding to an executive who sees the marketplace as a cost center.
- **Jay McBain** (Chief Analyst, Canalys): coined "the decade of ecosystems"; his 28-moments thesis - buyers pass through ~28 moments of pre-sales influence largely without the vendor present - is the rationale for why marketplace-wide demand gen outweighs any single vendor's outbound. Also notes hyperscaler marketplaces charge 3% or less per transaction, reshaping co-sell economics relative to take rates.
- **a16z design-partner framework** (Seema Amble, Jennifer Li): urgency / capability / representativeness selection criteria for a pre-launch cohort; advises 5-10 high-quality design partners over a large day-one cohort.
- **Velocity Partners' "Ecosystem Marketing" series** (including a Brinker interview), plus Partner Fleet and Crossbeam/PartnerStack content: named practitioner treatments of marketplace go-to-market specifically. Treat these as secondary/vendor commentary - useful to corroborate a pattern, not to source a specific operator's numbers.

# Featured-placement and spotlight program mechanics

No two operators run the same mechanic under the "app of the month" umbrella - the term covers at least three structurally different programs.

## Per-operator mechanics

- **Shopify Staff Picks** - editorial selection by the App Review team; roughly weekly default rotation, 1-2 months for localized/country-specific picks. Selection is explicitly not based on existing user base - Shopify states new additions "are not chosen based on an existing user base"; criteria lean on usability, innovation, onboarding quality, customer service. Impact for a small app can be large: Shippo reported 3x normal signups during its Staff Pick week (vendor-reported anecdote); Appointo was picked 1-2 weeks after listing while still an MVP.
- **Shopify Built for Shopify** - an always-on recognition tier layered on top of ordinary listing (applications opened March 2024). Quantitative gates: minimum 50 net installs from active shops on paid plans and minimum 5 reviews, plus a four-category quality checklist (safety/security, performance, UX/design consistency, accurate listing information) reviewed by the app review team. Benefits, all badge-conditional: preferential search placement, a visible badge in listings and search, and eligibility for homepage featuring and "recommended apps" inside the Shopify admin - a surface unbadged apps cannot access. It is a recurring gate tied to re-auditable standards, not a one-time launch bonus.
- **Atlassian Marketplace badges** - in Q1 2024 Atlassian retired a single staff-pick-style badge for three community-run badges: Spotlight (top apps by installs/reviews), Rising Star (newer apps gaining traction), Bestseller - plus themed Collections. Its "Marketplace Partner Spotlight" programs are reformatted around customer use cases, with partners tagging apps to use cases rather than Atlassian hand-picking winners. Always-on merchandising, free, distinct from tier-gated co-marketing.
- **Salesforce AppExchange/AgentExchange** - no single rotating spotlight; instead a menu-priced Partner Co-Marketing catalog (AMP) plus editorial listings and in-product surfacing via the Partner Marketing Center app.
- **HubSpot** - curated "Essential Apps" collections (e.g. "Essential Apps for Marketers," 22 apps) recommended by HubSpot, plus certified-app and tier badges (Rising/Leading/Premier) acting as an always-on search filter. HubSpot's own docs note collection-featuring benefits "are continuing to evolve" and are negotiated per-partner with a Technology Partner Manager, not published as a fixed program.
- **Microsoft AppSource/Azure (Marketplace Rewards, folded into ISV Success)** - "solution spotlights" target Microsoft's own field sellers internally, plus featured marketplace placement, featured blog posts, and executive endorsements; benefits tier by trailing-12-month marketplace billed sales.
- **Zoom** - an "Essential Apps" shelf bundling premium partner apps free for paid Zoom plans, plus curated categories; a permanent curated shelf rather than a rotation.
- **monday.com** - no dedicated spotlight; featured placement is bundled into its four-tier ARR-based partner structure.

## The Shopify parallel-program case

Shopify demonstrates that the badge and the rotation are complements, not alternatives, running on one marketplace:

- **Built for Shopify** is a quality-and-traction gate: it reliably buys eligibility, a trust signal, and a measurable near-term install bump - Shopify's Partners blog (updated October 2025, operator-published) reports "an average increase of 49% new installs in just 14 days of achieving status," and its Seguno case study reports suite-wide installs up 14%.
- **Contested effect, keep the label:** independent developer testimony diverges on organic keyword rank specifically - one developer tracking rankings with SASI reported "nothing happened" to his main keywords after earning the badge, concluding exact-match keywords and review volume mattered more. Read the badge as buying eligibility, trust, and an install bump - not a guaranteed rank boost. An operator publicizing a badge's ranking effect should flag this gap; partners measure, and overclaiming gets called out publicly.
- **Staff Picks** is the calendar-fair complement: it deliberately gives newer and smaller apps the shot the badge's 50-install/5-review floor denies them.

## Design implications for the operator

1. Offer the three shapes as a menu, not a default: time-boxed editorial rotation (cheapest ongoing labor per feature, best at surfacing new apps), always-on gated badges (scales without weekly editorial labor, structurally worst at surfacing new apps), menu-priced paid catalog (highest revenue potential, requires published pricing and an application process).
2. Publish the eligibility gates for any badge, and make losing the badge drop the endorsement, not the listing.
3. Whatever benefit figures you publish, baseline them against each app's own prior period, label the source, and never promise a rank effect the data contests.
4. Label paid placement as paid - a paid slot that reads as an editorial pick spends the trust the review gate bought.

# Founding-cohort benchmarks

## Cohort sizes across 12 operators

Founding cohorts span roughly 100x depending on curation philosophy and pre-existing assets:

| Marketplace                    | Debut        | Founding cohort                                   |
| ------------------------------ | ------------ | ------------------------------------------------- |
| Notion API/integrations        | May 13, 2021 | 3 launch partners (Zapier, Typeform, Automate.io) |
| Zoom App Marketplace           | 2018/19      | 15 production-ready apps                          |
| Webflow next-gen Apps          | ~Aug 2023    | 20+ apps                                          |
| Zoom "Zapps" (in-client)       | Oct 14, 2020 | 35 launch partners                                |
| Stripe App Marketplace         | May 24, 2022 | 50+ apps                                          |
| HubSpot Connect                | 2017         | 65 integrations (30 beta + 35 certified)          |
| monday.com Apps Marketplace    | Oct 27, 2020 | operator claimed 100+; press counted 78           |
| Slack App Directory            | Dec 15, 2015 | ~150-160 apps                                     |
| Microsoft Teams app publishing | May 10, 2017 | ~150 integrations                                 |
| Salesforce AgentExchange       | Mar 4, 2025  | 200+ partners                                     |
| Salesforce AppExchange         | 2005         | 575 apps / 250 ISVs by FY-end Jan 2006            |
| Atlassian Marketplace          | May 30, 2012 | ~1,000 add-ons (50 paid)                          |

The modal curated shape is 15-65 vetted apps. The 200+ outlier (AgentExchange) reflects Salesforce's 20-year installed base of existing partners, not a template for a new marketplace.

## The vetting gate

Nearly every operator markets its cohort as security/quality vetted, and the gate is what keeps a cohort small even when developer interest is much larger:

- Slack launched with only ~150 of roughly 4,000 apps developers had built - the rest "were not vetted well enough to be counted as official integrations."
- Zoom: marketplace apps are "fully vetted by Zoom for security and user experience."
- Microsoft Teams: "rigorous validation of the functionality, usability, and security of these apps."
- Salesforce AgentExchange: components "that passed rigorous security and customer reviews."

Implication: a cohort claim is only as strong as the gate behind it. Without a live review process, the launch language cannot honestly use "curated" or "vetted"; the review process is the `samber/developer-platform-skills@app-marketplace-review` sibling's territory.

## Tiering inside a cohort

HubSpot's 2017 Connect launch is the clearest documented tiered cohort: 65 launch integrations split into 30 entry-level "beta integrators" and 35 "Connect Certified Partners" who had "gained significant customer adoption and passed a certification process." The pattern scales the headline number without diluting the top tier's trust signal.

## Marquee anchor logos

Operators consistently name big brands in the launch release:

- AgentExchange led with Google Cloud, DocuSign, and Box.
- Stripe named DocuSign, Dropbox, Intercom, Mailchimp, Ramp, and Xero.
- Slack named Twitter, Dropbox, Trello, and Google Drive.

Three to six anchors is the observed norm; the anchors carry the press story, the rest of the cohort carries the breadth claim.

## Micro-cohort selection: the design-partner criteria

For a 3-6-partner micro-cohort, select on the a16z design-partner framework (Seema Amble, Jennifer Li - "A Framework for Finding a Design Partner"):

- **Urgency:** the partner needs the integration now.
- **Capability:** they can actually ship against a young API.
- **Representativeness:** their use case generalizes to the partners you want next.

The framework advises 5-10 high-quality design partners over a large day-one cohort; Notion's 3-partner debut is the marketplace-scale example.

## Waves instead of one moment

Several operators deliberately staggered inclusion:

- monday.com shipped its Apps Framework (Jun 30, 2020) months before the Apps Marketplace itself (Oct 27, 2020).
- Webflow ran a 2022 beta App Store before the 2023 integrated "next-gen Apps" wave (Whalesync was a launch partner in both).
- Zoom sequenced App Marketplace (15 apps) → Zapps (35 partners) → Zoom Apps GA (50+).
- Stripe launched 50 "with more to come," reaching ~125 apps within about two years.

Each wave is a full coordination cycle (cohort, embargo, event anchor), which is why waves lose on efficiency - but they de-risk a review pipeline that can't vet everything by one date, and they buy multiple press moments.

## Caution: day-one numbers are not always cohorts

- Atlassian's "1,000 add-ons" (2012) came from migrating a pre-existing plugin catalog into the new storefront - not a curated launch cohort.
- Salesforce's "575 apps / 250 ISVs" is a fiscal-year-end snapshot months after AppExchange's 2005 launch, not the launch-day figure.
- monday.com claimed "over a hundred" apps at launch; independent press counted 78.

Treat any operator-published day-one number skeptically until confirmed as a genuinely gated, simultaneously revealed cohort - and expect the press to apply the same skepticism to yours. Operator launch numbers run generous, and the divergence gets reported.

## The reveal pattern (observed) and embargo mechanics (inferred)

Observed across every operator studied:

- The operator's release embeds pre-approved partner quotes (AgentExchange published DocuSign's and Box's language verbatim).
- Partners publish same-day releases pegged to the operator's news (multiple Stripe launch apps all published May 24, 2022).
- The lift anchors to a flagship keynote (AppExchange at Dreamforce 2005, Teams at Build 2017, AgentExchange at TrailblazerDX 2025, Webflow at Webflow Conf, Zoom at Zoomtopia, Slack at a dedicated press event).

Inferred from standard PR practice - no operator discloses its embargo terms:

- State the exact date/time and timezone at the top of the embargo notice.
- Coordinate wire and social timing within roughly 15 minutes across both companies.
- Give 1-2 weeks' embargo lead for complex or security-sensitive launches.
- Use only current approved boilerplate for both brands.

---
name: app-marketplace-launch-marketing
description: Design a B2B SaaS marketplace operator's launch and ongoing app co-marketing program - sizing and gating the founding launch cohort, the keynote-anchored reveal and partner embargoes, featured-placement and app-of-the-month spotlight governance, and the budget split between marketplace-wide demand generation and rationed per-partner co-marketing (MDF, paid catalogs, tier gates). Use whenever the user mentions launching an app marketplace, picking launch partners, featured apps, partner spotlights, MDF, or a joint launch announcement - even if they never say "marketplace launch". Operator side only. Do NOT use for a vendor optimizing its own listing elsewhere - use samber/developer-platform-skills@integration-listing-optimization instead.
license: MIT
metadata:
  author: Samuel Berthe
  version: "1.0.1"
---

# App Marketplace Launch Marketing

You are a marketplace-marketing advisor for the operator side: a B2B SaaS platform team launching its app marketplace and running the ongoing program that markets the marketplace and the partner apps inside it. The output is a program design - cohort, reveal plan, featuring governance, budget split - that a partner-marketing team can execute and a partner can read without crying favoritism.

When figures are operator-published, contested, or inferred, they are labeled as such inline: keep those labels when you reuse the figures.

**Memory (advised):** When memory lives in a file, consider using `developer-platform-context.md`; if a different memory system is in use, rely on that instead. The file is an advisory reference, not a mandatory requirement. Separate task info in different sections. Remove finished tasks. Add a date to a task; no date for general project context. Some interview responses may differ between 2 tasks.

## Interview

Ask before proposing anything. One question per message, multiple-choice where offered - each answer moves a rung in the menus below, and batching buries the answer that changes everything.

1. Which launch is this? (a) the marketplace's own debut - nothing public yet (b) an ongoing program for apps launching into a live marketplace (c) a relaunch/rebrand of an existing surface.
2. What already exists on the supply side? (a) nothing - partners must be recruited (b) partners mid-build under a review pipeline (c) a pre-existing catalog or directory to migrate.
3. Is there a security/quality review gate partners must clear before listing? Live / planned / none. (No gate means the cohort can't honestly be marketed as vetted - see the sibling review skill below.)
4. Do you have a flagship conference or event to anchor the reveal, and when is it?
5. How many marquee-brand partners could plausibly co-sign the announcement? 0 / 1-2 / 3-6 / more.
6. For the ongoing program: what standing marketing labor can you commit - editorial hours per week, a partner-marketing headcount, productized campaign fulfillment?
7. Is there a formal partner-tier program already, or would this skill's program be the first thing that ranks partners?
8. By when must a result land - a hard date (the conference?), or open-ended?
9. One-off win (a loud debut) or compounding asset (a program that runs quarterly for years)?
10. Effort ceiling - headcount, budget for co-marketing funds, appetite for published commitments partners will hold you to?

Questions 8-10 exist because the menus below diverge sharply on time-to-effect, durability, and effort - the defaults cannot pick for the user:

- A hard conference date promotes fast rungs (micro-cohort, editorial picks).
- A compounding mandate promotes slow ones (badge systems, tier ladders).
- A low effort ceiling deletes options rather than demoting them.

## Scope

- **In scope:** every operator sourced here (Slack, Shopify, Atlassian, Salesforce, HubSpot, Stripe, Zoom, monday.com, Microsoft, Webflow, Notion) runs a B2B or prosumer marketplace, and the mechanics travel across them.
- **Out of scope:** a consumer app store (mobile platforms, games) markets through consumer press and paid installs, a different discipline this skill does not cover.

The splits that actually change the design are the ones the interview asks:

- debut vs ongoing program (question 1)
- existing catalog vs recruited cohort (question 2)
- standing labor (question 6)

## Workflow

1. Gate: which launch moment, and whether the vetting story is real.
2. Size and gate the founding cohort (debut only).
3. Plan the reveal: embargo, quotes, event anchor.
4. Design the ongoing featuring/spotlight program.
5. Split the budget: platform demand gen vs rationed per-partner co-marketing.
6. Define measurement.

Draft the program document section by section in that order, validating each with the user before the next. Skip step 2 (and compress step 3) when question 1 answers (b) - a live marketplace's program starts at step 4.

Re-rank every menu below against what you know about this user before presenting it - each of these moves rungs:

- an existing partner community
- a conference next quarter
- a marquee logo already committed
- a tier program already running

The defaults are defaults, not laws.

## 1. Gate: the vetting story

A launch cohort's credibility rests on the review gate behind it - nearly every operator studied markets its cohort as vetted ("fully vetted for security and user experience," "rigorous validation," "passed rigorous security and customer reviews"). If question 3 answers "none," stop and route to the review sibling skill first, or drop every "curated/vetted" claim from the launch language. Marketing an unvetted catalog as a curated cohort is the failure the press actually checks (see Failure modes).

## 2. Founding cohort (debut only)

Real founding cohorts span ~100x (from Notion's 3 launch partners in 2021 to Salesforce AgentExchange's 200+ in 2025) - and the outliers are explained by pre-existing assets, not ambition. Four shapes, ranked:

- effort (descending): `staggered waves > curated vetted cohort > design-partner micro-cohort > catalog migration`
- launch-day credibility (descending): `curated vetted cohort == staggered waves > design-partner micro-cohort > catalog migration` - the tie holds because waves reveal the same vetted cohort, split across moments
- efficiency: `curated vetted cohort > design-partner micro-cohort > catalog migration > staggered waves`

- **Default rung: curated vetted cohort of roughly 15-65 apps, anchored by 3-6 marquee logos.** This is the modal shape across operators (Zoom 15, Webflow 20+, Stripe 50+, HubSpot 65); marquee anchors are near-universal (Stripe named DocuSign, Dropbox, Intercom; Slack named Twitter, Dropbox, Trello). Scale the headline number without diluting trust by tiering inside the cohort - HubSpot's 2017 launch split 65 into 30 "beta integrators" and 35 "Connect Certified Partners."
- **Step down to a design-partner micro-cohort (3-6)** when supply must be recruited from zero (question 2a) or the review pipeline isn't live: Notion debuted with 3 partners. Select on the a16z design-partner criteria - urgency, capability, representativeness - not on logo size alone.
- **Catalog migration** applies only when question 2c holds: Atlassian's 2012 "~1,000 add-ons" was a migrated plugin catalog, not a curated cohort. It buys a big headline number cheaply and near-zero vetting credibility - never market it as curated, and expect press to count independently (press counted 78 where monday.com claimed 100+).
- **Starved option: staggered waves** - framework before marketplace (monday.com 2020), beta before GA (Webflow 2022-23), marketplace then in-client apps then GA (Zoom). Highest effort (every wave is a full coordination cycle) and it loses every efficiency round; a review pipeline that can't vet the full cohort by the date, or two flagship events a season apart, promotes it anyway.

Cohort table, vetting-gate quotes, and the day-one-number caveats: [references/launch-cohort-benchmarks.md](references/launch-cohort-benchmarks.md).

## 3. The reveal

The observed four-part pattern, consistent across every operator studied:

1. The operator's own release embeds pre-approved partner quotes.
2. Partners publish same-day releases pegged to the operator's news.
3. An embargo lifts everything simultaneously, almost always anchored to a flagship keynote (AppExchange at Dreamforce, Teams at Build, AgentExchange at TrailblazerDX).
4. Joint releases balance both brands' boilerplate with one attributed quote per side.

Exact embargo mechanics are inferred from standard PR practice, not operator-disclosed - no operator publishes its embargo terms. Checklist:

1. Draft the operator release first; get partner quotes pre-approved by each partner's comms team so both sides reuse the same language.
2. Fix one canonical announcement time and timezone; no partner release lifts before the operator's reveal.
3. Ship every launch partner a co-marketing kit with the embargo notice: approved boilerplate for both brands, the pre-cleared quote, logo and banner assets - so their same-day post needs no extra approval round-trip.
4. Anchor to the flagship event when question 4 has one; a quiet-week reveal diffuses the press moment the simultaneous lift exists to create.
5. Coordinate social posts within roughly 15 minutes of the wire time (PR-practice inference); give 1-2 weeks of embargo lead for security-sensitive launches.

## 4. Ongoing featuring and spotlight program

"App of the month" hides at least three structurally different programs - no two operators run the same mechanic. Three shapes, ranked; they compose (Shopify runs the first two in parallel), so the menu picks a starting rung, not a religion:

- operator effort (descending): `menu-priced paid catalog > time-boxed editorial rotation > always-on quality-gated badges` - fulfillment machinery, then standing weekly editorial labor, then criteria set once and re-audited
- new-app surfacing (descending): `time-boxed editorial rotation > menu-priced paid catalog > always-on quality-gated badges` - badge thresholds (Shopify requires 50 net installs and 5 reviews) structurally exclude new apps
- efficiency: `always-on quality-gated badges > time-boxed editorial rotation > menu-priced paid catalog`

- **Default rung: always-on quality-gated badges and tagged collections** (Shopify Built for Shopify; Atlassian's Spotlight/Rising Star/Bestseller badges; HubSpot tier badges as a search filter). Publish the eligibility gates and re-audit on a cycle - losing the badge drops the endorsement, not the listing.
- **Layer on a time-boxed editorial rotation** when surfacing new and small apps matters - Shopify Staff Picks rotates roughly weekly, selects explicitly not on install base, and the lift for a small app can be large (Shippo reported 3x normal signups during its pick week - vendor-reported anecdote). This is the calendar-fair complement to the badge's traction gate, not its replacement.
- **Starved option: the menu-priced paid catalog** (Salesforce's AMP: ~$4K industry e-books, ~$14K webinar promotions, $5K-$7.5K paid-media extensions, one application per partner per quarter - operator-published price points). Highest revenue and highest fulfillment effort; it loses every efficiency round. A partner base whose co-marketing demand outstrips team capacity even after tier-gating promotes it - and it requires published pricing, or it reads as pay-to-play favoritism.

When publicizing badge benefits, state only what's documented and label it: Shopify publishes "an average increase of 49% new installs in 14 days of achieving status" (operator-published), but independent developer rank-tracking found no organic keyword-rank change from the badge - the figure is contested, and partners measure. Overclaim and they will call it out publicly.

Cross-operator mechanics and the full Shopify case: [references/featured-and-spotlight-programs.md](references/featured-and-spotlight-programs.md).

## 5. Budget split: demand gen vs per-partner co-marketing

The load-bearing operating-model finding across every operator studied: marketplace marketing is structurally two motions, not one.

- **Platform-wide demand generation** (marketplace SEO, curated collections, category pages, keynote launches) is non-rival - one partner benefiting costs the others nothing - so fund it broadly for every partner.
- **Per-partner co-marketing** (MDF, co-sell, custom campaigns, spotlights) consumes real staff time per engagement, so every operator studied rations it rather than offering it broadly.

Atlassian states the posture outright in its developer docs: it "focuses on general promotion of the Atlassian Marketplace, rather than individual co-marketing with partners," reserving prioritized co-marketing for higher partner tiers.

Default every partner to the demand-gen baseline, then pick a rationing mechanism for the rival layer and publish it:

- setup effort (descending): `partner-tier ladder > menu-priced catalog > invitation cohorts` - a tier program is standing governance with quarterly evaluation; a catalog is productized offerings; cohorts are batch programs
- allocation transparency (descending): `menu-priced catalog == partner-tier ladder > invitation cohorts` - the tie holds because both publish objective criteria a partner can self-assess against (a price, a threshold); invitations are opaque by construction
- efficiency: `partner-tier ladder > invitation cohorts > menu-priced catalog`

- **Default rung: gate co-marketing on the partner-tier ladder** - the pattern at HubSpot (MDF prioritized to higher tiers), monday.com (MDF and lead sharing from Silver up, tiers by ARR band), Microsoft (benefits tier by trailing-12-month marketplace sales), and Atlassian. Reuse the tier program question 7 found; if none exists, the tier design belongs to the marketplace-strategy sibling, not here. Microsoft publishes a rare ROI claim for gated benefits - participants' marketplace sales average 5x non-participants' (vendor-published; selection effect not controlled, so treat as directional).
- **Invitation cohorts** (HubSpot's 6-week Partner Growth Accelerator; Salesforce's $50M Builders Initiative aimed at early-stage ISVs) are the cheap complement for a segment the tier ladder structurally starves - partners too new to have climbed it.
- **Starved option: the menu-priced catalog** - same rung as in section 4, promoted at the same scale condition, self-funding once productized.

The efficiency framing has a documented blind spot: partner programs that only fund what ranks well over-serve sales-adjacent co-marketing and starve slow compounding investments (technical enablement, new-partner surfacing). Question 9 answering "compounding asset" promotes the starved rungs deliberately.

Operator mechanisms, tier structures, and the named practitioners (Scott Brinker's ecosystem-sandbox framing, Jay McBain's "decade of ecosystems") to cite when a skeptical executive asks why the marketplace deserves broad demand-gen funding: [references/comarketing-allocation-and-tiers.md](references/comarketing-allocation-and-tiers.md).

## 6. Measurement

The program document passes when three gates hold - self-set gates, since no industry pass-standard exists for a marketing-program artifact; iterate until all three pass:

1. Every cohort or credibility claim in launch material traces to the review gate (step 1) - a "curated" claim without a gate behind it fails.
2. The reveal plan names one canonical embargo time and every partner has the co-marketing kit before it.
3. The rival co-marketing layer has a published allocation rule (tier threshold, price, or cohort criteria) a partner can read - an unpublished rule fails.

Post-launch, track:

- **Launch moment:** press pickup and partner same-day posts vs cohort size; day-one installs.
- **Featuring program:** install lift during and after a feature window, baselined against the app's own prior fortnight before you publicize any average.
- **Budget split:** share of partner-marketing spend on non-rival demand gen vs rival co-marketing; count of partners touched by each motion. The rival layer touching only the top tier is by design; the demand-gen layer touching only some partners is a bug.

Baseline against your own first quarter; the operator anchors in the references are context, not targets.

If your harness has persistent memory, record:

- the chosen cohort shape and size
- the event anchor and embargo time
- the featuring rungs chosen, with their promotion conditions
- the published allocation rule

Later runs (each new app launch, each quarterly tier review) should inherit these instead of re-asking.

## Failure modes

- **Marketing a migrated catalog as a curated cohort.** Press counts independently: monday.com claimed "over a hundred" launch apps, press counted 78; Atlassian's 1,000 was a migration. Claim only what the gate vetted.
- **Overclaiming featuring effects.** Shopify's 49%-install-lift figure is operator-published and its keyword-rank effect is contested by independent tracking. Partners run their own rank trackers; publish only baselined, labeled figures.
- **A partner release jumping the embargo.** One partner publishing early scoops the operator's own reveal. Fix: one canonical time in every kit, and the kit ships with the embargo notice, not after it.
- **Unpublished rationing.** Bespoke co-marketing granted ad hoc reads as favoritism to every partner who didn't get it. Publish the tier threshold, price, or cohort criteria - transparent rationing is the mechanism that makes saying no survivable.
- **Undisclosed paid placement.** A paid slot that reads as an editorial pick spends the trust the review gate bought. Label paid placement as paid.
- **Efficiency ratchet.** Funding only what measures well starves new-app surfacing and technical enablement - the documented partner-program failure. Re-promote the starved rungs on a schedule, not only when metrics demand it.

## Invocation examples

- "Our app marketplace goes live at our user conference in June - how many launch partners do we need and how do we coordinate the announcement?"
- "Design our featured-apps program: badges, staff picks, or should we charge for placement like Salesforce does?"
- "Partners keep asking for co-marketing and we're drowning - how do we decide who gets MDF without it looking like favoritism?"

## References

- [references/launch-cohort-benchmarks.md](references/launch-cohort-benchmarks.md) - 12-operator founding-cohort table with dates, vetting-gate quotes, cohort tiering, marquee anchors, wave sequencing, and the day-one-number caveats.
- [references/featured-and-spotlight-programs.md](references/featured-and-spotlight-programs.md) - cross-operator spotlight mechanics and the Shopify Built for Shopify / Staff Picks parallel-program case, contested figures labeled.
- [references/comarketing-allocation-and-tiers.md](references/comarketing-allocation-and-tiers.md) - the two-motion budget split with each operator's rationing mechanism, tier structures, and the ecosystem-marketing practitioners to cite.

See also, same collection:

- `samber/developer-platform-skills@connector-marketplace-strategy` - whether to build the marketplace at all, its operating model, and the seeding sequence this skill's launch executes; run it first when build/join/buy is still open.
- `samber/developer-platform-skills@app-marketplace-review` - the security/quality review gate every "vetted cohort" claim in step 1 depends on.
- `samber/developer-platform-skills@partner-app-onboarding` - the partner onboarding journey that fills the cohort pipeline this skill reveals.
- `samber/developer-platform-skills@app-marketplace-listing-standards` - listing content rules; this skill markets the apps, that one governs what a listing must contain.
- `samber/developer-platform-skills@app-marketplace-monetization-model` - rev-share and billing mechanics; featured-placement revenue and take-rate interact there, not here.
- `samber/developer-platform-skills@integration-listing-optimization` - the submitter side: a vendor optimizing its own listing on someone else's marketplace.

Bespoke one-to-one joint campaign planning with a single named partner is out of scope - this skill designs the operator's one-to-many program.