I run a fixed-date launch calendar as a system rather than by hand, and I built the intake that feeds it.
About eight events and five launches in the past five months at Dow Jones, each on a date that could not move.1 Before that, two years on one launch calendar across three Google properties through Android 12. I have produced launch and field material with product marketing leads; what I have never been is the writer of record for positioning, and that gets a section rather than a footnote.
Seventeen lines audited: eleven Strong, six Partial, no Gap.2 Eight minutes.
Section 01
The launch operating system
The posting names four things this role owns: the calendar, the plan of record, the review path and launch day. For each, what I would build and the nearest thing I have run. The transfer is the fixed date.
-
The calendar and the sequencing
What I would build. One calendar for every launch, each one’s tier declared rather than assumed, so what gets my hours is a decision anyone can argue with.
What I have run. Two years on one calendar across android.com, tv.google and wearos.google.com: three properties sharing components but not release schedules, with roadmap, creative, content, deployment and localization all landing against one announced Android 12 date, re-sequenced continuously with four product marketing stakeholders. Today, ten-plus event and conference properties.1
-
The plan of record
What I would build. One place where deliverables, owners, dependencies and dates live, with capacity computed rather than assumed, so the over-committed week appears before the work is promised away.
What I have run. I own the brand team’s Asana implementation and I built Relay, the intake layer that feeds it: six teams’ incompatible spreadsheets in, 120+ requests scoped since June, output pushed to Asana over the API so nothing is re-typed. Time off and partial weeks come off the top before anything is promised.
-
The path through review
What I would build. A named counterparty at each gate, dates people can plan against, and wait time measured per reviewer, because a legal review and a copy review are not the same promise.
What I have run. Hundreds of assets for one of GE Healthcare’s largest campaigns through a single gated pipeline where nothing shipped that had not cleared its gate, and a pharmaceutical MVP delivered inside merger-grade legal review.
What is missing. I have never owned a path where legal is the gating reviewer on the claim itself, and I have never worked with a policy function. That part I would be learning in public.
-
Launch day
What I would build. One readiness checklist per tier, one owner per surface, a rehearsal for anything going live for the first time, and a written record afterwards.
What I have run. Each migration onto the shared event-site build shipped alongside an event that could not move, so it proved itself on a live deadline in front of the team it replaced.3 The Row at Everyrealm brought external vendors, platform testing and the moment itself onto one day.
The caveat. Launch day for me has meant a site going live or an event opening, not a multi-surface release with an embargo, docs, pricing and a field team standing by. The checklist here is longer.
Then the fifth thing, which outlives any one launch. Eight build processes replaced by one shared system, six of eight migrated, build time down about 80%.4 One engineering team built it. My part was the agreement, with eight owners who each had reason to keep their own.
Section 02
Every line of the posting, judged
Eight responsibilities and nine qualifications, one line of evidence each.2 I am strong on every line about running the machine and weaker on the material moving through it.
-
R1
Core organizer of the launch process
EvidencePartialIntake through go-live for the Dow Jones brand function, six teams in, one plan out. Sites and events, not software.
-
R2
Own the launch calendar and sequencing
EvidenceStrongOne calendar across three Google properties that shared components but not release dates, through Android 12.
-
R3
Own the plan of record, surface risks early
EvidenceStrongThe Asana implementation is mine, Relay produces the plan, and capacity is computed so the over-committed week shows up early.
-
R4
Own the review path: legal, policy, product, comms
EvidencePartialA gated GE Healthcare pipeline, and a pharmaceutical MVP inside merger-grade legal review. Policy has never been a counterparty.
-
R5
Drive alignment across senior stakeholders
EvidenceStrongTwo years inside Google’s Android pod from an agency seat, directing four to six designers who reported elsewhere.
-
R6
Own launch-day execution: sequencing, timing, access, readiness
EvidenceStrongAbout thirteen fixed-date go-lives in five months, plus a launch where outside vendors, testing and the moment converged on one day.
-
R7
Own field resources and enablement operations
EvidencePartialSales decks, published white papers and executive collateral for Google’s field teams in 2014, agency side. I produced it; I never owned the library they pulled from. Section 03.
-
R8
Build playbooks that scale beyond one launch
EvidenceStrongEight build processes into one system, six migrated, build time down about 80%. Before that, creative operations built from zero.
-
Q1
Owned launch operations end to end, on time
EvidenceStrongAndroid 12 on a date that could not move, with a Google director on record that targets were hit without burnout.
-
Q2
Built or improved a launch process
EvidenceStrongOne shared build system replacing eight, and Relay replacing the two weeks of reconciliation that opened every quarter.
-
Q3
Treat process as a product, and measure adoption
EvidencePartialSix of eight owners moved onto a build they did not choose. Against it: Relay has one user, and the 80% is my own estimate.4
-
Q4
Background in product marketing, product ops or launch production
EvidenceStrongLaunch production and program management. The closest I come to product marketing is producing its material for Google teams in 2014, which is adjacency, not the job.
-
Q5
Keep a plan coherent when priorities shift
EvidenceStrongContinuous re-sequencing under an immovable date, a pivot at Everyrealm, an MVP shipped during a merger.
-
Q6
Effective at driving decisions without authority
EvidenceStrongFour references on record at four different altitudes, each naming planning, expectation management or communication.
-
Q7
Technical background, able to communicate complex AI concepts
EvidencePartialData models I specified, integrations holding in production, permissions in the schema, cost per agent. In 2014, explainers on programmatic advertising for technical and non-technical readers. No machine learning, no evals, not an engineer.5
-
Q8
Write clearly, and produce launch-ready material
EvidencePartialThe first half is this page. The second: a white paper series and five infographics published on Google’s DoubleClick blog in 2014, and executive collateral produced with a product marketing manager. I managed that work, never wrote it.
-
Q9
Energized by ambiguity and moving fast
EvidenceStrongA year on Google Search Ads with no date, no spec and no known answer.
Section 03
What is missing, before anyone has to ask
One thing I cannot claim at all, and one where the nearest evidence is real, agency side and eleven years old. Neither should be discovered in month four.
The one I cannot claim: writer of record
The posting says I will contribute directly as a product marketer when volume peaks. I have never written positioning, a messaging framework, a launch post or a product page. I oversee the people who do, resourcing design, content design and copy across ten-plus Dow Jones properties. That is managing writing, not being the writer of record.
What I would do about it. Start on the material closest to operations: enablement documentation, launch checklists, internal briefs, readiness docs. Then earn the rest over two quarters, drafting against real launches and being edited. If this team needs positioning written in month one, I am the wrong hire.
Field enablement: the closest thing I have, and what it is missing
This role owns the internal resources field teams reach for first, plus the operational side of enablement. I have produced that class of material once, at volume, from the other side of the table.
Sales material for Google’s field teams, agency side6
I produced the sales presentations Google’s sales teams used to sell its programmatic and DoubleClick products: hundreds of slides of content, data visuals and design, with a team of designers. With Google’s DoubleClick Video Product Marketing Manager and our art director I produced the video-product decks those teams carried globally. I managed the client relationship and the design phases of a white paper series published on Google’s own DoubleClick blog, and five infographics published globally that year. With five designers I produced fifteen animated decks presented by senior executives at Google’s 2014 client advisory board conference, including the deck for its Vice President of Display and Video Advertising Products, Neil Mohan.
What that is not. I produced the material and managed the designers; I did not write the positioning. And I was the agency, so I never owned the internal surface a field team self-serves from: no library to keep current, no version anyone has to trust on a Monday. The nearest thing is the brand hub my team’s visual system will feed at Dow Jones, and it has not shipped.7
What I would do about it. Of the eight responsibilities this is the most learnable: underneath the vocabulary it is a logistics and inventory problem, and I have run the 2014 version. What I would not have on day one is judgment about what a seller needs in the room; that comes from sitting in on the calls.
Why the trade is worth making. The operations half is the whole job most weeks, and it is the half I have done for thirteen years.
Section 04
Building the tooling, and what it is for
Each was built for a problem I hit at work. Operations systems, not ventures, not for sale, not looking for users.
First the boundary, because it matters more than the list. I am not an engineer and I do not hand-write production code. I specify the system, direct the agents that build it, then review and re-send until it holds, with staff engineer friends advising.5 The skill is knowing what to ask for, and recognising when the answer is structurally wrong.
The resourcing hour
The resourcing meeting is the most politically loaded hour in a creative team’s week: capacity, priority and whose work gets cut, decided out loud in front of the people it lands on.
So I built a resourcing tool for my own team. The decision made in the hour reaches the plan of record without a second write-up, staged for a one-click confirmation, with capacity computed rather than assumed. Fully built, in real weekly use, running on my own planning and not deployed across Dow Jones.8
The resourcing hour
In the meetingThe meeting updates the plan, instead of someone updating the plan after the meeting.
The parts that generalise are the refusals
- Nothing moves until a person confirms it, and that is a property of the schema rather than a setting somebody can switch off.
- A field nobody filled in renders as missing, never as a guess, and the system chases the gap until it closes.
- A proposed ranking arrives with a reason and a capacity cost attached. Priority stays mine, and every override is recorded.
- Every scheduled agent carries a unit cost, so whether an automation is worth keeping has an answer instead of an opinion. That is The Agent Room: about ten agents on an Airtable system of record, behind approval gates.9
- Buy when a product does the real job, adapt when the gap is process rather than software, build only when the near miss would force the team to reshape how it works. Usually it is buy.
The counter-evidence. Relay has exactly one user: me, weekly, on real quarterly planning, and the six teams who send spreadsheets never open it. A better signal than a signup count, and also not adoption.
Section 05
Why here, and the six months
I am not applying as an AI person. I am applying as an operator whose last two years happened to answer a question this company cares about: what an operations workflow looks like when a model is doing part of it, and where the human has to stay.
One thing is specific to this job rather than this company. I use Claude and Claude Code every week for real work, so I can read a launch brief and notice where the material claims something the product does not quite do.
The honest part, since a careful reader has already done the arithmetic. I am about six months into my role at Dow Jones, and I am not running from anything: the work is real and I am doing well at it. The reason I am writing is a preference that took thirteen years to get clear, not six months. I do my best work where the technology is the product itself, because that is where the operating layer behind the work is understood as something to design rather than tolerated as a quirk. Everywhere I have worked, technology served something else.
Two things make that specific rather than sentimental. The posting says to treat the launch process as a product, the argument I have been making from the operations chair for years, usually one floor below the people who could fund it. And the part of my week I built on nights and weekends stops being an unusual hobby here.10
Notes
Every marker resolves here
-
The Dow Jones figures come from my résumé: about eight events and five launches in five months; ten-plus event and conference properties across WSJ.com, Barron’s.com and MarketWatch.com; six requesting functions; 120+ requests scoped through Relay since June. Relay is internal and has no public address. ↩
-
Verdicts are self-assessed against the posting as published in August 2026, and deliberately harsh: a Partial means a real part of the line is missing. One has moved. Field enablement was a Gap here until I put the 2014 work in section 03 back on the table; it is a Partial now, not a Strong. Everything said here about the role comes from the posting itself. ↩
-
Eight properties were in scope for the shared event-site build and six have migrated. Two have not, and I always say so. ↩
-
About 80% is my own measure of build time before and after, an estimate across sites rather than an instrumented metric. ↩
-
Not an engineer. I do not hand-write production code and nothing here should be read as claiming I do. The builds are still real: a custom data model, permissions designed in rather than bolted on, hosting I set up and keep running. This page was made the same way, and the writing is mine. ↩
-
Beyond, Digital Producer, New York, October 2013 to April 2015. Agency side, working into Google, which is the whole qualifier: I produced the material and managed the designers, I did not write the positioning, and the library those field teams pulled from was never mine to own. Eleven years ago. ↩
-
The brand hub has not shipped. The visual system that will feed it is in progress: work underway, not a result. ↩
-
The claim to check hardest. The resourcing tool is fully built and in real weekly use, for a problem in my own role, running on my own planning rather than deployed across Dow Jones. ↩
-
About ten scheduled agents against an Airtable system of record, with human approval gates and cost tracked per agent. ↩
-
This is one of several application pages I have written, each for one posting, and each leads with its own gaps. ↩