Platform Positioning Map¶
Artifact — instantiates Position-Based Leverage Design
Shows where a product, protocol, API, marketplace role, or service sits relative to users, complements, substitutes, and governance gates.
A Platform Positioning Map locates a product, protocol, API, or marketplace role inside an ecosystem of other actors and asks what its relational standing is worth. It draws the surrounding graph of who depends on whom: the users on one side, the complements that make the offering more valuable, the substitutes that could replace it, and — decisively — the governance gates (the platform owners, standards bodies, or app-store reviewers) whose rules can promote or evict you. Its defining move is that positional value here comes not from how far you reach but from whose value you capture or gate, and who can gate you. It is an artifact about dependency and leverage in a many-sided market, drawn so that a company can see whether it sits in a place a bigger platform will tolerate, envelop, or crush.
Example¶
A startup sells a specialized analytics tool that plugs into a dominant workplace-chat platform. Business is good, but the founders are uneasy, so they build a Platform Positioning Map. On it they place their product as a complement riding on the chat platform's API; the chat platform itself sits above them as a governance gate that controls API access, app-directory ranking, and pricing rules. To one side they mark substitutes: a native feature the platform could ship, plus two rival plug-ins. The map makes the exposure obvious — the startup's whole position rests on an interface the gatekeeper can change or absorb. The strategic reading is not "we have a great product" but "we occupy a commoditizable complement slot." That reframes the roadmap: the founders decide to widen to a second host platform, court an integration the gatekeeper is unlikely to build itself, and build a direct user relationship (data export, a standalone workflow) so their standing is not defined solely by one gate. None of that is visible on a features-and-revenue chart; it is visible on the positioning map.
How it works¶
- Draw the sides, not a line. Place users, complements, substitutes, and gatekeepers as distinct roles around the offering, with dependency arrows showing who needs whom and who can set terms for whom.
- Mark the governance gates. Identify every actor that can change the rules of access — API terms, ranking, certification, revenue share — and note what leverage each holds over your position.
- Trace envelopment and substitution paths. For each adjacent actor, ask how they could absorb your role (bundle it, ship it natively) or route around it, and how fast.
- Assess holding cost. Estimate what it takes to keep the position defensible against those moves — integrations to maintain, compliance with gate rules, the direct relationships that reduce gate dependence.
Tuning parameters¶
- Ecosystem scope — how wide to draw the map (one platform, or the whole multi-platform landscape). Narrow scope is legible but hides the envelopment threat from an adjacent giant.
- Role granularity — treating "complements" as one blob versus distinguishing enabling from competing complements. Finer roles reveal envelopment risk but add clutter.
- Gate-power weighting — how much leverage to attribute to each gatekeeper. Overstating it breeds fatalism; understating it is how startups get evicted.
- Time horizon — a snapshot versus a projected map after the gatekeeper's likely next move; the second is where defensibility judgments actually live.
- Substitution sensitivity — how easily a role is assumed to be commoditized; set it optimistically and the map will reassure you right up to the platform update that ships your feature for free.
When it helps, and when it misleads¶
Its strength is that it exposes platform risk that revenue and usage metrics conceal: it shows when an offering is a healthy complement, when it is a commoditizable one, and when it is squatting in a slot the gatekeeper will reclaim. Whole strategies — multi-homing, courting an unlikely-to-be-built integration, building direct user ties — fall out of reading the map honestly. The concept of platform envelopment, where an adjacent platform leverages shared users to absorb your role, is exactly the failure this artifact is meant to make visible before it happens.[n1]
Its failure mode is that the map is a story about relationships, and stories flatter the teller: it is easy to draw yourself as an indispensable complement and the gatekeeper as a benign partner. It also goes stale fast — one API policy change or one native feature can redraw the whole ecosystem overnight — and it can tip into paralysis, treating every gate as a death sentence. The guarding discipline is to draw the adversarial version of the map (what the gatekeeper does if you succeed), to date it against the platform's actual release cadence, and to convert its warnings into concrete reductions in gate dependence rather than dread.
How it implements the components¶
Platform Positioning Map fills the ecosystem-standing side of the archetype's machinery — the components about relational leverage and its durability, not about physical reach:
platform_or_ecosystem_position_map— its core deliverable: the offering's location among users, complements, substitutes, and governance gates.competitor_and_countermove_model— the envelopment and substitution paths are an explicit model of how adjacent actors and gatekeepers can contest or absorb the position.defensibility_and_holding_cost_assessment— it estimates what holding the ecosystem slot costs and whether it survives the gatekeeper's likely moves.
It does not measure how much of a field you can physically reach from a spot within cost or time bands (adjacency_and_reach_model, value_graded_field_map, position_candidate_set) — that reach/catchment artifact is Access Catchment Map, its nearest twin; the two differ in that this map is about relational dependency among actors, while the catchment map is about coverage of targets.
Related¶
- Instantiates: Position-Based Leverage Design — supplies the ecosystem-standing and platform-risk read of a position.
- Consumes: Network Centrality Analysis can quantify how central the offering is in the ecosystem graph the map draws.
- Sibling mechanisms: Access Catchment Map · Chokepoint or Gateway Analysis · Interior-Lines Route Model · Market Entry Positioning Matrix · Network Centrality Analysis · Overton-Window Position Scan · Prepositioning and Staging Plan · Ranking or Shelf-Placement Audit · Terrain or Topology Position Review
Editorial Notes¶
Form Classification¶
Form family: Representation, Specification & Plan
Rationale: Platform Positioning Map operates as a static representation, map, specification, schema, or prospective plan that externalizes information because it shows where a product, protocol, API, marketplace role, or service sits relative to users, complements, substitutes, and governance gates.
Independent corroboration: The frozen evidence defines Platform Positioning Map as 'Shows where a product, protocol, API, marketplace role, or service sits relative to users, complements, substitutes, and governance gates', so its operative form is Representation, Specification & Plan.
Review outcome: Independent reviewer agreement; high confidence.
Origin Attribution¶
Primary origin: Economics & Finance
Origin pattern: Cross-disciplinary synthesis
Present-day reach: Multi-domain
Rationale: Platform Positioning Map is rooted in economics and finance: Competitive platform strategy maps users, complements, substitutes, governance gates, and envelopment risk.
Related originating lineages:
- Innovation & Entrepreneurship — Mapping a platform relative to users, complements, and substitutes is a canonical product and venture-strategy practice.
- Organizational & Management Science — Organizational and management science materially shaped Platform Positioning Map through coordination, organizational learning, performance, and change practice. Strategic management supplied value-chain and governance-gate mapping.
Review resolution: Light authoritative-source research resolves the primary-origin disagreement in favor of economics and finance. Platform Persistence: Network, Platform, and Complementor Attributes directly documents the defining practice or theory described in the selected origin rationale. Other listed domains are retained only where the blind reviews identify material co-development or translation; broader adoption remains separate as domain_reach=multi_domain.
Attribution caveat: The boundary with innovation and new-product-development practice is real because that field materially developed or translated the practice, but the cited provenance places the defining form in economics and finance.
Encyclopedia synthesis: The exact catalogued form synthesizes established practice rather than reproducing a single standard historical label.
Review outcome: Researched adjudication after independent review; high confidence.
Sources consulted:
Notes¶
[n1] Platform envelopment — the move, analyzed by Eisenmann, Parker, and Van Alstyne, in which one platform enters an adjacent platform's market by bundling its functionality and leveraging shared user relationships. It is the canonical way a "complement" position is absorbed by the platform it depends on, which is why the map foregrounds substitutes and governance gates. ↩