My 10 rules for dev tickets as a DTC marketer

isa-ecom

I've been writing dev tickets for years-mostly for cart recovery flows, loyalty programme tweaks, and post-purchase email triggers. Here are the rules I live by:

My goal is that the ticket never needs a follow-up meeting.
I write it so the dev team's job is actually easier, not harder.
I can't control how fast they implement, but I can control the quality of the ticket-and that directly affects speed.
I respect their time and expertise. They're the experts, their sprint capacity is precious.
I explain exactly what needs to happen, but never the how.
I don't dump decision-making on them. I give specs, not options. Reasoning stays out of the ticket.
I add context for prioritisation (e.g., "this affects 15% of checkout drop-off") but I don't expect them to share my urgency.
The ticket must be self-contained. No links to external docs unless it's official API reference.
I speak their language-HTTP status codes, database fields, event triggers-and use real data, not placeholders.
I document what exists now before specifying what changes.

What are your rules for writing dev tickets that actually get built?

ppcnerd

This is solid advice. It mirrors what I've seen in the ad space, where you have to lay all the groundwork so the algorithm thinks it found the winning audience on its own. The psychology is the same here - make the devs feel like they discovered the fix, not that you dictated it.

One thing I'd add is to provide evidence beyond the ticket specs - screenshots of the broken behaviour, a quick loom of the bug, or even a before/after of the metrics. It saves back-and-forth and builds trust that you've already done the hard yards

leadgen

Yep, learned that lesson myself after a ticket went wrong without proper acceptance criteria.

harper-local

I just apologise, thank them, and leave it in their hands. Works better than arguing over a dev ticket when you know the fix is simple but they're swamped.

olivia-roas

Rule #6 hits harder than most people realise, and it's exactly where the whole "devs don't care about SEO" narrative falls apart. in my world - scaling six-figure daily ad budgets - the same dynamic plays out with engineering tickets for pixel updates, CAPI integrations, and creative delivery fixes.

presenting specs without reasoning works when the dev team trusts that the ad impact justifies the engineering cost. But when those tickets sit next to product roadmap items competing for sprint capacity, the missing "why" means they get deprioritised because the PM has zero context for stack-ranking them against feature work. Nothing kills priority faster than a ticket that says "add UTM params to checkout flow" with no link back to revenue.

The addition that's saved my ass: include the reasoning not in the ticket body but in a dedicated "impact context" section that PMs actually read during planning. Something like "this pixel change affects the X% of users that drive Y% of total attributed revenue." The dev team skips it. The PM who decides whether it makes the sprint uses it to justify the allocation against a feature that "improves user experience" but has no measurable ROI.

One other rule I'd add: include a validation method. "After implementation, confirm by checking [specific event] firing in Meta Events Manager for [specific user action]." This prevents the inevitable follow-up ticket when the implementation is technically correct but doesn't produce the expected attribution outcome because of a detail the dev team couldn't have anticipated - like a server-side tag blocking the event before it hits the pixel.

Do you find your tickets actually get prioritised consistently, or is the engineering capacity fight the real bottleneck in your day-to-day?

gmbpro

I've been doing technical SEO migrations for about 15 years now, and my approach has shifted over time. I don't write tickets either - I document the issue, the expected behaviour, and the specific fix (e.g. GA4 event parameter mapping or missing dataLayer push). Devs create the ticket from my notes, implement, then tag me on staging for review.

Key differences in my workflow:

I always provide a clear before/after example in the ticket description, even if I didn't write the ticket itself
If the fix touches analytics tracking, I include a test script or GTM preview link so they can validate immediately
I set a hard SLA: if staging review isn't ready within 5 working days, I escalate

That said, I've found that being the "top priority" for the frontend team can backfire if you're not careful - you get the fast fix but then zero documentation or unit tests, so the same bug creeps back in after the next sprint. That's where leaving a paper trail in the ticket (even if you didn't create it) saves reintroducing the same broken UA→GA4 migration three times.

pixelpusher

Acceptance criteria are a nice idea in theory, but in practice most devs treat them as a suggestion. i've lost count of how many tickets I've written with crystal-clear criteria, only to have them ignored because the PM changed scope halfway through the sprint. The 3 Cs matter, but if you're not sitting in the same room as the devs and watching them test, you're just writing poetry for a brick wall.

isa-ecom

Nice rules. as a retention marketer, I'd add: include any SMS or email triggers the change might break. Nothing worse than fixing SEO and nuking an abandon cart flow

gmbpro

Long story short, but it comes down to proven results. In most companies I've worked with, around 80-90% of revenue ties directly to the GA4 setups and migration work I've done.

pixelpusher

Not saying this to be difficult, but I've been in the trenches with dev teams for years, and that "speak their language" advice from product managers is usually cargo cult nonsense. Nine times out of ten they're passing off basic Jira discipline as some kind of secret sauce.

If your tickets need a translator, your ticket format is wrong, not your communication style. Write specs that even a junior dev can execute without a hand-holding stand-up. That's the actual skill.