mbfinotti/partnerships-skillsチェック済み
SKILL DETAIL
partner-marketplace-strategy
mbfinotti/partnerships-skills/partner-marketplace-strategy
Decide which third-party marketplaces to list on, how much to invest in each, what ROI to expect, and when to delist - marketplace prioritization for partner teams. Covers cloud marketplace listing strategy, SaaS app store and integration directory prioritization, and retail marketplace selection for ecommerce (1P vs 3P vs hybrid), with a readiness gate, weighted scorecard, and provenance-flagged ROI expectations. Use whenever the user mentions AWS, Azure or GCP marketplaces, an app store listing, an integration directory, or asks whether a marketplace listing is worth it, even if they never say marketplace strategy. Do NOT use for choosing which partner category to launch next - use mbfinotti/partnerships-skills@partner-ecosystem-expansion instead.
インストール · 506出典を見る
Installation
npx skills add https://github.com/mbfinotti/partnerships-skills --skill partner-marketplace-strategy
スキルファイル
SKILL.md
最終同期 · 2026/10/23
evals/evals.json›
{
"skill_name": "partner-marketplace-strategy",
"evals": [
{
"id": 1,
"prompt": "I run partnerships at Vantrel. We sell a Kubernetes operator that ships as a container image customers run in their own clusters, $38K average ACV, 61% gross margin, fully sales-led. The direct motion is repeatable: 9 reps, 7 of them at quota last year. Our top 40 target accounts all run heavy AWS footprints. I want to put together the business case for an AWS Marketplace listing. What fee should I model, and what else does the case need to cover?",
"expected_output": "A business case framing that models the 20% server-image fee rather than the 3% SaaS rate, ties the rate to the deployment model, tests it against the 61% margin, names the full cost-to-serve stack, aims the case at the private-offer rung, and asks the deadline, effort-ceiling and horizon questions before finalizing.",
"files": [],
"expectations": [
"States the AWS Marketplace fee for a container, AMI or ML server image public offer is 20%, not the 3% SaaS listing rate.",
"Attributes the 20% figure to AWS's own published fee schedule rather than presenting it as an estimate.",
"Ties the rate to the deployment model (server image versus SaaS listing) rather than to company size or deal size.",
"States that private offers are priced differently from public offers, naming the tiers (3% under $1M, 2% from $1M to under $10M, 1.5% at $10M and above) or the fact that the rate falls with contract size.",
"States that renewals are charged at a lower rate (1.5%) than initial public offers.",
"Tests the 20% fee against the stated 61% gross margin as a readiness-gate item rather than treating the fee as a rounding error.",
"Recommends revisiting the packaging decision (SaaS listing versus server image) because the take rate follows the deployment method.",
"Names cost-to-serve items beyond the fee: metering and entitlement engineering, legal document harmonization (EULA, DPA, support SLA), tax and payout configuration, and a private-offer deal desk.",
"Quantifies the metering and entitlement build at roughly 4-8 weeks rather than leaving the effort unquantified.",
"States that committed-spend drawdown and co-sell access, not lead generation, are the buying drivers for the target accounts.",
"Recommends aiming the business case at the private-offer rung and treating transactable as the toll to reach it.",
"Requires the sales-comp treatment of marketplace-routed deals to be decided in writing before launch.",
"Asks clarifying questions covering at least the date the result must land, whether this is a one-off win or a compounding asset, and the effort ceiling, before finalizing a recommendation."
]
},
{
"id": 2,
"prompt": "We're Brixel, seed stage, 11 people, selling a SOC2 evidence tool at about $9K ACV. Pipeline is thin: our two AEs closed 3 deals between them last quarter and our founder closed the other 6. The board is pushing for a new channel and someone suggested AWS Marketplace plus the Azure one. I need a plan to get listed on both by the end of the quarter so inbound starts coming in from them. Nobody owns it yet, I'd pick it up on top of my current role. Can you map out the listing plan?",
"expected_output": "A readiness-gate refusal: the direct motion is not repeatable, no owner or sponsor exists, and operational capacity is absent. The answer names each disqualifier, corrects the inbound premise, states what must change, and stops without producing a listing plan.",
"files": [],
"expectations": [
"Concludes \"not yet\" and declines to produce the requested listing plan.",
"Names the direct motion not being repeatable as a disqualifier, citing the founder closing 6 of the 9 deals.",
"States that a marketplace amplifies a working sales motion and does not create one.",
"Names the absence of a named owner and executive sponsor as a separate disqualifier.",
"Names missing operational capacity (metering and entitlement engineering, deal desk, tax and legal setup) with no budget to build it as a disqualifier.",
"Corrects the premise that a listing produces inbound, stating a marketplace is primarily a transaction and procurement rail rather than a demand-generation channel.",
"Names \"list and pray\" as the most-cited failure mode in this field.",
"States explicitly, as a named list, what must change before the decision is revisited.",
"Stops at the gate without proceeding into candidate scoring, depth-of-participation, or ROI modeling.",
"Rejects the both-platforms-this-quarter goal and states that one platform is proven first if the gate ever clears.",
"Avoids offering listing-page optimization, marketplace keyword work, or marketplace ad spend as a substitute path.",
"States that deciding not to list is a valid, fundable outcome rather than a failed analysis."
]
},
{
"id": 3,
"prompt": "Halvren makes powder-coated steel shelving. Average order $180, 54% gross margin, $6M revenue, mostly through our own Shopify store. Amazon's vendor team reached out wanting us to go 1P on our three best-selling SKUs. We already sell those same SKUs 3P at full retail. My instinct is to say yes and run both, since it's more shelf space and their team handles fulfilment. Sanity check me?",
"expected_output": "A depth-of-participation answer ranking 3P above 1P on efficiency, ranking hybrid last despite its high value, requiring a 1P/3P firewall and written pricing policy before hybrid, quantifying 1P deductions and blended cost-to-serve, and naming contribution margin as the success variable.",
"files": [],
"expectations": [
"Ranks 3P above 1P on efficiency, stating that 3P returns more margin and pricing control per unit of operational work.",
"Names loss of pricing control as the specific thing 1P surrenders.",
"Quantifies 1P deductions and allowances at roughly 10-15% of payments rather than describing the cost qualitatively.",
"Ranks hybrid last on efficiency even while acknowledging it ranks highest on value.",
"Requires a firewall between the 1P and 3P teams, with pricing not shared between them, before entering hybrid.",
"Requires a written pricing or MAP policy to exist before going hybrid, not after.",
"Names 1P/3P self-competition and price erosion on the same SKU as a specific failure mode.",
"States that the Amazon referral fee is set by product category and cannot be negotiated by the seller, contrasting with the B2B pattern where the rate falls with deal size.",
"Gives blended cost-to-serve on the dominant retail platforms as commonly reaching 30-45% of selling price, with fulfilment, storage surcharges and advertising on top of the referral fee.",
"Names contribution margin after referral, fulfilment, ads and returns as the primary success variable for a consumer channel.",
"Requires that contribution margin to be decided in writing before launch.",
"States that hybrid is promoted only once a specific high-velocity SKU has already proven its 1P economics.",
"Presents at least two candidate approaches with trade-offs and a recommendation rather than a single verdict."
]
},
{
"id": 4,
"prompt": "Our VP Alliances pulled these numbers for the board deck: cloud marketplace ISVs see 27% higher win rates, 80% larger deal sizes and 40% faster sales cycles, and buyers get 377% ROI with a 6-month payback. We're Kestrenix, $28M ARR B2B SaaS, listing on a hyperscaler next quarter. Build me the year-one ROI expectation off those figures.",
"expected_output": "A refusal to build the base case on operator-commissioned figures: every quoted number carries a provenance flag, the commissioned uplifts become a labeled ceiling scenario, the base case comes from the company's own funnel at future rates, and baseline plus net-new/relocated separation are required.",
"files": [],
"expectations": [
"Flags the win-rate, deal-size and cycle-time figures as coming from a study commissioned by the marketplace operator rather than independent evidence.",
"Flags the 377% ROI and 6-month payback figure as operator-commissioned as well.",
"Names the sample basis or limitation behind the commissioned figures (a small interview and survey base) rather than repeating the percentages unqualified.",
"Refuses to build the base case from the published uplift figures.",
"Treats the commissioned figures as a ceiling scenario and labels them as such in the deliverable.",
"Builds the base case from Kestrenix's own funnel and the platform's verified economics instead.",
"Requires a baseline of direct-motion win rate, cycle time and deal size to be captured before the listing goes live.",
"Warns that without a pre-listing baseline, relocated revenue will be counted as marketplace ROI.",
"Requires net-new revenue to be separated from relocated revenue in the model.",
"Cites the industry base rate that most listed B2B software firms get only a small share of revenue through marketplaces (roughly 89% listed but only 22% above 20% of revenue, 41% under 5%).",
"Flags that base-rate figure's provenance as a GTM-tooling vendor survey with a self-selected sample.",
"Requires sourced versus influenced revenue definitions to be agreed with finance before launch.",
"Builds the model at the operator's announced future rate rather than only at today's rate.",
"Distinguishes independent analyst market sizing from vendor-published uplift claims in how each may be used."
]
},
{
"id": 5,
"prompt": "Here's the scoring table we used to pick our next marketplace. Four criteria, 25% each: brand reach, category size, setup ease, exec interest. Workflow app store B scored 4.75, the big cloud marketplace scored 3.00, an integration directory scored 2.75. So B wins. My CFO thinks the weights are off. Can you rebalance them so the result is defensible?",
"expected_output": "A rebuild rather than a reweight: the scorecard has no procurement dimension, its columns are demand assumptions, its equal weights decide nothing, and its winner has the worst economics. The answer proposes a new dimension set, agrees weights before scoring, and replaces the winner with four-way outcomes.",
"files": [],
"expectations": [
"Declines to simply rebalance the existing weights and rebuilds from the readiness gate and the demand-versus-procurement diagnosis instead.",
"Names the complete absence of a buyer-procurement dimension as the core defect.",
"States that buyer procurement presence should carry the heaviest weight, around 25%, as the single most predictive variable.",
"Identifies \"brand reach\" and \"category size\" as demand assumptions rather than evidence that anyone will find the listing.",
"Identifies \"setup ease\" as rewarding the cheapest option rather than costing the operational build honestly.",
"Identifies \"exec interest\" as the sponsored candidate scoring itself.",
"Flags the equal 25% weights as an unjustified default where the format decided instead of a person.",
"Names the missing take-rate or net-economics dimension and the resulting absence of any margin gate.",
"Proposes a replacement dimension set covering at least buyer procurement presence, strategic or ICP fit, net economics, operational cost to participate, competitive saturation, co-sell or promotion access, and platform risk.",
"Requires weights to be proposed and agreed with the user before any scoring happens.",
"States that a dimension with no supporting evidence is left unscored rather than given an invented number.",
"Replaces the single winner with a four-way outcome per candidate: pilot, prepare, hold for verification, do not prioritize.",
"Adds a second-pass impact by effort filter and states that the take rate must not be used as the effort axis."
]
},
{
"id": 6,
"prompt": "Orvenda, B2B analytics, $52K ACV, SaaS-delivered. Our entire engineering capacity for marketplace work is six weeks, total, this half. No deal desk: contracts go through one part-time counsel. We have no resellers and no SI relationships. Our CRO wants marketplace-attributed revenue in the number he presents at the March board meeting. Give me the marketplace plan.",
"expected_output": "A plan that deletes the rungs the constraints rule out and names them, promotes list-only against the hard date, says which stated constraint moved which option, warns that marketplace revenue by March is unlikely, and attaches an owner, envelope and delist trigger.",
"files": [],
"expectations": [
"Deletes the channel or multiparty private-offer rung from the plan outright and names it as deleted, rather than listing it as future upside at the bottom.",
"Justifies that deletion by the absence of any reseller or SI motion to route and by the stated effort ceiling.",
"States explicitly which stated constraint moved which option, for example that the hard March date promotes list-only and the six-week ceiling deletes rungs.",
"Promotes the list-only rung for the near-term date rather than recommending a transactable build.",
"Notes that six weeks sits at or below the commonly cited 4-8 week metering and entitlement build, making a transactable listing by March doubtful.",
"Names the absence of a deal desk as demoting the private-offer rung below a rung the team can actually run.",
"States that list-only buys near-zero revenue and exactly one thing: evidence that target buyers search or procure there.",
"Warns that marketplace-attributed revenue by the March board meeting is unlikely, rather than producing a plan that implies it.",
"Recommends one platform only, with a stated gate and required evidence before a second is added.",
"Attaches a delist or deprioritize trigger with a condition and a review date, written now rather than after launch.",
"Names a single owner and an investment envelope covering platform fees, cost-to-serve and that owner's time.",
"Presents two or three candidate approaches with trade-offs and a recommendation rather than a single plan."
]
},
{
"id": 7,
"prompt": "We're Talvyn, a 14-person ISV. Our app is a Connect app on the Atlassian Marketplace doing about $700K a year. Atlassian keeps pushing Forge, and the pitch is we'd keep 100% of revenue up to $1M lifetime Forge revenue. That's basically free distribution. I want to greenlight the migration, roughly a quarter of engineering. Tell me what the five-year revenue model looks like.",
"expected_output": "A model that treats the 100% band as an expiring acquisition subsidy, prices the post-threshold and announced future rates, compares against the Connect rate paid today, classifies the migration as the deep platform bet, and attaches a review trigger before funding.",
"files": [],
"expectations": [
"States that the 100%-to-$1M Forge band is an acquisition subsidy, not the real price.",
"Models the post-threshold rate as the real rate across the five-year view.",
"Notes that at roughly $700K a year the $1M lifetime cap is reached quickly, so the subsidy expires close to when the listing starts mattering.",
"Cites Atlassian's published schedule of future rate increases rather than assuming today's rate holds.",
"Gives the announced Forge rates (16% from 2026-04-01 and 17% from 2026-10-01) or states that the Forge rate steps up on a published schedule.",
"Compares against the Connect rate the app pays today (20%, rising to 25% on the published schedule) so the migration's actual economic gain is stated.",
"States that the operator prices architectures differently to steer ISV build decisions, making the take rate a policy lever rather than a constant.",
"Requires the business case to be stress-tested against the operator's announced and plausible future rates.",
"Classifies the Forge migration as the deep platform bet rung of the SaaS app store ladder.",
"States that the deep platform bet ranks last on efficiency despite ranking first on value, and is the least reversible commitment available.",
"Names the condition that would promote the deep bet anyway: the platform owns the ICP's daily workflow and the operator's fee schedule pays for the migration.",
"Attaches a delist, deprioritize or review trigger with a date before the commitment is funded.",
"Asks clarifying questions before producing the five-year model rather than delivering it immediately."
]
},
{
"id": 8,
"prompt": "Ranking exercise. Fenlow Systems, $95K ACV B2B SaaS, SaaS-delivered. Candidates: AWS Marketplace, the Microsoft commercial marketplace, and Google Cloud Marketplace. About a third of our target accounts are GCP-heavy. I need a ranked list with the fee for each so I can take it to our CFO on Thursday. Rank them.",
"expected_output": "A ranking where AWS and Microsoft carry published, sourced 3% rates, Google Cloud is recorded as publishing no rate card and routed to hold for verification with a named owner and source, nothing unverified is stated as fact, and each candidate ends at one of four outcomes.",
"files": [],
"expectations": [
"Gives the AWS Marketplace SaaS public-offer fee as 3%, sourced to AWS's own published schedule.",
"Gives the Microsoft commercial marketplace standard store service fee as 3% on transactable offers.",
"States that Google Cloud Marketplace publishes no rate card, rather than quoting an assumed rate of around 3% as fact.",
"Records the absent Google rate card as a finding: the fee is a negotiation input, not a known constant.",
"Routes Google Cloud Marketplace to \"hold for verification\" rather than rejecting it or accepting an assumed rate.",
"Names the owner and the source that would resolve the Google Cloud fee.",
"States the rule that an unresolved question is never converted into either a rejection or an acceptance.",
"Marks any unconfirmed figure \"unverified\" instead of presenting it as fact.",
"Notes that Microsoft's non-transactable or BYOL listings carry a 0% fee but are discovery-only rather than a transaction channel.",
"Avoids asserting Azure committed-spend drawdown behavior without flagging that prepaid Azure credits and commitment-consumption eligibility are distinct programs needing verification.",
"Leaves the net-economics scorecard dimension unscored for the candidate whose fee is unverified rather than inventing a score.",
"Ends each candidate at one of pilot, prepare, hold for verification, or do not prioritize, rather than a ranked yes/no list."
]
},
{
"id": 9,
"prompt": "Three listings, 14 months, zero transactions between them: AWS Marketplace, AppExchange, and a partner integration directory. We've spent roughly 700 engineering hours plus one PM at half time. Every quarter someone says give it more time. Our reps get paid on marketplace deals at 60% of a direct deal, which nobody has ever changed. What do we do: better listing copy, some marketplace ads, or something else?",
"expected_output": "A diagnosis that rejects copy and ads, names the 60% comp treatment as a primary cause, requires a written comp-neutrality policy, separates the directory's expected zero from the two revenue-motion listings, writes delist triggers with review dates, and states that delisting is a valid outcome.",
"files": [],
"expectations": [
"Rejects listing copy and marketplace advertising as the answer and identifies the compensation plan as a primary cause.",
"States that paying reps 60% of a direct deal makes them route around marketplace deals.",
"Requires a written comp-neutrality policy, drafted before the quarter starts.",
"Runs a demand-versus-procurement diagnosis and states what each listing was being asked to do.",
"Distinguishes the integration directory as a discovery and credibility surface that carries no revenue motion on its own, so zero transactions there is expected rather than failure.",
"Names the absence of a delist trigger written at approval time as the reason \"give it more time\" keeps winning.",
"States that a trigger decided up front survives sunk-cost pressure while one decided later rarely fires.",
"Writes a concrete delist or deprioritize condition plus a review date for each listing that is kept.",
"Gives a four-way outcome per listing rather than a binary keep-or-kill call.",
"Recommends concentrating on one platform at real depth instead of maintaining shallow presence across three.",
"Checks whether a private-offer motion and deal desk ever existed, noting that most cloud-marketplace revenue flows through private offers.",
"Notes that renewals are the documented low-risk path to first transactions on a cloud marketplace.",
"States that delisting entirely, or concluding not to list, is a valid and fundable outcome."
]
},
{
"id": 10,
"prompt": "Marra and Co, DTC kitchenware, 14M euro revenue, strong in France through our own site and Amazon.fr. The board wants Poland and the Benelux next year. I've been quoted 40K euro to set up a 3PL in Poland and I'm treating that as the main gate. Which platforms, and in what order?",
"expected_output": "A correction that logistics is not the gate: tax registration, EPR and localization are, each a standing obligation. Names the regional champions for the two geographies, gives the home-market-first sequencing default, gates each step on compliance readiness, and models contribution margin per market.",
"files": [],
"expectations": [
"Corrects the premise that logistics or 3PL setup is the gating step for regional champions.",
"Names tax registration (VAT), EPR compliance obligations, and localization as the actual gating steps, each landing before the first order.",
"Names concrete regional champion platforms for the target geographies, such as Allegro for Poland and CEE and Bol.com for the Benelux.",
"States that regional champions rank below the dominant retail marketplace on efficiency and value, and above it on effort and compliance cost.",
"Gives the established international sequencing default: validate the home market, expand to adjacent markets of the same dominant platform, then regional champions.",
"Gates each expansion step on tax, compliance and localization readiness rather than on revenue alone.",
"Names the condition that promotes a regional champion anyway: the home market is proven and the target geography's incumbent is a different platform the dominant marketplace does not serve.",
"Describes each compliance obligation as a standing job in a jurisdiction nobody on the team operates in, not a one-time setup cost.",
"Requires contribution margin after referral, fulfilment, ads and returns to be modeled per market before entry.",
"Recommends one market first with a stated gate and evidence before the second, rather than both in parallel.",
"Attaches a delist or exit trigger with a review date per market.",
"Asks clarifying questions covering at least the effort ceiling, the date the result must land, and who owns and approves the decision, before recommending a sequence."
]
}
],
"trigger_queries": [
{ "query": "Should we list our product on AWS Marketplace?", "should_trigger": true },
{ "query": "Is a cloud marketplace listing actually worth it for a $40k ACV product?", "should_trigger": true },
{ "query": "We sell a self-hosted container image. What would AWS take on a marketplace deal?", "should_trigger": true },
{ "query": "Help me build the business case for a transactable cloud marketplace listing.", "should_trigger": true },
{ "query": "which marketplaces should we prioritise this year", "should_trigger": true },
{ "query": "Our buyers keep asking whether they can pay for us out of their committed Azure spend. What should we do about it?", "should_trigger": true },
{ "query": "We're listed on three marketplaces and none of them transact. Which do we keep?", "should_trigger": true },
{ "query": "When should we pull a listing that hasn't produced anything?", "should_trigger": true },
{ "query": "Write me a delist trigger for our AppExchange listing.", "should_trigger": true },
{ "query": "Should we build a paid Shopify app or just keep the free integration listing?", "should_trigger": true },
{ "query": "Amazon's vendor team invited us to go 1P. Do we take it?", "should_trigger": true },
{ "query": "1P vs 3P on Amazon for a $65 skincare SKU, which way?", "should_trigger": true },
{ "query": "We want to run both 1P and 3P on the same product line. Any reason not to?", "should_trigger": true },
{ "query": "What ROI should I tell my CFO to expect from a marketplace listing?", "should_trigger": true },
{ "query": "how much does it really cost to sell on amazon once you count everything", "should_trigger": true },
{ "query": "Which should come first, Salesforce AppExchange or Google Cloud Marketplace?", "should_trigger": true },
{ "query": "Rank these for us: AWS Marketplace, Azure, GCP, and the Atlassian Marketplace.", "should_trigger": true },
{ "query": "Our integration is live on four partner directories. Is that worth maintaining?", "should_trigger": true },
{ "query": "Is it worth migrating our Atlassian app to Forge?", "should_trigger": true },
{ "query": "We're expanding to Poland and the Netherlands. Which platforms should we sell on there?", "should_trigger": true },
{ "query": "Should we sell on Walmart Marketplace as well as Amazon?", "should_trigger": true },
{ "query": "TikTok Shop, worth it for a consumer electronics accessory brand?", "should_trigger": true },
{ "query": "Build me a scorecard for choosing between cloud marketplaces.", "should_trigger": true },
{ "query": "My CEO wants us on every marketplace by Q4. Talk me through it.", "should_trigger": true },
{ "query": "We have six engineering weeks. What's the most we can do on a cloud marketplace with that?", "should_trigger": true },
{ "query": "Do we need to be transactable or is a contact-me listing enough to start?", "should_trigger": true },
{ "query": "What's a private offer and should we be aiming at it?", "should_trigger": true },
{ "query": "Our reseller wants to route a deal through the marketplace. Is that worth setting up?", "should_trigger": true },
{ "query": "procurement takes six weeks on every deal, is there a channel that fixes that", "should_trigger": true },
{ "query": "Our buyers have budget parked with their cloud provider that we can't touch. What's the move?", "should_trigger": true },
{ "query": "Write the memo I take to the exec team about listing on a cloud marketplace.", "should_trigger": true },
{ "query": "Our reps route around marketplace deals because they get paid less on them. Where do I even start?", "should_trigger": true },
{ "query": "Do we go direct-only, or put the product where the buyer's budget already sits?", "should_trigger": true },
{ "query": "The AppExchange security review fee plus a 15% revenue share, does the math work for us?", "should_trigger": true },
{ "query": "should we go all in on one platform's app store or stay neutral", "should_trigger": true },
{ "query": "Which comes first for us: the big cloud provider, or the app store our users live in every day?", "should_trigger": true },
{ "query": "Give me a recommendation on depth: just listed, or fully transactable?", "should_trigger": true },
{ "query": "We got approved for a marketplace listing. What do I actually need in place before launch?", "should_trigger": true },
{ "query": "How do I decide whether a marketplace listing is worth the engineering time?", "should_trigger": true },
{ "query": "Our competitor is on all three hyperscalers. Should we match them?", "should_trigger": true },
{ "query": "what's the case for and against selling through a third party platform instead of direct", "should_trigger": true },
{ "query": "Board wants marketplace revenue next quarter. Is that realistic?", "should_trigger": true },
{ "query": "We sell an ML model image on AWS. Trying to work out whether the economics hold.", "should_trigger": true },
{ "query": "Help me pick the first platform to prove the motion on, and how we expand after.", "should_trigger": true },
{ "query": "Our category on Amazon takes 15%. Can we negotiate that down?", "should_trigger": true },
{ "query": "Etsy versus our own store, where should the margin go?", "should_trigger": true },
{ "query": "Is there a reason not to list everywhere at once?", "should_trigger": true },
{ "query": "We want the listing to bring us leads. How many should we expect?", "should_trigger": true },
{ "query": "Put together the investment envelope for a Microsoft commercial marketplace listing.", "should_trigger": true },
{ "query": "Our contribution margin on Amazon went negative after ads. What do we do about the channel?", "should_trigger": true },
{ "query": "Talk me through whether a third-party platform listing is a procurement play or a growth play for us.", "should_trigger": true },
{ "query": "Who should own our marketplace listings internally?", "should_trigger": true },
{ "query": "We listed 14 months ago and have had zero transactions. Was it a mistake?", "should_trigger": true },
{ "query": "Should our next distribution bet be a hyperscaler, an app store, or neither?", "should_trigger": true },
{ "query": "Give me the go/no-go on a Google Cloud Marketplace listing.", "should_trigger": true },
{ "query": "We're a seed-stage SaaS with two customers. Too early for a cloud marketplace?", "should_trigger": true },
{ "query": "Rank our five named strategic alliance candidates for next year's partner capacity.", "should_trigger": false },
{ "query": "Which partner category should we add next, MSPs or systems integrators?", "should_trigger": false },
{ "query": "Write our deal registration policy, including the protection window and rejection grounds.", "should_trigger": false },
{ "query": "Plan the joint go-to-market launch with Northmere, our new ISV partner.", "should_trigger": false },
{ "query": "A direct rep and a reseller both claim the same account. Write the rules of engagement.", "should_trigger": false },
{ "query": "Model the unit economics of our largest reseller relationship.", "should_trigger": false },
{ "query": "Build the per-partner QBR scorecard and review cadence for our top ten partners.", "should_trigger": false },
{ "query": "We need gold, silver and registered tier criteria for our partner program.", "should_trigger": false },
{ "query": "Design the certification path and enablement tracks for our new SI partners.", "should_trigger": false },
{ "query": "Design a B2B channel program from scratch: motions, tiers, benefits, governance.", "should_trigger": false },
{ "query": "Map our whole partner ecosystem and find the channel coverage gaps.", "should_trigger": false },
{ "query": "What commission rate should we pay our affiliates, revenue share or flat CPA?", "should_trigger": false },
{ "query": "Write the first-touch email we send to recruit new affiliates.", "should_trigger": false },
{ "query": "Our affiliate traffic looks like cookie stuffing. Build the detection rules.", "should_trigger": false },
{ "query": "Audit this month's affiliate payout run before we disburse.", "should_trigger": false },
{ "query": "Draft the terms and conditions affiliates accept when they join.", "should_trigger": false },
{ "query": "Does this TikTok caption meet FTC disclosure rules?", "should_trigger": false },
{ "query": "Design the welcome sequence for newly approved affiliates.", "should_trigger": false },
{ "query": "Define the metrics and layout for our affiliate performance dashboard.", "should_trigger": false },
{ "query": "Shortlist creators for our spring campaign and score them on audience fit.", "should_trigger": false },
{ "query": "Write the creative brief for the creator we just signed.", "should_trigger": false },
{ "query": "Prepare me to negotiate usage rights and exclusivity with a creator.", "should_trigger": false },
{ "query": "Draft the first pitch DM to a newsletter writer we want to partner with.", "should_trigger": false },
{ "query": "Design the measurement plan for our upcoming creator campaign.", "should_trigger": false },
{ "query": "How much should we pay out for a refer-a-friend reward?", "should_trigger": false },
{ "query": "Set reward caps and cooldowns so customers stop gaming our referral program.", "should_trigger": false },
{ "query": "What does a partnerships manager need on their resume to get to director?", "should_trigger": false },
{ "query": "Design the interview loop for a channel manager hire.", "should_trigger": false },
{ "query": "I'm starting partnerships work at a new company. Where do I begin?", "should_trigger": false },
{ "query": "Design App Store screenshots and a preview video for our iOS app.", "should_trigger": false },
{ "query": "Our iOS app was rejected in App Store review. How do we respond?", "should_trigger": false },
{ "query": "A/B test our Play Store listing title, icon and first screenshot.", "should_trigger": false },
{ "query": "How do we get featured on the App Store?", "should_trigger": false },
{ "query": "Configure EAS Submit to push our builds to both app stores.", "should_trigger": false },
{ "query": "Improve our app store keyword rankings and install conversion rate.", "should_trigger": false },
{ "query": "Our Shopify app failed the app review checklist. Fix the listing requirements.", "should_trigger": false },
{ "query": "Write the Amazon product listing copy, bullets and A+ content for our new SKU.", "should_trigger": false },
{ "query": "Optimize our Amazon PPC campaigns, ACoS is at 42%.", "should_trigger": false },
{ "query": "Lower our TACoS without losing buy box share.", "should_trigger": false },
{ "query": "We're building a two-sided marketplace. How do we solve the cold start problem?", "should_trigger": false },
{ "query": "Design the seller onboarding flow for the marketplace we're building.", "should_trigger": false },
{ "query": "Which payment processor should our marketplace use for split payouts?", "should_trigger": false },
{ "query": "Write the take-rate policy for the marketplace platform we operate.", "should_trigger": false },
{ "query": "Publish my skill to the skills marketplace so other people can install it.", "should_trigger": false },
{ "query": "Our finance team wants to consolidate SaaS purchases through our Azure commit. Write the procurement policy.", "should_trigger": false },
{ "query": "Negotiate our next AWS enterprise discount program commitment.", "should_trigger": false },
{ "query": "Pick a PRM tool for our partner team and plan the CRM integration.", "should_trigger": false },
{ "query": "Set up partner portal SSO and lead distribution rules.", "should_trigger": false },
{ "query": "Write the pricing and packaging for our new enterprise tier.", "should_trigger": false },
{ "query": "Should we move from seat-based to usage-based pricing?", "should_trigger": false },
{ "query": "Design the SDK and API surface partners will build integrations against.", "should_trigger": false },
{ "query": "Write the developer docs quickstart for our public API.", "should_trigger": false },
{ "query": "Our reseller margin is 25% and they want 35%. How do I respond?", "should_trigger": false },
{ "query": "Draft the MSA and DPA templates for our enterprise contracts.", "should_trigger": false },
{ "query": "Plan our booth and sponsorship at the AWS re:Invent expo hall.", "should_trigger": false },
{ "query": "Recruit ten new resellers in DACH next quarter.", "should_trigger": false }
]
}
references/marketplace-economics.md›
# Marketplace Economics: Take Rates, Fee Structures, and the Real Cost
Fees marked **(published)** are from the marketplace operator's own published schedule. They are the operator's rate card and can change: re-verify before acting.
Fees marked **(unverified)** are not confirmed against operator sources. Never state an unverified fee as fact.
## B2B cloud marketplaces
- **AWS Marketplace** (published; fees on pre-tax total contract value): SaaS public offers 3%; server (AMI/container/ML) public offers 20%; private offers 3% under $1M, 2% from $1M to under $10M, 1.5% at $10M+; all renewals 1.5%; channel partner private offers add +0.5%; professional services 0.5% (private offers only); South Korea buyers +1% (from 2025-04-01).
- **Microsoft commercial marketplace** (published): 3% standard store service fee on transactable offers; BYOL/non-transactable listings 0% (but then discovery-only, not a transaction channel); qualifying private-offer renewals get a 50% fee discount. Caution: Microsoft's docs state prepaid Azure credits cannot pay publisher license fees - do not conflate that with MACC consumption-commitment eligibility for marketplace purchases, a distinct program with its own rules; verify before asserting drawdown behavior.
- **Google Cloud Marketplace** (unverified): partner docs publish no rate card - the fee is deliberately opaque, making it a negotiation input, not a known constant. Reported rates describe ~3% standard with reductions for large private offers and renewals.
Strategic reads: the B2B pattern is a fee that _falls_ with contract size and on renewal, structurally rewarding large private offers over public self-serve. The 20%-vs-3% gap by deployment method (server image vs SaaS) is the largest single fee-structure decision on the biggest cloud marketplace.
Fees at ~3% are no longer the deciding variable: the operators price marketplace revenue as committed-spend stickiness, not as a toll. The real cost is operational.
## SaaS app stores
- **Shopify App Store** (published): emerging developers (under $20M lifetime App Store earnings and under $100M company revenue) keep 100% of the first $1M per year, 85% above; high-volume developers keep 85% of everything; 2.9% processing fee on all app billing; themes 85%.
- **Atlassian Marketplace** (published): operator's share by app architecture, with a published schedule of future increases - from 2026-04-01: Forge 16%, Connect 20%, Data Center 25%; from 2026-10-01: Forge 17%, Connect 25%, Data Center 25%. Forge incentive: 100% of gross revenue to the partner up to $1M lifetime Forge revenue (from 2026-01-01). Payout at $500 accrued, 30-day refund window.
- **Salesforce AppExchange** (unverified): reported 15% of net revenue for standard paid apps, 25% for OEM, plus a per-app security-review fee and annual listing fee.
Strategic reads - the two most transferable lessons in this file:
- **The take rate is a policy lever, not a constant.** An operator sets different rates per technical architecture and publishes future increases to steer ISV build decisions. Any business case built on today's rate must be stress-tested against the operator's announced and plausible future rates - and against the build choice the rate is designed to push.
- **Introductory 0% bands are acquisition subsidies, not the price.** A discount that expires at a revenue threshold (a first-$1M band) means the true cost arrives exactly when the listing starts mattering. Model the post-threshold rate as the real rate.
## Retail marketplaces
- **Amazon US** (Amazon's own seller pricing page): Individual plan $0.99/item; Professional $39.99/month; referral fees by category roughly 5-45% of sale price ($0.30 minimum in most categories) - e.g. electronics 8%, home & kitchen 15%, jewelry 20% up to $250 then 5%, device accessories 45%; media items +$1.80 closing fee. Fulfilment, storage, aging-inventory surcharges, and advertising come on top; blended cost-to-serve commonly reaches 30-45% of selling price.
- **eBay** (eBay's own seller fees page): most categories 13.6% of the sale total up to $7,500 then 2.35% on the portion above, plus a $0.30 (orders $10 or under) or $0.40 (orders over $10) per-order fee. The category spread runs from 0.5% (the portion of a Business & Industrial sale, e.g. heavy equipment, over $15,000) to 15.3% (Books, Movies & TV, Music, up to $7,500) - e.g. NFT categories 5% flat, Business & Industrial (heavy equipment and similar) 3% up to $15,000 then 0.5% above, Guitars & Basses 6.7%, Athletic Shoes priced $150+ 8% with no per-order fee, Coins & Paper Money and select Collectibles (comic books, non-sport and sports trading cards, collectible card games) 13.25%, Jewelry & Watches and Women's Bags & Handbags 15% up to a $2,000-5,000 threshold then 9% above. The 13.25% vs. 13.6% figure once flagged as aggregator-level disagreement is not decimal noise: both are real, distinct category rates on eBay's own fee page.
- **Walmart, TikTok Shop, Etsy** (aggregator-checked, not primary-page-verified): reported ranges are Walmart 6-15% (some categories up to 20%) referral with no subscription or listing fee; TikTok Shop 6% flat referral, with a 3% introductory rate for a new seller's first 30 days; Etsy $0.20 per listing plus 6.5% transaction fee plus 3%+$0.25 payment processing, roughly 10-12% all-in before Offsite Ads. Verify on the operator's own fee page before using an exact figure in a business case.
Strategic read: on retail marketplaces the take rate is set by _product category_, not by the seller's negotiating position or contract size - the exact opposite of the B2B cloud pattern. A B2B team can negotiate its effective rate down by deal structure. A consumer brand can only change its rate by changing what it sells or where.
## Committed-spend drawdown - the B2B buying driver
Eligible cloud-marketplace purchases retire a customer's pre-committed cloud spend (the three hyperscalers each run such commitment programs). The "use it or lose it" dynamic makes committed buyers highly motivated, turns a new budget request into an allocation of already-promised money, and is why procurement presence outweighs fee levels in prioritization.
Aggregate committed spend across the three providers was estimated near $470B as of late 2025 (analyst estimate - Omdia; independent, but an estimate). Drawdown eligibility rules and caps differ per provider and change: verify per program before promising it to a buyer.
## Total cost-to-serve - the number the take rate hides
Model the full stack, not the headline fee:
- **B2B**: listing/metering engineering (commonly cited 4-8 weeks), legal harmonization (EULA, DPA, support SLA), tax and payout configuration, a private-offer deal desk, co-sell operations, optionally a cloud GTM tooling subscription, plus a fractional-to-dedicated owner.
- **B2C**: referral fee + fulfilment + storage and aging surcharges + returns reserve + effectively-mandatory retail-media budget + pricing/MAP enforcement + (international) tax registration and compliance per market.
A gross-to-net waterfall per marketplace - list price minus every named deduction down to contribution - is the honest comparison format. Comparing headline take rates alone systematically flatters the platforms with the heaviest hidden stack.
references/marketplace-taxonomy.md›
# Marketplace Taxonomy and Depth-of-Participation Ladders
Five categories of third-party marketplace, each doing a different job. Misreading the job - expecting demand from a procurement rail, or procurement leverage from a discovery directory - is the root of most failed listings.
Every ordering below is a default, not a law: it shifts with context and with who executes it. Re-rank it against what the Interview already told you.
Effort here always means engineering weeks, deal-desk rework, contractual commitment, coordination and reversibility, never a fee. Take rates are subject matter, not the effort axis.
## Which category first
No single ordering spans all five. The Interview's B2B/B2C answer picks the list, and a blended rank across both would be false precision - no company chooses between a hyperscaler and Amazon.
**B2B software**
- efficiency: `hyperscaler cloud > integration directory > SaaS app store`
- value: `hyperscaler cloud > SaaS app store > integration directory`
- effort: `SaaS app store == hyperscaler cloud > integration directory`
- compliance cost: `SaaS app store > hyperscaler cloud > integration directory`
The effort tie is real, not a dodge: each rung costs about a quarter of coordinated work before a first dollar can transact, and neither compresses by adding an owner.
- Hyperscaler cloud: metering, entitlement, tax and payout setup.
- SaaS app store: billing integration and a platform review cycle.
The directory ranks second on an hour of work and a ceiling to match: run it in parallel as hygiene, never as the quarter's bet.
The order starves the SaaS app store: the same effort as the cloud rung, plus a permanent revenue share and an architecture the operator can reprice. Promote it above the cloud rung when the Interview says buyers live inside one platform's daily workflow and hold no committed cloud spend - and then delete the cloud listing from the memo rather than staging it.
**B2C / retail**
- efficiency: `dominant retail marketplace > regional champion`
- value: `dominant retail marketplace > regional champion`
- effort: `regional champion > dominant retail marketplace`
- compliance cost: `regional champion > dominant retail marketplace`
The order starves regional champions: tax registration, EPR obligations and localization land before the first order, each a standing job in a jurisdiction nobody on the team operates in. Promote one when the home market is proven and the target geography's incumbent is a different platform - a geography the dominant marketplace does not serve is reachable no other way.
## The five categories
- **Hyperscaler / cloud marketplaces** - a procurement and transaction rail for B2B software. The buying driver is committed-spend drawdown (a purchase retires budget the customer already promised to the cloud provider) plus co-sell access to the provider's field sellers. Take rates depend on how the product is delivered: 3% for SaaS listings but 20% for server images (AMI/container/ML) on AWS Marketplace, falling with deal size and on renewal, so resolve the deployment method before quoting a rate. Beyond that, the real cost is operational. Examples: AWS Marketplace, Microsoft commercial marketplace, Google Cloud Marketplace.
- **Integration directories** - discovery and credibility surfaces, usually free or near-free, rarely transactable. They support an integration story and search presence. They do not carry a revenue motion on their own.
- **SaaS app stores** - distribution attached to a platform that owns the buyer's workflow. Discovery genuinely exists here, but the platform charges for it: revenue shares in the 15-25% band are typical. The strategic question is whether one platform owns your ICP's daily workflow deeply enough to justify going all-in. Examples: Salesforce AppExchange, Shopify App Store, Atlassian Marketplace.
- **Retail / consumer marketplaces** - demand plus fulfilment for physical goods. The platform supplies traffic and (optionally) logistics, and takes a category-set referral fee plus fulfilment and effectively-mandatory ad spend. Blended cost-to-serve commonly reaches 30-45% of selling price on the dominant platforms. Examples: Amazon, Walmart Marketplace, eBay, Etsy, TikTok Shop.
- **Regional champions** - the dominant local marketplace in a geography. Examples: Allegro (Poland/CEE), Bol.com (Benelux), Otto and Zalando (Germany), Cdiscount and ManoMano (France), Mercado Libre (Latin America), Shopee/Lazada and Coupang (Asia). Gating steps are tax registration (VAT), compliance (EPR), and localization - not logistics.
## Depth-of-participation ladder - B2B cloud marketplaces
The one ladder where value and effort genuinely climb together, and the rungs are cumulative - so rank the destination you fund, not the sequence you walk.
- efficiency: `private offer > transactable > list-only > channel offer`
- value: `private offer > channel offer > transactable > list-only`
- effort: `channel offer > private offer == transactable > list-only`
- compliance cost: `channel offer > private offer > transactable > list-only`
Private offer and transactable tie on effort because each costs roughly a quarter before returning anything, in departments that cannot substitute for each other.
- Engineering builds metering, entitlement and payout.
- The deal desk rebuilds around negotiated terms and a written comp-neutrality policy.
Aim the business case at the private-offer rung and treat transactable as the toll: a case that stops at transactable has paid nearly the whole cost for the smaller half of the value.
Default rung: transactable, funded as a private-offer program. The condition that moves you up is first transactions closed, renewals first.
1. **List-only ("contact me")** - near-zero effort, near-zero revenue. Buys exactly one thing: proof that target buyers search there. Gate to climb: that evidence exists.
2. **Transactable public offer** - the listing can be bought. Requires metering/entitlement engineering (commonly cited at 4-8 weeks), legal document harmonization, tax and payout setup. Gate: those capabilities funded and owned.
3. **Private offer** - negotiated price and custom terms. It is the enterprise workhorse and where most cloud-marketplace revenue actually flows. Requires a deal desk rebuilt around private offers and comp neutrality in writing - political capital, not engineering. Gate: first transactions proven (renewals are the documented low-risk path) and field alignment started.
4. **Channel / multiparty private offer** - routes a reseller or SI into the transaction (CPPO on one major cloud; multiparty offers on others) for a small fee uplift, on top of a three-party contract and a standing co-sell operation. Gate: a real channel motion exists to route.
The order starves the channel rung. Promote it when a reseller or SI motion already exists and is asking to be routed, or when a target account will only buy through its incumbent reseller: there it is not an upgrade but the only path to that deal.
Delete every rung the user's effort ceiling rules out from the memo, and name which ones you deleted. A ruled-out rung parked at the bottom reappears later as scope.
## Depth-of-participation ladder - SaaS app stores
- efficiency: `transactable paid app > free listing > deep platform bet`
- value, effort and compliance cost all order the same way: `deep platform bet > transactable paid app > free listing`
1. **Free listing / basic integration** - directory presence tied to the integration: an hour of work, and a credibility surface, not a revenue one.
2. **Transactable / paid app** - platform billing, revenue share applies, and the platform's review becomes a dependency on every release.
3. **Deep platform bet** - build on the platform's preferred architecture, pursue featuring and co-marketing.
The order starves the deep bet: a quarter or more of engineering aimed at an architecture only one operator accepts, and the least reversible commitment in this file. Promote it when that platform owns the ICP's daily workflow _and_ the operator's fee schedule pays for the migration.
Operators price architectures differently to steer exactly this choice: on AWS Marketplace a SaaS listing takes 3% where a server image takes 20%. That gap is the decision this rung actually turns on.
## Depth-of-participation ladder - retail marketplaces (1P / 3P / hybrid)
- efficiency: `3P > 1P > hybrid`
- value: `hybrid > 3P > 1P`
- effort: `hybrid > 3P > 1P`
- compliance cost: `hybrid > 1P > 3P`
3P returns the most control and margin per unit of operational work. 1P buys simplicity by surrendering the one variable that decides a consumer channel - price - which is why it ranks below a heavier option.
- **3P (seller)** - you sell direct on the platform: keep retail price minus referral, fulfilment, and ad fees, and own pricing, inventory, and customer service. It is the default for margin and pricing control. Documented platform pressure pushes smaller vendors here.
- **1P (vendor / wholesale)** - the platform buys wholesale and controls price and fulfilment. Simpler operations, lost pricing control, margin set by wholesale terms and allowances (typically 10-15% of payments in deductions). Reserve for specific high-velocity products.
- **Hybrid** - both at once on the same product line. Requires a firewall between 1P and 3P teams (pricing not shared) and a written pricing policy before entry.
The order starves hybrid: it doubles the operating surface and carries this file's heaviest compliance load - MAP enforcement plus a pricing firewall someone must audit. Promote it only when a specific high-velocity SKU has already proven its 1P economics and the firewall and pricing policy exist in writing.
International sequencing for consumer brands has an established default: validate the home market first, expand to adjacent markets of the same platform, then regional champions - gated on tax/compliance/localization readiness each time.
## Reading the ladders as strategy
- Depth follows evidence, never ambition: each rung's gate is proof from the rung below.
- The most defensible pattern in both worlds is concentration - prove one platform at real depth before adding a second, rather than shallow presence everywhere.
- A platform that owns the buyer's procurement (committed spend) or workflow (daily-use app platform) justifies depth. One that owns neither justifies at most a list-only or 3P toe-hold with a delist trigger attached.
references/prioritization-scorecard.md›
# Marketplace Prioritization: Hard Gates, Weighted Scorecard, Four-Way Outcome
Three passes, in order: screen hard gates, score survivors, filter by impact × effort. End each candidate at one of four outcomes - never a bare yes/no.
## Pass 1 - hard-gate screen (before any scoring)
Check binary blockers first. Scoring a disqualified candidate wastes the effort.
- Platform terms the business cannot accept (exclusivity, data, pricing-parity, IP clauses).
- A take rate or fee floor the gross margin cannot absorb.
- A prerequisite the company lacks with no budget to build (metering engineering, fulfilment capacity, required certifications).
- Buyer evidence absent: no target accounts procure there and no committed-spend or traffic signal.
Rule: never convert an unresolved question into a rejection or an acceptance. An unverified fee, an unclear compliance obligation, or an unknown committed-spend footprint sends the candidate to **hold for verification** with a named owner and source that would resolve it.
## Pass 2 - weighted scorecard
Propose weights, agree them with the user before scoring, and show the formula. Leave a dimension unscored when no evidence supports it: an unscored cell is honest. An invented score is not.
Starting dimension set (tune per engagement - weights below are a B2B illustration, not a standard):
| Dimension | Illustrative weight | What it measures |
| ------------------------------- | ------------------- | ----------------------------------------------------------------------- |
| Buyer procurement presence | 25% | Committed spend or buying traffic of target accounts on this platform |
| Strategic / ICP fit | 15% | Does the platform own the buyer's workflow or category |
| Net economics | 15% | Take rate + cost-to-serve vs margin, at future rates |
| Operational cost to participate | 15% | Engineering, deal desk, tax/legal (B2B); fulfilment, returns, ads (B2C) |
| Competitive saturation | 10% | Category crowding; whether differentiation is possible on-platform |
| Co-sell / promotion access | 10% | Field-seller incentives, featuring, retail-media leverage available |
| Platform risk | 10% | Rate-change history, policy/algorithm volatility, dispute governance |
Composite = Σ(score × weight) on a 1-5 scale. Weight buyer-procurement evidence heaviest by default: it is the single most predictive variable in both worlds, and the one teams most often replace with wishful demand assumptions.
### Worked example (B2B SaaS, ~$40k ACV, sales-led)
| Candidate | Procurement 25% | Fit 15% | Economics 15% | Ops cost 15% | Saturation 10% | Co-sell 10% | Risk 10% | Composite |
| ----------------------- | ------------------------------------------------------- | ------- | ---------------------------------------------------- | ----------------------------------- | ---------------------- | ----------- | -------- | --------- |
| Cloud marketplace A | 4.5 (60% of target accounts hold committed spend there) | 4.0 | 4.5 (3% - SaaS listing, confirmed; falls on renewal) | 2.5 (metering + deal desk to build) | 3.5 | 4.0 | 4.0 | **3.9** |
| Workflow app store B | 2.5 (buyers use it, don't buy software there) | 4.5 | 2.5 (20% share, announced increase) | 3.5 | 2.0 (category crowded) | 3.0 | 2.5 | **3.0** |
| Integration directory C | 1.5 | 3.5 | 5.0 (free) | 5.0 | 3.0 | 1.5 | 4.0 | **3.2** |
Reading: A wins on procurement evidence despite the heaviest build cost - the ops gap is the thing to fund, not a reason to pick C. C's high composite is cheapness, not opportunity: it earns a low-effort listing, never priority investment.
B goes to "prepare" or "hold" until the announced fee increase is modeled. The negative pattern this table exists to prevent: ranking by ease (C first) or by brand gravity (B first) instead of by where buyers already procure.
### Negative example - the list-and-pray scorecard
Same company, the way this goes wrong. This is the failure the skill's own body calls "the most-cited failure in both B2B and B2C", shown rather than named.
| Candidate | Brand reach (25%) | Category size (25%) | Setup ease (25%) | Exec interest (25%) | Composite |
| ----------------------- | ----------------- | ------------------- | ---------------- | ------------------- | --------- |
| Workflow app store B | 5 | 5 | 4 | 5 | **4.75** |
| Cloud marketplace A | 3 | 4 | 2 | 3 | **3.00** |
| Integration directory C | 2 | 2 | 5 | 2 | **2.75** |
What is wrong, line by line:
- **No procurement dimension at all.** The single most predictive variable - whether target buyers already hold budget and a purchasing path on that platform - is absent, so the table cannot answer the question it was built for.
- **"Brand reach" and "category size" are demand assumptions wearing scorecard clothing.** A marketplace is a procurement rail. Neither column is evidence that anyone will find the listing, and together they are half the score.
- **Equal weights, no justification.** Nobody decided anything. The format decided.
- **No take-rate column, so no margin gate.** B is a 20% server-image listing with an announced increase. Here it wins.
- **"Setup ease" rewards the cheapest option** rather than costing the ops build honestly - the composite hides that A's 2.5 on ops is the thing to fund, not a reason to reject it.
- **"Exec interest" is the sponsored candidate scoring itself.**
- **No four-way outcome, no unscored cells, no delist trigger.** Everything is "go", ranked by charm.
The output looks rigorous and crowns the platform with the biggest logo and the worst economics. When a user brings a scorecard shaped like this, rebuild from the readiness gate and the demand-vs-procurement diagnosis rather than reweighting its columns.
## Pass 3 - second-pass filter
Plot scored candidates on impact × effort before committing sequence: expected revenue impact against total effort (engineering weeks, deal-desk rework, contractual commitment, coordination, reversibility). Never use the take rate as the effort axis: it is an input to impact, not a measure of work.
On the first pass the ROI model does not exist yet: plot a provisional impact estimate, label it as such, and leave a candidate unplotted rather than invent a number. Re-run the filter once the ROI model is built, and record any candidate that changed quadrant.
Order the quadrants by value per unit of effort, and say the order out loud rather than leaving it implied:
- efficiency: `high impact + low effort > high impact + high effort > low impact + low effort > low impact + high effort`
Each quadrant gets a different response:
- The first starts now.
- The second is staged behind gates.
- The third runs lean or waits.
- The fourth is declined regardless of composite score: delete it from the memo and name it, rather than ranking it last where it returns as scope.
The filter catches what a composite hides: a strong score driven by cheap dimensions.
That order starves the second quadrant, and the biggest procurement unlocks live there. Promote a high-impact/high-effort candidate above a cheaper one when the effort is a one-time build the company owns afterwards - metering, a deal desk, a tax registration - rather than a recurring cost, and when the user's stated effort ceiling covers it.
## Four-way outcome per candidate
- **Pilot** - evidence supports a limited, gated start now. Envelope and delist trigger attached.
- **Prepare** - promising, but named work (capability, policy, verification of one number) must finish before commitment.
- **Hold for verification** - an unknown (fee, compliance, procurement footprint) could change feasibility. Name the owner and the source that resolves it.
- **Do not prioritize** - weaker fit than alternatives. Record what would change the decision, so the ranking can be revisited without re-running the whole exercise.
Re-score on the memo's review cadence and on trigger events: an operator fee change, a platform policy shift, or new evidence of buyer procurement moving.
references/roi-and-kpis.md›
# Marketplace ROI and KPIs - With Provenance Flags
Rule for every number in this file and every number the memo quotes: attach who published it and who paid for it. In this field, nearly every quotable ROI figure originates with a party that profits when the number looks good: the platforms, the GTM-tooling vendors, and the agencies.
The directional claims (marketplace/co-sell deals close faster, larger, at higher win rates; contribution margin decides consumer channels) are corroborated widely, but the precise percentages are marketing. No peer-reviewed validation of the headline uplift claims was found.
## KPI set - B2B
- Marketplace-sourced vs marketplace-influenced revenue (define both with finance before launch).
- Marketplace revenue as % of total; net-new vs relocated revenue, separated.
- Time to first transaction; private-offer share of marketplace revenue.
- Deal-size, cycle-time, and win-rate deltas vs the direct baseline (measure your own, don't quote vendors').
- Co-sell pipeline: registered opportunities, field-seller engagement.
- Cost-to-serve per marketplace vs the fee-plus-ops envelope in the memo.
## KPI set - B2C
- Contribution margin per marketplace after referral, fulfilment, ads, and returns - the primary success variable.
- TACoS (ad spend ÷ total revenue) for business health; ACoS for campaign efficiency. A rising TACoS with flat revenue means ads are propping up demand that won't survive without them.
- Featured-offer/buy-box win rate, share of search, conversion rate, sell-through, returns rate, order-defect rate.
## Published benchmarks and their provenance
| Claim | Source | Provenance flag |
| -------------------------------------------------------------------------------------------------------------------------------- | ----------------------------------------------------- | ---------------------------------------------------------------------------------------- |
| Win rates +27%, deal sizes 80% larger, sales cycles 40% faster for cloud-marketplace ISVs | Forrester TEI study, 2022 | Commissioned by the marketplace operator (AWS); 12 interviews + 60 surveys |
| 377% buyer ROI, 6-month payback from marketplace procurement | Forrester TEI, 2025 | Commissioned by the same operator |
| 234% ROI, up to 50% faster closure, 4-5x larger deals for channel partners | Forrester TEI, 2023 | Commissioned by the same operator |
| 89% of B2B software firms are listed, but only 22% get >20% of revenue via marketplace; 41% under 5%; 62% report net-new revenue | Clazar + Partner Insight survey, 2025, 100+ companies | GTM-tooling vendor; self-selected sample - but the most-cited reality check in the field |
| 64% of ISVs run comp-neutral models (up from 54%) | Tackle State of Cloud Marketplaces, 2024 | GTM-tooling vendor survey, self-reported |
| Partner-attached deals close 53% more often, 46% faster / 2-3x win rates, 2.5-3x size | Crossbeam; WorkSpan | Ecosystem-platform vendors |
| A large security ISV's cloud-marketplace sales cycle cut "by almost 50%" | CEO public statement | Customer testimony; directional only |
| Cloud-marketplace software sales $30B (2024) → $163B (2030), ~29% CAGR | Omdia, Oct 2025 | Independent analyst - prefer for sizing |
| $85B through cloud marketplaces by 2028 | Canalys | Independent analyst (often misattributed to Forrester) |
| Healthy ACoS ~15-25%; healthy TACoS ~5-15% established, 25-40% during launch | Multiple retail agencies | Agency-authored; ranges vary by agency - directional, not a platform standard |
Use the published benchmarks with this discipline:
- Use the vendor-flagged figures only as ceilings or direction.
- Use the two analyst forecasts for market sizing.
- Use the 89%/22% listing-to-revenue gap as the honest base-rate warning: most listings produce little revenue without co-sell or ad investment.
## Building a defensible ROI expectation
1. Baseline first: capture direct-motion win rate, cycle time, deal size (B2B) or channel contribution margin (B2C) before the listing goes live - without it, relocated revenue will masquerade as marketplace ROI.
2. Build the base case from your own funnel and the platform's verified economics, at the operator's future rate, never from a published uplift figure.
3. Treat commissioned-study uplifts as the ceiling scenario and label them as such in the memo.
4. Set expectations against the base rate: plan for the modal outcome (a listing that needs co-sell or ad investment to produce), not the case-study outcome.
5. Define the measurement plan in the memo: metric owners, sourced/influenced definitions agreed with finance, review cadence, and the delist trigger's metric and date.
6. If you can browse the web, re-verify each quoted benchmark and fee against its current source at engagement time. Published figures in this field change and rot quickly. If you cannot, say which numbers are unverified as of this run.
SKILL.md›
---
name: partner-marketplace-strategy
description: Decide which third-party marketplaces to list on, how much to invest in each, what ROI to expect, and when to delist - marketplace prioritization for partner teams. Covers cloud marketplace listing strategy, SaaS app store and integration directory prioritization, and retail marketplace selection for ecommerce (1P vs 3P vs hybrid), with a readiness gate, weighted scorecard, and provenance-flagged ROI expectations. Use whenever the user mentions AWS, Azure or GCP marketplaces, an app store listing, an integration directory, or asks whether a marketplace listing is worth it, even if they never say marketplace strategy. Do NOT use for choosing which partner category to launch next - use mbfinotti/partnerships-skills@partner-ecosystem-expansion instead.
license: MIT
metadata:
author: Maya-Beth Finotti
version: "1.0.3"
---
# Partner Marketplace Strategy
Set the strategy for listing on third-party marketplaces: which ones, how deep, in what order, with what investment, and the condition that ends it. The working method assembles:
- The list → transact → co-sell → scale capability ladder (broad B2B practitioner consensus).
- Tackle's Cloud GTM Maturity Model (vendor-authored, it sells stage-by-stage tooling).
- McFadyen Digital's Marketplace Maturity Model (consultancy-authored, B2C).
- For reading the vendor landscape: the Canalys Global Co-Sell Software Leadership Matrix, IDC MarketScape marketplace assessments, and Gartner's PERM market guide (independent analyst), plus Jay McBain's ecosystem work as the most credible individual voice.
No framework in this field has independent longitudinal validation. Every staged model is authored by a party selling the journey: use them as structure, not as evidence.
The output is a decision artifact an executive funds: the Marketplace Strategy memo, never execution work.
- Listing-form content, store optimization, and ad tactics belong elsewhere.
- Per-partner economics, named-alliance ranking, and joint GTM plans hand off to sibling skills (see Reference).
## Interview
Ask before strategizing. Ask one question per message, and offer multiple-choice answers when possible. Skip a question only when the user already gave the answer.
- B2B software, consumer brand, or hybrid?
- Product type and deployment model: SaaS, self-hosted/installable image, physical goods, services?
- Price band: typical ACV or order value, and gross margin? How much margin can a platform take rate consume?
- Which channels sell today, and does the direct motion already work repeatably? What is the evidence?
- Where does target buyers' procurement already sit: committed cloud spend (and with which provider), a dominant retail platform, or neither?
- Do buyers purchase through a marketplace today? Any committed-spend contracts among target accounts?
- Who owns this decision, and who must approve it (revenue, finance, product - or ecommerce, marketing, finance)?
- B2B: how is a marketplace-routed deal treated in sales compensation today - neutral, penalized, or undefined?
- Operational capacity: metering/entitlement engineering, deal desk, tax/legal for B2B, or inventory, fulfilment, returns, retail-media budget for B2C?
- What does success mean, in which metric, and by what date must the result land?
- Is this a one-off revenue win this period, or a compounding procurement asset that pays over years?
- What is the effort ceiling: engineering weeks available, deal-desk or fulfilment headcount, political capital for a comp-plan change, and how reversible the commitment must be?
The last three answers re-rank every option menu in this skill. Say out loud which answer moved which option:
- A hard near-term date promotes list-only and 3P, and demotes anything needing a build.
- A compounding mandate promotes the private-offer and deep-platform-bet rungs.
- A low effort ceiling deletes the channel/multiparty and hybrid rungs from the memo outright, rather than parking them at the bottom.
## Workflow
Hold three disciplines across every step:
- **Present options, then wait.** Wherever a real choice exists (which platform first, scorecard weights, depth of participation, 1P vs 3P, the delist condition), present 2-3 candidate approaches with trade-offs and a recommendation, then wait. Never present one option as the only one.
- **Flag provenance on every benchmark quoted.** Nearly all published marketplace ROI figures come from parties that profit when the number looks good: platform-commissioned studies, GTM-tooling vendors, agencies. Label each as operator-published, vendor, commissioned study, analyst, or agency, and treat precision as marketing.
- **Re-rank against the user.** Every ordering in this skill and its references is a default, not a law: it shifts with context and with who executes it. Say which fact moved which option, e.g. an existing metering and entitlement system deletes most of the transactable rung's cost, a committed-spend customer already asking to buy through the marketplace promotes the private-offer rung above everything else, and no deal desk at all demotes it below a rung the team can actually run.
Work in the profession's own collaborative formats, not generic brainstorming:
- B2B: business-case templates and stage-gate readiness reviews, QBRs with the marketplace/platform team, comp-neutrality policy drafted before the quarter, account mapping as the shared data layer.
- B2C: channel P&L models, written go/no-go criteria, pre-launch readiness checklists, weekly pacing reviews, and 90-day retros.
1. Run the Interview. Confirm scope is one business area with a stated goal before evaluating anything.
2. Apply the readiness gate. It is allowed to answer "not yet". Disqualifiers:
- Direct motion not yet repeatable: a marketplace amplifies a working motion; it does not create one.
- Margin that cannot absorb the take rate plus cost-to-serve. Resolve the deployment model first, because the take rate follows it: 3% for a SaaS listing but 20% for a server/AMI/container/ML image on AWS Marketplace, a gap that decides this gate on its own.
- No named owner or executive sponsor.
- Missing operational capacity with no budget to build it.
If disqualified, say so, name what must change, and stop.
3. Run the demand-vs-procurement diagnosis and write the answer down. A marketplace is primarily a transaction and procurement rail, not a demand-generation channel: "list and pray" is the most-cited failure in both B2B and B2C.
State explicitly what this listing is being asked to do:
- Unlock committed-spend budgets and shorten procurement.
- Capture demand that genuinely searches there.
If the plan assumes demand the platform will not supply, the plan funds demand generation or does not proceed.
4. Inventory candidate marketplaces by category (hyperscaler/cloud, SaaS app store, integration directory, retail marketplace, regional champion), anchored on where the Interview says buyer procurement and traffic already sit. Evaluate in default efficiency order: value returned per unit of effort, where effort is engineering weeks, deal-desk rework and reversibility, never a fee. No order spans both sides:
- B2B: `hyperscaler cloud > integration directory > SaaS app store`
- B2C: `dominant retail marketplace > regional champion`
If you can browse the web, extend the inventory from competitor listings, platform partner directories, and category neighbors. See [references/marketplace-taxonomy.md](references/marketplace-taxonomy.md) for the per-axis orderings and what each order starves.
5. Screen hard gates before scoring: scope violations, platform terms the business cannot accept, missing prerequisites. Mark unresolved compliance or fee questions "hold for verification". Never convert an unknown into a rejection or an acceptance.
6. Score survivors on the weighted prioritization scorecard: propose weights, agree them with the user before scoring, leave unsupported dimensions unscored rather than invent precision. Then apply the second-pass impact × effort filter on a provisional impact estimate - the ROI model is not built until step 11, so label the axis "provisional" and leave a candidate unplotted rather than inventing an impact number. Give each candidate a four-way outcome - pilot, prepare, hold for verification, do not prioritize - not a binary go/no-go. See [references/prioritization-scorecard.md](references/prioritization-scorecard.md).
7. Verify the economics of every ranked candidate.
- If you can browse the web, read the operator's own published schedule and date it.
- Otherwise, ask the user for it, and mark anything they cannot supply "unverified" rather than assuming a rate.
Where the operator publishes no rate card at all, record that as a finding: the fee is a negotiation input, not a constant. Stress-test the business case against announced future rates and post-subsidy rates, not just today's. See [references/marketplace-economics.md](references/marketplace-economics.md).
8. Decide depth of participation per prioritized marketplace. Each rung has its own cost and capability gate, so rank by value per unit of effort rather than by rung order:
- B2B cloud: `private offer > transactable > list-only > channel offer`
- SaaS app store: `transactable paid app > free listing > deep platform bet`
- Retail: `3P > 1P > hybrid`
The cloud rungs are cumulative: aim the business case at the private-offer rung and treat transactable as the toll to reach it, because a case that stops at transactable pays nearly the whole cost for the smaller half of the value. Delete every rung the user's effort ceiling rules out from the memo, and name which. Never park it at the bottom. See [references/marketplace-taxonomy.md](references/marketplace-taxonomy.md) for the per-axis orderings, the ties, and what each order starves.
9. Sequence: one platform first, prove the motion, then expand. Define the gate that unlocks each stage - e.g. first transactions closed (renewals are the documented low-risk proof path in B2B), comp policy in writing, contribution margin positive - and the evidence each gate requires.
10. Set the investment envelope: platform fees, the real cost-to-serve, and a named owner's time.
- B2B cost-to-serve: integration/metering engineering, deal desk, legal/tax setup.
- B2C cost-to-serve: fulfilment, returns reserves, effectively-mandatory retail media.
A listing without an owner and an envelope is visibility, not pipeline.
11. Build the ROI expectation and its measurement plan:
- Baseline before listing.
- Sourced vs. influenced definitions agreed with finance.
- Net-new vs. relocated revenue, separated.
- KPIs per side.
Use published benchmarks only as provenance-flagged ceilings, never as the base case. Then re-run step 6's impact × effort filter against the finished model, and record every candidate whose quadrant moved. That shift is a finding, not a correction to bury. See [references/roi-and-kpis.md](references/roi-and-kpis.md).
12. Write the delist/deprioritize trigger now, before launch: the condition and review date that ends or downgrades a listing (e.g. ops cost with no transactions after an agreed number of quarters of genuine effort, or contribution margin negative after ads and returns). A trigger decided up front survives sunk-cost pressure. One decided later rarely fires.
13. Present the memo section by section, in the order shown below, and validate each section with the user before drafting the next. Require explicit approval on every section before finalizing.
14. Check the finished memo against the Pass Threshold, and iterate until it passes. If no candidate passes, recommend not listing and record why: that is a valid, fundable outcome.
15. If your harness has persistent memory, memorize the approved decisions (ranked marketplaces, weights, depth choices, envelope, gates, delist trigger) so later runs start from them instead of re-interviewing.
## The Marketplace Strategy Memo
Deliver every engagement as this decision record:
```
MARKETPLACE STRATEGY - <company / business area>, <date>
Scope : product line, ICP, geography; B2B, B2C, or hybrid; what was excluded
Diagnosis : demand vs procurement - what each listing is being asked to do
Candidates : marketplaces evaluated, hard-gate screen results, holds for verification
Prioritization : scorecard result with weights shown; second-pass filter; four-way
outcome per candidate (pilot / prepare / hold / do not prioritize)
Depth : per marketplace - list-only / transactable / private offer / channel
offer (B2B) or 1P / 3P / hybrid (B2C); the rung funded, the reason,
and the rungs deleted because the effort ceiling rules them out
Economics : take rate per ranked marketplace with source and date ("unverified"
stated where it is); envelope vs gross margin; comp treatment (B2B)
or contribution margin after ads/returns/fulfilment (B2C), in writing
Staged plan : one platform first; the gate and evidence that unlock each stage
ROI expectation: expected range and payback horizon; provenance flag on every
benchmark used to build it
Delist trigger : the condition and date that deprioritizes or removes each listing
Owner : named owner, approvers, review date
Open questions : what could not be verified, and what would verify it
```
Every line carries a reason a reviewer can check. The open-questions section is mandatory: a memo with no stated uncertainty stopped asking.
## Pass Threshold
The memo is done when all of these hold. Iterate until they do:
- **Every ranked marketplace has a take rate with a named source and date**: the operator's own published schedule where one exists, explicitly "unverified" where not. No silently assumed fees.
- **The business case survives the operator's announced future rate and post-subsidy rate**, not just today's schedule.
- **A named owner and approver exist**: "listed but no one owns the results" is the field's most common quiet failure.
- **Comp treatment (B2B) or contribution margin after ads, returns, and fulfilment (B2C) is decided in writing** before launch.
- **Every benchmark carries a provenance flag** (operator, vendor, commissioned study, analyst, agency).
- **A delist trigger with a review date exists**, written at approval time.
- **The demand-vs-procurement diagnosis is answered explicitly** in the memo.
## B2B and B2C
The decision logic is genuinely identical on five points. Say so instead of reinventing the method per side:
- The marketplace is a transaction mechanism, not a lead source ("list and pray" fails in both).
- Channel conflict is a first-class design problem (comp neutrality in B2B, MAP policy and the 1P/3P firewall in B2C).
- Sequence one platform, prove it, then expand, gating expansion on operational readiness.
- Measure influenced revenue as well as sourced revenue.
- Watch concentration risk and net-new vs. relocated revenue.
What genuinely differs:
| Dimension | B2B software / cloud | B2C / retail |
| ------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------ | ---------------------------------------------------------------- |
| Decision owner | Alliances / cloud GTM lead, chief partner or ecosystem officer | Head/VP of Ecommerce, marketplace manager |
| Approvers | CRO + CFO + product | VP Ecommerce / CMO + finance |
| Core buying driver | Committed-spend drawdown + co-sell access | Consumer demand, search ranking, fulfilment promise |
| Platform take | Deployment-dependent, not a constant: 3% for SaaS but 20% for server/AMI/container/ML images on the largest cloud marketplace; falls with deal size and on renewal | 6-45% by category, plus fulfilment and ads |
| Primary success variable | Sales-comp neutrality | Contribution margin after ads/returns/fulfilment |
| The marketplace really is | A procurement rail on an existing sales motion | A net-new operating business (listings, inventory, ads, returns) |
## Failure Modes
| Failure | Fix |
| --------------------------------------------------------------------------------------- | --------------------------------------------------------------------------------- |
| List and pray - listing treated as a demand channel | Demand-vs-procurement diagnosis in writing; fund demand separately or do not list |
| Comp plan penalizes marketplace deals; reps route around it (B2B) | Comp-neutrality policy written before the quarter, in the memo |
| Listed, but no one owns the results | Named owner and envelope in the memo; no owner means no listing |
| Business case built on today's take rate or an introductory 0% band | Stress-test announced future rates and post-subsidy rates |
| Hidden cost-to-serve breaks the case late (metering, tax, deal desk; VAT, returns, ads) | Full cost-to-serve inside the envelope before approval |
| 1P/3P self-competition or price erosion on the same product (B2C) | Firewall and pricing policy decided before going hybrid |
| Relocated revenue counted as marketplace ROI | Baseline before listing; separate net-new from shifted |
| Second platform added before the first proves | Stage gates with evidence; renewals-first proof on platform one |
| Delist decision deferred until sunk cost dominates | Trigger and date written at approval time |
## Invocation Examples
- "Should we list on a cloud marketplace? We sell a self-hosted container image at $40K ACV, sales-led, direct motion works."
- "We are listed on three marketplaces and none of them transact. Tell me which to keep, which to deprioritize, and what the delist trigger should be."
- "Build the business case for a transactable listing, including the take rate and the real cost-to-serve."
## Reference
- [references/marketplace-taxonomy.md](references/marketplace-taxonomy.md) - marketplace categories and depth-of-participation ladders, each ranked by value per unit of effort, with the per-axis orderings and what each order starves.
- [references/prioritization-scorecard.md](references/prioritization-scorecard.md) - hard-gate screen, weighted scorecard mechanics with a worked example, second-pass filter, four-way outcome gates.
- [references/marketplace-economics.md](references/marketplace-economics.md) - verified take rates with dates and sources, fee-structure strategic reads, committed-spend drawdown, total cost-to-serve.
- [references/roi-and-kpis.md](references/roi-and-kpis.md) - KPI sets per side, published benchmarks with provenance flags, building a defensible ROI expectation.
Sibling skills (same collection):
- `mbfinotti/partnerships-skills@partner-ecosystem-expansion` - adding new partner categories beyond marketplaces; use for scope decisions about non-marketplace channels.
- `mbfinotti/partnerships-skills@co-selling-strategy` - the co-sell motion a transactable cloud listing unlocks.
- `mbfinotti/partnerships-skills@joint-gtm-planning` - the joint motion with one named partner or platform after this strategy picks it.
- `mbfinotti/partnerships-skills@partner-channel-conflict` - rules of engagement for the conflict zones a marketplace creates.
- `mbfinotti/partnerships-skills@partner-performance` - ongoing scorecards and review cadence once listings run.
- `mbfinotti/partnerships-skills@partner-economics` - unit economics of one partner relationship, including one platform relationship.