Digital Platform Strategy and Network Effects

A platform strategy governs the value outsiders create through your product and the platforms you depend on. Define the exchange, test network effects and make the rules explicit.

Why this matters

Enterprise products often combine a core pipeline with an ecosystem of connectors, partners and marketplaces. Decide who can build, what participants gain and who captures the value.

An open API gives builders access. A functioning ecosystem also needs demand, rewards and quality controls. Test claims that each new participant improves the product for others.

Your strategy must also cover hosts you depend on: marketplaces, suites, clouds and AI assistants. Their fees, rules and competing products can change your economics. Chapters 13, 15 and 16 connect these choices to competition, pricing and defensibility.

Platforms and pipelines

Two ways to create value

Marshall Van Alstyne, Geoffrey Parker and Sangeet Paul Choudary distinguish pipelines from platforms in Platform Revolution and their 2016 HBR article. A pipeline controls a linear chain: design, make, sell and support. A platform enables valuable, safe, repeatable exchanges between external producers and consumers.

Their Apple example shows both: a pipeline handset and a platform App Store. B2B software often combines a core product with an integration catalog, partner program and API.

The authors name four roles in every platform ecosystem:

The same company can hold more than one role. A managed service provider can be a provider (it delivers your product to its customers) and a producer (it writes automations that run on it).

Three shifts

The authors identify three strategic shifts:

1. From resource control to resource orchestration. On a platform, the hard-to-copy asset is the network of producers and consumers and what its members contribute, more than anything the owner holds on its own balance sheet.
2. From internal optimization to external interaction. Management shifts from running your own processes to persuading people you don’t control to participate, which makes ecosystem governance a core skill.
3. From customer value to ecosystem value. A platform maximizes the total value of the ecosystem, which sometimes means subsidizing one side to attract the other.

The authors also argue that platforms need different metrics, and name four for a platform health review: interaction failure (how often a consumer arrives and finds nothing useful), engagement (how actively participants contribute and return), match quality (how well the platform connects the right producer to the right consumer) and negative network effects (congestion, spam and misbehavior that grow with scale).

The core interaction

Platform Revolution starts with the core interaction: the exchange a platform enables. Define its participants (producer and consumer), value unit (such as an app or connector) and filter (how units reach consumers). Choudary’s 2015 MIT interview urges designers to start with this interaction. Costly mismatches need stronger filters.

The HBR authors add a sequencing rule: launch with one high-value core interaction, then expand to adjacent ones, as Facebook did when it opened from one university to other colleges and then to everyone.

For a B2B product, write the core interaction as a sentence:

On our platform, [producer] creates [value unit]; [filter] matches it to [consumer], who [acts on it].

If you can’t fill in the filter, you probably have an API and not yet a platform.

Network effects

What a network effect is, and what it isn’t

NFX, a venture firm that publishes a widely cited taxonomy of network effects, defines one simply: each new user makes the product more valuable to every other user. NFX’s own study claims network effects account for about 70% of the value created by technology companies since 1994. That’s NFX’s analysis rather than independent research, but it explains why “we have network effects” appears in so many pitch decks.

Distinguish network effects from these other advantages:

• Scale effects: fixed costs spread over more customers, so you can invest more in the product. Real advantage, no network.
• Learning effects: the vendor learns from usage and improves the product. Real, often valuable, but the benefit doesn’t depend on users connecting to each other.
• Switching costs: customers stay because leaving is painful. That’s lock-in.

Chapter 16 treats each of these as a moat in its own right. Keep them separate from network effects because they behave differently: network effects can compound and tip a market, while scale and learning effects usually flatten out.

The types that matter in B2B

NFX’s “Network Effects Manual” (2021 version) lists 16 types, arranged on a map with the strongest and simplest at the center. You don’t need all 16. For enterprise and platform businesses, a handful do most of the work:

The first row is a family rather than a single NFX type: NFX groups several same-side effects, protocol effects among them, under its direct category, and groups marketplace, platform and asymptotic marketplace effects as two-sided.

Direct network effects are same-side: more of one kind of participant helps others of the same kind. Indirect or cross-side effects run between sides: more developers help users, and more users attract developers. B2B platforms mostly depend on cross-side effects, so the hard part is usually getting the producers to show up.

Expertise can reinforce adoption. Trained administrators reduce customers’ hiring and training costs. More customers make the skill worth learning. Certification and public training can strengthen this effect.

Data network effects and their limits

The most overclaimed effect in B2B, and especially in AI products, is the data network effect: “More customers give us more data, which makes the product better, which brings more customers.”

Andrei Hagiu and Julian Wright took this loop apart in a 2020 HBR article, “When Data Creates Competitive Advantage.” “In most instances,” they write, “people grossly overestimate the advantage that data confers.” They prefer the term data-enabled learning because the loop often involves no network at all. The vendor learns; customers don’t benefit from each other. Their analysis suggests asking a set of questions before you count data as an advantage:

