product ownership at platform scale
Most product ownership happens with the platform already yours to hold. I've spent the last decade doing the harder version — agency-side, forward deployed, governing a platform I didn't start out with the keys to.
what it actually means
Product ownership at scale is not writing tickets. It's owning what gets built and why — the architecture direction, the roadmap, the decision rights on prioritization — and staying close enough to the system to know when it's working. I hold that for the Lexus.com platform: one roadmap across eight teams and a 98-person digital organization, serving roughly 7–8M monthly users.
why agency-side is the harder game
A client-side product owner inherits authority from the company they sit inside. Agency-side, you own the outcome without owning the org — you have to earn decision rights across a client and a production-led agency that were both built to move work through, not to govern a platform. When I came in as the first agency-side product owner at Team One, the role didn't exist yet. Agencies ship campaigns; nobody had asked one to own a platform. The Build & Price rebuild — backend services through an Unreal Engine asset pipeline, JD Power best in class across all OEMs — was the proof that they can.
forward deployed — same hands
The industry has started calling this work forward deployed: embedded with the client, shipping production systems, training the org on adoption. The part most leadership resumes can't say is that I build the thing myself. I write the specs, define the data models, and ship the production tools — 17 of them, on an internal AWS container platform — through agentic workflows, on 14+ years of hand-written code underneath. The leadership and the making are the same hands, not two roles passed between people.
governance is the point
Governance here isn't process for its own sake — it's decision lanes, clear guardrails, and prioritization clarity that let a lot of people build in the same direction without a bottleneck. I founded the product owner discipline at Team One and scaled it from one seat to a governed team of six, treating the discipline itself as a designed system: the same governance, guardrails, and ownership lanes I apply to code, applied to people instead. Innovation without governance is just noise.
the proof, not the claim
Every claim here traces to shipped work — founding the product owner discipline (one role into a governed team of six) and the Lexus & Toyota Build & Price rebuild (agency-side platform ownership, JD Power best in class). The insights index is the 90-second version of how I decide what to build.
questions people actually ask
What is agency-side product ownership?
Product ownership practiced from the agency side of the table — owning a platform's roadmap, architecture direction, and decision rights, not just delivering a campaign against someone else's spec. At Team One I was the first agency-side product owner; the role didn't exist before that program, because agencies ship campaigns and nobody had asked one to own a platform.
Why is agency-side product ownership harder than client-side?
Because you own the outcome without owning the org. A client-side product owner inherits authority from the company they sit inside; agency-side, you have to earn decision rights across a client and a production-led agency that were both built to move work through, not to govern a platform. You install the guardrails and the ownership lanes yourself, from a seat that starts with influence and no formal authority.
What is a forward-deployed product leader?
A product leader embedded with the client who ships production systems and trains the org on adoption — the pattern the labs call the forward-deployed engineer, applied to product leadership outside a lab. In practice it means I write the specs, define the data models, and build the production tools myself — 17 of them on an internal AWS container platform — instead of handing a deck to someone else to build.
Can an agency own a platform, not just campaigns?
Yes — that was the thesis I got to prove. Leading the Lexus and Toyota Build & Price rebuild end to end, from backend services to an Unreal Engine asset pipeline, showed an agency operating with real product governance: owning architecture, prioritization, and the roadmap. It earned JD Power best in class across all OEMs. Agencies can own platforms, not just the work that runs on them.
What does platform governance at scale look like?
One roadmap across eight teams and a 98-person digital organization, for a platform serving roughly 7–8M monthly users. Governance here isn't process for its own sake — it's decision lanes, clear guardrails, and prioritization clarity that let a lot of people build in the same direction without a bottleneck. Innovation without governance is just noise.
How do you build a product owner discipline from scratch?
You treat the discipline itself as a system to be designed — governance, guardrails, and ownership lanes applied to people instead of code. I scaled the product owner function at Team One from a single seat to a governed team of six, with prioritization standards, roadmap governance, and training for incoming POs built in from the start.
What makes a builder-leader different from a traditional product manager?
A builder-leader stays close enough to the system to build it. I've been the designer, the frontend developer, the product owner, and the strategist, so I can write the spec and then ship the production tool against it through agentic workflows — on 14+ years of hand-written code underneath. The leadership and the making are the same hands, not two roles passed between people.