I build the systems marketing runs on.

The challenge

Digital campaign data at ServiceNow lived in five places that did not talk to each other: Campaign Manager 360 and DV360 for the campaigns themselves, Snowflake holding the data, Power BI for reporting, and Marketo for email operations. Each had its own login, its own metrics and its own idea of what a dimension was.

For the AdTech team that was friction. For senior executives it was a wall — they had neither the access patterns nor the bandwidth to go platform by platform, so every question became a request routed to a person. A single query like "how did this campaign perform last quarter?" could take a week to come back, by which point the decision it was meant to inform had usually been made.

My role

I brought the idea from proposal to execution and supported it end to end. To be precise about the split: the engineering team built the platform. I defined what it needed to be.

• Wrote the PRD, and translated business requirements into technical concepts the engineers could build against.
• Ran the proof of concept and the initial user testing.
• Worked directly with the real users — APAC marketers and AdTech team members — to shape how the tool should behave, rather than deciding on their behalf.
• Made sure engineering had the resources and answers it needed to keep moving.
• Ran weekly office hours after launch: answering questions, supporting adoption, and carrying enhancement requests back to engineering to be deployed.

In practice that was a product management role in everything but title.

The approach

The obvious fix for scattered data is a unified dashboard, and it would have failed the same way the platforms did. A dashboard still requires you to know where to look, which view answers your question, and what each platform means by "impression". That is precisely the knowledge a C-suite executive does not have and should not need.

So the interface became the design decision. If the user can ask in plain English, they need no map of the systems underneath — the burden of knowing which platform holds the answer moves from the person to the software. That reframing is what made it useful to executives rather than to analysts.

The second decision was to talk to the actual users early and often. The people whose week it would save were APAC marketers and the AdTech team, so they shaped it during testing and kept shaping it through office hours after launch.

What we built

The reporting stack, drawn. On a phone, scroll the diagram sideways.

A single conversational platform sitting over all five systems, built on ServiceNow's own LLM and AI agents. A user types a question — about a DV360 campaign, say — and the agent interprets it, fetches from the platform that holds the answer, and returns results as a table using that platform's own metrics and dimensions. It also reads historic data and trends to suggest how a campaign's efficiency could be improved.

What changed

• 100+ users across the Digital AdTech and MarTech teams could answer their own questions instead of filing requests.
• Quarterly business review reporting stopped being a week of manual assembly — managers pulled precise, actionable numbers when they needed them.
• Executives got answers at the speed they actually make decisions, rather than a week after asking.
• The analysts who had been pulling those reports got that week back.
• Campaign recommendations came with the data, so the tool suggested what to do next rather than only reporting what had happened.

What it taught me

Office hours turned out to matter as much as the PRD. Sitting with users every week surfaced the gap between what people said they wanted during testing and what they actually reached for once the tool was real — and that steady stream of small enhancement requests, fed back to engineering, is what moved it from a working system to one people chose to use.

It also taught me where my value sits on a project like this. I could not have built it. What I could do was hold the problem clearly enough that the people who could build it never had to guess what mattered.

The challenge

Every campaign at ServiceNow — tradeshow, roadshow, webinar, nurture, a simple list upload — began life as a copy of an existing Marketo program. That meant marketers needed access to the instance, and it meant a person had to remember the naming convention, choose the right template, keep the program inside the correct folder and set the tokens.

When someone got it wrong, nothing broke loudly. It surfaced later: a program filed in the wrong place, a token that was never set, reporting that didn't roll up, a navigation tree slowly becoming unnavigable. And the people making these mistakes were usually occasional users doing it for the third time that year.

My role

I designed and delivered the integration, and defined the program template standards it depends on.

The approach

The obvious response is more training and better documentation. I had watched that fail — a guide read once, months before it was needed, does not compete with someone in a hurry. So I stopped treating it as a knowledge problem and started treating it as a design one: if an error is possible, eventually it happens.

That reframed the goal. Not "help marketers clone programs correctly", but "remove the step where the error occurs". Which meant campaign creation had to leave Marketo and move to where marketers already were — Allocadia, where they planned the campaign budget in the first place.

What I built

An integration between Allocadia and Marketo, sitting on a governed set of Marketo program templates — one per campaign type.

