How I ran product through two acquisitions with six owners and one coupling layer.

Ten products, three product orgs, six domains, six owners. I took advertising.

Two acquisitions put ten products and three product orgs under one roof, and I led product and engineering for what came out. Five product managers came with the acquisitions. I was the sixth. The first decision was how to distribute ownership so it held up against business requirements that changed month to month.

I split it by domain: streaming and social, fintech, data lake, cloud infrastructure, advertising, and commerce. I took advertising. Each product manager owned their roadmap and their workstreams. I owned the north star, the vision and strategy, the result leadership held me accountable to, and I represented the product organization to executive leadership as one voice.

We ran priorities and dependencies as one team, because a feature in social changed what fintech had to build. We challenged each other's assumptions and argued from what the data said.

One central plan, re-ranked by me, for priorities that changed every month.

The problem I was handed was integration. The one I noticed was pace. The acquired organizations ran waterfall, with program and project management holding one central plan, and that was going to fail here. Priorities from the top changed faster than a single roadmap could be re-sequenced, so any plan we wrote was stale inside weeks, and five people were waiting on me to re-rank it.

The real change was cultural. The acquired teams had already integrated that way of working and trusted it.

Program and project management was cut before any of this settled.

Nobody was left to hold sequencing, dependencies, or assignment across ten products. The cut was a cost decision, and it was also an opening. Without a layer between a decision and the people doing the work, we could put the plan where the knowledge already sat, take a handoff out of every change, and let the team own its own sequence.

Product owned the metric, engineering owned the sequence, I owned the coupling between domains.

Product managers owned the vision, the strategy, the prototype, and the metric that defined success. Engineering owned scope and order: what got built, in what sequence, and who built it. I owned the coupling layer: strategy across domains, sequencing between surfaces, and the line that said what does not get worked on.

The trade was certainty. We agreed to ship, get to market, be intentional about what we delivered, and when something missed, call it fast and iterate. That did two things:

1. Ownership. Engineering got accountability for an outcome.
2. Pace. Nobody waited on a plan to be re-approved before moving.

For You shipped fast and promoted the wrong content.

An engineer delivered the feed quickly, which was the point. Assumptions went into the ranker unchecked, and it promoted the wrong content. That was the first test of the model, and by the goal we set, it failed.

We took that risk on purpose, and the miss still moved the number. Average session time rose a minute and a half, about 18 percent. That bought the time to do it properly: an eval suite behind the ranker and A/B testing on every change after it, so the next version was measured against a holdout.

Status automated, a five-day line on scope, one weekly meeting, and a high bar.

A small set of tools and habits, so the team spent its time on the product:

1. Status. Progress, scope and risks were automated. AI tooling over MCP pulled them from GitHub, the ticket system and Slack, so nobody wrote a status report.
2. The five-day line. Any call that added scope and moved a schedule by more than five days came to me. Everything under that line belonged to the product manager.
3. The weekly meeting. For challenging assumptions, reviewing the data, and working the dependencies across domains.
4. The bar. I held each of them to a high standard, gave them autonomy, and expected them to take risks they were willing to own. The ask was to learn, and to get uncomfortable on purpose.

A risk I took, a time I was wrong, and a failure I carried upstairs.

The risk

I put the product manager who led security and data on the creator studio. He had built our data lake, and the studio was an extension of it. The half he had to learn was the creators, what they valued and what they would never touch. He exceeded every expectation I had set.

The time I was wrong

I wanted merchants verified before they could sell. My product manager wanted them verified before they got paid, because a merchant who has not sold anything has nothing to take. We disagreed, she held her domain, and at the 30-day retro after launch the data went her way. I recognized her for both in front of the team.

The failure

My CEO picked a critical vendor. We ran with it for 60 days and it was all theory, nothing that could be demoed. The product manager had to call a failure on a decision he had not made. He triaged it and made the call, and I carried it to leadership as my own decision, post-mortem included. The recovery was a new vendor, a smaller scope, and biweekly check-ins for three weeks until we had a proof of concept.

About two decisions a month reached me.

Premium shipped on mobile and web in 20 days. Production builds went from every two weeks to twice a week. The plan lived with the people who had the knowledge, and the only calls that climbed to me were the ones that added scope.

Six owners across ten products, and a For You number measured without a holdout.

This was six product owners across ten products. It doesn't prove the split holds at sixty, where the coupling layer would need its own people.

The 18 percent on For You was measured before the eval suite and the holdout existed. It's the one number on this page I'd want a control group behind.

And the release cadence has more than one cause. The faster release cadence came with the AI transformation as much as with this operating model. That story is in How I build.