Managing Context Switching When You Run Multiple Products

The real cost of running many products is not the work — it is the switching. Every jump between products pays a toll: reloading the codebase, the customer, the current thread of thought. Unmanaged, the tolls quietly consume the day, leaving you busy on six products and effective on none. We treat switching cost as a first-class engineering problem, and we attack it from both sides: make switches cheaper, and make them rarer.

Make switches cheaper: externalize the state

Expensive switching is mostly the cost of reconstructing what was in your head last time. So we never rely on the head. Every product keeps a running NOW file: what is in flight, what is decided, what the next action is, and any open question with its current best answer. Closing a work session ends with two minutes of updating that file. Reopening one starts with reading it. Resuming a product goes from a half-hour of archaeology to five minutes of reading — and the same files double as perfect context for AI agents picking up the thread.

Make switches rarer: batch by depth

• —Deep work gets one product per day. Feature work on two products in one day means neither gets real thought.
• —Shallow work gets batched across all products in a single sweep — support, metrics, small fixes — where switching is cheap because nothing is deep.
• —Never interleave the two. A support sweep in the middle of a build day costs far more than the tickets are worth.

Let automation hold the routine

Anything that runs on a schedule — metrics digests, error triage, dependency updates, first-pass support replies — is a context switch a machine can absorb instead of us. The weekly review then becomes the only place the whole portfolio needs to fit in one head at once, and its output is simply the assignment of next week's deep days.

You do not scale a portfolio by getting better at multitasking. You scale it by needing less of your mind resident in each product.