• How much value does customer data add compared with what the product does without it?
• Does the marginal value of more data stay high, or does it plateau quickly?
• How fast does the data lose relevance?
• Is the data proprietary, or can competitors get the same thing elsewhere?
• Are the improvements hard to imitate once someone sees them?
• Does learning from one customer improve the product for other customers? (If yes, it’s closer to a real network effect.)

Martin Casado and Peter Lauten argue in “The Empty Promise of Data Moats” (2019) that enterprise data advantages often weaken with scale. A support chatbot learns common intents cheaply, then pays more for smaller gains in the long tail. They recommend a minimum viable corpus, high-quality proprietary sources and advantages beyond data.

NFX’s manual agrees: data network effects are generally weaker than many investors believe, and their strength depends on how central the data is to the product. A credit bureau gets more valuable with more data, but consumers don’t generate that data by using the product, so NFX classes it as a scale effect.

Strength, ceilings and leaks

Three ideas from NFX’s “Network Effects Bible” help you judge strength.

• Density and clustering. A network with many connections per member is stronger than a large but sparse one. NFX advises finding the densest center of your network and expanding outward from it. In B2B, density often sits inside a single account, an industry vertical or a partner’s customer base.
• Asymptotes. Past some size, more participants add little value for the people already there. Once a responder has connectors for every tool they run, the hundred-and-first connector does nothing for them.
• Leaks. Two threats drain value out of a network. Disintermediation happens when participants meet on the platform, then transact off it. Multi-homing (NFX calls it multi-tenanting) happens when participants join competing networks at the same time because it’s cheap to do so.

Andrei Hagiu’s 2013 MIT Sloan article distinguishes switching costs (leaving) from multihoming costs (also joining a rival). B2B partners can often list on several marketplaces, and customers can connect several tools. Cheap multihoming weakens winner-take-all outcomes and increases the importance of interaction quality.

Getting started: the cold start problem

Every network is worthless at size zero. Andrew Chen’s The Cold Start Problem (2021) describes how networks get going in five stages: the Cold Start Problem, the Tipping Point, Escape Velocity, Hitting the Ceiling and The Moat.

Three of Chen’s ideas matter most for B2B PMs:

• The atomic network. The smallest network that is stable and can grow on its own. In consumer products it might be one campus or one city. In B2B it’s often one team, one account or one integration pair: a single SRE team with its five core tools connected, say, or one partner’s customer base.
• The hard side. Chen describes it as the minority of users who create disproportionate value: creators, sellers, app developers. They are the hardest to attract and keep. His advice is to solve a hard problem for the hard side, starting with an underserved niche of it, then expand to adjacent segments. In a developer platform, the hard side is the builders.
• Anti-network effects. Early on, a network that’s too small drives people away because they can’t find what they need, which shrinks it further. A sparse integration catalog does exactly this to an enterprise evaluator.

Annabelle Gawer and Michael Cusumano’s 2008 MIT Sloan article recommends building key complements or creating incentives for others. A B2B vendor can build the first connectors and open a partner program once the atomic network works.

Openness, governance and envelopment

Two dials of openness

Van Alstyne, Parker and Choudary describe openness along two dimensions:

• Open architecture: how much access outsiders have to the platform’s resources, such as APIs, SDKs, data and developer tools.
• Open governance: how much outsiders shape the rules of trade and share in the rewards.

Move both dials together: access enables builders, and rewards motivate them. Platforms often open over time. The authors’ ideal, permissionless innovation, lets producers build without approval and guarantees a share of the value.

Openness needs curation. The authors cite Chatroulette’s failure to control harmful noise. Reviews, ratings, certification and enforcement help protect useful participation.

Four platform decisions

Hagiu’s MIT Sloan article frames the strategic choices for any multisided platform as four decisions. They make good section headings for a platform plan:

1. Number of sides. Who are the distinct groups you bring together? Adding a side (say, managed service providers alongside direct customers and integration partners) adds value and complexity.
2. Design. Which features and services does the platform provide itself, and which does it leave to participants?
3. Pricing structure. Which side pays, how much, and which side gets subsidized? Chapter 15 covers pricing mechanics; the platform question is who pays.
4. Governance rules. What can participants do, what’s forbidden, and how are rules enforced?

Gawer and Cusumano add that platform leaders solve technical problems (architecture, interfaces, how much intellectual property to disclose so others can build) and business problems (which complements to make and which to incentivize). The HBR authors warn that skills for controlling internal resources don’t transfer well to nurturing an ecosystem.

APIs, developer ecosystems and marketplaces

An API is open architecture and nothing more. It becomes a developer ecosystem when the other three pieces arrive: a reason to build (Chen’s hard problem for the hard side), a share of the value (the open-governance dial) and a filter that puts builders’ work in front of the customers who need it. Treat the developer surface as a product with its own customer, the builder, and its own funnel:

