Scope and Ecosystem Mapping

Purpose

Create a visual map of the broader system, stakeholders, and contextual factors surrounding a validated need or opportunity, revealing how the focal user/problem connects to adjacent actors, systems, influences, and constraints. Scope and ecosystem mapping prevents tunnel vision—ensuring teams understand the full context before committing to problem boundaries, solution direction, or strategic positioning.

The map answers: Who else is involved? What systems/processes are connected? What external forces shape this need? What are the system boundaries? This understanding informs A1.3 boundary decisions (what to include/exclude) and A1.4 strategic fit (where does this opportunity sit in the larger landscape?).

When to Use

Use ecosystem mapping when:

• Problem/need involves multiple stakeholder types beyond primary user
• User operates within complex organizational, regulatory, or market system
• Need to understand dependencies, constraints, or influences outside direct user control
• Solution may impact adjacent actors or systems (network effects, multi-sided markets)
• Defining A1.3 boundaries—need to see full landscape before deciding what's in/out of scope
• A1.4 strategic fit—assessing competitive landscape, partnership opportunities, ecosystem positioning

Do NOT use when:

• Simple, isolated user need with minimal external dependencies (individual consumer product with no stakeholder complexity)
• Time-constrained A1.1—ecosystem mapping takes 2-4 hours; may be unnecessary if scope is obvious
• Ecosystem already well-understood by team—don't map for the sake of mapping

Prerequisites

• A1.2 research completed: Interviews/observations revealing stakeholder landscape
• Workshop participants: 3-6 people (user researcher, product lead, domain expert, business strategist)
• Visual workspace: Large whiteboard, poster, or digital tool (Miro, Mural)
• Mapping template: Concentric circles or network diagram structure
• Time: 2-3 hours for collaborative mapping workshop

Complete Procedure

Step 1: Identify Focal User/Problem (10 minutes)

Place primary user or validated need at center of map.

Example—Sales Forecast Confidence:

• Focal user: Mid-market sales manager (10-15 reps, 50K-500K deals)
• Validated need: Confidence in deal health assessment for accurate forecasting

Step 2: Map Stakeholders in Concentric Rings (30-45 minutes)

Concentric ring framework:

verbatim ┌─────────────────────────────────────────────────────────┐ │ EXTERNAL FORCES (Ring 4) │ │ Market trends, regulation, economy, technology │ │ ┌───────────────────────────────────────────────────┐ │ │ │ EXTENDED ECOSYSTEM (Ring 3) │ │ │ │ Indirect stakeholders, partners, competitors │ │ │ │ ┌─────────────────────────────────────────────┐ │ │ │ │ │ IMMEDIATE STAKEHOLDERS (Ring 2) │ │ │ │ │ │ Direct interactors (frequent contact) │ │ │ │ │ │ ┌───────────────────────────────────────┐ │ │ │ │ │ │ │ FOCAL USER / NEED (Ring 1—Center) │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ └───────────────────────────────────────┘ │ │ │ │ │ └─────────────────────────────────────────────┘ │ │ │ └───────────────────────────────────────────────────┘ │ └─────────────────────────────────────────────────────────┘ verbatim

Ring 2—Immediate Stakeholders (direct, frequent interaction):

• Sales reps (reports to manager)
• VP of Sales (manager reports to)
• CRM system (primary tool)
• Customers/prospects (in active deals)

Ring 3—Extended Ecosystem (indirect, occasional interaction):

• Marketing team (generates leads)
• Sales operations (CRM admin, reporting)
• Finance (revenue forecasting, quota planning)
• Product team (deal feedback loop)
• Competitors (indirect—influence deal outcomes)

Ring 4—External Forces (contextual factors, no direct interaction):

• Economic conditions (recession impacts deal closures)
• Industry trends (shift to product-led growth affects sales motion)
• Technology evolution (AI forecasting tools emerging)
• Regulatory constraints (data privacy limits CRM tracking in some regions)

Step 3: Map Relationships and Flows (30 minutes)

Add directional arrows showing:

• Information flows: Who provides data to whom?
• Influence/power: Who has authority or decision-making power over whom?
• Dependencies: Who relies on whom for success?
• Value exchange: What flows between actors (money, data, services)?

Example relationships—Sales Manager ecosystem:

Key insight from mapping: Manager is information broker—receives raw data from CRM/reps, synthesizes into forecast for VP. If CRM data incomplete (missing health signals), manager must manually gather/assess, creating bottleneck and anxiety.

Step 4: Identify Constraints, Gaps, and Opportunities (30 minutes)

Review completed map and mark:

1. Constraints (red flags): Factors limiting solution options itemize
2. Example: CRM system locked down by IT—can't customize fields without 6-month approval process
3. Example: VP expects weekly forecast—can't change cadence itemize
4. Gaps (broken/weak connections): Missing information flows or relationships itemize
5. Example: No direct customer signal into manager's assessment—relies on rep's interpretation (potential distortion)
6. Example: Reps don't update CRM real-time—manager gets stale data itemize
7. Opportunities (green flags): Potential leverage points or partnerships itemize
8. Example: Sales Ops team has access to historical deal data—could build predictive models
9. Example: Product team wants deal feedback—mutual benefit opportunity (manager gets insights, product gets customer intel) itemize

