TBM 356: Product Party Modes

For some context, I’m back in the product management game as Head of Product at Dotwork. Apologies for the delay in posting — it can be hard to juggle the day job and writing! We’re definitely in the controlled chaos stage as we onboard new customers.

A simple post for this week. I’m constantly reminded of how product teams don’t function like widget factories. It’s so tempting to imagine your “capacity” as being a function of the number of developers on your team, and to rationalize “splitting” it like you’re dividing up a pie or allocating compute across containers. But the reality is so beautifully messy.

I was brainstorming today on how varied the work is, and how different types of work “drain” capacity differently.

I got a little carried away with the naming here, but think about the difference between Questing with your whole team, in it together, on an open-ended mission, and Chipping away at something you can always come back to, where you can “move the rock” a bit at a time. Or Spellcasting — summoning all of your focus alone or with one other person, completely heads-down, allergic to any interruption — versus being on Firewatch.

When you put it this way, it’s easy to see why teams get overwhelmed. Imagine if you’re on a Quest and you’re putting out a lot of Fires. That could be your whole week, done. But maybe you’re in a mode with one person Spellcasting, another Chipping, while others are Questing, and maybe someone is Trailblazing. You’re doing more at once, but the shapes of your actions are a lot more complementary.

During a recent project at Dotwork, we had to be explicit about calling out a Quest. This was our signal that everyone should jump in and help (when needed), and that it might require some messy collaboration. We acknowledged that, but also realized that someone was Trailblazing on an AI effort, someone was Spellcasting, I was doing some Mapchecking, Trailblazing, and Spotting, and meanwhile, there was a lot of Chipping during Quest downtime. It worked.

Meanwhile, I remember teams I’ve worked with that applied very strict bucket constraints—yet somehow, it never helped. I truly believe this was because it was the wrong mix. Maybe there was an incentive for all developers to work alone (perhaps everyone wanted to Spellcast, and collaboration was difficult). There was no slack to Spot or Tidying, so the debt got worse and worse.

Over the years I remember being in many different mode mixes:

You can be very dogmatic about limiting WIP and forget that humans may function well with a mix of efforts. It provides mental breaks. It allows you to change pace. You might also assume that something is only tapping “20% of the team because it’s only one person,” but vastly underestimate the net effect across the team.

Some questions to ponder:

1. What determines the right mix at any given point in time?

2. What is your team biased towards? Why?

3. How do you give yourself a mental break from continuous Questing and Firewatch?

4. Who Scouts? Should you mix that up?

5. If you don’t do any Tidying, why is that?

6. When do allocation percentages lie? Why?

---

If you currently work on a product operations team at a company with 150+ developers, engineers, PMs, etc., and you’d like to take a look at what I’m working on, I’d be happy to demo it for you. Unfortunately, because that is work related, I need to focus these calls on people actively working on product ops teams.