npx skills add ...
npx skills add mbfinotti/partnerships-skills --skill 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.
npx skills add mbfinotti/partnerships-skills --skill 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:
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.
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.
The last three answers re-rank every option menu in this skill. Say out loud which answer moved which option:
Hold three disciplines across every step:
Work in the profession's own collaborative formats, not generic brainstorming:
Run the Interview. Confirm scope is one business area with a stated goal before evaluating anything.
Apply the readiness gate. It is allowed to answer "not yet". Disqualifiers:
If disqualified, say so, name what must change, and stop.
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:
If the plan assumes demand the platform will not supply, the plan funds demand generation or does not proceed.
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:
hyperscaler cloud > integration directory > SaaS app storedominant retail marketplace > regional championIf you can browse the web, extend the inventory from competitor listings, platform partner directories, and category neighbors. See references/marketplace-taxonomy.md for the per-axis orderings and what each order starves.
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.
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.
Verify the economics of every ranked candidate.
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.
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:
private offer > transactable > list-only > channel offertransactable paid app > free listing > deep platform bet3P > 1P > hybridThe 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 for the per-axis orderings, the ties, and what each order starves.
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.
Set the investment envelope: platform fees, the real cost-to-serve, and a named owner's time.
A listing without an owner and an envelope is visibility, not pipeline.
Build the ROI expectation and its measurement plan:
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.
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.
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.
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.
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.
Deliver every engagement as this decision record:
Every line carries a reason a reviewer can check. The open-questions section is mandatory: a memo with no stated uncertainty stopped asking.
The memo is done when all of these hold. Iterate until they do:
The decision logic is genuinely identical on five points. Say so instead of reinventing the method per side:
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 | 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 |
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.