Product communications, not marketing

Context

There’s a useful boundary in lifecycle communications that most companies blur: marketing emails versus product communications.

Marketing emails are scheduled, broadcast, and optional. Their job is to persuade. Their cadence is set by the marketing team, and their content is governed by the brand.

Product communications are triggered, individualised, and operational. Their job is to confirm, instruct, or unblock a user in the middle of doing something inside the product. Their cadence is determined by what the user does (or doesn’t do). Their content is governed by the product.

These are different content systems with different requirements. Conflating them — running both through the same CRM with the same writers — produces predictable failure modes: product messages that feel like marketing, marketing cadence that crowds out product clarity, and a localisation pipeline that breaks both.

This case is about building the product communications system properly, with the boundary defended.

Problem

When I took ownership of triggered communications at Admirals, the existing system had three structural issues.

It was treated as marketing. Messages went through marketing review, were written in marketing voice, and competed with promotional emails for send-time slots. The result: users got celebratory copy when they needed instructional copy, and instructional copy buried under brand voice.

The event schema was incomplete. Some product events that should have triggered a message didn’t exist as events. Others existed but didn’t carry the payload needed to write a useful message — the system knew a user had submitted KYC, but didn’t pass through what was submitted or where it was reviewed. Personalisation was limited to first-name-token level.

Reliability was opaque. When a flow broke (a triggered email never sent, or sent with empty variables) there was no monitoring that surfaced it. The first signal was usually a support ticket. Fallback content didn’t exist; if a personalization variable was null, the email shipped with a literal “{firstName}” in it.

Approach

1. Drew the boundary explicitly

The first deliverable wasn’t a message. It was a one-page document defining what counts as a product communication, what counts as marketing, and which team owns which. That document went through Product, Marketing, Support, and Engineering for sign-off.

The rule: if a message is triggered by a product event and serves an operational purpose (confirm, instruct, unblock, recover), it’s a product communication and lives in the product. Marketing messages — newsletters, promotions, re-engagement — stay in marketing’s CRM and follow marketing’s review process.

Most of the work that followed was only possible because this boundary was drawn and agreed first.

2. Built the trigger map

For each stage of the user journey I mapped what events should generate what messages, in what channel, with what content. The triggers live on product events; the messages live on the trigger map.

A representative slice of the map:

The map covers the onboarding stretch, with similar coverage for activation, reactivation, and the security lifecycle (2FA, password reset, suspicious-login).

3. Defined event schema with engineering

This is the part of the work most content designers don’t get to do. I sat with the Product Engineering team and we co-defined the event schema underlying the trigger map.

For each product event, the schema specifies:

• Definition — when does this event fire, exactly? (e.g. kyc.submitted fires when the user submits, not when the queue picks it up.)
• Payload — what data is carried, in what types, with what nullability. The content team’s needs go on the requirements list alongside the product team’s needs.
• Trigger conditions — fires every time? fires once per user? throttled? respects quiet hours per locale?
• SLA — how soon after the event does the message need to send?

4. Built reliability and fallback content

Triggered communications fail silently if you don’t watch for it. I owned the reliability layer:

• Fallback content for every personalisation variable. If {firstName} is null, the message reads “Hello,” not “Hello {firstName}.” If a market-specific link is missing, the message falls back to the generic one. Each fallback was authored, not generated.
• Monitoring on send-rate anomalies. A drop in kyc.submitted send volume in a specific locale is now an alert, not a discovery weeks later.
• Send-blocking on broken templates. If a template renders with errors in staging, it doesn’t ship to production.
• A regular review of bounce, unsubscribe, and complaint rates by message — high rates flag content problems, not just delivery problems.

5. Optimization cycle

Once the system was stable, I ran a continuous optimization cycle on the highest-volume messages.

The format: pick the message, name the hypothesis, A/B test one variable at a time, measure email-to-next-action, ship the winner, log the result.

Outcome

• +15% triggered email conversion across the system, measured on email-to-next-action.
• −20% SMS / 2FA message volume, achieved through clearer in-app copy that pre-empted “I didn’t get the code” reactions and consolidated SMS delivery routes.
• Event schema now documented and owned by Product / Engineering, used by both the content team and downstream analytics.
• Zero silent template failures since the staging-gate was introduced.

What I’d do differently

Push the marketing / product boundary into engineering, not just content. I drew the boundary at the content-and-process level. The cleaner version is for the systems themselves to enforce it — marketing CRM and product communications running on separate infrastructure, with different review workflows baked in. We did this partially; full separation would have been cleaner.

Treat fallback content as a first-class deliverable. I authored fallbacks reactively, as edge cases came up. Better: write the fallback at the same time as the primary content, ship them together, never let a primary template through review without its fallback.

Build the trigger map collaboratively from day one. I wrote the first version of the trigger map alone, then reviewed it with Product. The reverse — workshop the map with Product and Engineering, then write it up — would have surfaced event-schema questions earlier and saved a round of rework.

Work led at Admirals between 2023 and 2024. The trigger map covers onboarding, activation, reactivation, and the security lifecycle. Examples in this case are anonymised or paraphrased.