How I created a mobile-first platform that resulted in 3x capability for our support team.

Context

PubMatic helps app and website owners monetize through ads. The web business was the company, and web was in structural decline as third-party cookies got phased out.

Mobile was the fastest-growing channel in the company, and it was being run on a tool built for the channel that was dying.

Problem

The mobile tool wasn't built for mobile. It was the web tool with mobile screens bolted on. Developers couldn't use it themselves, so an internal support team did the work for them. Support capacity was the ceiling on mobile growth.

What I did

Pitched the standalone product, ran the working session that produced the blueprint, and led design end to end: research, IA, workflows, vocabulary, and the shift from managed service to self-serve. Stayed on it through launch and into post-launch demos with prospects in-market.

Impact

Share of mobile revenue went from 12% to 21% in year one. Support reps roughly tripled the publishers they could cover. Our largest competitor, which had previously declined to integrate with us, agreed to a partnership during the launch run-up. [VERIFY: PM confirmation on causation]

Mobile was growing. Web wasn't. Our mobile product had been built on web.

Web was the company's main business, and web was on a known decline. Third-party cookies were being phased out browser by browser, and ad revenue was going to follow. Mobile was the fastest-growing channel and the bet for where the business was going next.

The mobile product wasn't built for that bet. It was the web tool with mobile screens added on. Same one-page form. Same vocabulary built for websites. Developers said "apps," the tool said "profiles." Mobile workflows that didn't fit got handled by adding more fields to a page that already had too many.

The clearest signal the tool was broken came from inside the company. Client Service support, the team running managed service for mobile clients, were doing 90% of the work on developers' behalf. Every app launch, every pricing adjustment, every post-launch change came in as a support request, got scheduled, and got executed by a rep logged in as the developer.

That was the ceiling. Mobile could only grow as fast as we could hire support to do the work for our customers. The bet was real. The product underneath it wasn't.

The pitch nobody asked me to make.

When I started pitching the standalone product, nobody had asked me to. There was no PM brief, no leadership ask, no quarterly OKR pointing at it. The company knew mobile was its fastest-growing channel and knew web was declining. But nobody was saying the mobile product itself was the thing holding it back. So I said it.

What I brought to Redwood City.

I'd spent the prior months with the solutions engineers running managed service for mobile clients, watching where developers got stuck. That gave me the user side. I knew the business side from working in the channel: web was a declining business built on cookies that were going away, and mobile was where the growth was. And I had a loose prototype of what a separate product could look like, including the language mobile developers actually used instead of the web vocabulary the existing tool inherited.

I flew to Redwood City and spent a week in a room with the lead engineer, lead PM, and senior mobile team. We came out aligned on a separate product.

Five decisions that turned a workaround into a product.

The sitemap, the components, the flows: I did all of that. But the actual work was the decisions above it.

01

Build a standalone product, not a mobile layer.

The web tool had the wrong bones for mobile. A layer would have shipped with the same problems baked in. The Redwood City session was where I made the case for treating it as a separate product instead.

02

Use the project as the new design system's first proving ground.

We were in the middle of a brand refresh and the new design system was still building out components. A full platform refresh wasn't viable. I pitched the SDK as a long-enough, low-stakes project to be the design system's first user, which gave the standalone product an easier path to buy-in and gave the design system team a real product to build against.

03

Translate the workshop into shipped product, not a documented vision.

The Redwood City session produced alignment. Most workshops die there. I stayed with it through months of engineering iteration, then went to Korea post-launch and ran developer demos with our country manager. This one didn't.

New platform

7 visible and 4 intentionally collapsed form fields that are relevant and critical to setting up their apps

04

Design for continuous tuning, not one-time setup.

Developers didn't come once and leave. They came back weekly to swap ad networks, adjust pricing, and run experiments. I designed for the developer who came back, not the one finishing onboarding.

05

Build the vocabulary from the developer's world, not ours.

Reusing the existing platform's terms would have made the new product feel consistent with the suite. It tested badly. Tree tests, card sorts, and competitor audits gave me a vocabulary built from how developers actually talked: apps, not profiles. Optimization, not mediation.

The bet paid off.

— Prospective client, APAC market