• Discover. Can a builder find out what the platform lets them do, and which customers they’d reach?
• First working call. How long from sign-up to a call that returns real data in a sandbox? This is the leading indicator of a developer ecosystem, because builders who stall here rarely come back.
• Ship. What review, certification and listing steps sit between a working integration and a customer using it, and how long do they take?
• Earn. How do builders get paid or rewarded: revenue share, co-sell, leads, placement, a certification badge?
• Stay. What do you promise about versioning and deprecation? Builders weigh the cost of rework every time you break an interface.

Expose enough interfaces for valuable complements while retaining the controls that hold the platform together. Record these choices in the developer platform brief.

A marketplace adds transactions to the ecosystem, so the HBR health metrics matter more. Interaction failure (a buyer searches and finds nothing that fits) is the cold start showing up in the catalog. Match quality decides whether buyers trust the ranking. Disintermediation is the marketplace’s particular leak: once a partner and a customer have met, they can close the next deal directly. You can’t stop that entirely, so make staying on the platform worth it through billing, procurement, trust signals and support, and write any rules about steering customers off the platform into the governance policy.

Envelopment: the B2B threat

Thomas Eisenmann, Geoffrey Parker and Marshall Van Alstyne described platform envelopment in a 2011 Strategic Management Journal paper. A provider in one platform market enters another by bundling its own functionality with the target’s, using the user relationships it already has. The entrant needs a bundle and a shared customer, not a breakthrough. Network effects protect an incumbent against standalone rivals; they offer much less protection against a platform that already owns the customer relationship.

In enterprise software, envelopment is a common way for specialist products to lose. A large suite adds your category as a feature, includes it in a contract the customer already has, and wins on procurement simplicity rather than capability. Chapter 13’s competitive analysis should name the platforms that could envelop you, and Chapter 16 covers the defenses.

Platforms you don’t own

Hosts and complements

When you list on an app store, a hyperscaler marketplace or an AI assistant’s directory, you’re a producer on someone else’s platform. Gawer and Cusumano’s term for what you supply is a complement: something that makes the host platform more valuable.

Being a good complement is often the right strategy. The host brings distribution, trust and a buying path; the cost is dependency. Four questions frame the tradeoff:

1. What does the host give us? Distribution, procurement shortcuts, trust signals, billing, discovery.
2. What does it take? Fees, data, rules about what we can do, sometimes the direct customer relationship.
3. What can change without our consent? Policies, ranking, fees, technical requirements.
4. What’s our exit and multi-homing plan? Can we serve the same customers through another host, or directly, if this one changes the deal?

Add a fifth for B2B: are we a complement the host might envelop? A host has every incentive to build the features its complements prove valuable.

App stores and published rules

Apple’s App Review Guidelines illustrate published governance across Safety, Performance, Business, Design and Legal. Broken apps may be removed, review abuse can lead to expulsion and developers remain accountable for third-party code.

The guidelines also show that a host’s rules change. As of October 2026, apps on Apple’s US storefront may include buttons and links to purchase methods outside Apple’s in-app purchase system without applying for a special entitlement, while most other storefronts still require one. If your revenue model depends on a host’s rules, those rules are a dependency to track like any other.

Hyperscaler marketplaces

Cloud marketplaces have become a buying path for enterprise software for an economic reason. Microsoft’s September 2025 launch of Microsoft Marketplace, which merged Azure Marketplace and AppSource, made the logic explicit: purchases of eligible solutions count fully toward a customer’s Azure consumption commitment. A buyer with a pre-committed cloud budget can buy your product without finding new money. Microsoft also described resale-enabled private offers that let a vendor authorize channel partners to sell on its behalf.

AWS added a category for AI agents and agent tools to AWS Marketplace in July 2025, with listings that can indicate support for agent protocols such as MCP and A2A. Salesforce launched AgentExchange in March 2025 as a marketplace for prebuilt agent actions, templates and components, with more than 200 partners at launch. The pattern: the large platforms are turning agent capabilities into catalog items, and protocol support has become a filter buyers use.

AI model and assistant platforms

AI model providers and assistant directories are also hosts. Record model dependencies in the vendor register (Chapter 31). As of October 2026, assistant directories accept MCP-based integrations under their review requirements.

Assign each AI host an owner and exit plan. Track model deprecations, directory rules and capabilities the host may build itself.

How to apply it

This six-week method produces a platform map, network effects assessment, ecosystem strategy, developer brief and governance policy.

Weeks 1 and 2: Map what exists.