Step 5: Define Ecosystem Boundaries for A1.3 (20 minutes)

Use ecosystem map to inform A1.3 boundary decisions:

In-scope stakeholders:

• Primary: Sales Manager (Ring 1)
• Secondary: Sales Reps, VP Sales (Ring 2—immediate stakeholders whose needs/behaviors must be considered)

Out-of-scope (acknowledge as constraints or future):

• Sales Ops, Marketing, Finance (Ring 3—address their needs indirectly or defer)
• External forces (Ring 4—acknowledge but don't attempt to change)

Rationale: Focusing on manager + immediate stakeholders (reps, VP) creates manageable scope while addressing core information flow. Ring 3/4 actors acknowledged as context but not primary users.

Quality Criteria

Excellent ecosystem map demonstrates:

1. Comprehensive stakeholder coverage: All relevant actors identified (primary, secondary, indirect)
2. Relationship clarity: Arrows/connections show information flows, dependencies, power dynamics
3. Constraint visibility: External forces, regulations, locked systems clearly marked
4. Gap identification: Missing or weak connections highlighted (design opportunities)
5. Boundary implications: Clear rationale for in-scope vs. out-of-scope stakeholders
6. Evidence-based: Stakeholders and relationships validated by A1.2 data (not speculation)

Mapping Frameworks

Framework 1: Concentric Rings (above)—Best for:

• Showing proximity to focal user (who's closest/most important?)
• Hierarchical or influence-based relationships
• Filtering stakeholders by relevance (inner rings = higher priority)

Framework 2: Network Diagram—Best for:

• Complex, non-hierarchical ecosystems (many-to-many relationships)
• Emphasizing information flows, dependencies, value exchange
• Multi-sided markets or platform ecosystems

Framework 3: Swim Lane Ecosystem—Best for:

• Process-oriented problems (who does what in a workflow?)
• Showing handoffs, delays, bottlenecks across stakeholders
• Organizational/operational contexts

Relationship to Other Methods

Ecosystem Mapping provides input to:

• A1.3 Boundary Definition: Map reveals which stakeholders in/out of scope
• A1.3 POV Questions: Identifies stakeholders for multi-perspective framing
• A1.4 Strategic Fit: Shows competitive landscape, partnership opportunities
• B1 Business Model: Ecosystem actors become customers, partners, channels

*A1.4 Application: Ecosystem Dependency Analysis sec:method-ecosystem-A1.4

Purpose shift from A1.1/A1.3. In A1.1, ecosystem mapping answers “What surrounds this opportunity?” (exploration). In A1.3, it answers “What's in/out of scope?” (boundary-setting). In A1.4 Step~4, the purpose shifts to strategic dependency assessment: “What must we coordinate with to address this need, and can we?” The A1.4 application transforms a descriptive map into a decision-relevant artifact by adding three analytical layers: dependency classification, partnership feasibility assessment, and solution architecture determination.

When to use (A1.4-specific triggers). Apply the full A1.4 extension when any of the following hold:

• Step~2 constraint mapping revealed external dependencies (APIs, regulatory bodies, data providers)
• The validated need spans organisational boundaries (user interacts with multiple systems or organisations)
• Solution likely requires data, distribution, or regulatory access the organisation does not control
• Initial ecosystem map from A1.1 showed ≥3 actors in Rings~2–3

If the need is simple (single user, standalone tool, no external data dependencies), document the “Simple ecosystem—standalone solution viable” determination and skip the full extension.

Inputs (beyond base method).

• Completed A1.1/A1.3 ecosystem map (base layer)
• A1.4 Step~2 Technical Constraint Map (identifies external dependencies flagged as constraints)
• A1.4 Step~3 User Context Model (identifies actors present in critical design contexts)
• Domain expert access for partnership feasibility validation (2–4 interviews)
• Secondary research: partner/platform business models, API documentation, partnership case studies

Procedure — Layer 1: Dependency Classification.

Starting from the base ecosystem map, classify every Ring~2–4 actor into one of three dependency categories:

1. Identify all ecosystem actors affecting need resolution. Review the base map. For each actor, ask: “If we built a solution to this need, would this actor need to be involved?” Retain actors where the answer is yes or possibly; remove purely contextual actors (e.g., “economy” from Ring~4 unless a specific economic mechanism creates a dependency).
2. Classify each retained actor. description[nosep]
3. [Critical dependency ( red):] Solution cannot function without this actor's participation. Blocking: if partnership fails, solution fails. Test: “Can we deliver the core value proposition without this actor?” If no Critical. Examples: CRM API provider (Salesforce) for sales data access; EHR vendor (Epic) for clinical data integration; regulatory body (FDA) for device clearance.
4. [Value-enhancing dependency ( yellow):] Solution functions without this actor but is significantly better with their participation. Non-blocking but strategically important. Test: “Does this actor's participation improve the value proposition by ≥30%?” If yes Value-enhancing. Examples: Gong conversation data enriching sales signals; medical AI model provider improving transcription accuracy; payroll data provider adding income context.
5. [Optional dependency ( green):] Solution functions well without this actor. Participation provides marginal improvement or future expansion opportunity. Test: “Could we launch V1 without this actor and still satisfy P0 success criteria?” If yes Optional. Examples: secondary CRM integration (HubSpot when Salesforce is primary); analytics dashboard provider; professional association endorsement. description
6. Validate classifications with domain experts. Present classified map to 2–3 domain experts or potential partners. Confirm: “Is [actor] truly critical, or could we work around them?” Reclassify based on expert input.

Procedure — Layer 2: Partnership Feasibility Assessment.

For each Critical and Value-enhancing dependency, assess partnership feasibility:

1. Score each dependency across four dimensions (1–3 scale): itemize
2. Access difficulty: 1 = open API / public access; 2 = partnership required but standard process (marketplace listing, revenue share); 3 = proprietary / requires deep negotiation / exclusive relationship.
3. Timeline to partnership: 1 = <3 months; 2 = 3–12 months; 3 = >12 months.
4. Cost/commitment: 1 = low (<50K / standard terms); 2 = moderate (50–500K / revenue share); 3 = high (>$500K / equity / exclusivity).
5. Relationship status: 1 = existing partnership / warm relationship; 2 = no relationship but standard partner program exists; 3 = cold / no partner program / competitor relationship. itemize
6. Calculate partnership risk score. Sum of four dimensions (range 4–12). itemize
7. 4–6: Low risk — partnership achievable within standard timelines.
8. 7–9: Moderate risk — partnership requires dedicated effort and may introduce timeline risk.
9. 10–12: High risk — partnership is a major programme risk; consider alternatives or flag as potential Defer trigger. itemize
10. Identify risk mitigation for high-risk partnerships. For scores ≥10: Can the dependency be reduced (e.g., build rather than partner)? Is there an alternative actor providing similar access? Should partnership risk trigger a Defer recommendation in Step~7?

Procedure — Layer 3: Solution Architecture Determination.

Based on Layers~1 and~2, determine the solution architecture category:

Output (A1.4-enhanced). The A1.4 Ecosystem Dependency Diagram extends the base ecosystem map with three additional layers:

1. Colour-coded dependency classification (Critical / Value-enhancing / Optional) per actor
2. Partnership feasibility scores and risk ratings per Critical and Value-enhancing actor
3. Solution architecture determination with implications narrative

Accompanying narrative (1–2 pages): ecosystem summary, critical dependency analysis, partnership risk assessment, architecture determination, and implications for Step~7 feasibility and recommendation.

Quality criteria (A1.4-specific).

• Every Critical dependency validated by ≥1 domain expert (not assumed)
• Partnership feasibility scored with evidence (not guessed—cite API documentation, partner programme terms, prior relationship history)
• Architecture determination follows logically from dependency count and risk scores
• High-risk partnerships flagged for Step~7 feasibility assessment (not buried in map)
• Platform opportunities explicitly called out for I2 attention (require B1 strategic commitment)

Common errors (A1.4-specific).

• Ecosystem optimism — assuming partnerships will materialise without assessing feasibility; treating Cold/No-programme actors as if access is assured
• Dependency under-counting — classifying Critical dependencies as Value-enhancing to make the architecture look simpler
• Platform ambition without platform strategy — identifying platform opportunity without recognising the order-of-magnitude increase in complexity, cost, and strategic commitment
• Ignoring regulatory actors — omitting FDA, HIPAA, GDPR, IRS as ecosystem dependencies when they gate solution viability
• Static map — treating ecosystem as fixed when actors, APIs, and partnership programmes evolve; note “as of [date]” on all feasibility assessments

Relationship to A1.4 Steps 2, 5, and 7.

• Step~2 Step~4: Constraints flagged as “external dependency” in constraint mapping become actors in the ecosystem diagram. CRM API dependency (Hard constraint) becomes Salesforce (Critical dependency, partnership risk score X).
• Step~4 Step~5: Ecosystem actors who provide existing solutions (e.g., QuickBooks for tax estimation) appear in both the ecosystem diagram (as actors) and the solution landscape matrix (as existing approaches). Cross- reference to avoid contradictory assessments.
• Step~4 Step~7: High-risk Critical dependencies feed directly into feasibility assessment. Partnership risk score ≥10 may trigger “feasible later” (Defer) if partnership cannot be secured within required timeline.

Worked micro-example. Sales Forecasting Confidence (Example~1 from the referenced method):

Architecture determination: Integration- dependent (1~Critical dependency, Low risk). Salesforce AppExchange listing is standard process (2–4 weeks, 20% revenue share). Existing partner relationship accelerates. No Defer trigger from ecosystem analysis.