Implementation worksheet · 5 min read
A Component Ownership Matrix for Growth and Engineering
Split ownership by decision type rather than by component: content and targeting belong to growth, integration and performance belong to engineering, and three things need a named joint owner — the selectors that connect guidance to the application, the performance budget, and anything that can be changed in production without a deploy. Those three are where the failures cluster, because each sits between the two teams and is therefore owned by neither. Write the matrix down with names, not team labels, and review it when either team reorganises.
In-app guidance is unusual in that one team edits what users see and another team owns the code it runs in. That works while both are small and breaks at the first refactor, when engineering changes a class name for good reasons and nobody knew a tour depended on it.
Put it into practice
1. List the decisions, not the components
Copy, targeting rules, when a tour runs, which selector it attaches to, how the SDK loads, what the performance budget is, who can publish to production. Ownership arguments are almost always about a decision rather than a file, and a matrix listing files does not resolve them.
2. Give growth content and targeting outright
Copy, audience, timing, sequencing. These should not require an engineering ticket — the moment they do, guidance stops being iterated and the whole investment underperforms. Engineering's interest here is the guardrails, not the decisions.
3. Give engineering integration and performance outright
How the SDK loads, what it is allowed to cost, what happens on failure. These are not negotiable by content velocity, and the build-enforced budget is the mechanism that makes that real rather than a stated preference.
4. Name a joint owner for selectors
This is the seam. A selector is written by growth and lives in engineering's markup. Someone has to be responsible for the stable attribute existing and surviving refactors — usually an engineer who knows guidance depends on it, named, not a team.
5. Name a joint owner for the performance budget
Engineering sets it, growth lives within it, and when a feature would exceed it somebody decides. Without a named decider that conversation resolves by whoever is more insistent, which is not a process.
6. Name who can publish to production without a deploy
Remote-configurable guidance means someone can change what every user sees in seconds. That power needs a name attached and a review rule — it is the most under-governed capability in this whole category precisely because it is the most convenient.
7. Review when either team reorganises
Ownership matrices decay at reorganisations, and the seam items are the first to become unowned. A short review at that point costs ten minutes and prevents the quiet period where the selectors belong to nobody.
The ownership matrix
Copy this structure into your review document and record your observed result for each row.
| Decision | Owner | Consulted | Named person |
|---|---|---|---|
| Copy and content | growth | — | |
| Targeting and audience rules | growth | engineering (data availability) | |
| When guidance runs | growth | — | |
| Selector / stable attribute | JOINT | both | |
| SDK loading and initialisation | engineering | growth | |
| Performance budget | JOINT | both | |
| Failure behaviour | engineering | growth | |
| Production publish without deploy | JOINT | both | |
| Incident response for broken guidance | engineering | growth | |
| Measurement definitions | growth | engineering |
A failure worth checking
The unowned selector. Growth writes a tour against a class name. Engineering refactors the component months later, with no reason to know anything depends on that class. The tour breaks silently, nobody is alerted, and when it is found each team reasonably believes the other owned it. The matrix marks selectors as jointly owned with a named person precisely because the default state is that they belong to neither team, and the default failure is silent.
Common questions
Should engineering review every content change?
No — that removes the velocity that makes in-app guidance worth having. Engineering's control should be structural: the budget, the failure behaviour, the stable attributes. Reviewing copy is neither a good use of their time nor a real safeguard.
What if growth has no engineering support at all?
Then the seam items are unowned and will fail, which is worth stating plainly rather than working around. The minimum is one named engineer who knows guidance depends on specific markup — less than that and every refactor is a coin flip.
Basis and scope
This is a proposed implementation method using illustrative examples, not a measured benchmark or a customer case study. Prepared with AI assistance. Validate product-specific behavior against current documentation and your own test environment.