1. Inventory the outsiders. List every party outside your company that creates value in your product today: partners, connector authors, resellers, MSPs, integrators, customers who share runbooks. For each, note what they produce, who consumes it and what they get. Pull the evidence (integration usage, partner-sourced revenue, marketplace transactions) rather than relying on the partner team’s slide.
2. Draw the platform map. Assign each party to a role: owner, provider, producer or consumer. Write the core interaction as one sentence, including the filter. Then list the platforms you depend on (marketplaces, clouds, model providers, AI assistants) and the platforms that could envelop you.
3. Write the four decisions as they stand today. Number of sides, design, pricing structure and governance rules. Note which were decided deliberately and which just happened.

Weeks 3 and 4: Test the network effects.

4. List every claimed network effect. Take them from strategy decks, board materials and sales pitches. For each, name the NFX type, the sides involved and the mechanism: who gets more value when whom joins?
5. Find the evidence. For a cross-side effect, does an account’s usage rise when more relevant integrations exist, and do producers arrive faster as the customer base grows? For a data effect, does customer A’s usage measurably improve the product for customer B, and where does that plateau? Write a verdict for each: real network effect, data-enabled learning, scale effect, switching cost or aspiration.
6. Place yourself on Chen’s five stages. Name the atomic network and the hard side. Check the four HBR health metrics: interaction failure, engagement, match quality and negative network effects.

Week 5: Decide the stance.

7. Choose host, complement or both, platform by platform. For your own platform, decide how far to open the architecture and governance, and in what order. For each platform you depend on, answer the five host questions and write the exit or multi-homing plan.
8. Write the ecosystem and partner strategy. Segment partners, define the value exchange for each segment and pick three to five metrics.
9. If you’re opening to builders, write the developer platform brief. Target builder, the hard problem you’ll solve for them, surfaces, access tiers, reward model, versioning and deprecation policy, success metrics.

Week 6: Govern and commit.

10. Draft the platform governance policy. Participant obligations, review and certification, data and security rules, quality filters, an enforcement ladder, appeals, and how much notice you give before changing the rules.
11. Review with your leadership and the partner organization. Record the openness decision, the network effect verdicts and the governance policy in the decision log. Agree on which platform metrics go into the quarterly business review (Chapter 29).

Revisit the network effects assessment twice a year. Asymptotes arrive and multi-homing rises as a product grows, so an effect that was real at one size can flatten at the next.

The AI lens

Agent ecosystems are platforms

Agent ecosystems let AI agents discover tools and work with other agents. Their protocols now have shared governance.

MCP, agent to tool. Anthropic introduced the Model Context Protocol in November 2024 as an open standard for connecting AI assistants to the systems where data lives, replacing a custom integration for every pairing of assistant and data source. On 9 December 2025, Anthropic donated MCP to the newly formed Agentic AI Foundation (AAIF), a directed fund under the Linux Foundation. The foundation’s founding projects were MCP, Block’s goose and OpenAI’s AGENTS.md, and its platinum members include the major cloud and AI vendors. At the time of the donation, Anthropic reported more than 10,000 active public MCP servers and more than 97 million monthly SDK downloads, with clients including ChatGPT, Cursor, Gemini, Microsoft Copilot and VS Code.

A2A, agent to agent. The Agent2Agent protocol, created by Google and announced in April 2025, became a Linux Foundation project in June 2025. Its stable v1.0 specification arrived in early 2026, with signed Agent Cards (the descriptions agents publish about themselves) and support for multi-tenancy. In August 2026 the A2A project announced it had joined the AAIF as a growth-stage project, reporting backing from more than 150 organizations. The project describes MCP as the vertical layer (an agent reaching down to tools and data) and A2A as the horizontal layer (agents working with other agents), and calls the two complementary.

Registries and marketplaces. Discovery is layering the way app stores did. The MCP Registry, previewed in September 2025, is an open catalog of public MCP servers that anyone can build sub-registries on top of: public ones that act as curated marketplaces for particular clients, and private ones that enterprises run internally. Hyperscaler and SaaS marketplaces now list agents and agent tools, and AI assistant directories accept MCP-based integrations subject to review.

In NFX’s terms, MCP and A2A are protocol network effects: each product that adopts them makes adopting them more valuable for everyone else. Anthropic’s donation is a clear case of the HBR authors’ open-governance lever. A platform owner gave up control of a protocol to grow the protocol’s network effect, and the competition for value moves up the stack to models, clients and services.

Host, complement or both

The agent ecosystem forces the host and complement choice on every B2B product:

• Be a host. Agents and connectors from outside plug into your product. You need a filter (which ones you trust), governance (what they may do) and a cold start plan for the builders.
• Be a complement. Publish your capabilities as an MCP server or an A2A agent so other hosts (assistants, ITSM suites, cloud agent runtimes) can use them. You get distribution through someone else’s network, and you take on the host dependency.
• Do both. Decide, platform by platform, which role you’re playing and what you expect from it.

Publishing an MCP server is now a distribution decision more than a bet on one vendor, because the protocol is neutrally governed and supported by many clients. It also hands buyers a new question to ask: is your server in our private registry, with the scopes our security team approved? Plan for that question in the governance policy and the security pack.

