Leadership · 2024–2026
Ten products, six domains. About two decisions a month reached me.
Leading product through two acquisitions meant setting the goals, owning the space between them, and keeping an agile team moving while both the people and the scope kept changing underneath it.
Ten products, six domains. I owned one.
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 a set of 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, and 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.
The plan was the bottleneck, and the bottleneck had my name on it.
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 method 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.
Project and program 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.
We split the job three ways and agreed to fail fast.
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, and be intentional about what we delivered, and when something missed we called it fast and iterated. That did two things.
- 1. Engineering got ownership and accountability for an outcome.
- 2. Nobody waited on a plan to be re-approved before moving.
For You shipped fast and highlighted the wrong thing.
An engineer delivered the feed quickly, which was the point. The outcome was not what we set out for. 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. The platform got better even though the goal was not met. 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.
About two decisions a month reached me. The rest were theirs.
We put a small set of tools and habits in place so the team could spend 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. 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 product meeting was for challenging assumptions, reviewing the data, and working the dependencies across domains.
- 4. 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.
Three examples.
A risk I took.
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.
A 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.
A time we failed.
My CEO picked a critical vendor. We ran with it for sixty 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.