What changed

• Naming conventions became consistent by construction rather than by enforcement.
• The folder tree stayed organised, so reporting kept rolling up correctly.
• Marketers stopped needing instance access, which shrank both the error surface and the permissions surface.
• Marketing operations — me — came out of the critical path for routine campaign setup.

What it taught me

The strongest governance isn't a rule people are asked to follow — it's a step they cannot skip. And adoption was almost frictionless precisely because it asked marketers to learn nothing: the work happened in a tool they already opened every week.

The challenge

Implement a complete Marketo instance from scratch, and connect it to the systems the business already ran on — Salesforce, enterprise data lakes and Magento — with nothing to inherit and nothing to copy.

My role

I owned the implementation: instance architecture, governance model, core automation, and the integrations validated end to end.

The approach

Greenfield builds are deceptive. The pressure is to show campaigns running quickly, but the decisions that determine whether an instance is still workable in year three are all made before the first campaign launches — and they are boring: naming, folder hierarchy, lead lifecycle states, who is allowed to do what.

My experience at Adobe was the direct input here. I had spent two years inside instances where those decisions were made carelessly or not at all, so I knew exactly which shortcuts would come back. I set the architecture and the conventions first, then built on top of them.

What I built

• Instance architecture and governance practices, plus the core automation workflows campaigns would be built from.
• An end-to-end Marketo–Salesforce integration, built and validated for lead synchronisation rather than assumed to work.
• Custom integrations connecting Marketo to enterprise data lakes and Magento through MuleSoft.
• An audit of the environment, with performance tuned through REST API testing and QA.

Alongside the build I supported Centre of Excellence work — RFPs, resource planning, platform enablement and a Web Personalization implementation.

What changed

• Campaigns could be launched from templates and conventions that already existed, instead of being invented each time.
• Lead data moved between Marketo and Salesforce reliably enough that reconciliation stopped being a manual routine.
• Marketing had a platform with a shape to it — one a second person could pick up and understand.

What it taught me

Architecture is mostly the decisions you make before anyone is watching, when there is no visible cost to getting them wrong and no visible reward for getting them right.

The challenge

The primary way an interested visitor could reach ServiceNow was a web form — long, tedious, and followed by silence. Every question a prospect had in the moment became a queued task for someone else to answer later, if at all.

My role

End-to-end implementation of Adobe Dynamic Chat and its integration with Marketo: setup, playbooks, and ongoing optimisation and support afterwards.

The approach

It was tempting to treat this as a form problem — shorten it, split it across steps, make it prettier. But the friction wasn't really the number of fields. It was the latency: the gap between someone having a question and someone answering it.

Shortening a form does nothing about that gap. Putting a live sales rep at the other end of it does. So the design goal became conversation in real time, with the conversation itself feeding the marketing system rather than sitting outside it.

What I built

Chatbots running on servicenow.com pages, with playbooks that qualified visitors in context and handed them to a sales representative in real time — and the interaction data flowing back into Marketo, so what someone asked about became something marketing could act on.

What changed

• Interested visitors could get an answer while they were still interested, instead of joining a queue.
• Sales reps reached prospects at the point of intent rather than days afterwards.
• Conversations became data in Marketo — lead quality improved because qualification happened in dialogue rather than in a form field.

What it taught me

Users complain about the thing they can see. The form was visible, so the form got blamed — but the actual cost sat in the silence afterwards. Finding the real constraint before optimising the obvious one is most of the job.

The challenge

During my time at ServiceNow, Adobe Experience Platform took over as the data hub sitting above Marketo. That changes more than storage. It changes where a segment is defined, which system is trusted when two disagree, and what every downstream tool is really reading from.

My role

I built the schemas and the field mapping between Marketo and AEP, built segmentation in the platform, and then took on the part that decided whether any of it mattered: getting other people able to use it.

The approach

Field mapping looks like a mechanical exercise and isn't. Two systems that have each been the source of truth for the same person hold different versions of them, and deciding which version wins is a business decision wearing technical clothing. I worked through those cases deliberately rather than mapping like for like and hoping.

The second half was adoption. A data hub that only one person can query is a bottleneck with better branding — so I built the enablement alongside the implementation, not after it.