Protocol governance also gives you a model for your own. The MCP specification published on 28 July 2026 adopted a formal feature lifecycle and deprecation policy with a minimum twelve-month deprecation window. A published deprecation policy tells builders how long their work will keep running. If you want producers to invest in your platform, make them the same kind of promise.

Choudary’s more recent book, Reshuffle, argues that AI lowers coordination costs and so changes firm boundaries and where value gets captured. Applied to agent ecosystems, that suggests the agent that coordinates the others, deciding which tool or agent handles each step, holds a strong position. If someone else owns that coordinating agent, watch it for envelopment.

Building AI-powered platform products

Three platform questions are specific to AI products. First, “our agent learns from every customer” is a data-enabled learning claim at best; data residency and customer contracts often forbid the cross-customer learning that would make it a network effect. Second, when an outside connector or agent acts through your product, its failure looks like yours, so governance has to cover what third-party tools may do as well as what they may read. Third, if each interaction costs you inference, subsidizing a side costs more than on a pure software platform; model it before promising free usage to builders (Chapters 15 and 31 cover the cost side).

Doing the work with AI

A harness connected to your CRM, partner portal, marketplace listings, analytics and integration logs can gather most of the evidence for a network effects assessment. Ask it questions:

• Which integrations are used weekly by the most accounts, and which are installed but idle?
• Do accounts with more active integrations retain or expand at different rates, after accounting for size?
• Which partner-sourced deals closed, through which marketplace, and against which cloud commitments?
• How long did the last ten new connectors take from first contact to first working call?

Ask the harness to draft an assessment with sources and verdicts. For every claimed effect, request the opposing case and evidence that would disprove it.

AI can review policy gaps and certification submissions. An accountable person must decide governance matters that affect partners.

The Beacon case: Beacon’s platform decision

The platform map. Northlight owns Beacon. Producers include connector vendors, MSPs, Northlight teams and SREs who author runbooks. Dana and Priya consume them. MSPs and resellers provide access. The core interaction is: a builder creates an integration or runbook step, Beacon’s diagnosis agent matches it to an incident, and a responder acts. The diagnosis agent and approval gate form the filter.

The network effects assessment. You list four claimed effects and give each a verdict:

Classify the Learn loop as data-enabled learning. Measure it separately while building the cross-side platform effect.

Cold start. The atomic network is one platform team (Priya’s 40 people) with its five core tools connected, or one MSP with its tenants. The hard side is the connector builders and MSPs. Following Gawer and Cusumano, Northlight builds the first 20 connectors itself, prioritized by which tools appear most in customer incidents, and opens a partner program only once those 20 are used weekly.

The openness decision. The Observe-versus-agnostic tension turns out to be an openness question. Observe-only protects a data advantage that, on inspection, is data-enabled learning. Opening the architecture to any observability tool through MCP connectors grows the market and the cross-side effect. You recommend an open architecture with curated governance: certified connectors, scoped credentials and Beacon’s human approval gate for any action, with full autonomy only for low-risk actions the customer allowlists. Observe customers still get the deepest integration, which keeps the advantage without making it a wall.

Platforms Beacon doesn’t own. You map three host relationships:

• Hyperscaler marketplaces, so Marcus can buy Beacon against existing cloud commitments and Leo can buy through a distributor’s marketplace. Pricing per resolved incident needs metering that works through each marketplace’s billing.
• A Beacon MCP server, so responders can ask about incidents from the AI assistants they already use, listed in the public registry and in customers’ private registries with scopes documented for Sam.
• A Beacon agent exposed over A2A, so an ITSM agent (including Northlight Desk’s) can hand off diagnosis and receive a cited root cause back.

The envelopment risk goes on the map too: the large observability platforms named in the competitive analysis, and cloud providers’ own operations agents, could bundle a “good enough” incident agent into contracts customers already have.

Governance. The hallucinated root cause incident, where a customer rolled back the wrong service, shapes the policy. Any third-party connector that feeds diagnosis must pass certification; connectors that return bad data move through an enforcement ladder from warning to suspension to delisting; and every third-party runbook action that touches production runs with least privilege, audit logging and the approval gate. Sam reviews the policy before it’s published to partners.

The decision. Leadership approves the open architecture, the 20-connector cold start, the three host listings and the governance policy. The board deck replaces “network effects from our Learn loop” with two lines: a cross-side platform effect being built, and data-enabled learning being measured. You add three platform metrics to the quarterly review: weekly active integrations per account, connector-sourced diagnosis acceptance rate and time for a partner to build a first working connector.

Product 360 artifacts

# Platform map · [Product] · v[n] · [Date]

**Owner:** [PM]   **Reviewed with:** [partnerships lead, architect]   **Next review:** [Date]

