The Ecosystem Tube Map — Dugald Morrow  🔗 **Source:** [The Ecosystem Tube Map — Dugald Morrow](https://www.youtube.com/watch?v=5DrPU4ojIrM) > [!note]+ Document Notes > tags: [developer-relations, ecosystem-modeling, devrel-metrics, causal-chains, ai-agents, mcp] > author: Dugald Morrow > source: Dev Rel (YouTube) > reference: https://www.youtube.com/watch?v=5DrPU4ojIrM > date created: 2026-10-15 17:43 > > > [!info] Generated analysis — not the author's words. Sections below are machine-written > > from the captured source. Only text inside `> [!quote]` blocks is verbatim from the author. > > Do not quote or attribute any other line to the named author. > > # 🏷️ Title: The Ecosystem Tube Map — Dugald Morrow > <!-- deep-read:sections start --> ## 🧭 Table of contents - [📝 Summary](#-summary) - [📖 Main content](#-main-content) - [🗒️ Notes](#️-notes) - [📚 References](#-references) - [🗣️ Paraphrase](#️-paraphrase) - [📰 Newsletter](#-newsletter) - [✅ Action items](#-action-items) - [🧪 Hypotheses](#-hypotheses) - [📊 Methodology](#-methodology) - [❓ Questions](#-questions) - [🔮 Future research](#-future-research) - [💡 Implications](#-implications) - [🧠 Learning styles assessment](#-learning-styles-assessment) - [📊 Accessibility assessment](#-accessibility-assessment) - [🌍 DEIB assessment](#-deib-assessment) - [✅ Logical validity](#-logical-validity) - [🛡️ DARVO analysis](#️-darvo-analysis) - [🎯 Conclusion](#-conclusion) - [🔄 Refactor appendix](#-refactor-appendix--the-ecosystem-tube-map--dugald-morrow) ## 📝 Summary - **What happened.** The Dev Rel channel published a 23:44 recording (uploaded 2026-10-14) of Dugald Morrow, a DevRel practitioner at Atlassian, presenting "The Ecosystem Tube Map" at DevRelCon 2026 in NYC. The talk runs about 17 minutes of presentation and demos, then about 7 minutes of audience Q&A. The auto-transcript spells the company "Alassian" and the community "Devreil" or "Devril"; this analysis uses Atlassian and DevRel, and quotes keep the transcript spelling. - **The claim.** A developer ecosystem is better modeled as a transit map than as a single funnel. Each workstream (evangelism, channels and events, builder journey, partner journey, customer journey, app maturation, platform development, platform) is a "tube line." Stops are milestones and interchanges are where lines connect. The model's purpose is to let DevRel trace a causal chain from top-of-funnel activity to customer success and stop reporting vanity metrics. - **The mechanism.** The map is an SVG diagram plus markdown files that describe its conventions and abstractions. Because it's plain text, an AI agent can read it, call an MCP server for metrics, and generate a monthly business review (MBR). Morrow built an internal app around this and promises a public "visualizer branch" with Atlassian data stripped out. - **Why it matters.** DevRel teams routinely can't connect an event or campaign to a business outcome. This model gives a shared structure for placing metrics and a diagnostic procedure: trace the chain, find the weak link. - **Key stakeholders.** DevRel and developer advocates, platform R&D (owns the platform development line), partners, customers, leadership who read business reviews, and the DevRel Agency whose "Mind the Gap" developer-journey tube map inspired the visual metaphor. - **Risks and tradeoffs.** No metric values, funnel conversion rates, or outcome data appear in the talk. The "causal chain" is a modeled structure, and an audience member at 00:22:42 challenges whether it is causal or correlative. The AI demos are grounded in the model's own documentation, which the speaker says "is going to bias it" (paraphrased from 00:15:20). The working app contains Atlassian data and isn't available yet. - **Bottom line.** The separation of builder, partner and customer funnels, and the instruction to measure each independently, is a usable idea with no data attached. Treat the map as a hypothesis-generating framework until someone publishes outcomes from using it. ## 📖 Main content **The problem.** DevRel runs successful events and campaigns, then arrives at a business review with vanity metrics and hopes leadership accepts them. Morrow's diagnosis is that the work has value but teams lack a model of the ecosystem that shows how the value flows downstream. **Building the map (00:01:35 to 00:05:55).** The canvas is split into zones. Left to right runs discovery to maturity. Top to bottom runs different kinds of ecosystem concepts. Lines are added one at a time: - **Evangelism:** promotion activities such as talks, blog posts, social content and community engagement. Most stations sit in the discovery zone, with one on the right for processing feedback into platform development. - **Channels and events:** the delivery mechanisms (a conference talk, a YouTube tutorial, a Discord community). Separating this from evangelism lets you ask whether the message or the distribution is the problem. - **Builder journey:** technical activities from discovering the platform to shipping an app, with two start points (new developers and developers activating on features). - **Partner journey:** the commercial track, such as signing agreements, marketplace listing and go-to-market decisions. Builders and partners are often the same people or organizations, but the activities differ, and conflating them "leads to confused outreach." - **Customer journey:** end users and adopting organizations, from learning that extensibility exists to daily use. - **App maturation:** how an app moves from newly created through health improvement to a stable, mature inventory. - **App platform development:** the R&D line (APIs, CLIs, SDKs, infrastructure). DevRel doesn't own it, but platform gaps are often the real cause of developer churn. - **App platform:** the runtime offering customers actually interact with. - **Interchanges:** stations where lines connect, representing moments where activities interact. **Abstractions (00:05:55 to 00:08:47).** Lines that start linear and end in loops show investment turning into growth and scale. That pattern yields three independent funnels (developers, partners, customers). A person can sit in more than one: a developer is in the builder funnel personally while the employer is in the partner or customer funnel. The builder and partner funnels together produce the **app pipeline**, which flows toward **customer success**. The **platform experience** layer abstracts the platform line into the stakeholder's experience (docs quality, API reliability, CLI usability, support readiness). The **metrics** layer marks measurement points across the system. A short animation shows red dots moving through the customer funnel, developer funnel and app pipeline in parallel until the customer starts using the app. **Diagnosis (00:08:47 to 00:11:42).** Morrow wanted to understand causal chains because DevRel "has often struggled" to turn top-of-funnel metrics into business outcomes (paraphrase). With a metric at each stage you can trace backward from an outcome to find the weak link. Top-of-funnel metrics are leading indicators that become more valuable once the chain can predict downstream impact. Gray links on the diagram represent churn, caused by the gap between what stakeholders expect and what the platform provides. A rubric (a structured scorecard) scores each platform-experience dimension, from documentation quality to API reliability and support quality. The ultimate health measure is business outcomes such as app usage. **AI integration (00:11:42 to 00:16:04).** The SVGs and markdown files are plain text. An agent loads a skill (here, an MBR skill), reads relevant parts of the model documentation, sends that context to an LLM, gets back instructions to query metrics, delegates the queries to an MCP server, then makes a second LLM call with the metric data to produce the report. More MCP servers, skills and context extend the pattern, and Atlassian users can connect it to the Teamwork Graph, which spans Jira, Confluence and other products. Three demos follow: map visualization with toggleable layers and click-through documentation, an AI analysis of whether the three funnels could be merged (the agent says no and gives reasons), and a skill generating an MBR with blurred output. **Implications for DevRel (00:16:04 to 00:17:35).** Developer advocates work with developers, partners and customers, so they see across all three funnels. The model gives them language to claim a place in the causal chain "as measurable drivers of ecosystem outcomes." **Q&A (00:17:35 to 00:23:44).** Three questions. (1) Can AI find efficiencies across the funnels? Morrow answers that the map holds more detail than shown, that a company can embed its own beliefs about the industry, and that combining beliefs with real data has produced reports and OKRs. (2) How do you tie the stops to business outcomes? Customer-success metrics are usage proxies for retention, such as monthly active apps and API usage, plus funnel metrics that track how an app moves from a potentially high-impact app to a high-impact app. Each organization must define its own metrics. (3) Is it causal or correlative? Morrow says the terminology may differ but the aim is to identify the metrics, interpret their signals and trace to the next set downstream. **Contested and unverified in this source.** - No funnel numbers, conversion rates, churn percentages or outcome data are given anywhere in the talk. - The "high impact app" definitions are described as having "a lot of theory" behind them and aren't explained. - The correlation-versus-causation question at 00:22:42 isn't answered on the merits. The reply at 00:23:25 shifts to metric selection and interpretation. - The public app and "more complete version" are offered "if there's interest," with a QR code on screen and no URL in the transcript. ## 🗒️ Notes #### ⏱️ [00:00:08](https://www.youtube.com/watch?v=5DrPU4ojIrM&t=8) Problem statement and agenda - Frames the tension: successful event or campaign, then vanity metrics at the business review. - Agenda: build the map, add abstractions, use it as a diagnostic tool, machine-readable design for AI, demos. - Garbles: "Devreil" is DevRel; "east ecosystems" at 00:01:35 reads as "these ecosystems." #### ⏱️ [00:01:35](https://www.youtube.com/watch?v=5DrPU4ojIrM&t=95) Credit and the map's zones - Credits a DevRel Agency piece titled "Mind the Gap Dev Journey Tube Map," which maps one developer's journey on the London Underground metaphor. - States this talk doesn't replace that work. It applies a similar metaphor to the whole ecosystem. - Zones run discovery to maturity left to right; concept types run top to bottom. > [!quote] [00:01:35] > This presentation isn't an attempt to replace or improve that work. #### ⏱️ [00:03:00](https://www.youtube.com/watch?v=5DrPU4ojIrM&t=180) Builder, partner and customer lines - Builder journey: tutorials, SDK improvements, office hours move developers along the line. - Partner journey is the business track (agreements, marketplace listing, go-to-market). - Customer journey ends at active daily use and is the "downstream beneficiary" of the rest. #### ⏱️ [00:04:28](https://www.youtube.com/watch?v=5DrPU4ojIrM&t=268) App maturation and platform development - App maturation runs from newly created to stable mature inventory. An app that ships isn't done. - Platform development is R&D's line. DevRel doesn't own it, but platform gaps often explain churn. - The transcript contains a stutter loop ("st st st ...") at 00:04:28. The intended word is "stable." #### ⏱️ [00:05:11](https://www.youtube.com/watch?v=5DrPU4ojIrM&t=311) Interchanges and the full map - Interchanges mark where activities and concepts interact, like changing trains. - The full map lists the activities in an ecosystem and where they connect, and identifies those with the most impact on early developer-journey stages. - Scope ranges from amplifying platform feature releases to campaigns, events and community multi-channel content. Morrow calls that breadth a defining characteristic of DevRel. #### ⏱️ [00:06:39](https://www.youtube.com/watch?v=5DrPU4ojIrM&t=399) Three funnels and the app pipeline - Lines with a linear start and a loop end model investment leading to growth and scale. - Three funnels (developer, partner, customer) are independent but influence each other. One person or organization can sit in several. > [!quote] [00:06:39] > the map highlights three funnels, one each for developers, partners, and customers. - Builder plus partner funnels produce the app pipeline, flowing toward customer success. #### ⏱️ [00:08:03](https://www.youtube.com/watch?v=5DrPU4ojIrM&t=483) Platform experience and metrics layers - Platform experience abstracts the platform line into each stakeholder's experience: docs quality, API reliability, CLI usability, support readiness. - Metrics layer overlays measurement points to align teams on what to monitor. - Animation: red dots start in the customer funnel, then the developer funnel and app pipeline, in parallel. Customer-funnel work includes evaluating risk and estimating costs. #### ⏱️ [00:09:31](https://www.youtube.com/watch?v=5DrPU4ojIrM&t=571) The model as a diagnostic tool - Goal: understand causal chains so top-of-funnel activity translates to business outcomes. - Backward tracing finds activities affecting downstream outcomes. The three funnels are collapsed in the diagram but are each nested chains. > [!quote] [00:09:31] > as long as you have metrics measuring at each stage, you can trace along the chain to see where the weak links are. - Top-of-funnel metrics are leading indicators and gain value when the chain predicts downstream impact. #### ⏱️ [00:10:14](https://www.youtube.com/watch?v=5DrPU4ojIrM&t=614) Churn and the platform-experience rubric - Gray links on the diagram represent churn. > [!quote] [00:10:14] > The gray links represent churn which is caused by the difference between what stakeholders expect and what the platform actually provides. - A rubric scores each dimension of developer and partner experience, from documentation quality to API reliability and support quality. - Health is ultimately measured by business outcomes such as app usage. Funnels and the app pipeline are leading indicators, and funnel health depends on platform experience. #### ⏱️ [00:11:42](https://www.youtube.com/watch?v=5DrPU4ojIrM&t=702) Machine-readable design and the agent flow - Implementation: SVG graphics plus markdown files describing SVG conventions and every abstraction. > [!quote] [00:11:42] > Because this is all plain text, it's easy for AI to consume it. - Atlassian example: an agent loads the MBR skill, reads the model docs, sends context to the LLM, delegates metric queries to an MCP server ("MPC" in the transcript), then makes a second LLM call with the data to generate the report. #### ⏱️ [00:13:10](https://www.youtube.com/watch?v=5DrPU4ojIrM&t=790) Extending with MCP servers and the Teamwork Graph - More MCP servers, skills and context extend the pattern. - For Atlassian tool users, the model can connect to the Teamwork Graph, the knowledge layer across Jira, Confluence and other products, so reports reflect actual work data. #### ⏱️ [00:13:53](https://www.youtube.com/watch?v=5DrPU4ojIrM&t=833) Evolution from diagram to app - Path: SVG concept diagram, then markdown documentation, then grounding an AI agent on Atlassian's ecosystem with MCP servers and skills, then an app that packages the model with AI for colleagues. - A public "visualizer branch" will have Atlassian-specific data stripped. Demos use the internal app. - Map demo: toggle layers on and off, click elements to open documentation. A separate documentation view gives direct access, which Morrow says helps keep everyone aligned. #### ⏱️ [00:15:20](https://www.youtube.com/watch?v=5DrPU4ojIrM&t=920) AI analysis demo and the bias caveat - The agent is asked whether the three funnels can be combined. It says no and gives several reasons. - Morrow flags that the agent is grounded in the model documentation, "which is going to bias it" (paraphrase of the speaker's caveat). - Skill demo: an MBR skill specifies the report format and the MCP servers fetch data. Output is blurred because it contains Atlassian data. #### ⏱️ [00:16:49](https://www.youtube.com/watch?v=5DrPU4ojIrM&t=1009) Takeaway for DevRel and the offer - Developer advocates see across all three funnels. The model supplies structure and language to claim a place in the causal chain. - Offers a more complete app version "if there's interest" after stripping Atlassian data. A QR code is shown; no URL is in the transcript. #### ⏱️ [00:17:35](https://www.youtube.com/watch?v=5DrPU4ojIrM&t=1055) Q&A 1: can AI optimize across funnels? - The asker notes the AI said the funnels can't be combined and asks whether AI can find efficiencies. - Morrow says the demos are simple scenarios, that company beliefs can be embedded in the model, and that he has had AI produce reports and OKRs from documented beliefs plus real ecosystem data. #### ⏱️ [00:19:49](https://www.youtube.com/watch?v=5DrPU4ojIrM&t=1189) Q&A 2: tying stops to business outcomes - Every organization needs its own metric set. Morrow tried to keep the model generic. - Customer-success metrics are usage proxies for retention and growth (monthly active apps, API usage). The audience member's "customer protection" is a mishearing of retention. - Funnel metrics track an app from an early stage to a "potentially high impact app" and then a "high impact app." Definitions exist but weren't explained. > [!quote] [00:21:59] > the framework itself is giving you sort of like the map to place those metrics on if you like. - Key point: separate stakeholder concerns and track each funnel independently, because each drives different decisions. #### ⏱️ [00:22:42](https://www.youtube.com/watch?v=5DrPU4ojIrM&t=1362) Q&A 3: causal or correlative? - The asker questions whether signals map to business outcomes by causation or correlation and calls causal links "very specious." - Morrow concedes the terminology may differ and says the aim is identifying metrics, interpreting what they signal and tracing to downstream metrics. - The talk ends at 00:23:44 with applause. "Dald" in the transcript is Dugald. ## 📚 References The transcript itself contains no links; the following come from the video description or are primary sources for named entities. - [The Ecosystem Tube Map — Dugald Morrow](https://www.youtube.com/watch?v=5DrPU4ojIrM): source video on the Dev Rel channel, 23:44, uploaded 2026-10-14. - [DevRelCon 2026 NYC](https://nyc.devrelcon.dev/): the conference where the talk was presented, linked in the video description. - Harry Beck's 1933 London Underground map: the topological-map inspiration named in the video description. No link is given in the transcript or description. - "Mind the Gap Dev Journey Tube Map," DevRel Agency: the single-developer tube map Morrow credits at 00:01:35. No URL is given; the transcript renders the publisher as "Devreil. Agency." Find the original before citing. - [Model Context Protocol](https://modelcontextprotocol.io): the protocol behind the "MCP server" that fetches metrics (the transcript writes "MPC"). - [Atlassian Teamwork Graph](https://www.atlassian.com/platform/teamwork-graph): the knowledge layer Morrow says spans Jira, Confluence and other products. Verify the current product page before citing. - The "visualizer branch" public app: promised at 00:13:53 and 00:16:49, shown only as a QR code. No URL is in the transcript or description. ## 🗣️ Paraphrase Morrow starts from a problem every DevRel team knows. You run an event, you report attendance and views, and leadership asks what it was worth. His answer is a model, not a metric. Draw the ecosystem as a transit map where each workstream is a line, each milestone is a stop, and each place where two workstreams meet is an interchange. Once the lines exist, you can see that the developer, the partner and the customer move through three separate funnels, that their combined output is a pipeline of apps, and that all of it points at customer success. The diagnostic value comes from putting a metric at each stop. If customer success drops, you walk the chain backward until you find the stop where the numbers went wrong. Platform quality sits underneath everything: when what the platform delivers falls short of what a stakeholder expects, that gap shows up as churn, so Morrow scores the platform experience with a rubric. Because the whole model is SVG plus markdown, an AI agent can read it. Morrow shows an agent that loads a report skill, reads the model docs, asks an LLM what to query, pulls numbers through an MCP server, and writes a monthly business review. He then packaged that into an internal app. The Q&A pushes on the weak spots. One person asks whether linking signals to outcomes is truly causal, and the answer is closer to "pick the right metrics and interpret them" than a defense of causation. ## 📰 Newsletter **Draw the ecosystem as a tube map, then count who gets off at each stop.** A DevRelCon NYC 2026 talk by Dugald Morrow of Atlassian offers a framework that WordPress community teams can borrow. The idea: model each workstream as a line (evangelism, channels and events, builder journey, partner journey, customer journey, app maturation, platform development) and mark where lines meet. Where this lands for us: a WordPress contributor moves through a builder-style funnel, a hosting company or agency sits in a partner-style funnel, and a site owner sits in a customer-style funnel. The same person can be in two at once, which is exactly Morrow's point about a developer whose employer is the customer. Mapping Make teams, WordCamps and the plugin directory this way would show where people leave and which team owns the interchange. The caution: the talk shares no data, and an audience member at 00:22:42 asked whether the "causal chain" is really correlation. Treat the map as a hypothesis generator. Links: [the video](https://www.youtube.com/watch?v=5DrPU4ojIrM), [DevRelCon NYC](https://nyc.devrelcon.dev/), [Model Context Protocol](https://modelcontextprotocol.io). ## ✅ Action items #### DevRel - Developer advocacy: draw one tube map for the team's own ecosystem with the eight lines from the talk, and use it in the next business review as the frame for reporting instead of a metric list. - Education: run a workshop where each participant places their last three activities on the map and names the stop each one affects. - Developer experience: score platform experience with a rubric across docs quality, API reliability, CLI usability and support readiness, and publish the scorecard quarterly. - Developer marketing: separate "is our message wrong" from "is our channel wrong" by tracking evangelism and channels-and-events as distinct lines. - Community management: track builder, partner and customer funnels independently, since the speaker says each drives different decisions. - Internal/external/cross-project: agree on one definition for the stage names (for example "potentially high impact app") before sharing any dashboard across teams. #### OSPO - Policy and governance: no direct action from this source; nearest relevance: the map's decision-rights question is who owns the platform development line versus the evangelism line. - License compliance: if the public visualizer app is released, check its license before reuse. - Security management: an agent that reads internal metrics through an MCP server needs scoped, read-only credentials. Document them before building the MBR flow. - Software inventory: treat the SVG plus markdown model as a versioned artifact with an owner and a review cadence. - Developer support: no direct action from this source; nearest relevance: the platform-experience rubric includes support readiness as a scored dimension. - Community engagement: no direct action from this source; nearest relevance: partner-funnel stops (agreements, listings) map to MoUs and operator agreements. - Strategic alignment: map each KPI and OKR to a named stop on the map so executive reports show where an outcome comes from. #### Community - Maintainers: map the contributor path from first look to maintainer and put one metric on each stop. - Contributors: identify the interchange where contributors become maintainers and document how that handoff works. - Sponsors: tie each sponsor-funded program to a stop and report the downstream metric it moves. - Ecosystem: no direct action from this source; nearest relevance: cross-funnel dependencies are the interchanges, and drills could test them. #### WordPress - Core: no direct action from this source; nearest relevance: platform development is a distinct line whose gaps surface as developer churn. - Core Performance: no direct action from this source; nearest relevance: performance is one dimension of the platform-experience rubric. - Core AI: no direct action from this source; nearest relevance: the agent-plus-MCP flow is a concrete example of grounding an AI agent in a plain-text model. - **Core Program Team:** no direct action from this source; nearest relevance: interchanges are the cross-team dependencies a program team already tracks. - Mobile: no direct action from this source; nearest relevance: none beyond the generic funnel model. - Playground: no direct action from this source; nearest relevance: an early-stop activation point in the builder journey. - Community: map WordCamp and meetup activities onto the channels-and-events line and compare them with the evangelism line. - Training: place learning paths on the builder journey line and measure completion at each stop. - Marketing: separate message from distribution in campaign reviews using the evangelism and channels lines. - Support: no direct action from this source; nearest relevance: support readiness is a scored platform-experience dimension. - Design: no direct action from this source; nearest relevance: none beyond the map's visual conventions. - Documentation: docs quality is a named platform-experience dimension. Add a rubric score to docs audits. - Photos: no direct action from this source. - TV: no direct action from this source. - Polyglots: no direct action from this source. - Accessibility: no direct action from this source; nearest relevance: accessibility of the map itself needs a text alternative (see Accessibility assessment). - Meta: no direct action from this source; nearest relevance: a shared ecosystem map would live in tooling that Meta maintains. - CLI: no direct action from this source; nearest relevance: CLI usability is a named platform-experience dimension. - Hosting: hosts sit in a partner-style funnel. Map the hosting-partner journey separately from the contributor journey. - Tide: no direct action from this source. - Openverse: no direct action from this source. - Themes: map the theme author's path from first upload to a stable, reviewed theme using the app-maturation line. - Plugins: map plugin maturation (new, health improvements, stable) and put review-queue metrics at each stop. #### The WPOCC - Programs: use the three-funnel separation when The WP Open Community Collective reports on programs, so contributor, partner and beneficiary outcomes aren't blended. - Projects: no direct action from this source. - Funding experiments: require a named metric at a named stop for any microgrant, and report it next to the grant. ### FAIR - Technical independence: no direct action from this source; nearest relevance: the platform line shows where upstream dependencies cause downstream churn. - Policies and covenants: no direct action from this source; nearest relevance: partner-funnel stops (agreements, marketplace listing) correspond to covenant events. - Productized governance artifacts: a scored platform-experience rubric is a template for an operator scorecard. ## 🧪 Hypotheses 1. Organizations that report metrics at each of the three funnels separately will identify a churn point faster than organizations that report one blended funnel, measured as days from a metric drop to a named cause. 2. In a real ecosystem, at least 20% of developers are in more than one funnel at once (builder personally, partner or customer through an employer), so a single linear funnel undercounts them. 3. Platform-experience rubric scores predict next-quarter churn better than top-of-funnel activity counts alone, measured by correlation with retention. 4. An AI agent grounded in the model documentation proposes more of the model's own concepts and fewer outside ones than an ungrounded agent given the same metric data, confirming the bias the speaker mentions at 00:15:20. 5. Leading indicators at the top of the chain forecast customer-success metrics with an error below that of a naive trend baseline, but only after the stage definitions are fixed. 6. Teams that use the map to align cross-functional work (engineering, marketing) reduce the time from a platform gap to a prioritized fix versus teams without it. ## 📊 Methodology - **Design for H1.** Pick 4 to 6 DevRel teams. Give half the tube-map reporting structure and keep half on blended funnels. Inject or wait for a known metric drop and record days to a named cause, with the cause confirmed by the platform team. - **Design for H2.** Join CRM, identity and platform telemetry to count how many individual developers also belong to a partner or customer account. Report the share with confidence intervals and the definition of "same person." - **Design for H3.** Score documentation quality, API reliability, CLI usability and support readiness each quarter with a fixed rubric. Correlate the composite with retention the next quarter, controlling for company size. - **Design for H4.** Run the same MBR skill and metrics twice, once with the model docs loaded and once without. Count references to the model's named concepts and have two raters judge whether the recommendations are supported by the data. - **Design for H5.** Use three or more quarters of historical top-of-funnel data to forecast customer-success usage with and without the stage structure, compared against a naive trend. Report mean absolute error. - **Design for H6.** Track platform-gap tickets from first report to prioritization before and after adoption. Use a difference-in-differences comparison with a team that didn't adopt. - **Controls throughout.** Fix definitions of each stop before data collection, pre-register thresholds, and don't let the team being measured score its own rubric. ## ❓ Questions - What outcomes, in numbers, has the model produced at Atlassian: a churn point found, a budget decision changed, a metric dropped? - How are "potentially high impact app" and "high impact app" defined, and what thresholds separate them? - Is the chain causal, correlative or a mix, and what test would separate those readings from the metrics available? - Who owns the interchanges between lines, and what happens when two owners disagree on a handoff? - When an agent is grounded only in the model documentation, how does the team detect that its answers merely echo the model's assumptions? - How does the model handle one person occupying several funnels without double counting in reports? - What is the rubric's scoring scale, and who scores platform experience? - When will the public visualizer branch be released, under what license, and where? ## 🔮 Future research - **Validation of the causal claim.** Morrow's chain is a modeled structure. A longitudinal study that tests whether top-of-funnel movement precedes downstream movement would turn the model's assumption into evidence. - **Cross-ecosystem generality.** The model is built from one enterprise ecosystem. Testing it on an open-source ecosystem, where contributors and users aren't customers, would show which lines transfer. - **Grounding bias in agent analysis.** The speaker flags it. A controlled comparison of grounded and ungrounded agents on the same data would quantify it. - **Metric definition governance.** The "potentially high impact app" example shows that stage definitions carry hidden theory. Research on how teams document and revise those definitions is missing. - **Topology versus geography.** The description argues connectivity matters more than layout. User studies could test whether a topological diagram improves stakeholder comprehension over a conventional funnel chart. ## 💡 Implications - **Practice.** Separate funnels by stakeholder and measure each independently. That is the one prescriptive step in the Q&A that doesn't depend on Atlassian's data. - **Policy.** Business reviews that rely on AI-generated reports need a stated rule for which source documents ground the agent and who reviews the output. - **Security.** An agent that queries metrics through an MCP server touches internal business data. Scope its credentials, log its queries and review the skill definitions. - **Education.** The tube-map metaphor gives non-technical stakeholders a familiar visual language. It also risks teaching the map as fact when it's a hypothesis. - **Funding.** If a funder wants to see value, tying a program to a named stop and a downstream metric is a defensible reporting format, provided the stop definitions are public. - **Measurement literacy.** The correlation-versus-causation exchange at 00:22:42 is a reusable teaching case for DevRel reporting. ## 🧠 Learning styles assessment - **Reading level estimate.** Flesch-Kincaid Grade Level on the transcript is approximately grade 10, with Flesch Reading Ease near 55. Conversational English, with domain terms (MCP, MBR, SVG, funnel, causal chain) that assume a DevRel or developer-tools audience. #### 👀 Visual learners - Present: the entire talk is a diagram built layer by layer, plus an animation and three app demos. - Improve: the narration doesn't describe line colors, positions or station names for viewers who can't see them. Name each station as it appears. #### 🔊 Aural learners - Present: steady narration with a clear agenda at 00:00:51 and a recap at 00:16:49. - Improve: the stutter loop at 00:04:28 and the "Whoops" at 00:08:03 interrupt the flow. Repeating the three funnel names in the closing would help listeners without the visuals. #### 🗣️ Verbal learners - Present: each line is defined in one or two sentences as it's added. - Improve: MBR and MCP are expanded only partly. Spell out "monthly business review" and "Model Context Protocol" on first use. #### 🧩 Kinesthetic learners - Present: three demos show the app in use. - Improve: no repository, no template and no exercise is given. The public visualizer is promised but unlinked in the transcript. #### 🧠 Logical learners - Present: the causal-chain diagnostic gives a clear procedure: measure each stage, trace backward, find the weak link. - Improve: no metric values or worked example are shown. Walk through one real trace with numbers. #### 🧑‍🤝‍🧑 Social learners - Present: live Q&A with three questions and the speaker's invitation to share the app "if there's interest." - Improve: no community channel or discussion venue is named for follow-up. #### 🧘‍♀️ Solitary learners - Present: self-contained, with the build-up in order, and short enough to rewatch. - Improve: no reflection prompt. "Which of your activities sit on which line?" would turn the talk into an exercise. #### 🌿 Naturalistic learners - Present: the transit metaphor ties to a physical, navigable space. - Improve: no natural-world analogy. An ecosystem metaphor from biology (energy flow, food webs) would suit this audience and the word "ecosystem" already invites it. ## 📊 Accessibility assessment #### Screen reader semantics - Present: YouTube supplies page landmarks and player controls. The transcript is machine-readable. - Improve: the map is the content, and the narration doesn't describe it fully. WCAG 2.2 AA 1.1.1 (Non-text Content) and 1.2.5 (Audio Description, Prerecorded) aren't met for the diagram, the animation and the demos. Publish an SVG with a text equivalent or a structured outline of lines and stations. #### Keyboard navigation - Present: the YouTube player is keyboard operable with visible focus. - Improve: the video adds no barrier. 2.1.1 (Keyboard) and 2.4.7 (Focus Visible) pass through the platform. The demo app's keyboard support is unknown. #### Contrast and readability - Present: unverifiable from a transcript. Colored lines on a diagram are a known risk. - Improve: tube lines distinguished by color alone fail 1.4.1 (Use of Color) unless labeled. Confirm 1.4.3 contrast on labels and station text. #### Text resizing and reflow - Present: the player scales and captions resize independently. - Improve: burned-in slide text and diagram labels don't resize. 1.4.4 (Resize Text) and 1.4.10 (Reflow) fail for any text baked into frames. The blurred report in the demo is intentional but adds nothing for low-vision viewers. #### Media and captions - Present: an auto-generated transcript exists, and the video has no chapters in its metadata. - Improve: the captions garble proper nouns ("Alassian," "Devreil," "MPC server," "Dald") and the speaker's own stutter produces a long "st st st" run at 00:04:28. Audience questions are captured in the same stream as the speaker with no speaker labels. That is a substantive 1.2.2 (Captions, Prerecorded) failure. The lack of chapters weakens 2.4.5 (Multiple Ways) for a 23-minute talk. #### Forms and interactions - Present: none in the video. The offer to share the app is made via a QR code. - Improve: a QR code is not an accessible link. Put the URL in the description as selectable text. 3.3.2 (Labels or Instructions) applies to whatever form that page presents. #### Standards reference - Primary gaps against WCAG 2.2 AA: **1.2.2** (inaccurate, unlabeled captions), **1.2.5** (no audio description for the diagram), **1.1.1** (map conveyed visually only), **1.4.1** (color-coded lines), **1.4.4 / 1.4.10** (burned-in text), **2.4.5** (no chapters). Highest impact and cheapest fix: corrected captions with speaker labels, plus chapter markers. ## 🌍 DEIB assessment #### Cultural breadth - Present: the London Underground metaphor is widely known, and the audience at DevRelCon NYC is international. - Improve: the metaphor assumes familiarity with a London-style transit diagram. Some audiences use different transit conventions. All examples come from one enterprise software company. #### Inclusive language - Present: no exclusionary terms in the transcript. The language is direct. - Improve: "stalled trains" and "disembarking" appear in the description and are fine. No change needed on inclusivity; the main risk is jargon such as "vanity metrics," which could be defined. #### Neurodiversity support - Present: the layer-by-layer build makes each step small, and the agenda at 00:00:51 sets expectations. - Improve: no chapters in the metadata, and the on-screen animation moves while narration continues. Offer a static version of the full map. #### Representation - Present: one speaker and three audience questioners. The transcript carries no gendered pronouns for any person, so none are inferred here. - Improve: the talk gives no voices from partners or customers, the stakeholders the model describes. A guest perspective from a builder or partner would test the model's claims. #### Psychological safety - Present: the speaker takes challenging questions calmly, concedes terminology may differ at 00:23:25, and states a limit on the AI demo at 00:15:20. - Improve: the conditional offer to share the app "if there's interest" is open-ended. Stating a date and a place would let people plan. ## ✅ Logical validity #### Strong reasoning - **Decomposition, 00:01:35 to 00:05:11.** Separating evangelism from channels and events lets a team ask whether the message or the distribution is failing. That is a sound use of separation to isolate a variable. - **Separation of stakeholder journeys, 00:03:44.** Builder and partner activities are done by the same people but are different work. Splitting them prevents "confused outreach." The argument is valid and testable. - **Independent funnels with overlap, 00:06:39.** The point that one developer can be in the builder funnel while the employer is in the partner or customer funnel anticipates double counting. - **Diagnostic procedure, 00:09:31.** If each stage has a metric, you can trace backward and find the weak link. The inference is valid given its premise. - **Self-limiting disclosure, 00:15:20.** Morrow volunteers that grounding the agent in the model documentation will bias its answer, which raises the credibility of the AI demos. #### Fallacies - **Unsupported assertion, 00:09:31.** "This concern can be mitigated if we have a model that clearly identifies how top offunnel activities translates to business outcomes." No example shows a mitigation. *Fix:* show one real trace with named metrics and values. - **Equivocation on "causal," 00:22:42 to 00:23:25.** The model is presented as revealing a "granular causal chain" at 00:09:31, and the answer to a direct challenge is that "the terminology" may differ. A modeled sequence of stages isn't a demonstrated cause. *Fix:* say "assumed causal path" and state which links have been tested. - **Circular grounding, 00:15:20.** The agent says the funnels can't be combined, but it's grounded in documentation that defines them as separate. The speaker flags the bias, yet the demo is still offered as analysis of the model. *Fix:* compare against an ungrounded agent. - **Argument by assertion about uses, 00:18:21.** "I've used it for a lot more" (paraphrase): the talk cites reports, OKRs and predictions produced from beliefs and data without showing any. *Fix:* show one output with the inputs. - **Undisclosed dependence on a private artifact, 00:13:53.** The Atlassian app, its data and its metric definitions are internal. The audience can't evaluate or reproduce the results. *Fix:* publish the stripped public version first or state plainly that the evidence isn't available. - **Vanity-metric framing without counterexample, 00:00:08.** The talk asserts DevRel reports vanity metrics and hopes leadership agrees, but names no specific metric that failed. *Fix:* cite two examples of metrics the model replaces. #### Tone of voice - Calm, explanatory and second-person, with contractions ("we've," "I'm just using a similar metaphor"). The register is that of a practitioner walking colleagues through a build, with no hype superlatives. The enthusiasm is modest ("it's actually quite powerful" at 00:19:07). The weakest passages are where evidence should appear: claims about results come as assertions, while the diagram description is precise. The speaker answers all three audience questions directly and without defensiveness. ## 🛡️ DARVO analysis Not applicable to this source. DARVO (Deny, Attack, Reverse Victim and Offender) describes a response pattern to an accusation. This is a conference talk with Q&A and no accuser. The closest thing to a challenge is the causal-versus-correlative question at 00:22:42. For completeness across the three prongs: **Deny**: the speaker doesn't deny the point. He says the terminology may differ at 00:23:25. **Attack**: no attack on the questioner or on other approaches. The DevRel Agency's tube map is credited and explicitly not criticized at 00:01:35. **Reverse victim/offender**: no such move appears. ## 🎯 Conclusion The durable idea is structural: separate the developer, partner and customer funnels, put a metric on each stop, and trace backward from an outcome to find the weak link. That procedure is valid on its own terms at 00:09:31, and the instruction at 00:21:59 to track each funnel independently because they drive different decisions is usable today without any software. The evidence does not match the ambition. No metric value, conversion rate or outcome appears in the 23-minute recording. The "causal chain" is a modeled path, and the audience challenge at 00:22:42 gets an answer about terminology instead of a test. The AI demos are grounded in the model's own documentation, which the speaker flags as a bias, and the app itself is internal, so nobody watching can reproduce it. **Next steps for readers:** draw your own ecosystem on the eight lines, assign one metric to each stop, and write down which links you've tested versus assumed. Then run the comparison in the Methodology section before using the map to defend a budget. Get the public visualizer URL from the speaker, because the transcript has only a QR code, and fix the caption garbles ("Alassian," "MPC") before citing any quote. ## 🔄 Refactor Appendix — The Ecosystem Tube Map — Dugald Morrow > Density: 2–5 Literature atoms (H3 pad), 0–3 Permanent candidates (H4 pad). > Emitted: 5 Literature, 2 Permanent. Resonance filter applied: the demo walkthrough > and the offer to share the app were dropped as non-claims. > > Konik claim-header rules: present tense, declarative, ≤10 words, searchable, unique. > > Atomicity: one declarative sentence per atom. "and"/"also" → split. > > Tag pool: #bmf · #addendum · #xref · #articleseed · #storystem · #share · #aphorisms ### 📚 Literature Split Pad #### [H1] DevRel sees three separate funnels > [!quote] [00:06:39] > the map highlights three funnels, one each for developers, partners, and customers. **Context & use**: - 00:06:39, right after the lines that start linear and end in loops are introduced. - The funnels are independent but influence each other, and one person can sit in several. Record both halves together or the atom implies a single pipeline. **Tags**: #xref #articleseed <!-- atomicity: 1 idea ✓ --> #### [H2] Stage metrics let you trace weak links > [!quote] [00:09:31] > as long as you have metrics measuring at each stage, you can trace along the chain to see where the weak links are. **Context & use**: - 00:09:31, the core diagnostic claim. - It is a conditional: it only holds when every stage has a metric, and the talk shows no metric values. **Tags**: #xref <!-- atomicity: 1 idea ✓ --> #### [H3] Churn is the expectation-to-platform gap > [!quote] [00:10:14] > The gray links represent churn which is caused by the difference between what stakeholders expect and what the platform actually provides. **Context & use**: - 00:10:14, introducing the platform-experience rubric. - Makes platform quality a DevRel measurement concern even though DevRel doesn't own the platform line (00:04:28). **Tags**: #xref #bmf <!-- atomicity: 1 idea ✓ --> #### [H4] Plain-text models are legible to AI agents > [!quote] [00:11:42] > Because this is all plain text, it's easy for AI to consume it. **Context & use**: - 00:11:42, the case for SVG plus markdown as the model format. - The agent flow that follows (skill, docs, LLM, MCP, second LLM call) is the worked example. The grounding bias admitted at 00:15:20 is the counterweight. **Tags**: #xref #addendum <!-- atomicity: 1 idea ✓ --> #### [H5] The framework supplies a map for metrics > [!quote] [00:21:59] > the framework itself is giving you sort of like the map to place those metrics on if you like. **Context & use**: - 00:21:59, the answer to how stops tie back to business outcomes. - Concedes that each organization must define its own metrics. The framework is a placement scheme, not a measurement set. **Tags**: #xref #share <!-- atomicity: 1 idea ✓ --> ### 🧠 Atomic Split Pad #### [P1] Measure each stakeholder funnel separately **Claim** (one sentence, Courtney's voice): When different stakeholders make different decisions, each needs its own funnel and metrics, and blending them hides where people actually leave. **Evidence pointer**: [[#H1]] · [[#H5]] **Scope & conditions**: Holds when stakeholder types make distinct decisions (a builder choosing an SDK versus a partner choosing a marketplace listing). Weaker when one person plays all roles, and funnels overlap, so reports need a rule for people who appear in more than one. **Links**: - [[Developer relations metrics]] — because extends - [[Single linear funnel reporting]] — because contrasts on how many stakeholder journeys one metric chain covers - [[Open source contributor funnel]] — because applies-in an ecosystem where contributors, sponsors and users differ <!-- atomicity: 1 idea ✓ --> #### [P2] A causal chain is a hypothesis until each link is tested **Claim** (one sentence, Courtney's voice): A model that orders stages from activity to outcome is an assumed causal path, and it earns the word "causal" only for links with evidence. **Evidence pointer**: [[#H2]] **Scope & conditions**: Applies to any funnel or tube-map model used to justify spend. Doesn't apply to the diagnostic use (tracing a drop backward to find a candidate cause), which is useful whether or not the links are proven. **Links**: - [[Correlation versus causation in reporting]] — because extends - [[Leading and lagging indicators]] — because applies-in predicting downstream outcomes from top-of-funnel signals - [[Vanity metrics]] — because contrasts on whether a metric connects to an outcome <!-- atomicity: 1 idea ✓ --> ### ✏️ Fleeting Queue - [F1] Find the DevRel Agency's "Mind the Gap" developer-journey tube map the talk credits at 00:01:35; the transcript spells the publisher "Devreil. Agency" — https://www.youtube.com/watch?v=5DrPU4ojIrM #fleeting #inbox - [F2] Get the public visualizer branch URL from Morrow; the transcript shows only a QR code at 00:16:49 #fleeting #inbox - [F3] Open question: how are "potentially high impact app" and "high impact app" defined (00:21:14)? #fleeting #inbox - [F4] Draw my own ecosystem on the eight lines and mark which links I've tested versus assumed #fleeting #inbox - [F5] Article seed: "A causal chain is a hypothesis" using the 00:22:42 exchange as the example #fleeting #inbox #articleseed - [F6] Check whether an agent grounded only in the model docs reproduces the docs' assumptions; Morrow flags the bias at 00:15:20 #fleeting #inbox ### → Things 3 (max 2 actions) - [ ] Ask Dugald Morrow for the public visualizer URL and the high-impact-app metric definitions — DevRelCon follow-up, 10 min #things - [ ] Draw one tube map of the team's own ecosystem with a metric per stop and mark tested versus assumed links — DevRel metrics #things <!-- deep-read:sections end --> 📄 **Full text:** [[Full Document Contents/Articles/The Ecosystem Tube Map — Dugald Morrow.md|The Ecosystem Tube Map — Dugald Morrow by Dugald Morrow]] ## Highlights - [00:05:55] range from amplifying platform feature releases to campaigns and events. This includes community multi- channelannel content delivery and events. This broad range of scope is one of the defining characteristics of Devril and it's reflected by the map. Now that the map is built, let's explore some abstractions that reveal more information about how ecosystems work. You may have noticed that some tube lines start with a linear section and end with loops. This pattern indicates how investment leads to growth and scale over time. For example, the tube lines representing the journeys of developers, partners, [00:06:39] and customers illustrate the acquisition and retention of these stakeholders. In other words, the map highlights three funnels, one each for developers, partners, and customers. The funnels are independent from one another, but activity in one can influence activity in another. Also, a single person organization can be active in more than one funnel at a time. A developer at a company might be in the builder funnel personally while their employer may be in the partner or customer funnel. The combined output of the builder and partner funnels is the app pipeline. The flow of apps moving from development to ([View Highlight](https://read.readwise.io/read/01m50s7ta63weekp3h81pwp790)) - Note: [H1] DevRel sees three separate funnels - Tags: atom/literature/h1 - [00:08:47] parallel. Customerfunnel work includes evaluating risk and estimating costs. Developer funnel work is the actual app development resulting in artifacts in the app pipeline. The activities culminate in customer success which is when the customer starts using the app. Next, let's look at how the fun how the model functions as a diagnostic tool, tracing causal chains and identifying where health can break down. One of my goals when creating this framework was to understand the causal chains within ecosystems. Devil has often struggled with reporting on vanity metrics, but not being able to [00:09:31] translate this into business outcomes. This concern can be mitigated if we have a model that clearly identifies how top offunnel activities translates to business outcomes. A granular causal chain also helps us diagnose problems because as long as you have metrics measuring at each stage, you can trace along the chain to see where the weak links are. Often this chain often this tracing is done backwards to identify activities affecting downstream outcomes. The model reveals a granular causal chain from evangelism through to customer success. For simplicity, the three funnels of collapse, but in reality, they are each nested causal ([View Highlight](https://read.readwise.io/read/01m50s7wxg5smy77j0nmdgcmn8)) - Note: [H2] Stage metrics let you trace weak links - Tags: atom/literature/h2 - [00:10:14] chains. Topfunnel metrics are important because they provide leading indicators of impact. They become more valuable, however, when a co causal chain can confidently predict downstream business impact. Zooming out slightly, this diagram also illustrates the investment in the app platform. The gray links represent churn which is caused by the difference between what stakeholders expect and what the platform actually provides. This means it's important to measure the platform experience in order to diagnose and even predict causes of churn. We can do this using a rubric, a structured [00:10:59] scorecard that evaluates each dimension of the developer and partner experience from documentation quality to API reliability and support quality. So whilst the ultimate way to calculate ecosystem health is by measuring business outcomes such as app usage, the upstream funnels in app pipeline are leading indicators of health and the health of the funnels are also dependent on the platform experience. In addition, the model provides detailed traceability to diagnose problems. Now let's look at the implementation of the model and how it can be leveraged by AI. ([View Highlight](https://read.readwise.io/read/01m50s7zcw786nvpe8t16914v5)) - Note: [H3] Churn is the expectation-to-platform gap - Tags: atom/literature/h3 - [00:11:42] The tube graphics are in SVG format and are accompanied by a number of markdown files that describe the SVG conventions and all the abstractions in the model. Because this is all plain text, it's easy for AI to consume it. AI agents can query it, reason about it, and help you help you generate reports from it without needing a data team. This sequence of calls shows how the model can be leveraged using an AI agent to create a report. For example, at Alassian, we we create reports known as monthly business reviews or MBRS. The agent starts by entering it, ensuring it has the relevant skills [00:12:26] loaded, and in this case, it would load the MBR skill. It then consults relevant parts of the model's documentation. All this context is sent to the LLM which returns instructions to the agent with details to query metrics. The agent delegates this to an MPC server and then makes another LLM call that includes all the metric data. The LLM finally returns the generated report for the user to view. So this is a slightly simpler version of the previous diagram which illustrates how the model can be leveraged by AI. We can extend this pattern by adding ([View Highlight](https://read.readwise.io/read/01m50s81pcn50fwn6k1jx4rssj)) - Note: [H4] Plain-text models are legible to AI agents - Tags: atom/literature/h3 - [00:21:59] explain what those metrics are and what they care about to provide that linkage. Uh but the f the framework itself is giving you sort of like the map to place those metrics on if you like. uh and one of the key points is to separate out the concerns of the different stakeholders and make sure that they're each funnel is being tracked independently because they all have different types of decisions amongst them. >> So you talked a lot about causal links I'm assuming from signals you're picking up from all the points on the map. >> Yep. >> To business outcomes. >> Yep. So, are you saying you're making direct [00:22:42] attributable connections between the things you're seeing out there from signals across those different surfaces and business outcomes or are you really more looking at correlative uh attachment? Right? Because I think causal links are very specious. >> Yeah. >> To to directly say like these set of things cause this outcome. So I was just kind of wondering did you really mean causal or correlative or is there some combination thereof that is making that linkage? >> Yeah, maybe the terminology we we're using maybe different terminology or whatever but yeah it's definitely um identifying the metrics that you care ([View Highlight](https://read.readwise.io/read/01m50s840ehsb59kz16svrmv6j)) - Note: [H5] The framework supplies a map for metrics - Tags: atom/literature/h3