<?xml version="1.0" encoding="utf-8"?>
<feed xmlns="http://www.w3.org/2005/Atom">
    <id>https://trmccormick.com/blog</id>
    <title>Trevor McCormick Blog</title>
    <updated>2026-04-12T00:00:00.000Z</updated>
    <generator>https://github.com/jpmonette/feed</generator>
    <link rel="alternate" href="https://trmccormick.com/blog"/>
    <subtitle>Trevor McCormick Blog</subtitle>
    <icon>https://trmccormick.com/img/favicon.png</icon>
    <rights>Copyright © 2026 Trevor McCormick.</rights>
    <entry>
        <title type="html"><![CDATA[Ten Principles for Instrumentation Leadership (and What Comes Next)]]></title>
        <id>https://trmccormick.com/blog/ten-principles-what-comes-next</id>
        <link href="https://trmccormick.com/blog/ten-principles-what-comes-next"/>
        <updated>2026-04-12T00:00:00.000Z</updated>
        <summary type="html"><![CDATA[The capstone: ten principles distilled from building instrumentation at scale, and a vision for where the data product function goes from here.]]></summary>
        <author>
            <name>Trevor McCormick</name>
            <email>trevor.ryan.mccormick@gmail.com</email>
            <uri>https://github.com/trevormccormick</uri>
        </author>
        <category label="Leadership & Teams" term="Leadership & Teams"/>
        <category label="Strategy & Roadmapping" term="Strategy & Roadmapping"/>
    </entry>
    <entry>
        <title type="html"><![CDATA[From Data PM to Data Product Leader: The IC-to-Manager Transition]]></title>
        <id>https://trmccormick.com/blog/from-data-pm-to-leader</id>
        <link href="https://trmccormick.com/blog/from-data-pm-to-leader"/>
        <updated>2026-04-05T00:00:00.000Z</updated>
        <summary type="html"><![CDATA[The IC-to-manager transition for data PMs means letting go of schema ownership and learning to lead through others. The skills that made you a great IC won't make you a great leader.]]></summary>
        <author>
            <name>Trevor McCormick</name>
            <email>trevor.ryan.mccormick@gmail.com</email>
            <uri>https://github.com/trevormccormick</uri>
        </author>
        <category label="Leadership & Teams" term="Leadership & Teams"/>
    </entry>
    <entry>
        <title type="html"><![CDATA[Build vs. Buy for Analytics Infrastructure: A Recurring Evaluation Framework]]></title>
        <id>https://trmccormick.com/blog/build-vs-buy-analytics-infrastructure</id>
        <link href="https://trmccormick.com/blog/build-vs-buy-analytics-infrastructure"/>
        <updated>2026-03-29T00:00:00.000Z</updated>
        <summary type="html"><![CDATA[Build-vs-buy is not a one-time decision. It's a recurring evaluation as your scale, team, and requirements change. Here's a framework for making the call repeatedly.]]></summary>
        <author>
            <name>Trevor McCormick</name>
            <email>trevor.ryan.mccormick@gmail.com</email>
            <uri>https://github.com/trevormccormick</uri>
        </author>
        <category label="Strategy & Roadmapping" term="Strategy & Roadmapping"/>
        <category label="Platform & Architecture" term="Platform & Architecture"/>
    </entry>
    <entry>
        <title type="html"><![CDATA[Org Design for Data Product Teams: Conway's Law in Practice]]></title>
        <id>https://trmccormick.com/blog/org-design-conways-law</id>
        <link href="https://trmccormick.com/blog/org-design-conways-law"/>
        <updated>2026-03-22T00:00:00.000Z</updated>
        <summary type="html"><![CDATA[The org chart is a product design decision. How you structure the data team determines how your instrumentation system evolves — Conway's Law is inescapable.]]></summary>
        <author>
            <name>Trevor McCormick</name>
            <email>trevor.ryan.mccormick@gmail.com</email>
            <uri>https://github.com/trevormccormick</uri>
        </author>
        <category label="Leadership & Teams" term="Leadership & Teams"/>
        <category label="Strategy & Roadmapping" term="Strategy & Roadmapping"/>
    </entry>
    <entry>
        <title type="html"><![CDATA[Building the Business Case for Instrumentation Investment]]></title>
        <id>https://trmccormick.com/blog/building-business-case</id>
        <link href="https://trmccormick.com/blog/building-business-case"/>
        <updated>2026-03-15T00:00:00.000Z</updated>
        <summary type="html"><![CDATA[Frame instrumentation's indirect value in revenue, cost, and risk terms that leadership understands. Data infrastructure doesn't generate revenue directly — it enables everything that does.]]></summary>
        <author>
            <name>Trevor McCormick</name>
            <email>trevor.ryan.mccormick@gmail.com</email>
            <uri>https://github.com/trevormccormick</uri>
        </author>
        <category label="Strategy & Roadmapping" term="Strategy & Roadmapping"/>
        <category label="Leadership & Teams" term="Leadership & Teams"/>
    </entry>
    <entry>
        <title type="html"><![CDATA[Managing a Data Product Portfolio: Where to Invest, Maintain, and Sunset]]></title>
        <id>https://trmccormick.com/blog/data-product-portfolio</id>
        <link href="https://trmccormick.com/blog/data-product-portfolio"/>
        <updated>2026-03-08T00:00:00.000Z</updated>
        <summary type="html"><![CDATA[You manage multiple data products simultaneously. A portfolio view tells you where to invest more, where to maintain, where to incubate, and where to sunset.]]></summary>
        <author>
            <name>Trevor McCormick</name>
            <email>trevor.ryan.mccormick@gmail.com</email>
            <uri>https://github.com/trevormccormick</uri>
        </author>
        <category label="Strategy & Roadmapping" term="Strategy & Roadmapping"/>
        <category label="Product Management" term="Product Management"/>
    </entry>
    <entry>
        <title type="html"><![CDATA[Making Invisible Work Visible: Internal Marketing for Data Teams]]></title>
        <id>https://trmccormick.com/blog/making-invisible-work-visible</id>
        <link href="https://trmccormick.com/blog/making-invisible-work-visible"/>
        <updated>2026-03-01T00:00:00.000Z</updated>
        <summary type="html"><![CDATA[Data work is invisible by default — pipelines that don't break, schemas that don't drift, quality that doesn't degrade. Make it visible with PM-grade communication.]]></summary>
        <author>
            <name>Trevor McCormick</name>
            <email>trevor.ryan.mccormick@gmail.com</email>
            <uri>https://github.com/trevormccormick</uri>
        </author>
        <category label="Leadership & Teams" term="Leadership & Teams"/>
        <category label="Product Management" term="Product Management"/>
    </entry>
    <entry>
        <title type="html"><![CDATA[The Instrumentation Roadmap: Balancing New Features, Migration, and Tech Debt]]></title>
        <id>https://trmccormick.com/blog/instrumentation-roadmap-strategy</id>
        <link href="https://trmccormick.com/blog/instrumentation-roadmap-strategy"/>
        <updated>2026-02-22T00:00:00.000Z</updated>
        <summary type="html"><![CDATA[A roadmap makes tradeoffs visible across three competing priorities: new instrumentation for upcoming features, migration of legacy systems, and technical debt reduction.]]></summary>
        <author>
            <name>Trevor McCormick</name>
            <email>trevor.ryan.mccormick@gmail.com</email>
            <uri>https://github.com/trevormccormick</uri>
        </author>
        <category label="Strategy & Roadmapping" term="Strategy & Roadmapping"/>
        <category label="Product Management" term="Product Management"/>
    </entry>
    <entry>
        <title type="html"><![CDATA[Managing Data Product Managers: Coordination-Output vs. Code-Output Teams]]></title>
        <id>https://trmccormick.com/blog/managing-data-product-managers</id>
        <link href="https://trmccormick.com/blog/managing-data-product-managers"/>
        <updated>2026-02-15T00:00:00.000Z</updated>
        <summary type="html"><![CDATA[Managing people whose output is coordination and influence requires different techniques than managing people whose output is code or analysis.]]></summary>
        <author>
            <name>Trevor McCormick</name>
            <email>trevor.ryan.mccormick@gmail.com</email>
            <uri>https://github.com/trevormccormick</uri>
        </author>
        <category label="Leadership & Teams" term="Leadership & Teams"/>
    </entry>
    <entry>
        <title type="html"><![CDATA[Hiring for Instrumentation: Building a Team With No Existing Playbook]]></title>
        <id>https://trmccormick.com/blog/hiring-for-instrumentation</id>
        <link href="https://trmccormick.com/blog/hiring-for-instrumentation"/>
        <updated>2026-02-08T00:00:00.000Z</updated>
        <summary type="html"><![CDATA[No job templates exist for instrumentation roles. Build hiring criteria, career ladders, and onboarding from scratch — because the field is too new for standard playbooks.]]></summary>
        <author>
            <name>Trevor McCormick</name>
            <email>trevor.ryan.mccormick@gmail.com</email>
            <uri>https://github.com/trevormccormick</uri>
        </author>
        <category label="Leadership & Teams" term="Leadership & Teams"/>
    </entry>
    <entry>
        <title type="html"><![CDATA[Building a Data-Informed Product Culture Without More Dashboards]]></title>
        <id>https://trmccormick.com/blog/data-informed-culture</id>
        <link href="https://trmccormick.com/blog/data-informed-culture"/>
        <updated>2026-02-01T00:00:00.000Z</updated>
        <summary type="html"><![CDATA[Data culture is a product problem, not a dashboard problem. More dashboards don't change behavior — rituals, incentives, and access do.]]></summary>
        <author>
            <name>Trevor McCormick</name>
            <email>trevor.ryan.mccormick@gmail.com</email>
            <uri>https://github.com/trevormccormick</uri>
        </author>
        <category label="Leadership & Teams" term="Leadership & Teams"/>
        <category label="Product Management" term="Product Management"/>
    </entry>
    <entry>
        <title type="html"><![CDATA[How to Measure the Impact of Instrumentation and Data Products]]></title>
        <id>https://trmccormick.com/blog/measuring-impact-of-data-products</id>
        <link href="https://trmccormick.com/blog/measuring-impact-of-data-products"/>
        <updated>2026-01-25T00:00:00.000Z</updated>
        <summary type="html"><![CDATA[Report outcomes (decisions enabled), not outputs (events shipped). Your VP doesn't care about event counts — they care about what decisions your data made possible.]]></summary>
        <author>
            <name>Trevor McCormick</name>
            <email>trevor.ryan.mccormick@gmail.com</email>
            <uri>https://github.com/trevormccormick</uri>
        </author>
        <category label="Metrics & Measurement" term="Metrics & Measurement"/>
        <category label="Product Management" term="Product Management"/>
    </entry>
    <entry>
        <title type="html"><![CDATA[The Data Product Maturity Model: From MVP to Self-Serve]]></title>
        <id>https://trmccormick.com/blog/data-product-maturity</id>
        <link href="https://trmccormick.com/blog/data-product-maturity"/>
        <updated>2026-01-18T00:00:00.000Z</updated>
        <summary type="html"><![CDATA[A data product matures through stages: MVP (it exists), validated (stakeholders trust it), automated (it runs itself), self-serve (consumers don't need you).]]></summary>
        <author>
            <name>Trevor McCormick</name>
            <email>trevor.ryan.mccormick@gmail.com</email>
            <uri>https://github.com/trevormccormick</uri>
        </author>
        <category label="Product Management" term="Product Management"/>
        <category label="Strategy & Roadmapping" term="Strategy & Roadmapping"/>
    </entry>
    <entry>
        <title type="html"><![CDATA[When to Rewrite Your Event Schema From Scratch]]></title>
        <id>https://trmccormick.com/blog/when-to-rewrite-schema</id>
        <link href="https://trmccormick.com/blog/when-to-rewrite-schema"/>
        <updated>2026-01-11T00:00:00.000Z</updated>
        <summary type="html"><![CDATA[The decision to rewrite is a product decision, not a technical one. When incremental evolution isn't enough, here's how to evaluate whether a rewrite is warranted.]]></summary>
        <author>
            <name>Trevor McCormick</name>
            <email>trevor.ryan.mccormick@gmail.com</email>
            <uri>https://github.com/trevormccormick</uri>
        </author>
        <category label="Schema Design" term="Schema Design"/>
        <category label="Strategy & Roadmapping" term="Strategy & Roadmapping"/>
    </entry>
    <entry>
        <title type="html"><![CDATA[Migrating Instrumentation Without Breaking Dashboards and Models]]></title>
        <id>https://trmccormick.com/blog/migrating-instrumentation</id>
        <link href="https://trmccormick.com/blog/migrating-instrumentation"/>
        <updated>2026-01-04T00:00:00.000Z</updated>
        <summary type="html"><![CDATA[Instrumentation migration is a product launch in reverse — you're replacing something people depend on, not adding something new. The coordination is harder than the code.]]></summary>
        <author>
            <name>Trevor McCormick</name>
            <email>trevor.ryan.mccormick@gmail.com</email>
            <uri>https://github.com/trevormccormick</uri>
        </author>
        <category label="Schema Design" term="Schema Design"/>
        <category label="Product Management" term="Product Management"/>
    </entry>
    <entry>
        <title type="html"><![CDATA[Writing Requirements for What Not to Send: SDK-Level Collection Controls]]></title>
        <id>https://trmccormick.com/blog/what-not-to-send</id>
        <link href="https://trmccormick.com/blog/what-not-to-send"/>
        <updated>2025-12-28T00:00:00.000Z</updated>
        <summary type="html"><![CDATA[SDK-level conditions that suppress event emission — kids mode blocks collection, input events must not contain PII, flags exclude events from marketing use.]]></summary>
        <author>
            <name>Trevor McCormick</name>
            <email>trevor.ryan.mccormick@gmail.com</email>
            <uri>https://github.com/trevormccormick</uri>
        </author>
        <category label="Schema Design" term="Schema Design"/>
        <category label="Product Management" term="Product Management"/>
    </entry>
    <entry>
        <title type="html"><![CDATA[The Analytics Code Review: What a PM Should Look For]]></title>
        <id>https://trmccormick.com/blog/analytics-code-review</id>
        <link href="https://trmccormick.com/blog/analytics-code-review"/>
        <updated>2025-12-21T00:00:00.000Z</updated>
        <summary type="html"><![CDATA[The PM's contribution to analytics code review isn't code quality — it's requirements fidelity. Does the implementation capture what stakeholders need to know?]]></summary>
        <author>
            <name>Trevor McCormick</name>
            <email>trevor.ryan.mccormick@gmail.com</email>
            <uri>https://github.com/trevormccormick</uri>
        </author>
        <category label="Product Management" term="Product Management"/>
        <category label="Monitoring & Quality" term="Monitoring & Quality"/>
    </entry>
    <entry>
        <title type="html"><![CDATA[Managing Schema Evolution Without Breaking Downstream Consumers]]></title>
        <id>https://trmccormick.com/blog/managing-schema-evolution</id>
        <link href="https://trmccormick.com/blog/managing-schema-evolution"/>
        <updated>2025-12-14T00:00:00.000Z</updated>
        <summary type="html"><![CDATA[Every schema change is a negotiation between producers and consumers. Versioning, compatibility rules, and deprecation processes keep evolution safe.]]></summary>
        <author>
            <name>Trevor McCormick</name>
            <email>trevor.ryan.mccormick@gmail.com</email>
            <uri>https://github.com/trevormccormick</uri>
        </author>
        <category label="Schema Design" term="Schema Design"/>
    </entry>
    <entry>
        <title type="html"><![CDATA[Build vs. Buy for Notification Telemetry: Why Third-Party Tracking Falls Short]]></title>
        <id>https://trmccormick.com/blog/notification-telemetry-build-vs-buy</id>
        <link href="https://trmccormick.com/blog/notification-telemetry-build-vs-buy"/>
        <updated>2025-12-07T00:00:00.000Z</updated>
        <summary type="html"><![CDATA[Building in-house notification instrumentation vs. relying on third-party telemetry you don't control, can't validate, and may not give you everything you need.]]></summary>
        <author>
            <name>Trevor McCormick</name>
            <email>trevor.ryan.mccormick@gmail.com</email>
            <uri>https://github.com/trevormccormick</uri>
        </author>
        <category label="Experimentation & Growth" term="Experimentation & Growth"/>
        <category label="Platform & Architecture" term="Platform & Architecture"/>
    </entry>
    <entry>
        <title type="html"><![CDATA[Using Instrumentation to Validate Audience Segment Targeting]]></title>
        <id>https://trmccormick.com/blog/validating-audience-segments</id>
        <link href="https://trmccormick.com/blog/validating-audience-segments"/>
        <updated>2025-11-30T00:00:00.000Z</updated>
        <summary type="html"><![CDATA[Proper instrumentation helps PMs validate that different audience segments are served the correct experiences — not just that experiments ran, but that the right people saw the right thing.]]></summary>
        <author>
            <name>Trevor McCormick</name>
            <email>trevor.ryan.mccormick@gmail.com</email>
            <uri>https://github.com/trevormccormick</uri>
        </author>
        <category label="Experimentation & Growth" term="Experimentation & Growth"/>
        <category label="Metrics & Measurement" term="Metrics & Measurement"/>
    </entry>
</feed>