## Ecosystem roles
| Role | Who (named parties or segments) | What they create or do | What they get today | Evidence |
|---|---|---|---|---|
| Owner | [us] | Architecture, access, rules | | |
| Providers | [resellers, MSPs, marketplaces] | Deliver access to customers | | |
| Producers | [partners, connector authors, customers who share content] | Create value units | | |
| Consumers | [users and teams] | Act on value units | | |

## Core interaction
On our platform, [producer] creates [value unit]; [filter] matches it to [consumer], who [acts on it].

- Value unit:
- Filter (how the right value unit reaches the right consumer):
- What a failed interaction looks like:

## Adjacent interactions (later)
1.
2.

## The four platform decisions, as they stand
| Decision | Today (deliberate or accidental?) | Proposed |
|---|---|---|
| Number of sides | | |
| Design (what we provide vs what participants provide) | | |
| Pricing structure (who pays, who is subsidized) | | |
| Governance rules | | |

## Platforms we depend on (we are a complement)
| Host platform | What it gives us | What it takes | What can change without our consent | Exit or multi-homing plan |
|---|---|---|---|---|
| | | | | |

## Platforms that could envelop us
| Platform | Shared customer relationship | Bundle they could offer | Early warning signal | Our defense (see moats, Chapter 16) |
|---|---|---|---|---|
| | | | | |

# Network effects assessment · [Product] · [Date]

**Owner:** [PM]   **Evidence sources:** [analytics, CRM, partner portal, marketplace data]

## Claimed effects
| # | Claimed effect (as stated in our materials) | NFX type | Sides involved | Mechanism: who gets more value when whom joins? | Evidence today (metric, value, source) | Density and clustering | Limits (asymptote, multi-homing, disintermediation) | Verdict |
|---|---|---|---|---|---|---|---|---|
| 1 | | | | | | | | |

Verdict options: real network effect / data-enabled learning / scale effect / switching cost / aspiration (no evidence yet).

## Data moat test (for any data claim)
| Question | Answer | Evidence |
|---|---|---|
| How much value does customer data add compared with the product without it? | | |
| Does the marginal value of more data stay high, or plateau? Where? | | |
| How fast does the data lose relevance? | | |
| Is the data proprietary, or available to competitors? | | |
| Are the improvements hard to imitate? | | |
| Does one customer's data improve the product for other customers? Are we allowed to use it that way? | | |

## Cold start position
- Stage (Cold Start Problem / Tipping Point / Escape Velocity / Hitting the Ceiling / The Moat):
- Atomic network (smallest stable network that grows on its own):
- Hard side (participants who create disproportionate value and are hardest to attract):
- Hard problem we solve for the hard side:

## Platform health
| Metric | Definition for our platform | Current value | Trend |
|---|---|---|---|
| Interaction failure | | | |
| Engagement | | | |
| Match quality | | | |
| Negative network effects (congestion, spam, misbehavior) | | | |

## What changes in our strategy and board story
[One paragraph: which effects we will build on, which we will stop claiming, what we will measure.]

# Ecosystem and partner strategy · [Product] · [Date]

**Owner:** [PM]   **Partner organization lead:** [Name]   **Decision maker:** [Name]

## Stance by platform
| Platform | Our role (host / complement / both) | Why | Commitment level (explore / invest / core) |
|---|---|---|---|
| Our own platform | Host | | |
| [Marketplace] | Complement | | |
| [AI assistant or agent runtime] | Complement | | |

## Partner segments and value exchange
| Segment | Examples | What they give us | What they get | Terms (rev share, co-sell, listing, certification) | Owner |
|---|---|---|---|---|---|
| Technology integrations | | | | | |
| Marketplaces and distributors | | | | | |
| Channel (resellers, MSPs) | | | | | |
| Systems integrators | | | | | |
| Agent and connector builders | | | | | |

## Openness plan
- Architecture (what outsiders can access now, and next):
- Governance (what say and share of value outsiders get now, and next):
- Sequence (what opens when, and the trigger for each step):

## Dependency and exit plan
| Host | Revenue or pipeline share through it | Biggest rule-change risk | Multi-homing or direct alternative |
|---|---|---|---|
| | | | |

## Metrics (three to five)
| Metric | Target | Review cadence |
|---|---|---|
| | | |

## Decisions and open questions
-

# Developer platform brief · [Product] · v[n] · [Date]

**Owner:** [PM]   **Engineering lead:** [Name]   **Developer relations:** [Name]

## Target builder (the hard side)
- Who they are (partner type, role, skill level):
- The hard problem we solve for them:
- What they use today instead:

## Job story
When [situation], I want to [motivation], so I can [expected outcome].

## Surfaces
| Surface | Purpose | Status | Audience |
|---|---|---|---|
| Public API | | | |
| SDKs | | | |
| MCP server (agent to tool) | | | |
| A2A agent and Agent Card (agent to agent) | | | |
| Sandbox and test data | | | |

