Increasing adoption by preserving campaign control

Selected work from my time as VP of Product at Pixability (2020–2024).

The problem

When I took over the Campaign Optimization Engine (COE) team, engineers were trying to rewrite a system built over years. They had little documentation and no data-science support. Working backward from the code had produced little progress.

Executives and sales were frustrated, and I needed to show progress in my first quarter. The story reaching management was that nobody used COE. Yet auto-stop, which ended campaigns on delivery, and safety pause already had 100% adoption. Other features were around 60–70%.

Preserve the choices

Campaign control

• Budget · creative
• Targeting · geography

→

Automate the work

Useful automation

• Budget-only pacing
• Auto-stop · safety pause

Internal user feedback shaped the change.

What I did

Find out why campaign managers opted out

I redirected the work toward understanding adoption before committing to the rewrite. I examined usage by feature and campaign type, then built a dashboard to show historical adoption and track subsequent changes.

I sat down with the head of operations to understand the gaps. COE could move budget toward campaigns it judged to be performing better, but clients and campaign managers wanted control over which campaigns continued, which creatives ran, and which targeting and geographies they used. Automatic reallocation could conflict with those choices.

A client could have millions invested in producing a creative and want control over how long it ran before optimization took over. The criteria for calling campaigns winners or losers were also insufficiently transparent or agreed upon. Some stories about COE going rogue did not hold up under investigation, but the need for campaign control was real.

Part of the problem was in how the system communicated. It acted first and reported afterwards: paused campaigns X, Y and Z, 0% success rate. True, and not something anyone could carry into a client conversation.

Even the most sophisticated advertisers were uneasy about an algorithm retiring creative on performance alone. The ones who had thought about it hardest ran a policy: leave it untouched for two or three weeks, then let the engine optimize. Most clients did not want to work that way at all.

The reason was not technical. A CMO who has spent a million dollars producing creative number two does not want a system telling him it is not performing, and the person who has to deliver that verdict is the one who pays for it. The model being right makes that harder rather than easier.

So the question I ended up working on was not how to make the model more accurate. It was how much of the decision the system should be taking, and when.

Automate pacing while preserving those choices

I set an end-of-quarter adoption target and prioritized the campaign types used most, balancing operations' needs against what we could change in a poorly documented codebase.

The first improvement was budget-only pacing. It automated spend pacing against the budget without requiring performance-based reallocation. We developed it with an internal advisory panel of COE users, including supporters and detractors, and released it within my first quarter overseeing the team.

I then worked through the remaining campaign types while the system continued operating. I also spearheaded improvements to auto-stop and safety pause, using multiple Google scripts to check for completed delivery or daily overspending at 15-minute intervals.

Defer the ML work that usage did not justify prioritizing

As we replaced parts of the system incrementally, a data scientist reviewed the ML predictions and found that system rules overrode most of them. Budget-only pacing, auto-stop, and safety pause drove most usage. We deferred rewriting the rules and retraining the models while improving those simpler features.

Put the engineers in the room

A senior person assigned to the project before I arrived had started blueprinting the whole system from the bottom up. It was careful work, and it could have run six to nine months without moving adoption at all.

I told the engineering leads I wanted them in the adoption conversations, and opened it to anyone on the team who wanted to come. No closed-door analysis handed over afterward as findings. There is no magic sauce, and behaving as though there is keeps the people building the thing away from the people using it.

They were reluctant. Nobody volunteers to sit in a room with users who may be unhappy about their project. That changed, and they came to look forward to it, because the users stopped being tickets and became people with a job to do.

Three things followed, and they are the reason I would do this again on any product with an adoption problem:

Requirements and specs got better, because I was no longer the only translation layer between the people using COE and the people building it.

The engineers started poking holes in commitments before they were made, which caught problems I would otherwise have promised my way into.

And the advisory panel eventually became the adoption enforcement itself, asking their own peers why something was not being used. That is the point where adoption stopped being the product manager's job.

The outcome

• The first release increased adoption by 25 percentage points, exceeding its target.
• Budget-only pacing eliminated daily manual budget adjustments. It eventually exceeded 90% adoption across 80% of campaign types.
• Observed campaign stopping time fell from 60–90 minutes to approximately 15 minutes, reducing overspend.

Before leaving, I built a solution for the remaining campaign types. Its subsequent adoption is not included in these results.