Monday morning. You're a five-person studio with twelve products live. Three are throwing crash alerts you'll have to read at some point. Two are losing retention to a competitor app update that shipped over the weekend. One has a store listing that needs refreshing by Friday or it falls out of the featured slot. There are 47 customer reviews waiting. The spend on Game 4 is somehow up 30%. Burak is asking about a roadmap call. Someone on the team is asking about Game 7. Your week starts in eight minutes.
This is portfolio operations. Nobody has written the playbook for it.
Most ops advice was written for the wrong shape
The operations canon (the books, the threads, the LinkedIn posts) assumes you run one thing. Hire a head of growth. Set up your funnel dashboard. Run your weekly product council. Pick a North Star metric.
None of that survives contact with a portfolio.
A five-person studio running twelve products is not a smaller enterprise. It is not a startup at scale. It is a different operating shape entirely: lean headcount, high product count, shallow per-product context, rich cross-product context. The headcount math means you cannot hire a head of growth for each product. The product count math means you cannot run a weekly product council for each one. The playbooks built for either shape stretch and break.
Most studios discover this around their fifth product. The first three felt manageable. The fourth was hard. The fifth made it clear: the framework that got you here cannot get you to ten.
The shape doesn't have a settled name yet. Some operators call it a portfolio. Some call it a holdco. Most just call it "we run a bunch of stuff." Whatever you call it, the operating discipline is its own thing (portfolio operations), and most of it is unwritten because it lives in the heads of operators who don't have time to write.
This post is an attempt to start writing it down. Specifically: the five places single-product playbooks fail multi-product studios, and what to do instead.
The five failure modes
1. Manual scanning eats Monday morning
The first failure is the cheapest to spot and the hardest to fix. Every morning, somebody on the team scans every product. Crash dashboards. App store reviews. Spend reports. Engagement panels. Customer support inbox.
On product one, this is the founder's job and takes thirty minutes. On product five, it is still the founder's job and takes three hours. On product twelve, it is no longer happening, and the studio is finding out about real fires in customer tickets.
Manual portfolio scanning does not scale. Not because operators are bad at it, but because the work is inherently linear in product count and the operator is one person. You can buy yourself some time with dashboards, but you cannot dashboard your way out of needing to know which of twelve product alerts actually matters.
The work that needs to happen is signal triage, and it needs to happen before the operator opens the dashboard, not after.
2. Lessons get lost between products
Three months into running multiple products, you'll have the same painful conversation twice: somebody on the team raises a problem on Game 4, and a longer-tenured teammate says "we solved this on App 2 last March." Then everyone realizes nobody can remember what the solution actually was.
Single-product orgs solve this with wikis and runbooks. Portfolio studios cannot, because the relevant lesson is buried in the context of a different product. The runbook for Game 4 doesn't have it. The runbook for App 2 has it, but only the App 2 lead reads that runbook. The cross-product memory lives in nobody's head reliably.
The fix is not a bigger wiki. The fix is institutional memory structured per-product but readable across products. Game 4's problem and App 2's solution have to be in the same shape, in the same place, by default, without anyone reformatting them.
3. Decision moments slip
Every multi-product studio has the same backlog: decisions that should have been made last Tuesday and weren't. The bid floor on Game 4 that should have been adjusted weeks ago. The store listing refresh on App 7. The retention test on Game 11 that nobody remembered to fork.
The studio isn't lacking judgment. It's lacking moments. The call that would take ten minutes if context were ready takes two hours of prep, so it gets pushed. Pushed enough times, it stops happening.
What's needed is a decision cadence: a guarantee that for each product, certain decisions happen on a predictable rhythm, with the context already assembled. Not a meeting schedule, but a contract that the moment will arrive prepared.
4. Cross-functional context fragments
In a small studio, "cross-functional" doesn't mean different teams. It means the same three people wearing three hats. The person running ads is also running the store listing is also running live-ops. They are not misaligned; they are out of phase with themselves.
The problem is the operating surface. The ad spend lives in one tool. The store listing lives in another. The live-ops doc lives in a third. Each one tells a different story about the same product on the same day. The operator is the only thing aware they're the same product.
Cross-functional context in a portfolio studio isn't about better meetings. It's about a single per-product record that the same person can read from three different hats. When the question is "what's happening with Game 4 today?", there should be one answer to read, not three to assemble.
5. Growth loops decay quietly
The most expensive failure in portfolio ops is the one nobody notices. A growth loop ships, works for two weeks, and then drifts. The retention test that was supposed to fork after the first cohort never gets forked. The monetization curve that was tuned in March drifts back to default by June. Nobody is wrong; nobody is even doing anything wrong. The loop just isn't being maintained.
In single-product ops, the founder remembers. In portfolio ops, the founder has eleven other things to remember.
A self-running growth loop is one that the system maintains awareness of: it surfaces when the loop is decaying, when its assumptions have changed, when it needs to fork. The operator still decides. The system makes sure the moment to decide doesn't slip past.
What actually works
The fixes for the five failure modes are not five separate tools. They're the same underlying shift, applied to different surfaces. Most multi-product studios that are surviving past twelve products have figured out some version of this on their own, usually painfully. Here's the shorter version.
1. The unit is the product, not the company.
Most operating tools default to a company workspace: one knowledge base, one channel, one dashboard. For multi-product studios this is the wrong default. The canonical unit of memory has to be the product. Game 4 gets its own decision record, its own signal log, its own context store. The portfolio reads across them when it needs to, but the unit is the product.
This is per-product memory. It sounds obvious; almost no off-the-shelf tool defaults to it.
2. Decisions are first-class, not documents.
Most tools record what was made. What's needed is also why it was made, what signal triggered the call, and what was considered and rejected. A decision record is not a doc. It's a structured artifact that survives the operator forgetting.
The test: three months from now, can a new teammate read the record for Game 4 and reconstruct the operator's reasoning at the time of the call? If yes, the record is doing its job. If no, the studio is going to learn the same lesson twice.
3. Cadence over capacity.
You will not solve portfolio ops by hiring. You will solve it by making sure the decisions that need to happen, happen on a rhythm the studio can sustain. Decision cadence is the contract. The work of the studio is to honor it.
4. Specialist agents, not general assistants.
The temptation, when AI tools showed up, was to ask one general assistant about everything. It didn't survive Monday morning in a real studio. What works is specialist agents: one per operating function, with scoped memory and a single job. The one watching crash reports doesn't try to write copy. The one watching store listings doesn't propose monetization changes.
The scope is the trust mechanism. A specialist agent with full memory of one function can be audited, calibrated, and reversed. A general agent with everything cannot.
5. One operating mind across the portfolio.
The five things above only work if they live in the same place. Otherwise you've just replaced twelve dashboards with twelve better ones. The point of the work is one operating mind: the same brain reading every product, the same agents acting across every line, the operator no longer the only integration layer.
A note on Qualia
This is the playbook we're building Qualia against. The product is the AI COO for portfolio operators: small studios of 2-10 people running 3-20 live games or apps. The architecture is per-product memory plus specialist agents plus a shared portfolio brain. The default is human-in-the-loop. The metric we grade ourselves on is operator boredom: if a founder reading a Qualia screen yawns, the screen is wrong.
We are early. Two customers. 30-minute setup. If you're running a multi-product studio and any of the failure modes above are eating your week, we'd like to talk. Book a demo.
Why this is unwritten
Most playbooks assume you're scaling one thing. Portfolio operators are scaling against multiplicity: more products, same headcount, no per-product slack. The work is different. So the tools have to be. And so does the playbook.
If you've found versions of this that we missed, we want to hear them.
By Doğan Turan, Co-founder, Qualia ·