## Access tiers
| Tier | Who qualifies | What they can do | Review required? |
|---|---|---|---|
| Open | | | |
| Certified partner | | | |
| Strategic | | | |

## Reward model
How builders share in the value they create: [listing, revenue share, co-sell, lead sharing, certification badge, marketplace placement].

## Versioning and deprecation
- Versioning scheme:
- Minimum deprecation notice: [period]
- How breaking changes are announced:
- Support window for old versions:

## Registry and marketplace listings
Where builders' work, and our own servers and agents, will be discoverable: [public registries, private enterprise registries, marketplaces].

## Success metrics
| Metric | Definition | Target |
|---|---|---|
| Time to first working integration | | |
| Active builders (shipped in last 90 days) | | |
| Third-party integrations used weekly | | |
| Share of customer value from third-party integrations | | |

## Risks and open questions
-

# Platform governance policy · [Platform] · v[n] · Effective [Date]

**Policy owner:** [Name]   **Approved by:** [product, security, legal]   **Next review:** [Date]

## Purpose and principles
[Two or three sentences: what the platform is for, and the balance it strikes between users' safety and builders' opportunity.]

## Scope
Who this applies to: [connector authors, agent builders, marketplace sellers, resellers].

## 1. Safety and security
- Least-privilege access: [scopes allowed by default; scopes needing review]
- Actions on customer systems: [which require human approval; which may run autonomously and under what customer allowlist]
- Audit logging: [what must be logged and retained]
- Data handling: [residency, retention, training use]
- Responsibility for third-party code and models inside a submission:

## 2. Performance and quality
- Certification criteria: [functional tests, accuracy thresholds, uptime]
- Quality filters: [how listings are ranked and matched]
- What happens when a submission stops working:

## 3. Business terms
- Fees and revenue share:
- Pricing and billing rules (including metering for usage-based pricing):
- Rules on steering customers off the platform:

## 4. Design and experience
- Required disclosures to users (what the integration does, what it can access):
- Branding rules:

## 5. Legal and compliance
- Regulatory obligations passed to participants (for AI features, see Chapter 33):
- Contract terms and liability:

## Review process
| Stage | Who reviews | Target time |
|---|---|---|
| Submission | | |
| Security review | | |
| Certification | | |

## Enforcement ladder
| Level | Trigger | Action | Notice given |
|---|---|---|---|
| 1. Warning | | | |
| 2. Suspension | | | |
| 3. Delisting | | | |
| 4. Removal from program | | | |

## Appeals
How a participant appeals, who decides and how fast.

## Changes to this policy
Minimum notice before a change takes effect: [period]. Where changes are announced: [channel]. Change log below.

| Version | Date | Change | Reason |
|---|---|---|---|
| | | | |

Prompts

Goal: Draft a platform map grounded in operating evidence.
Paste in (or connect the harness to): the partner list, integration usage data, marketplace transaction reports, reseller and MSP account lists, and the current product strategy. Use only tools approved for customer and partner data.

Build a platform map for [product] using the four ecosystem roles: owner, providers, producers and consumers.

1. Assign every party in the material to one or more roles. For each, say what they create or do, what they get today, and cite the source.
2. Write the core interaction as one sentence: "[producer] creates [value unit]; [filter] matches it to [consumer], who [acts on it]." If the material doesn't show a filter, say so.
3. List the platforms we depend on as a complement, with what each gives us and what it takes.
4. List platforms that share our customer relationships and could bundle our function into their offer.
5. State the four platform decisions (number of sides, design, pricing structure, governance rules) as they appear today, and mark each as deliberate or accidental based on the evidence.

Use documented partners, usage numbers and terms. Write "No evidence" for missing information.

Check the output: confirm three of the cited figures against the source reports. Check that the filter is a real mechanism in the product, not a marketing phrase.

Goal: Separate real network effects from scale effects, learning and aspiration.
Paste in: every network effect claim from our strategy, board and sales materials, plus the analytics the harness can reach (account usage, integration usage, retention and expansion by cohort). Use only tools approved for customer data.

Act as a skeptical board member reviewing the network effect claims for [product].

For each claim:
1. Name the network effect type (direct, protocol, two-sided platform, marketplace, asymptotic marketplace, expertise, data) and the sides involved.
2. State the mechanism: who gets more value when whom joins?
3. Propose the evidence that would confirm it and the evidence that would refute it, then report what our data shows, with sources.
4. For any data claim, answer: does one customer's usage improve the product for other customers, are we allowed to use the data that way, and where does the improvement plateau?
5. Give a verdict: real network effect, data-enabled learning, scale effect, switching cost or aspiration.
6. Argue the opposite of your verdict in two sentences.

Use "flywheel" only where evidence supports every step.

Check the output: for every "real network effect" verdict, look at the cited evidence yourself. If the evidence is an aggregate correlation, ask whether account size explains it.

