Product Thinking Podcast — Episode 242: Why Context Switching Slows You Down

Host: Melissa Perri
Date: September 5, 2025

Episode Overview

This episode tackles a prevalent issue in product organizations—multiple product managers (PMs) sharing a single development team and the resultant productivity losses from constant context switching. Melissa Perri responds to a listener’s question about managing this dynamic and explains why context switching can dramatically slow delivery, diminish quality, and frustrate both PMs and developers. She also provides actionable strategies for product leaders to address these organizational bottlenecks.

Key Discussion Points and Insights

The Listener Question & Commonality of the Problem (02:41)

• Listener’s Scenario: Several PMs share a developer team of 7, rotating them each sprint between three product areas—wondering if this is common and if delivery will suffer.
• Melissa’s Response: This scenario is “more common than it should be,” particularly in smaller or rapidly growing companies with insufficient staffing.
• “Your instinct about delivery slowdown… is completely spot on. And this isn't just a product management problem, it's an organizational efficiency problem that's going to affect everyone.” (04:10)

Why Context Switching Kills Productivity

Technical and Product Context Loss (05:00)

• Developers switching between several domains “have to get back up to speed on it”—not only technically, but also understanding user needs and strategy.
• Analogy: “Think of it as asking a writer to… switch between writing a romance novel and then a technical manual and then a legal brief every, like few weeks. That cognitive load is just really enormous.” (06:17)

Quantifying the Cost (07:05)

• Referencing research: It takes “15 to 25 minutes to fully refocus after switching tasks.” In development, it could mean “hours or even days.”
• Companies could lose “20 to 30% of your team’s productivity on just overhead here.” (07:40)

Impact on Ownership and Quality (08:05)

• Lack of long-term ownership makes teams less likely to streamline, fix bugs, or deliver improvements. Miscommunication becomes more likely.

Ideal Team Structure and Leadership Responsibilities

The Need for Dedicated Teams (09:20)

• Best practice: “Dedicated teams focused on these specific areas for extended periods.”
• Even with a small team, allocation can be made so certain developers focus on specific product areas.

The Role of Engineering Leadership (10:10)

• Engineering leads should assess strengths, workload, and area criticality, then “distribute the team appropriately.”
• “That’s going to be way better than… everybody switching everything all the time.” (11:05)

Ownership Creates Accountability (11:40)

• With clear domain ownership, teams “have deeper product thinking… make decisions on their own… go a lot faster.”

The Product Manager to Developer Ratio Problem

Notable Ratio Guidance (12:30)

• “You have way too many product managers for the amount of developers you have. If you had that much work… you should hire more developers.”
• Ideal ratios: 1 PM per 5-7 (sometimes up to 9) engineers, not 3 PMs for 7 devs.

Pushing for Change (13:30)

• Use data (cycle time, bug rates, delivery delays) to show leadership the cost of context switching.
• “That’s where you have to use your product management sense and your negotiation tactics and your influence… to get them to see that not all of this can be accomplished with the size team that you have.” (15:20)

Tools for Making the Case

Data-Driven Advocacy (16:45)

• Track how long tasks wait in queues, the cost of handoffs, and time needed to reach productivity after switches.
• “Start measuring the real cost of how you’re operating right now.” (17:30)

Developers as Allies (18:00)

• Ask developers about their experience and preferences: “Have a conversation with them about this. Look at velocity differences… if you have an area where people are focused versus where they're switching, you can use that as well.” (18:40)

Presenting Options to Leadership (19:10)

• Present trade-offs: need to hire, rescope, or dedicate developers more purposefully.
• “Present these options to leadership so that they can make the informed choice.” (19:50)

The Impact on Startups and How to Move Forward

• “In a small company, you cannot afford that. Startups win on speed, right? That’s what we’re doing.” (20:20)
• Teams should be able to go deep in an area for “at least a year… in a startup, maybe… 3–6 months, but you want them to be able to go deep.” (20:45)

Memorable Quotes & Moments

• On Cognitive Load:
  “Think of it as asking a writer to… switch between writing a romance novel and then a technical manual and then a legal brief every, like few weeks. That cognitive load is just really enormous.” (06:17)
• On Productivity Loss:
  “You’re probably losing like 20 to 30% of your team’s productivity on just overhead here.” (07:40)
• On Team Ratios:
  “That is not a typical ratio. We typically would see one product manager to every, I’d say, five to seven engineers… Three to seven is like, that's an insane ratio.” (12:17)
• On Advocacy:
  “Present these options to leadership so that they can make the informed choice. Present the trade offs. Present all of this stuff so that you can get the buy-in you need.” (19:50)
• On Startups:
  “In a small company, you cannot afford that. Startups win on speed, right? That’s what we’re doing.” (20:20)

Key Actionable Takeaways

• Avoid rotating developers frequently between vastly different areas; instead, assign them for longer periods (ideally a year, or at least several months).
• Leverage engineering leaders to distribute team focus according to criticality and strengths.
• Use data (lost time, bug rates, velocity dips) to advocate for more staff or process changes with leadership.
• Engage developers in building the case for reducing context switching and improving team structure.
• Aim for industry-standard PM/Engineer ratios (1:5–7); restructure or hire as necessary when out of balance.

Timestamps for Important Segments

• 02:41 — Listener question introduction
• 05:00 — Cognitive burden of context switching
• 07:05 — Research on lost productivity and time
• 09:20 — Why dedicated teams matter
• 10:10 — The role of engineering leadership
• 12:17 — Guidance on PM/Developer ratios
• 16:45 — How to measure and present lost productivity
• 19:10 — Strategies for influencing leadership
• 20:20 — The impact on startups and moving forward

By the end of the episode, listeners gain a nuanced understanding of why shared dev teams slow productivity, how to advocate for better structures, and practical frameworks to communicate these challenges upstream. Melissa’s pragmatic answers and actionable advice make this an essential episode for product managers navigating organizational growing pains.