What I built

• Schemas in Adobe Experience Platform, with Marketo fields mapped into them.
• Audience segmentation defined once in AEP and consumed downstream, rather than rebuilt per campaign.
• Lifecycle journeys in Adobe Journey Optimizer — welcome and abandoned-cart among them — personalised from AEP segments instead of from exported lists.
• Training sessions and a set of educational videos so cross-functional colleagues could work in AEP themselves.

AEP sat natively on top of the Marketo database and synced both ways, so a lead arriving from any source was stitched into the right profile and segment. From Marketo the data streamed through Kafka queues to Microsoft Dynamics and ServiceNow’s SURF CRM as sales-ready records, updating Snowflake for reporting and the MDM system for account data in parallel.

The lead-data flow, drawn. On a phone, scroll the diagram sideways.

What changed

• Audiences were defined once and reused, so two teams targeting "the same" segment were finally targeting the same segment.
• Journeys in AJO could respond to behaviour held centrally rather than to a snapshot someone exported last week.
• Colleagues could build their own segments, which removed me as a dependency and spread the platform knowledge past one person.

What it taught me

Making the videos changed how I thought about the implementation. Explaining a schema to someone who has never seen one exposes every place you accepted a convention without justifying it — I ended up simplifying things purely because they were too hard to teach.

The challenge

Building emails and landing pages was slow, and the slowness was mostly assembly rather than thinking. Generative AI was the obvious answer and also the obvious risk: a tool that writes good copy into a document still leaves someone to paste it into a template, keep it on brand, and route it through approval. That can easily cost more than it saves.

My role

I owned this one alone — I implemented and integrated Adobe GenStudio with Marketo, ran the pilot that proved out email and marketing asset generation, built the automated process behind it, then trained the cross-functional teams and wrote the step-by-step process guide.

The approach

I treated generation as the least interesting part of the problem. The question worth answering was where the output lands: if a generated email arrives as text someone has to rebuild inside Marketo, nothing has been automated — the manual work has just moved.

So the requirement I set was that output had to arrive inside existing Marketo templates, under the right campaign, already governed by the brand and compliance guidelines. Anything short of that was a demo, not a workflow. I ran it as a pilot first, deliberately, so the limits showed up while the stakes were still low.

What I built

What changed

• Marketers and the email operations team could produce assets from a prompt rather than assembling them by hand.
• Brand and compliance adherence held, because the guidelines were part of the generation step rather than a review afterwards.
• Assets landed under the correct campaign in Marketo automatically, so the speed gain didn't create a filing problem.
• Turnaround for stakeholders waiting on creative shortened noticeably.

What it taught me

With generative tools the interesting engineering is almost never the model. It is the plumbing on either side of it — where the request comes from, and where the output has to arrive for anyone to benefit.

The challenge

The AdTech team produced display creative that had to match campaign requirements before it could go live, and then be uploaded into Google Campaign Manager 360. Both halves were manual: someone reviewed each asset against a spec, and someone uploaded the approved ones. Neither task was difficult. Both were easy to hurry, and a mistake in either meant a live campaign carrying the wrong creative.

My role

I helped conceptualise and build the tool, working across the AdTech and marketing operations sides to define what it needed to catch.

The approach

Two things were worth automating here and they are different in kind. The upload was pure mechanics — a task with no judgement in it, which is the ideal candidate. The review needed judgement, which meant the tool should advise rather than decide: analyse the creative against the campaign requirements, and tell a person what to change.

Keeping those separate mattered. An AI that silently approves its own analysis and publishes the result is a much riskier system than one that flags issues and waits.

What I built

A conversational tool that analyses submitted creative, flags where it diverges from the campaign requirements, and pushes the approved version straight into Campaign Manager 360. Related work on the same track used the Marketo REST API to generate emails automatically rather than building each one by hand.

What changed

• Creative review stopped depending on how much time was left before launch.
• The manual upload step into CM360 disappeared, along with the transcription errors that came with it.
• Campaign execution moved faster because the checking and the publishing happened in one pass rather than three handoffs.

What it taught me

Automate the mechanical step completely and the judgement step only partially. The value came from being clear about which was which — a tool that suggests is adopted, a tool that overrules is switched off.