Goal: Find the atomic network and a hard problem to solve for the hard side.
Paste in: the platform map, a list of integrations customers request most (from support tickets, sales notes and lost-deal reasons), and current integration usage. Use only tools approved for customer data.

For [product], help me plan how to start the producer side of our platform.

1. Propose three candidate atomic networks: the smallest set of customers, builders and integrations that would be stable and grow on its own. For each, say why it's dense.
2. Identify the hard side: which participants create disproportionate value and are hardest to attract?
3. For the hard side, propose two hard problems we could solve for them, starting with an underserved niche.
4. List the complements we should build ourselves before opening to partners, ranked by how often they appear in customer demand, with sources.
5. Define the signal that would tell us the atomic network works and it's time to open the partner program.

Check the output: are the "build ourselves" complements backed by demand evidence, or by what's easy to build? Confirm the hard side is the group that's actually scarce today.

Goal: Make a deliberate choice about MCP servers, A2A agents and agent marketplaces.
Paste in: the platform map, the product's main capabilities, customers' requests for AI assistant or agent integrations, the security team's requirements, and the list of agent marketplaces and assistant directories we're considering. Use an approved tool for customer requests and security requirements.

For [product], recommend whether to act as a host, a complement or both in the agent ecosystem.

1. List the capabilities other agents and assistants would most want to call, with evidence from customer requests.
2. For each, say whether it should be exposed as an MCP server (agent to tool), an A2A agent (agent to agent), or neither yet, and why.
3. For each marketplace or directory under consideration, answer: what it gives us, what it takes, what can change without our consent, and our exit plan.
4. Identify where we'd be a complement that the host could later absorb into its own product.
5. List the governance requirements a customer's security reviewer will ask about (scopes, audit logs, approval gates, registry listing) and which we already meet.

Base claims about protocols and marketplaces only on the documents I provide. If something isn't covered, say "needs verification."

Check the output: verify any statement about protocol versions, governance or marketplace terms against the current official documentation before it goes into a decision.

Goal: Produce a first draft of governance rules that builders can read and security can approve.
Paste in: the platform map, the developer platform brief, the security team's requirements for third-party access, recent incidents involving third-party integrations, and any existing partner terms. Incident and partner details are confidential, so use an approved tool.

Draft a platform governance policy for [platform] with these sections: purpose and principles; scope; safety and security; performance and quality; business terms; design and experience; legal and compliance; review process; enforcement ladder (warning, suspension, delisting, removal); appeals; and how much notice we give before changing the policy.

Rules:
- Tie every security rule to a requirement in the material, and cite it.
- For any third-party action on customer systems, state whether it needs human approval and who can allowlist autonomous actions.
- Make every enforcement step specific: trigger, action, notice.
- Flag any rule that would be hard for a small partner to meet.

Check the output: have legal and security review it before publishing. Read the enforcement ladder from a partner's point of view: is each trigger objective enough that two reviewers would reach the same decision?

Goal: Understand how a larger platform could bundle your function, and what would defend against it.
Paste in: the competitive analysis, win and loss notes that mention bundling, and public announcements from the platforms that share our customers. Use only approved tools for deal data.

For [product], analyze the envelopment threat from [platform].

1. Describe the shared customer relationship: which buyers, which contracts, which budget lines.
2. Describe the bundle they could offer and what "good enough" would look like to our buyer.
3. List the evidence from win and loss notes that bundling has already cost us deals, with sources.
4. Identify which of our advantages survive a bundle (network effects, data-enabled learning, expertise, integrations, trust) and which don't.
5. Propose three responses, from cheapest to most ambitious, and the signal that would trigger each.

Base roadmap assessments on public announcements and our deal evidence. Label predictions separately.

Check the output: confirm the cited deals. Ask whether the proposed defenses are things buyers have said they value, or things we wish they valued.

Anti-patterns

Checklist

• The platform map names the owner, providers, producers and consumers, with evidence for each.
• The core interaction is written as one sentence, including a real filter.
• The four platform decisions (sides, design, pricing structure, governance) are written down and marked deliberate or accidental.
• Every claimed network effect has a type, a mechanism, evidence and a verdict.
• Every data claim has passed or failed the data moat test, and the board story matches the verdict.
• The atomic network and the hard side are named, with a hard problem the platform solves for the hard side.
• Openness of architecture and governance move together, with a sequence and a trigger for each step.
• Every platform you depend on has an owner, a dependency note and an exit or multi-homing plan.
• Envelopment threats are named, with early warning signals.
• For agent ecosystems, the host, complement or both decision is recorded per platform, with MCP and A2A choices and registry plans.
• The developer platform brief includes a published versioning and deprecation policy.
• The platform governance policy covers security, quality, business terms, enforcement, appeals and change notice, and security and legal have approved it.
• Platform health metrics (interaction failure, engagement, match quality, negative network effects) are in the quarterly review.