mbfinotti/partnerships-skillsチェック済み
SKILL DETAIL
partner-ecosystem
mbfinotti/partnerships-skills/partner-ecosystem
Map a company's partner and channel ecosystem as a strategy exercise - an inventory of every partner type (resellers, distributors, MSPs, ISVs, SIs, affiliates, marketplaces, plus retail, creator, licensing and co-branding partners for consumer brands), partner account overlap analysis, channel coverage gaps and conflict zones, a weighted partner scorecard, and a prioritization 2x2. Use whenever the user mentions partner ecosystem mapping, a partner landscape, channel coverage, partner type classification, ecosystem whitespace, or which partner categories deserve investment, even if they never say ecosystem. Do NOT use for sequencing which category to launch next - use mbfinotti/partnerships-skills@partner-ecosystem-expansion instead.
インストール · 513出典を見る
Installation
npx skills add https://github.com/mbfinotti/partnerships-skills --skill partner-ecosystem
スキルファイル
SKILL.md
最終同期 · 2026/10/23
evals/evals.json›
{
"skill_name": "partner-ecosystem",
"evals": [
{
"id": 1,
"prompt": "I'm the first partnerships hire at Meridian Stack - B2B SaaS, about 140 people, three product lines (a data-quality product, an observability product, and a compliance-reporting add-on we launched in March). My VP wants a partner ecosystem map for the whole company by the end of the month. I've pulled the raw material together already: 34 companies that emailed our partnerships@ alias over the past year asking to partner, plus 11 agencies and consultancies I know personally from my last job. Can you turn that into the map? ARR is about $18M, mid-market ICP, sales-led with a self-serve entry tier.",
"expected_output": "A refusal to map all three product lines at once, a scoping choice offered back to the user, rejection of the inbound-request and personal-network list as an inventory source, a redirect to the internal data pull as the first evidence source, and the remaining interview questions - not a finished map.",
"files": [],
"expectations": [
"Refuses to map all three product lines at once and states the one-business-area scoping rule.",
"Offers the named product lines as two or three candidate scopes and waits for the user to choose rather than picking one silently.",
"Names the inbound partnerships@ list and the personally-known agencies as an invalid source for the inventory rather than accepting them as the starting list.",
"Gives the reason: teams that build inventories that way sign partners with no shared accounts, no shared ICP, and no path to joint pipeline.",
"Directs the inventory to be rebuilt from customer and CRM evidence instead.",
"Names the internal data pull - CRM records, closed-won notes, support tickets, integration and product usage - as the evidence source to start with.",
"Justifies starting there on the ground that every name it returns is evidence the player touched a real customer.",
"Keeps the 34 inbound companies only as unverified candidates to check against customer evidence, never as inventory.",
"Asks what decision is waiting on the map and by what date.",
"Asks whether this is a one-off executive ask or a compounding asset.",
"Asks the effort ceiling: the user's own hours, whose calendars they can command, how much political capital they can spend.",
"Does not produce a finished ecosystem map, classification, or prioritization in this reply."
]
},
{
"id": 2,
"prompt": "Rowanbridge Analytics - B2B SaaS for hospital finance teams, about 9M in ARR, 60 staff. I am the entire partnerships function: one person, no budget, and I can't get an hour on anyone else's calendar until Q3 because the exec team froze all internal meetings during the funding round. I need the partner landscape for our revenue-cycle product in roughly three weeks. Also worth knowing: I work from a locked-down laptop with no internet access at all, so anything outside our own systems and my own phone calls is off the table. Where do I get the raw material from, and in what order?",
"expected_output": "An evidence-source ordering stated explicitly, with the workshop and the public sweep both deleted for this user's stated constraints and named as deleted, the internal data pull recommended as the default, and customer interviews named as the escalation with its trigger.",
"files": [],
"expectations": [
"Names the internal data pull as the default and the place to start.",
"States the ordering of evidence sources out loud rather than leaving it implied by the order of a list.",
"Separates effort from value rather than collapsing them into one blended ranking.",
"States that the internal data pull and the public sweep tie on effort: each is an hour or two of one person, needing nobody's permission and no calendar.",
"States that they do not tie on value, and that the internal data pull wins that axis because only its output is evidence about this company's own customers.",
"Deletes the Value Network Analysis participative workshop because the user's effort ceiling is solo, and says explicitly that it is deleted rather than merely ranking it last.",
"Gives the reason the workshop is deleted: it needs other people to say yes.",
"Deletes the public sweep because the user cannot browse the web, and says so rather than listing a source nobody can reach.",
"Does not recommend competitor partner directories, marketplace listings, review-site category neighbours, or conference sponsor lists to this user.",
"Names customer interviews as the escalation and gives the trigger: closed-won notes naming third parties that cannot be classified, or an empty influence band.",
"States that an empty influence band is a gap in the company's own logging rather than evidence the ecosystem has no influencers.",
"Does not put the workshop first on the strength of its value alone."
]
},
{
"id": 3,
"prompt": "Calderwood Systems, B2B SaaS, workforce scheduling for logistics companies, $24M ARR. The ecosystem map for our EU business goes in front of the board on 3 December, so about three weeks out. One of our integration partners, Fenwick Logistics Cloud, has verbally agreed to swap filtered account lists with us. Our legal team quotes six weeks minimum for any data-sharing agreement plus a privacy review, and nobody else has agreed to share anything yet. I'd much rather have real account-level overlap numbers than guesses - how do I get them in time?",
"expected_output": "The interview-and-tech-stack proxy recommended as the mechanic for this map, account mapping deleted with its reason recorded rather than parked as phase two, the compliance-cost axis surfaced separately, and an explicit ban on the board deliverable claiming account-level overlap it did not measure.",
"files": [],
"expectations": [
"Recommends the interview-and-tech-stack proxy as the overlap mechanic for this first map.",
"States plainly that the proxy is directional per category and never per account.",
"States that permissioned account mapping is the only mechanic that yields overlap at account granularity.",
"Deletes account mapping for this map because the privacy review will not clear inside the three-week window.",
"Records the deletion together with its reason rather than carrying account mapping as a phase-two item.",
"Gives the reason for that rule: a mechanic parked as phase two is how a map ships claiming account-level overlap it never measured.",
"Surfaces compliance cost as its own axis, naming the data-sharing agreement, the privacy review, and an account list that cannot be un-shared once sent.",
"States that account mapping only overtakes the proxy on efficiency once three or more partners will share, because the legal and filtering setup is paid once and reused per partner.",
"Notes that only one partner has agreed here, which keeps the proxy ahead on efficiency.",
"Does not let the absence of account mapping stall or postpone the exercise.",
"Requires overlap to be approximated from evidence - what customers say they use and buy through - never from assumption.",
"States that the board deliverable must not present account-level overlap figures it did not measure."
]
},
{
"id": 4,
"prompt": "Here's my player list for Ostara Cloud's identity product (B2B, enterprise, roughly $40M ARR). Classify each one, one label each, so I can drop it straight into a spreadsheet column. Halbrook IT - resells our licences turnkey with a bit of config, no ongoing contract. Stenning Group - runs our product for 40 client hospitals on a monthly retainer, and also resells licences to them. Verrick Partners - builds custom identity architectures across four vendors including us, big enterprise projects. AWS Marketplace - about 15% of our new bookings flow through it. Dunmore Labs - they built an integration into their HR suite and ship it to their own customers. I also deliberately left Caskett Identity and two other competitors off the list since they aren't partners. Give me the single cleanest label for each so the map stays readable.",
"expected_output": "A two-axis classification rather than one label per player, hybrid roles recorded as hybrid, the MSP/VAR and SI/VAR boundaries drawn on the stated criteria, the marketplace kept on the map as a route to market, and the excluded competitors put back.",
"files": [],
"expectations": [
"Classifies each player on two axes - role in the customer journey and engagement depth - rather than assigning one label.",
"Names the journey-role axis as influence, transact, or integrate-and-deliver.",
"Attributes the trifurcation of the channel to Jay McBain (Canalys).",
"Names the engagement-depth rungs: listing, integration, co-marketing, co-selling, embedded.",
"Refuses the single-cleanest-label request for the players carrying more than one role and records hybrid roles as hybrid.",
"Records Stenning Group as carrying both an MSP role and a reseller role rather than picking one.",
"Distinguishes MSP from reseller/VAR by contract duration rather than by activity.",
"Classifies Halbrook IT as a reseller/VAR that resells turnkey with additions and Verrick Partners as an SI that builds new custom solutions, stating that distinction.",
"Treats AWS Marketplace as a route to market rather than a partner per se, while keeping it on the map because it transacts and influences.",
"Puts the excluded competitors back on the map and states that coopetition, and the partners shared with competitors, is signal rather than noise.",
"Does not rank or score the engagement-depth rungs against each other.",
"Does not recommend moving any named player up the depth ladder as an output of this classification step.",
"States that a forced single label is a misclassification that misroutes enablement and compensation."
]
},
{
"id": 5,
"prompt": "Thornhill Data, B2B SaaS, $31M ARR. I have four ecosystem categories and last quarter's partner-sourced revenue for each. Rank them so I know where next year's partner budget goes, and use one 5-point scorecard across all four so the comparison stays fair. Referral/affiliate band: $410K sourced last quarter, dirt cheap to run, 31 partners. ISV/integration partners: $95K sourced, but integrations came up in a lot of our closed-won notes and our API already shipped - no partner manager assigned to them though. Regional SIs: $0 sourced, the enterprise segment is basically uncovered for us, and we have no implementation docs. Cloud marketplace listing: $60K sourced, buyers in our segment mostly aren't procuring there yet. Rank by revenue contribution and tell me the budget split.",
"expected_output": "A refusal of both the single shared scorecard and the revenue-first ranking, the four categories placed on the strategic-fit x ease-of-execution 2x2 with the quadrant order stated, and the two out-of-scope ranking questions handed off by name.",
"files": [],
"expectations": [
"Refuses the single shared scorecard and requires scorecard weights segmented by partner type.",
"Gives the reason: each partner type has a different route to revenue, cycle length, and influence.",
"Rejects ranking by last quarter's partner-sourced revenue as over-weighting a lagging indicator.",
"States that over-weighting lagging revenue is the most-cited error the scorecard exists to prevent, and that here it would rank the referral band first and the ISVs last.",
"Plots the four categories on a strategic fit x ease of execution 2x2 instead of a single revenue ranking.",
"Attributes the partnerships-specific 2x2 to Chris Lavoie.",
"Names the four quadrants: holy grail, next best choice, uphill battle, low priority.",
"States the resulting order out loud: holy grail > next best choice > uphill battle > low priority.",
"Places the ISV/integration category in the holy grail quadrant, citing the closed-won evidence and the shipped API.",
"Names the missing partner manager as the capacity gap to fix, and puts capacity to support a category inside its prioritization score rather than treating it as an afterthought.",
"Places the referral/affiliate band in next best choice and states plainly that cheap to run is not the same as high priority.",
"Places the cloud marketplace listing in low priority because buyers are not procuring there yet, with a re-score trigger when procurement behaviour shifts.",
"Hands sequencing of categories the company does not yet run to mbfinotti/partnerships-skills@partner-ecosystem-expansion, and ranking of named candidate companies to mbfinotti/partnerships-skills@alliance-prioritization."
]
},
{
"id": 6,
"prompt": "Kestrel Freight Systems, B2B SaaS for freight brokers, $12M ARR. I've finished scoring six partner categories on our weighted scorecard - composites came out between 2.1 and 4.3. Next thing I want is the Ideal Partner Profile written up. Just take our ICP (freight brokers, 50-500 employees, US and Canada, running a TMS) and use that as the IPP so recruiting knows what to look for. One IPP for the whole program is fine, we're small.",
"expected_output": "A correction that the IPP is not the ICP copied across, one IPP per surviving category rather than one program-wide, and the JVP kill test relocated ahead of scoring with a retro-run on the six already-scored categories.",
"files": [],
"expectations": [
"States that the Ideal Partner Profile is not the ICP copied across.",
"Defines the IPP as a profile of the company best placed to bring you those customers, not a profile of the customer.",
"Refuses a single program-wide IPP and requires one IPP per partner category that survives prioritization.",
"Names the IPP as an output of the map rather than an input to it.",
"Names the IPP criteria families: firmographics, customer-base overlap with the ICP, delivery capability, economic motivation, and solution fit or sales-motion alignment.",
"States that the Joint Value Proposition workshop belongs before scoring, not after it.",
"States that a category which cannot articulate joint customer value does not proceed.",
"Gives the reason for that ordering: a category that fails the test never receives a composite that later has to be retracted.",
"Recommends retro-running the JVP test across the six already-scored categories and retracting the composite of any that fail.",
"Names at least three of the JVP workshop questions, drawn from the fundamental customer benefit, each side's differentiated contribution, how the offerings combine, the customer-visible outcome, why a customer should trust the pairing, and who the target is.",
"Names the WIIFT question explicitly - whether the partner category's own motivation is obvious.",
"States that a weak JVP combined with high overlap is the uphill-battle quadrant, feeding the verdict back into the 2x2."
]
},
{
"id": 7,
"prompt": "Ambervale Robotics - industrial automation, B2B, we sell through distributors and systems integrators. Board deck goes out on the 14th. I want a proper network diagram of the whole partner ecosystem, plus the concentric-circle tier view showing who our gold, silver and bronze partners are, plus a heat map, plus the matrix. More views, more credible. Nobody on my team has any design or data-viz skill - I'll be building these in slides myself. The board question is simple: where do we put next year's channel investment?",
"expected_output": "One recommended format rather than four, the matrix recommended for this investment question, the network diagram deleted for lack of layout skill, the tiered view skipped as a restatement of the 2x2, and the concentric-circles-are-not-tiers correction.",
"files": [],
"expectations": [
"Does not build all four views.",
"Recommends the matrix as the format for this board question, since the decision in front of the board is where to invest.",
"States the format ordering out loud rather than leaving it implied by row order.",
"Describes the matrix as near-zero build because it is a table fed by scorecard composites already computed.",
"Deletes the network diagram because nobody on the team has layout skill.",
"States that without layout skill the network diagram reads as a hairball and settles nothing, and does not present it as the ambitious option.",
"Names the question only the network diagram can answer - who the hubs are - and the condition that would promote it: a hub decision plus someone with real layout skill free.",
"Skips the tiered view because the prioritization 2x2 already carries that ranking.",
"Gives the reason: two views of one ranking invite the reader to look for a difference that is not there.",
"Corrects the premise that the concentric circles show gold, silver and bronze tiers, stating the circles are a map layout and must not be presented as tier criteria.",
"Points tier criteria and benefits to mbfinotti/partnerships-skills@partner-tiering rather than producing them here.",
"Names the heat map as what to build instead when the stated goal is coverage gaps rather than investment, and notes it needs one clean dimension attached to every player."
]
},
{
"id": 8,
"prompt": "Loxley Grid, B2B SaaS, energy-sector analytics, $27M ARR. Our partner count went from 60 to 180 over 18 months. 22 of them registered a deal in the last 90 days. Our CRM has one field called 'Partner Involved' - a checkbox - and nothing that separates sourced from influenced, and IT has a hard freeze on new CRM fields until next fiscal year. Two of our categories only hold 5 and 6 partners each. Somebody on the exec team keeps repeating that partners drive 28% of revenue at good companies and asking why we're not there. Give me the health read on this ecosystem.",
"expected_output": "The activation ratio read first and computed, the recruitment-outrunning-enablement diagnosis, the sourced-versus-influenced split deleted with the earning question declared unanswered rather than pending, and every quoted benchmark carrying a provenance flag.",
"files": [],
"expectations": [
"Reads the activation ratio first and computes it from the given numbers: 22 of 180, roughly 12%.",
"States why it is read first: it is one query and it invalidates a whole class of map.",
"Diagnoses partner count tripling while activation stays low as recruitment running ahead of enablement.",
"States that the map should flag that category rather than celebrate its size.",
"Names logo collecting explicitly, and that a partner list is not a channel.",
"Deletes the sourced-versus-influenced split because the CRM cannot carry those fields in the time available.",
"Says plainly that the earning question - whether the ecosystem makes money at all - stays unanswered, rather than carrying it as a pending metric.",
"Gives the reason: carrying it as pending lets a later reader assume it was measured.",
"States that sourced and influenced must never be summed without a written overlap policy, and that a single 'Partner Involved' checkbox cannot separate them.",
"Tracks the two categories holding 5 and 6 partners as raw counts rather than percentages, because below roughly eight partners one partner going quiet swings a rate by double digits.",
"Flags the 28% figure with its provenance as analyst and secondhand rather than repeating it as established fact.",
"States that partner-sourced revenue share is category-dependent and never transferable across categories, contrasting the SaaS median near 24% with hardware and security near 41% and services-led near 58%.",
"States that the company's own baseline tracked by cohort beats any external benchmark.",
"Declines to offer a single comparable industry benchmark for partner-influenced revenue share, stating that definitions of influenced differ per company so the figures are not comparable."
]
},
{
"id": 9,
"prompt": "Fenmarsh Outdoor - we make hiking and camping gear, sell through about 400 independent retailers plus three national chains, and our own webstore has gone from 8% to 26% of revenue in two years. Three of our biggest retail accounts have now formally complained about our direct discounting and one threatened to cut our shelf facings in half. Map our partner ecosystem and give me the rules we should put in place so this stops. Also, everything I read about partner ecosystems is B2B SaaS - does any of this even apply to a gear brand?",
"expected_output": "The D2C-versus-retail conflict detected and sized but not resolved, rules of engagement handed off by name, the levers listed as observed practice and left unranked with a stated reason, and an explicit answer that the method's spine is identical in B2B and B2C with the four dimensions that genuinely change.",
"files": [],
"expectations": [
"Detects and sizes the D2C-versus-retail conflict but does not write the rules of engagement.",
"Hands the rules of engagement to mbfinotti/partnerships-skills@partner-channel-conflict by name.",
"Quantifies the conflict zone by accounts, revenue at stake, and territory.",
"Names D2C versus retail as the signature B2C conflict, distinct from the partner-versus-partner and direct-versus-partner patterns.",
"Notes that D2C is resource-intensive and that its payoff is first-party data, margin, and brand control.",
"Lists the observed levers - channel-exclusive ranges or editions, D2C-priority allocation of high-demand products, selective retention of key retail partners - as observed practice rather than prescription.",
"Leaves those levers deliberately unranked and says why: the ranking depends on contract terms this exercise never reads.",
"Answers the B2B/B2C question by stating the method's spine is identical in both rather than reinventing a consumer-side method.",
"Names what stays identical, including the identify-analyze-visualize-optimize sequence, the one-business-area scoping rule, the map-from-customer-data-not-inbound-requests rule, the recurring-review discipline, and strategic-fit x ease-of-execution prioritization.",
"Names what genuinely changes between B2B and B2C: partner vocabulary, partner counts, attribution, and signature conflict.",
"Uses B2C partner vocabulary - retail and wholesale, creators and affiliates, licensing, co-branding - rather than resellers, VARs, MSPs and SIs.",
"Frames B2C attribution as transactional and fast-cycling, comparing lifetime value of partnership-acquired customers against other channels plus brand lift, rather than sourced-versus-influenced pipeline over long cycles.",
"Flags any quoted figure on pipeline lost to unresolved conflict as vendor-published and directional."
]
},
{
"id": 10,
"prompt": "Done! Here's the ecosystem map for Vantry Commerce's payments product. Six players on it: two payment ISVs, three agencies and one marketplace. Overlap I estimated myself - I know these accounts well enough, it's roughly 40% overlap with the ISVs and maybe 15% with the agencies. It's one slide, colour-coded, looks great. I'm sending it to our CEO on Friday and then we're going to go recruit ten more agencies. Anything you'd add before I send?",
"expected_output": "A plain statement that the map fails the pass threshold, each failed criterion named, an honest next step scoped instead of a polish pass, and the deliverable redirected from one slide to a two-page memo with its mandatory open-questions section.",
"files": [],
"expectations": [
"States plainly that the map does not pass, rather than polishing or approving it.",
"Names the player-count failure against the at-least-ten-players threshold.",
"Names the overlap failure: the 40% and 15% figures are assumption, not account-mapping output or customer-interview evidence.",
"Names the missing retroactive closed-won influence analysis.",
"Names the missing decision with an owner, and states that a map driving no decision is the discipline's most common failure.",
"Names the requirement that every quoted benchmark carry a provenance flag.",
"Scopes the honest next step - customer interviews and a closed-won deal review - rather than shipping a decorative map.",
"Warns against recruiting the ten agencies before overlap is verified.",
"Names the failure this would repeat: signing partners with no shared accounts, no shared ICP, and no path to joint pipeline.",
"Requires the deliverable be an ecosystem strategy memo of roughly two pages rather than a single colour-coded slide.",
"Names the open-questions section as mandatory, with the reason that a map with no stated uncertainty is a map that stopped asking.",
"Requires every memo claim to name its source, contrasting a reviewable claim against an unsourced assertion.",
"Sets a recurring review cadence plus immediate-update triggers: a merger or acquisition, new regulation, and a category moving quadrants."
]
}
],
"trigger_queries": [
{ "query": "Map the partner ecosystem around our mid-market product line", "should_trigger": true },
{ "query": "I need a partner landscape view I can put in front of the exec team", "should_trigger": true },
{ "query": "Which partner categories actually influence our closed-won deals?", "should_trigger": true },
{ "query": "We keep signing partners who share no accounts with us - how do I catch that before we sign?", "should_trigger": true },
{ "query": "Where are the coverage gaps in our channel?", "should_trigger": true },
{ "query": "Help me classify the third parties that touch our customers", "should_trigger": true },
{ "query": "What's the whitespace in our partner coverage across DACH?", "should_trigger": true },
{ "query": "Is a firm that resells our licences and also runs them on a monthly retainer an MSP or a VAR?", "should_trigger": true },
{ "query": "I have 40 companies in a spreadsheet and no idea which are resellers, which are SIs, and which just influence the buyer", "should_trigger": true },
{ "query": "Build the account overlap analysis between us and our integration partners", "should_trigger": true },
{ "query": "Our CEO asked what our partner ecosystem looks like and I genuinely don't know where to start", "should_trigger": true },
{ "query": "How do I work out which partner categories deserve investment next year?", "should_trigger": true },
{ "query": "partner ecosystem mapping", "should_trigger": true },
{ "query": "channel coverage analysis for our EU business", "should_trigger": true },
{ "query": "Are we a keystone in this ecosystem or just a niche player in someone else's?", "should_trigger": true },
{ "query": "Show me which segments and geographies none of our partners reach", "should_trigger": true },
{ "query": "I want to size our ecosystem for a board ask", "should_trigger": true },
{ "query": "We have resellers, a marketplace listing, some agencies and a few integrations - I need one picture of all of it", "should_trigger": true },
{ "query": "Do a strategic-fit versus ease-of-execution 2x2 on our partner categories", "should_trigger": true },
{ "query": "Who else is in the room when our buyers make a decision?", "should_trigger": true },
{ "query": "Our partner list has 180 logos and 22 of them have done anything in 90 days. What does that tell me?", "should_trigger": true },
{ "query": "Before we build any program I want to know what's actually out there around our customers", "should_trigger": true },
{ "query": "How do I score partner categories against each other without just ranking them by revenue?", "should_trigger": true },
{ "query": "landscape of resellers, distributors and systems integrators in our space", "should_trigger": true },
{ "query": "I want to understand where our channel and our direct team are stepping on each other, and how big that actually is", "should_trigger": true },
{ "query": "We're a consumer gear brand - our webstore is now 26% of revenue and our retailers are furious. I need the full picture of our channel.", "should_trigger": true },
{ "query": "What should go on an ecosystem map, and what proves it's real rather than decorative?", "should_trigger": true },
{ "query": "Diagram our partners and where they sit relative to us", "should_trigger": true },
{ "query": "Retroactively review our closed-won deals for partner influence", "should_trigger": true },
{ "query": "ecosystem whitespace analysis", "should_trigger": true },
{ "query": "Every partner conversation we have starts because someone emailed us. Is that a problem?", "should_trigger": true },
{ "query": "I need to know which partner types touch our customers before I hire anyone", "should_trigger": true },
{ "query": "How should I weight a partner scorecard across referral partners and systems integrators?", "should_trigger": true },
{ "query": "Give me the partner type taxonomy for a consumer brand", "should_trigger": true },
{ "query": "Our board wants to see the partner picture - matrix, heat map, or network diagram?", "should_trigger": true },
{ "query": "Can you help me work out who our partners even are?", "should_trigger": true },
{ "query": "partner category prioritization", "should_trigger": true },
{ "query": "What's the difference between an SI and a VAR on a map like this?", "should_trigger": true },
{ "query": "We want to run a Value Network Analysis session on our channel", "should_trigger": true },
{ "query": "I need to see which of our partner categories overlap with our ICP and which don't", "should_trigger": true },
{ "query": "Map coopetition - which partners do we share with our competitors?", "should_trigger": true },
{ "query": "How do I prove to finance that the ecosystem already touches revenue?", "should_trigger": true },
{ "query": "Run an ecosystem health read for me: productivity, robustness, niche creation", "should_trigger": true },
{ "query": "Where do our resellers and our marketplace listing collide on price?", "should_trigger": true },
{ "query": "I've been asked to produce a channel strategy and I have no data to build it on", "should_trigger": true },
{ "query": "What questions should I ask before mapping a company's partner landscape?", "should_trigger": true },
{ "query": "Assess our integration partners, agencies and marketplace against each other", "should_trigger": true },
{ "query": "We sell through distributors in eight countries and I can't tell you which countries are actually covered", "should_trigger": true },
{ "query": "Write the ecosystem strategy memo for the exec team", "should_trigger": true },
{ "query": "I want to know if we're accidentally behaving like a dominator", "should_trigger": true },
{ "query": "Which of our four partner bands should get headcount, and why?", "should_trigger": true },
{ "query": "Everyone tells me to do account mapping with our partners. Is it worth the legal review?", "should_trigger": true },
{ "query": "Put together the ecosystem inventory for our observability product line only", "should_trigger": true },
{ "query": "How many different players should I expect to find around a B2B buying process?", "should_trigger": true },
{ "query": "Our partner data is a mess and I need a defensible picture of it for a strategy review", "should_trigger": true },
{ "query": "give me the partner map", "should_trigger": true },
{ "query": "Which partner category should we launch next - MSPs or agencies?", "should_trigger": false },
{ "query": "Sequence our partner category rollout over the next four quarters with readiness gates", "should_trigger": false },
{ "query": "Rank these five named alliance candidates and tell me which one to sign first", "should_trigger": false },
{ "query": "Which of these three companies should we partner with first?", "should_trigger": false },
{ "query": "Design our partner program from scratch - tiers, benefits, governance", "should_trigger": false },
{ "query": "Are we even ready to launch a channel program at all?", "should_trigger": false },
{ "query": "Rework our silver, gold and platinum tier criteria", "should_trigger": false },
{ "query": "What benefits should sit in each partner tier?", "should_trigger": false },
{ "query": "Write our rules of engagement for contested deals between direct and channel", "should_trigger": false },
{ "query": "A reseller and our direct rep are both claiming the Halberd account - who wins?", "should_trigger": false },
{ "query": "Design our deal registration policy and protection window", "should_trigger": false },
{ "query": "How should we split deal credit between partner-sourced and partner-influenced on comp plans?", "should_trigger": false },
{ "query": "Model the P&L of our relationship with one reseller", "should_trigger": false },
{ "query": "Is this reseller worth the margin we give them?", "should_trigger": false },
{ "query": "Build a per-partner scorecard and QBR structure", "should_trigger": false },
{ "query": "One of our gold partners has missed target three quarters running - what's the escalation ladder?", "should_trigger": false },
{ "query": "Should we list on AWS Marketplace or Azure Marketplace first?", "should_trigger": false },
{ "query": "What ROI should I expect from a cloud marketplace listing?", "should_trigger": false },
{ "query": "Design the certification track for our reseller partners", "should_trigger": false },
{ "query": "What training do partners need before their first deal?", "should_trigger": false },
{ "query": "Plan a joint webinar with our integration partner next quarter", "should_trigger": false },
{ "query": "Write the better-together story for our integration launch", "should_trigger": false },
{ "query": "What commission rate should we pay our affiliates?", "should_trigger": false },
{ "query": "Should our affiliate commission be lifetime or capped at 12 months?", "should_trigger": false },
{ "query": "Draft our affiliate program terms and conditions", "should_trigger": false },
{ "query": "Does this Instagram caption meet FTC disclosure rules?", "should_trigger": false },
{ "query": "This affiliate's conversion rate tripled overnight - is it cookie stuffing?", "should_trigger": false },
{ "query": "Audit next week's affiliate payout run before we disburse", "should_trigger": false },
{ "query": "What metrics belong on an affiliate performance dashboard?", "should_trigger": false },
{ "query": "Write the welcome email series for newly approved affiliates", "should_trigger": false },
{ "query": "Draft outreach copy to recruit coupon and cashback affiliates", "should_trigger": false },
{ "query": "Shortlist creators for our spring campaign", "should_trigger": false },
{ "query": "Write the DM I send to this YouTuber about a collab", "should_trigger": false },
{ "query": "Brief the creator we just signed on deliverables and specs", "should_trigger": false },
{ "query": "Negotiate usage rights and exclusivity with a creator's talent manager", "should_trigger": false },
{ "query": "How do I measure a single influencer campaign?", "should_trigger": false },
{ "query": "How big should our refer-a-friend reward be?", "should_trigger": false },
{ "query": "Customers are creating fake accounts to farm referral credits - what guardrails do I need?", "should_trigger": false },
{ "query": "How do I break into partnerships from a sales role?", "should_trigger": false },
{ "query": "Write a job description for a channel partner manager", "should_trigger": false },
{ "query": "Which partnerships skill do I need for this task?", "should_trigger": false },
{ "query": "Analyze the competitive landscape in the workflow automation market", "should_trigger": false },
{ "query": "Map our competitors' positioning and pricing against ours", "should_trigger": false },
{ "query": "Give me a primer on the Rust ecosystem", "should_trigger": false },
{ "query": "Map our npm dependency ecosystem and flag unmaintained packages", "should_trigger": false },
{ "query": "What does the ecosystem around the Model Context Protocol look like right now?", "should_trigger": false },
{ "query": "Run a test coverage analysis on the payments module", "should_trigger": false },
{ "query": "Our pytest coverage dropped below 80% - where are the gaps?", "should_trigger": false },
{ "query": "Check our detection coverage against MITRE ATT&CK", "should_trigger": false },
{ "query": "Build our go-to-market strategy for the new product launch", "should_trigger": false },
{ "query": "Map the decision-making process our enterprise buyers go through", "should_trigger": false },
{ "query": "Set up a Shopify Partner account and build an app listing", "should_trigger": false },
{ "query": "Draw an architecture diagram of our microservices and their dependencies", "should_trigger": false },
{ "query": "Map our sales territory coverage and rep quota assignments", "should_trigger": false },
{ "query": "Which vendors should we shortlist for our data warehouse?", "should_trigger": false },
{ "query": "Build a stakeholder map for this internal migration project", "should_trigger": false }
]
}
references/discovery-workshops.md›
# Discovery Workshops: VNA, Value Blueprint, IPP, JVP
The profession has its own discovery formats. Run these instead of generic brainstorming, and keep the session discipline throughout: one question per message, 2-3 candidate options with trade-offs plus a recommendation, and every output validated section by section before it hardens.
## Value Network Analysis - the participative mapping workshop
Verna Allee's Value Network Analysis (developed 1993, adapted 1997; later adopted by ITIL and eTOM standards) is the most directly applicable _technique_ for drafting the map itself, and it is natively a **participative workshop**. That participative form is also the most expensive way to source an inventory: a week of calendars plus the political capital to convene them. Workflow step 2 ranks it last on efficiency and reaches for it only when the map has to be owned outside partnerships.
The technique below still applies when you draft solo. You just lose the ownership, and you have to hunt the intangible arrows yourself.
1. Place the focal organization at the centre of a shared canvas.
2. Arrange the roles around it - partner categories, customers, competitors, other participants.
3. Draw an arrow for every **tangible** deliverable exchanged (product, payment, leads) and every **intangible** one (trust, market insight, brand association).
4. Assign an owner to each relationship layer (sales owns customers; partnerships owns consultants, channel, alliances).
5. Follow up with interviews and analysis where the workshop exposed unknowns.
The intangible arrows are the point: they surface the influence band (advisors, communities, advocates) that a transaction-only view misses entirely.
## Adner's value blueprint - the dependency check
Ron Adner's _The Wide Lens_ (2012) supplies the strategic overlay: the **value blueprint**, "a map that makes your ecosystem and your dependencies explicit." Apply its three tests to the drafted map:
- **Co-innovation risk** - which mapped players must build or change something for your value proposition to work?
- **Adoption-chain risk** - which intermediaries must adopt before the end customer can? A partner category on the chain that has no reason to adopt is a hidden blocker, not coverage.
- **Minimum Viable Ecosystem** - the smallest set of mapped players that delivers the value proposition at all; anything beyond it is expansion, not requirement.
## IPP definition session - one per surviving category
An **Ideal Partner Profile** is a screen: it defines who is worth recruiting before anyone spends time on an individual partner. Crucially, it is _not_ the ICP copied across: it profiles the company best placed to _bring you_ those customers.
Sequencing, resolved for mapping work: outcomes scope the map first (what the company needs: markets, integration, distribution). Then **one IPP per partner category that survives prioritization** is an _output_ of the map, not an input to it.
Criteria families to work through in the session:
- Firmographics - size, market standing, financial stability, geography.
- **Customer-base overlap with your ICP** - the map's overlap data answers this directly.
- Delivery capability - can they actually sell, implement, or build with you.
- Economic motivation - does the partnership pay them enough to prioritize it.
- Solution fit and sales-motion alignment.
Review the drafted IPP with sales, product, and marketing before anyone targets recruitment from it.
## JVP workshop - the category kill test
A **Joint Value Proposition** workshop tests whether a category can articulate joint customer value. A category that cannot should not survive the map. Run it as a structured session, preceded by discovery interviews, and work the questions one at a time:
- What is the fundamental customer benefit of the joint solution?
- What unique, differentiated contribution does _each_ side make?
- How do the offerings combine - technical integration, service layer, or domain expertise?
- What outcome will the customer see - faster deployment, better ROI, lower risk - and can it be backed with a use case or measurable result?
- Why should a customer trust the pairing - certifications, recognition, shared clients?
- Who is the target - existing customers of either side, or a new market?
- **WIIFT - what's in it for them?** If the partner category's motivation is not obvious, its members will never prioritize the relationship.
Output: a core JVP framework adaptable across segments, commonly compressed into 25-, 50-, and 100-word narratives, tailored per partner type (co-innovating, integrating, implementing, reselling). Feed the JVP verdict straight back into the prioritization 2×2: a weak JVP with high overlap is the definition of the uphill-battle quadrant.
references/ecosystem-health-kpis.md›
# Ecosystem Health KPIs and Benchmark Honesty
Use these ecosystem-level readings to _validate the map_: does the classified ecosystem actually behave the way the map claims? Per-partner scorecards, QBRs, and underperformance triggers belong to `mbfinotti/partnerships-skills@partner-performance`.
Sections below run in order of what each reading is worth, not of what it costs to produce. Workflow step 11 carries the effort and efficiency axes and tells you which to run first. Normally that is the activation ratio, because it is one query, unless the CRM fields for the sourced/influenced split already exist and make that reading free too.
## Sourced vs influenced - keep them separate
- **Partner-sourced revenue**: closed-won revenue from opportunities a partner _created_ (registration, referral). First-touch. Measures pipeline-generation capability; justifies recruitment spend.
- **Partner-influenced revenue**: closed-won revenue from opportunities _you_ created where a partner materially advanced the deal - a documented event that changed stage or met a gating requirement (co-sell, technical win, required integration). Measures acceleration capability; justifies enablement spend.
Why separation matters: one combined "partner revenue" number invites finance to discount it wholesale. Two numbers, each with a rule behind them, invite a conversation about which to grow.
Never sum them without a written overlap policy. Lock the definitions into CRM fields: first-touch de-duplication for sourced, evidence thresholds for influenced.
**Diagnostic reading for the map:** partner count growing while sourced revenue stays flat means recruitment is running ahead of enablement: the map should flag that category, not celebrate its size.
## Activation ratio
Share of partners with at least one referral/registration in the last 90 days. The activation gap is the norm: 50 recruited with 8 active is a 16% activation rate, meaning 84% of recruitment investment returns nothing.
Time-to-first-value is the leading signal. Partners who act within two weeks of joining tend to stay active; those silent at 30 days rarely ever activate.
Measurement cautions:
- Below ~8 partners in a category, track raw counts, not percentages - one partner going quiet swings a rate by double digits.
- Portal logins are a bad engagement proxy; strong partners work off-portal.
- Readiness metrics (certifications completed) untied to revenue measure nothing.
- Your own baseline, tracked by cohort, beats any external benchmark.
## The four-bucket tracking frame
The chain runs in order:
1. **Activity** (leading indicator): registrations per partner, joint-plan completion, enablement progress.
2. **Pipeline**: sourced and influenced opportunities.
3. **Revenue**: closed-won, channel share.
4. **Health**: customer NPS on partner-served accounts, partner churn.
Sustained low activity nearly always precedes low revenue.
## Benchmarks - quote them only with provenance flags
Almost every published number in this field comes from a vendor that profits when the number looks good. Flag every figure inline as vendor first-party, analyst, aggregator, or consultancy. Never apply one category's benchmark to another.
| Metric | Cited value | Flag |
| ------------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------- |
| Partner-sourced revenue share, SaaS median | ~24% - vs ~41% hardware/security, ~58% services-led | Aggregator citing vendor data; **category-dependent, never transferable across categories** |
| Win-rate lift with partners involved | +11.7% average | Vendor first-party (account-mapping network data) |
| Faster close / deal-size lift with partners | ~46% faster; deals ~60% larger | Vendor first-party survey |
| Mature-program revenue share | Up to ~28% of company revenue | Analyst, secondhand |
| Companies with mature ecosystems grow faster | ~34% faster than peers | Analyst-published |
| "90% of partners are inactive" / "25-40% is a healthy active ratio" | - | Third-party consultancy and affiliate-benchmarking figures; **not** attributable to any account-mapping vendor's research; directional only |
| Partner-influenced revenue share of total | Definitions of "influenced" differ per company, so figures are not comparable - confirmed permanently non-comparable rather than an unmeasured gap: even Crossbeam, which publishes size-banded influenced-revenue targets by company headcount, states no universal cross-company benchmark exists | Treat any single number offered with suspicion |
Read self-positioning health (Iansiti & Levien, 2004) through the mapped ecosystem:
- **Productivity**: does participation make members more efficient?
- **Robustness**: does it survive shocks?
- **Niche creation**: does it keep spawning new specialist roles?
A diverse, active population of niche players is the standard sign of health. A hub extracting without sustaining, a dominator, is the standard sign of decay. The typology predates modern digital platforms; use it as a lens, not a scorecard.
references/overlap-and-conflict.md›
# Account Overlap, Coverage Gaps, and Conflict Zones
Overlap data is what makes an ecosystem map real. Without it the map is a list of logos arranged aesthetically.
## Account mapping - the four overlap quadrants
Compare your account list with a partner's, cell by cell:
| Their side ↓ / your side → | Your customer | Your prospect |
| -------------------------- | ------------------------------------------- | -------------------------------------------------- |
| **Their customer** | Co-sell and expand together | **Partner-sourced intro - the highest-value cell** |
| **Their prospect** | You can introduce them - builds reciprocity | Co-sell into a net-new logo |
Run this permissioned and filtered: pre-filter by geography, segment, and use case, and grade what each partner sees (totals only, account names, or more). Where no partner will share data yet, approximate overlap from customer interviews and tech-stack evidence, never from assumption.
Attribution note: this mechanic was popularized by **Ecosystem-Led Growth** (Bob Moore, Crossbeam, 2024), which also coined the **Ecosystem Qualified Lead (EQL)**: a lead identified through ecosystem activity, treated as a distinct, higher-converting category alongside MQL/SQL. State plainly that ELG is a category its author's company created to sell the associated tooling: useful vocabulary and a sound method, not independent research.
## Whitespace and coverage gaps
As overlap accumulates across partners, the inverse picture emerges: segments, geographies, and journey stages where no mapped partner reaches your ICP. Quantify each gap: how many target accounts, how much revenue potential, which journey stage is uncovered. This skill surfaces and sizes the gap; planning which partner category to add into it is the expansion sibling's job.
The strongest warning in the practitioner literature: teams that skip the map and jump to partner conversations pick partners based on who they know or who reached out. They sign agreements with partners who share no accounts, no ICP, and no path to joint pipeline. The map must come from customer interviews and data, not LinkedIn connections or inbound requests.
## The retroactive closed-won review
Sample recent closed-won deals and record every third party that influenced each: who advised the buyer, what integrations were required, who implemented, which marketplace transacted. This is the cheapest high-signal step in the exercise. It proves the ecosystem is already influencing revenue before any new partner is recruited, and it grounds the influence band of the map in deals rather than theory.
## Conflict zones - detect and quantify, never resolve here
Three overlap patterns to flag on any map, plus a fourth specific to consumer brands. For each, record the accounts, revenue, and territory at stake. Writing rules of engagement is `mbfinotti/partnerships-skills@partner-channel-conflict`'s job.
1. **Partner vs partner** - e.g. a high-volume discounter competing against a value-added partner that invests in pre-sales and needs higher margin. Root cause is usually structural over-recruitment: too many partners in one territory creates a zero-sum environment.
2. **Direct vs partner** - the direct rep's immediate win against the partner's need to build a sustainable business. Aggravated when partner deals and direct deals live in separate systems with no shared visibility.
3. **Multi-channel / ecosystem** - a customer finding a lower marketplace price than a reseller quoted; an affiliate driving a lead that closes through a VAR with no credit. Growing as vendors run resellers, marketplaces, direct, product-led, and referral motions simultaneously.
4. **D2C vs retail partner (B2C signature conflict)** - building direct-to-consumer weakens retail relationships; watering down direct promotions to please retail partners hurts direct sales. D2C is resource-intensive, and its payoff is first-party data, margin, and brand control.
Levers the map should note as observed practice, not prescribe, and deliberately left unranked:
- Exclusivity of certain ranges or editions to owned channels.
- D2C-priority allocation of high-demand products.
- Selective retention of key retail partners.
Ordering these levers here would be false precision from this skill: it detects and sizes conflict without the mandate to fix it, and the ranking depends on contract terms it never reads. `mbfinotti/partnerships-skills@partner-channel-conflict` ranks them.
Cost of unmanaged conflict, with flags: research circulated by channel-management vendors puts pipeline lost to unresolved conflict at 30-40% and names conflict the top reason partners disengage (vendor-published, directional).
The capacity question, are we staffed to support this partner type at all, belongs in the prioritization score, not as an afterthought.
## Choosing the map artifact
Pick by the decision the format settles against what it costs to build: `matrix > heat map > tiered view > network diagram` on that ratio. A whiteboard or slides suffice for simple maps.
The full axis breakdown and the conditions that reorder it sit at workflow step 10, where the choice is actually made. Rows below are in that same order.
| Format | Settles | Build effort |
| ------------------------------------------------------------------------- | ------------------------------------------- | ------------------------------------------------------------- |
| Matrix view - partners on a grid, e.g. market coverage × capability depth | Where do we invest? | Near-zero - a table, fed by the scorecard composites |
| Heat map - colour by geography, vertical, or capability | Where is concentration; where are the gaps? | An hour, once one clean dimension is attached to every player |
| Tiered view - concentric circles or pyramid by strategic relevance | Who is core vs periphery? | An hour, but it restates a ranking step 9 already produced |
| Network diagram - vendor, partners, and connections between them | Who connects to whom; where are the hubs? | A day or more, plus layout skill; unreadable without it |
Placement convention: your company at the centre, partners in concentric circles by strategic relevance. The circles are a map layout, not program tiers, and must not be presented as tier criteria.
references/partner-type-taxonomy.md›
# Partner Type Taxonomy
Classify by what a partner does in the customer journey, not by contract name. A name-based list does not travel between industries or between B2B and B2C; a role-based axis does. The role determines the margin a partner expects, the enablement it needs, and how it gets paid.
## Axis 1 - role in the customer journey
Jay McBain (Chief Analyst, Canalys; formerly Forrester) calls this the **trifurcation of the channel**:
- Partners that _influence_ a purchase before it happens.
- Partners that _transact_ it.
- Partners that _integrate and deliver_ it (and thereby retain it) after it.
His headline numbers are analyst-published, not peer-reviewed; cite them with that flag:
- Roughly 7 partners around an average buying process.
- A role for partners in ~96% of sales decisions.
- ~75% of world trade flowing indirectly.
## Axis 2 - engagement depth
Independent of type, each relationship sits on a depth ladder:
1. Listing
2. Integration
3. Co-marketing
4. Co-selling
5. Embedded
Crossing the two axes gives the 2D map this skill produces: a reseller at listing depth and a reseller co-selling are different strategic objects even though the type label matches.
The rungs carry no efficiency ranking here, on purpose. This is an observation axis: it records where a relationship already sits, so that the map reflects reality. Ranking the rungs would turn it into a recommendation to deepen, which is a program-design decision made per partner against economics this skill never sees: `mbfinotti/partnerships-skills@partner-channel-program` and `@partner-economics` own that call.
## B2B partner types
| Type | Journey role | Revenue mechanic | Typical context |
| -------------------- | ----------------------------------------------------------------------- | ----------------------------- | ---------------------------------------- |
| Referral / affiliate | Influence - sends leads, never owns the sale | Referral fee or commission | SaaS, services |
| Reseller / VAR | Transact - buys and resells, adds configuration or support | Margin on resale | IT, hardware, mid-market |
| Distributor | Transact one tier up - sells to resellers, carries inventory and credit | Volume margin | Hardware, multi-tier, cloud distribution |
| MSP | Deliver - operates the technology on an ongoing basis | Recurring managed-service fee | SMB IT, cybersecurity |
| SI / GSI | Integrate - designs and implements multi-technology solutions | Services fees | Enterprise |
| ISV / tech partner | Integrate via product - builds with or on you | Co-build, marketplace listing | SaaS API ecosystems |
| OEM / embed | Integrate invisibly - your tech inside their product | Embed license | Manufacturing, components |
| Marketplace | Transact + influence - a route to market more than a partner | Platform fee, co-sell | Hyperscaler and SaaS marketplaces |
| Strategic alliance | Co-innovate, co-GTM | Joint investment | Enterprise |
## B2C partner types
The B2B taxonomy does not transfer name-for-name. Consumer-side archetypes (the least-documented context in practitioner literature: treat published claims here as thinner than the B2B ones):
- **Retail / wholesale channel partners** - shelf space, online marketplaces, white-label arrangements. The B2C analogue of the distributor/reseller band; bulk-selling buys access to a mainstream retail network without acquiring the customers yourself.
- **Creators and affiliates** - performance-based commission for driving sales. The analogue of the referral/influence band, at far higher partner counts and far lower value per partner.
- **Licensing** - one brand lends another the right to use its IP.
- **Co-branding** - both names on a shared initiative, with co-selling tracking underneath so both parties earn from the sales it drives.
- **Also inventory:** co-created products, limited collections, bundles, retail pop-ups, event sponsorships.
## Contested boundaries - expect them, map them
Practitioners openly disagree on labels; a single firm can be a VAR, MSP, and SI at once, and assigning one label misroutes enablement and compensation. When classifying:
- **MSP vs reseller/VAR** - contract duration, not activity: an MSP sells an ongoing service for a recurring fee; a VAR's engagement is transactional.
- **ISV vs tech partner vs integration partner** - the labels overlap; classify by what the firm does with you, and record hybrid roles as hybrid rather than picking one.
- **SI vs VAR** - an SI builds new custom solutions; a VAR resells turnkey with additions.
- **Affiliate vs referral vs advocate vs ambassador** - one pre-sale influence layer with different payment mechanics; on the map they share a band.
- **Marketplace: channel or partner?** - treat it as a route to market within the ecosystem, not a partner per se, but keep it on the map because it transacts and influences.
When a player defies clean classification, record all applicable roles and depths. A forced single label is a misclassification trap, and misclassification is a documented failure mode of this exercise.
references/prioritization-scorecards.md›
# Prioritization: Weighted Scorecard + 2×2
Two complementary tools. The scorecard produces defensible numbers; the 2×2 turns them into an investment conversation. This skill applies them to ecosystem _categories_ (segments of the map); ranking named candidate alliances belongs to `mbfinotti/partnerships-skills@alliance-prioritization`.
## The weighted scorecard
Score each category on a weighted combination of engagement, performance, and potential indicators. The composite drives attention and investment.
- **The load-bearing decision** is not which inputs to include but how heavily to weight leading indicators (engagement, enablement progress, joint activity) against lagging ones (revenue). The most-cited error is over-weighting lagging revenue and missing operational decay.
- **Segment weights by partner type - never one scorecard for all.** A referral band, a reseller band, an SI band, and an alliance band have different routes to revenue, cycle lengths, and influence. Define each category's _intended contribution_ before choosing its metrics: a mature reseller category carries heavier revenue/retention weighting; an emerging strategic category is judged on market development.
- **Reject the weak default** of scoring only sales volume, account size, and partner type - it says almost nothing about where to invest.
- **Validate the model**: compare its predictions against actual outcomes and adjust weights where it over- or under-predicted.
## The prioritization 2×2
Axes: **strategic fit × ease of execution** (equivalently, size of prize × ability to win). The partnerships-specific version is **Chris Lavoie's 2×2** (AfterShip, circulated through the ELG community):
| | High joint value | Weak joint value |
| ----------------------- | ---------------------------------------------- | ----------------------------------------------- |
| **High overlap / fit** | **Holy grail** - priority investment | **Uphill battle** - co-marketing only, early on |
| **Lower overlap today** | **Next best choice** - high-potential, nurture | **Low priority** - watch, wait |
Say the resulting order out loud instead of leaving it implied by grid position: `holy grail > next best choice > uphill battle > low priority`. That is already an efficiency ordering rather than a cost one: ease of execution _is_ the effort side of the ratio, which is why the category cheapest to run routinely is not the one to fund first.
The worked example below inverts in exactly that direction.
The ordering is a default, not a law. Re-rank it against what the map already knows about this company:
- An in-house capability the ease-of-execution axis assumed away (an integration team already shipping, a partner manager already hired) promotes a category by a full quadrant.
- A category whose fit rests on a whitespace nobody has staffing to enter belongs lower than its composite says.
Explicitly a **recurring exercise**: categories and partners move quadrants over time, so re-plot on the map's review cadence rather than treating a placement as permanent.
## Combining them
Use the scorecard to produce a composite score for _each axis_, then plot:
- **Strategic fit** = ICP overlap, joint value proposition strength, market alignment.
- **Ease of execution** = technical readiness, sales capacity, contracting friction, partner motivation - and your own capacity to support the category (staff, enablement, tooling).
Ease of execution cuts both ways: partners overwhelmingly select vendors on ease of doing business (a widely repeated ~80% figure, practitioner-circulated; treat as directional). Your own friction belongs in the assessment, not just theirs.
## Worked category example
A B2B SaaS map with four categories, composites on a 1-5 scale:
| Category | Strategic fit | Ease of execution | Quadrant | Reading |
| -------------------------- | --------------------------------------------------------------------- | --------------------------------------------- | ---------------- | ---------------------------------------------------------------- |
| ISV / integration partners | 4.4 (heavy account overlap, integrations named in closed-won reviews) | 3.8 (API ready, no partner manager yet) | Holy grail | Invest first; the capacity gap (no owner) is the blocker to fix |
| Referral / affiliate band | 3.1 (ICP-adjacent audiences) | 4.5 (cheap to run) | Next best choice | Run lean; do not confuse low cost with high priority |
| Regional SIs | 3.9 (enterprise segment uncovered - a mapped whitespace) | 2.2 (no implementation docs, long enablement) | Uphill battle | Quantified gap hands off to expansion planning; not this quarter |
| Marketplace listing | 2.4 (buyers not procuring there yet) | 3.5 | Low priority | Watch; re-score when procurement behavior shifts |
Note what the example does. Each placement cites map evidence (overlap, closed-won review, whitespace), and each reading ends in a decision. The pass-threshold requirement, that the map inform at least one named decision, is satisfied inside the prioritization view itself.
Negative example to avoid: the same four categories ranked by last quarter's partner-sourced revenue alone would rank the referral band first and ISVs last, with lagging revenue inverting the strategic picture. That is the over-weighting error the scorecard exists to prevent.
SKILL.md›
---
name: partner-ecosystem
description: Map a company's partner and channel ecosystem as a strategy exercise - an inventory of every partner type (resellers, distributors, MSPs, ISVs, SIs, affiliates, marketplaces, plus retail, creator, licensing and co-branding partners for consumer brands), partner account overlap analysis, channel coverage gaps and conflict zones, a weighted partner scorecard, and a prioritization 2x2. Use whenever the user mentions partner ecosystem mapping, a partner landscape, channel coverage, partner type classification, ecosystem whitespace, or which partner categories deserve investment, even if they never say ecosystem. Do NOT use for sequencing which category to launch next - use mbfinotti/partnerships-skills@partner-ecosystem-expansion instead.
license: MIT
metadata:
author: Maya-Beth Finotti
version: "1.4.9"
---
# Partner Ecosystem Mapping
Map the full partner and channel landscape of one business area. No single canonical framework owns this discipline.
The map covers:
- Which partner types touch your customers.
- Who overlaps with your market.
- Where the coverage gaps and conflict zones sit.
- Which ecosystem segments deserve investment attention.
Built from:
- A role taxonomy: Jay McBain's trifurcation of the channel.
- An overlap mechanic: account mapping, popularized by Ecosystem-Led Growth.
- A mapping technique: Verna Allee's Value Network Analysis, Ron Adner's value blueprint.
- A prioritization pass: weighted scorecard plus 2×2.
The output is a decision artifact, never a partner program:
- Ecosystem map.
- Coverage/whitespace view.
- Prioritization view.
- A short ecosystem strategy memo.
Program design, tier criteria, conflict rules of engagement, and per-partner economics hand off to sibling skills instead (see Reference).
## Interview
Ask before mapping anything. One question per message; offer multiple-choice answers when possible. Skip a question only when the user already gave the answer.
- B2B, B2C, or hybrid? What does the company sell, to whom (ICP), at what price band, through which motion (self-serve or sales-led)?
- Which single business area or product line should the map cover? (Never the whole company at once - offer the 2-3 plausible scopes as choices.)
- What is the goal of the map: choose a channel strategy, find coverage gaps, diagnose conflict, size the ecosystem for an executive ask, or landscape before building a program?
- Current partner mix: which partner types exist today, roughly how many per type, and how many are actually active?
- What data exists: CRM closed-won history, sourced/influenced attribution fields, account-overlap data with any partner, customer tech-stack or purchase-channel information?
- Are you the platform others build on, or a participant in someone else's ecosystem? (Both can be true in different areas.)
- Constraints: who sponsors this, who must approve it, and how much capacity exists to act on it?
- By what date must the map land, and what decision is waiting on it? (A date inside a week promotes the closed-won review and the interview-based overlap proxy; a quarter of runway makes permissioned account mapping and a convened workshop affordable.)
- One-off win or compounding asset? (A single exec ask stops at a static matrix and a memo; a compounding mandate justifies the CRM field definitions, the overlap infrastructure, and the recurring review cadence that keep the map alive after the meeting.)
- What is the effort ceiling - your own hours, whose calendars you can command, and how much political capital you can spend convening stakeholders or asking a partner for their account list? (A solo ceiling rules out both the participative workshop and partner data sharing; both need other people to say yes.)
Carry these three answers into every ranking below. They are the only inputs that can reorder the defaults for this user.
## Workflow
Hold one discipline across every step below, wherever a real choice exists:
- Which business area to scope.
- Which overlap proxy to accept.
- How to weight a scorecard.
- Which visualization to build.
- Which categories make the cut.
Put 2-3 candidate approaches to the user with their trade-offs and your recommendation, then wait. Never present a single option as if it were the only one. Never let an assumption harden into the map unstated.
Every ordering in the steps below is a default, not a law. It ranks by value returned per unit of effort, never the same ordering as cheapest-first, and it shifts with context and with who executes it. Re-rank it against what you already know about this user before recommending anything.
Signals that move the reordering:
- A CRM that already carries structured partner-influence fields moves the internal data pull further ahead of everything else.
- A designer on hand moves the network diagram up.
- An audience that reads spreadsheets rather than diagrams moves it back down.
- An existing partner already sharing account data makes account mapping the cheap option rather than the expensive one.
Say which of their answers moved which option, so the reordering is auditable rather than a preference you asserted.
1. Run the Interview; confirm the scope is one business area with a stated goal before touching data.
2. Inventory every third party that touches customers of that area, working the evidence sources in this order. Never build the inventory from inbound partnership requests or the team's personal network; teams that do sign partners with no shared accounts, no shared ICP, and no path to joint pipeline.
- **Internal data pull** - CRM records, closed-won notes, support tickets, integration and product usage. An hour or two on data you already own, and every name it returns is evidence that the player touched a real customer. Start here always.
- **Customer interviews** - a week of scheduling and conversations. The only source that finds the advisors, communities, and unlogged influencers nothing in your systems ever recorded, which is exactly the band a transaction-only view misses.
- **Public sweep** - competitor partner directories, marketplace listings, review-site category neighbors, conference sponsor lists. Near-zero effort where you can browse the web, and it returns breadth fast, but nothing it finds is evidence that any of those players touch _your_ customers. Treat its output as candidates to verify, never as inventory.
- **Value Network Analysis participative workshop** - a week of calendars plus the political capital to convene stakeholders. It buys the intangible exchanges (trust, market insight, brand association) and, more importantly, shared ownership of the map by people outside partnerships. See [references/discovery-workshops.md](references/discovery-workshops.md).
- effort: workshop > customer interviews > internal data pull == public sweep
- value: customer interviews > workshop > internal data pull > public sweep
- efficiency: internal data pull > customer interviews > public sweep > workshop
The internal data pull and the public sweep tie on effort: each is an hour or two of one person working alone, with no permission to obtain and no calendar to negotiate. They are nowhere near equal on value: the pull wins that axis because only its output is evidence about _your_ customers.
Where you cannot browse the web, the sweep is not cheap but impossible: delete it and say so, rather than listing a source nobody can reach.
- **Default:** the internal data pull alone.
- **Escalate to customer interviews when** closed-won notes name third parties you cannot classify, or the influence band comes back empty. It usually does; that is a gap in your logging, not in the ecosystem.
- **What this order starves:** the workshop. It is second on value, first on effort, last on efficiency, so a ratio never once convenes it, and it is the only source that makes people outside partnerships own the map instead of receive it.
- **Promote the workshop when** the map has to be owned by sales, product, or an exec sponsor rather than merely read by them; the map is drafted there, not after it has been scored.
- **Delete the workshop when** the Interview gave a solo effort ceiling. Name it as deleted: it needs other people to say yes, and one carried at the bottom of the list returns as a week of calendars nobody agreed to.
3. Classify each player on two axes:
- Role in the customer journey: influence, transact, or integrate-and-deliver (McBain's trifurcation, Canalys).
- Engagement depth: from listing through embedded.
Include competitors. Coopetition and the partners you share with them are signal, not noise. See [references/partner-type-taxonomy.md](references/partner-type-taxonomy.md).
4. Establish overlap using one of two mechanics. This is the one place in the exercise where the cheaper option is not merely weaker but _safer_, so rank all four axes before recommending:
- **Permissioned account mapping** - exchange filtered account lists with the partner and classify shared accounts into the four overlap quadrants. The only mechanic that yields overlap at account granularity, which is what makes co-sell targets and whitespace countable rather than adjectival.
- **Interview and tech-stack proxy** - infer overlap from what customers say they use and buy through. Directional per category, never per account.
- effort: account mapping (a partner contact who agrees, plus a filtering and grading pass per partner) > proxy (a few hours on interviews you are running anyway)
- compliance cost: account mapping (a data-sharing agreement, a privacy review of what leaves your systems, and an account list you cannot un-share once sent) > proxy (none)
- value: account mapping (countable quadrants) > proxy (directional signal)
- efficiency: proxy > account mapping while only one or two partners will share; account mapping > proxy once three or more will, since the legal and filtering setup is paid once and reused per partner
- **Default:** the proxy, for the first map. Never let its absence stall the exercise.
- **Start account-mapping paperwork in parallel when** the answers say a compounding asset, so the second map has real quadrants.
- **Delete account mapping when** no partner will share a list, or a privacy review will not clear in the time available. Record it as deleted with the reason: a mechanic parked as "phase two" is how a map ships claiming account-level overlap it never measured.
- Approximate from evidence, never from assumption. See [references/overlap-and-conflict.md](references/overlap-and-conflict.md).
5. Run the retroactive closed-won review: sample recent closed-won deals and record every third party that influenced each one. This is the cheapest high-signal step in the whole exercise. It proves whether the ecosystem already influences revenue before anything new is recruited.
6. Surface coverage gaps: segments, geographies, and journey stages with no partner coverage. Surface conflict zones too: partner-vs-partner, direct-vs-partner, multi-channel, and D2C-vs-retail for consumer brands. Quantify each one by accounts, revenue at stake, and territory.
Detect and measure only. Writing the resolution rules belongs to `mbfinotti/partnerships-skills@partner-channel-conflict`.
7. Ask the self-positioning question: on this map, are you a keystone, a niche player in someone else's ecosystem, or accidentally behaving like a dominator (Iansiti & Levien, 2004)? The answer determines whether you recruit partners or get recruited.
Read overall ecosystem health through three measures:
- Productivity: does participation make members more efficient?
- Robustness: does it survive shocks?
- Niche creation: does it keep spawning new specialist roles?
The typology predates modern digital platforms.
8. Run the category-level discovery sessions in the profession's own formats, not generic brainstorming:
- An IPP definition session for each candidate category.
- A JVP workshop testing whether the category can articulate joint customer value.
A category that fails the JVP test does not proceed. Run this _before_ scoring, so a category that cannot state its joint value never receives a composite that later has to be retracted. See [references/discovery-workshops.md](references/discovery-workshops.md).
9. Prioritize the surviving categories. Build a weighted scorecard composite for each axis, then plot categories on the prioritization 2×2: strategic fit × ease of execution (Chris Lavoie's quadrants). Segment scorecard weights by partner type: a referral partner and a systems integrator must never share one scorecard.
Rank the categories that already exist in this ecosystem, for investment attention among them. Two handoffs apply beyond this ranking:
- Ranking named candidate alliances belongs to `mbfinotti/partnerships-skills@alliance-prioritization`.
- Sequencing categories the company does _not_ yet have (entry order, readiness gates, capacity limits) belongs to `mbfinotti/partnerships-skills@partner-ecosystem-expansion`, which takes this ranking and the whitespace below as its input.
See [references/prioritization-scorecards.md](references/prioritization-scorecards.md).
10. Choose the visualization by the decision it settles, not by how it looks in a deck. Rank the four formats before offering them. Present the top 2-3 with their trade-offs and your recommendation, then let the user pick before building it.
- **Matrix** - a grid of partners on coverage × capability depth. Settles the investment call, which is the decision this whole map exists to inform. Near-zero build: it is a table, and it reads from the scorecard composites you already have.
- **Heat map** - colour by geography, vertical, or capability. Settles where the whitespace is, at a glance and in one image an exec will actually retain. An hour, and it needs one clean dimension attached to every player.
- **Network diagram** - vendor, partners, and the connections between them. Settles who the hubs are, and it is the only format that can. A day or more plus real layout skill; without it the picture reads as a hairball and settles nothing.
- **Tiered view** - concentric circles or a pyramid by strategic relevance. Settles core versus periphery, but that ranking was already decided in step 9, so the format mostly restates it.
- effort: network diagram > heat map > tiered view > matrix
- value: matrix > heat map > network diagram > tiered view
- efficiency: matrix > heat map > tiered view > network diagram
Default to the matrix. Build the heat map instead when the stated goal from the Interview was coverage gaps rather than investment. It costs an hour more than the tiered view because it needs one clean dimension attached to every player, where the tiered view only redraws a ranking step 9 already produced.
- **What this order starves:** the network diagram. It answers a question no other format can answer at all, and it is the only one that costs a day plus a skill the team may not have, so a ratio rejects it every time and hub structure simply never gets looked at.
- **Promote it when** the decision in front of the user is which player is the hub (routing, aggregation, or a partner other partners depend on) and someone with real layout skill is free.
- **Delete it when** nobody has that skill. A hairball settles nothing and costs a day, so don't present it as ambitious.
- **Skip the tiered view entirely** once the prioritization 2×2 exists: two views of one ranking invite the reader to look for a difference that is not there.
See [references/overlap-and-conflict.md](references/overlap-and-conflict.md).
11. Validate the map against ecosystem-level health metrics, as a diagnostic reading only. Per-partner scorecards and review cadences belong to `mbfinotti/partnerships-skills@partner-performance`.
- effort: sourced-vs-influenced split (CRM field definitions plus a written de-duplication policy - a week where they don't exist, near-zero where they do) > activation ratio (near-zero wherever registration dates exist) == coverage read (already computed in step 6)
- value: sourced-vs-influenced split (whether the ecosystem earns money at all, and whether recruitment is outrunning enablement) > activation ratio (catches logo collecting) > coverage read (restates step 6)
- efficiency: activation ratio > sourced-vs-influenced split > coverage read
Activation ratio and coverage read tie on effort at a genuine zero: one is a single query against registration dates you already store, the other is a number step 6 has already computed. Neither costs anything beyond reading it. They separate on value, and the activation ratio wins.
- **Read first:** the activation ratio. It is one query and it invalidates a whole class of map.
- **What this order starves:** the sourced-vs-influenced split. It is the only reading that says whether the ecosystem earns money at all, and the week of CRM field definitions and de-duplication policy behind it loses to two free numbers every time.
- **Promote it when** the map is asking for investment rather than reporting coverage, since no exec funds an ecosystem on an activation ratio. It leads outright wherever those CRM fields already exist, which turns the most expensive reading here into a free one.
- **Delete it when** the CRM cannot carry those fields. Say plainly that the earning question stays unanswered: carrying it as a pending metric lets a later reader assume it was measured.
See [references/ecosystem-health-kpis.md](references/ecosystem-health-kpis.md).
12. Present the deliverable section by section, and validate each section with the user before drafting the next:
- Inventory
- Classification
- Overlap findings
- Gaps and conflicts
- Self-positioning
- Prioritization
- Memo
Revise on pushback. Require explicit approval on every section before finalizing anything.
13. Score the finished map against the pass threshold below. Iterate until it passes. If it cannot pass (fewer than ten real ecosystem players, no verifiable overlap), say so plainly and scope the honest next step, usually customer interviews, rather than shipping a decorative map.
14. Set the review discipline: the map is never finished. Agree a recurring review cadence plus immediate-update triggers:
- A merger or acquisition.
- New regulation.
- A category moving quadrants.
Timelines for the exercise itself are not reliably published. Treat any duration as an estimate, though a founder-led compressed first pass has been done in roughly a day.
15. If your harness has persistent memory, memorize the approved map's scope, partner categories, and prioritization decisions so a later run starts from them instead of re-interviewing.
## Pass Threshold
A first map is done when all of these hold. Iterate, meaning more interviews, more deal reviews, or a tighter scope, until they do:
- **At least ten ecosystem players categorized** by journey role and engagement depth.
- **Verified overlap data** behind every overlap claim - account mapping output or customer-interview evidence, never assumption.
- **A retroactive closed-won influence analysis** showing where the ecosystem already touches revenue.
- **At least one named decision the map informs**, with an owner - a map that drives no decision is the discipline's most common failure.
- **Every quoted benchmark carries a provenance flag** (vendor first-party, analyst, aggregator, or consultancy) - almost every published number in this field comes from a vendor that profits when the number looks good.
## The Ecosystem Strategy Memo
The map is the evidence. The memo is what an executive actually reads and funds. Keep it to roughly two pages, and write every line so a reader can trace it back to map evidence:
```
ECOSYSTEM MAP - <business area>, <date>
Scope : business area, ICP, geography, and what was deliberately excluded
Inventory : players found, by journey role × engagement depth, with data sources
Overlap : verified overlap per partner category + the four-quadrant read
Closed-won read: what the retroactive review showed about existing ecosystem influence
Gaps : uncovered segments/geographies/journey stages, each sized
Conflicts : zones detected, accounts and revenue at stake (detection only)
Positioning : keystone, niche player, or drifting toward dominator - and why
Priorities : categories on the 2x2, with the scorecard weights that placed them
Decisions : what this map asks for, each with an owner and a review date
Open questions : what the data could not answer, and what would answer it
```
Two rules govern the memo:
- **Every claim names its source.** "Three of eight closed-won deals named an implementation partner" is reviewable; "SIs matter to us" is not.
- **The open-questions section is mandatory.** A map with no stated uncertainty is a map that stopped asking, which is how a decorative landscape gets mistaken for evidence.
## B2B and B2C
The spine is identical in both:
- The identify, analyze, visualize, optimize sequence.
- The one-business-area scoping rule.
- The map-from-customer-data-not-inbound-requests rule.
- The recurring-review discipline.
- Strategic-fit × ease-of-execution prioritization logic.
Say so when the user asks. Do not reinvent the method per side.
What genuinely changes:
| Dimension | B2B | B2C |
| ------------------ | ---------------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------- |
| Partner vocabulary | Resellers/VARs, distributors, MSPs, SIs, ISVs, marketplaces, alliances | Retail/wholesale, creators and affiliates, licensing, co-branding |
| Partner counts | Tens to hundreds; high value per partner | Influence band runs to thousands at far lower value each |
| Attribution | Sourced vs influenced pipeline over long cycles | Transactional and fast-cycling: LTV of partnership-acquired customers vs other channels, plus brand lift |
| Signature conflict | Partner-vs-partner and direct-vs-partner | D2C vs retail partner |
Both taxonomies and the D2C-vs-retail conflict pattern are detailed in [references/partner-type-taxonomy.md](references/partner-type-taxonomy.md) and [references/overlap-and-conflict.md](references/overlap-and-conflict.md).
## Failure Modes
These carry no efficiency ordering, deliberately, because each row is a different diagnosis with one fix, not a menu of competing fixes for one problem. Ranking them would rank the reader's symptoms rather than their options, which is false precision. Apply every row that matches.
| Failure | Fix |
| ---------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------- |
| Map created but never used for a decision | Attach named next steps with owners; put the map into a recurring strategic review |
| Competitors excluded from the map | Map coopetition and the partners you share with competitors - they are signal |
| Map treated as finished | Review cadence plus event triggers (M&A, regulation, quadrant moves) |
| Whole company mapped at once | Scope to one business area; re-run per area later |
| Inventory sourced from inbound requests or personal network | Rebuild from customer data and verified overlap |
| Logo collecting - a long tail of inactive partners counted as coverage | Read the activation ratio; a partner list is not a channel |
| One scorecard for all partner types | Segment weights by type; each type has a different route to revenue |
| Recruitment running ahead of enablement | Partner count rising while sourced revenue stays flat is the tell; capacity to support a category belongs in its prioritization score |
## Invocation Examples
- "Map the partner ecosystem around our mid-market product line - I need to show the exec team where the coverage gaps are."
- "Which partner categories actually influence our closed-won deals? We have three years of CRM history and no attribution fields."
- "We keep signing partners with no shared accounts. Build the overlap analysis that would have caught that."
## Reference
- [references/partner-type-taxonomy.md](references/partner-type-taxonomy.md) - journey-role and depth axes, the B2B and B2C type tables, contested boundaries and misclassification traps.
- [references/overlap-and-conflict.md](references/overlap-and-conflict.md) - account mapping quadrants, whitespace rules, the three conflict patterns plus D2C-vs-retail, and the artifact format table.
- [references/prioritization-scorecards.md](references/prioritization-scorecards.md) - weighted scorecard mechanics, the Lavoie 2×2, how the two combine, with a worked category example.
- [references/ecosystem-health-kpis.md](references/ecosystem-health-kpis.md) - sourced vs influenced, activation ratio, the four-bucket frame, benchmarks with provenance flags.
- [references/discovery-workshops.md](references/discovery-workshops.md) - Value Network Analysis workshop format, Adner's value blueprint, IPP definition session, JVP workshop question set.
Sibling skills (downstream handoffs, same collection):
- `mbfinotti/partnerships-skills@partner-channel-program` - designing the partner program the map says is warranted.
- `mbfinotti/partnerships-skills@partner-tiering` - tier criteria and benefits inside an existing program; the map's concentric circles are a layout, not tiers.
- `mbfinotti/partnerships-skills@partner-ecosystem-expansion` - planning which partner categories to add into the whitespace this map quantifies.
- `mbfinotti/partnerships-skills@alliance-prioritization` - ranking named candidate alliances; this skill ranks categories only.
- `mbfinotti/partnerships-skills@partner-channel-conflict` - rules of engagement for the conflict zones this map detects.
- `mbfinotti/partnerships-skills@partner-performance` - per-partner scorecards and review cadences beyond this map's ecosystem-level diagnostic.