Categorizing Launch Contributors

Strategic intent: Turn an unbounded design space ("how do we structure each of fifteen relationships?") into a structured decision tree, by placing every dependency in one of five categories.

#Overview

This is the entry technique of the Launching Initiatives in a Distributed Organization pipeline. Every internal launch reduces to the same five categories of contributor. Once each dependency is placed, the contract logic, funding mechanism, and value-sharing approach follow almost automatically.

The technique then prunes the dependency list to the minimum coherent ecosystem and maps the dependency tree to expose the critical path and hidden dependencies.

#When to use it

• At the start of any internal launch that composes existing internal capabilities
• When a launch is blocked by too many bilaterally-negotiated dependencies
• When the dependency list feels unbounded and the launch design intractable

#Composition

1. #1. List every required contribution

   Every internal team whose contribution is needed for the launch, however small.

2. #2. Classify into the five categories

   Category	What it is	Contract logic
   1 — Enabling General Capabilities	Horizontal, on-demand, commoditized (UX, generic engineering, integration platforms)	Purchase, on-demand / milestone
   2 — Enabling Platforms (Tweaks)	Existing platforms needing small, targeted, potentially reusable modifications	Purchase / revenue-share / holding-investment (see Choosing Funding Sources)
   3 — Standard Demand Servicers	Existing services extending to a new internal customer, unchanged	Standard transactional pricing
   4 — One-Off Launch Reviewers	Security, regulatory, legal, compliance — bounded to pre-launch	Fixed-scope on-demand
   5 — Steady-State Overhead	HR, facilities, basic IT	Tax-style allocation

3. #3. Prune to the minimum coherent ecosystem

   Apply the test to each contributor: if this contributor does not participate, can the launch still deliver its shared user scenario and its shared quantitative goal? If yes → defer to a later release. The minimum coherent ecosystem is typically 30–50% smaller than the initial list.

4. #4. Map the dependency tree

   Build the directed graph of which contributor unblocks which. This determines the critical path and surfaces hidden dependencies (e.g. a Category-2 tweak that itself requires a Category-4 reviewer).

#Inputs

• Required: the initiative definition (value proposition, customer, leading goal, launch lead)
• Required: a complete list of internal teams whose contribution is required

#Outputs

• Categorized dependency list — every contributor placed in one of five categories
• Minimum coherent ecosystem — the structurally-required subset
• Dependency tree — critical path and hidden dependencies
• Deferral list — what is explicitly out of scope for launch (handled in a later release)

#Process heuristics

• Mixing categories is the #1 failure mode — a Category-2 contributor treated like Category-3 produces a misaligned contract
• Edge cases are signals — a dependency fitting no category usually carries an unusual mix of strategic value and uncertainty; design it explicitly
• Prune aggressively — the smaller the coherent ecosystem, the more tractable the multi-party contract

#Validation criteria

• Every dependency classified into exactly one category (edge cases flagged)
• Minimum coherent ecosystem identified via the participation test
• Dependency tree drawn with critical path marked
• Hidden dependencies surfaced and added

#Common mistakes

• Treating the launch as a flat dependency list — without categories the contract logic is undecidable
• Skipping the prune — an oversized ecosystem makes multi-party negotiation infeasible
• Missing hidden dependencies — the launch later blocks on a contributor nobody contracted

#Used in pipelines

• Launching Initiatives in a Distributed Organization — as the entry technique

#Connections

• Feeds: Choosing Funding Sources — only Category-2 dependencies proceed there
• Feeds: Designing the Multi-Party Launch Contract — the minimum coherent ecosystem defines the signatories

#Related reading

• Boundaryless field methodology "The Ecosystem Formation Pattern" — the five-category taxonomy and the dependency-tree challenges
• Legacy 3EO Toolkit — service types and contract patterns