How to build a Team OS in Claude Code with Hannah Stulberg, PM @ DoorDash

**Hannah Stulberg** (0:00)
I have spent now 1,500 hours in Claude, and I'm still iterating on my setup and improving it literally every single day.

**Aakash Gupta** (0:06)
So we've talked about Claude. There's Claude, there's ChatGBT, there's Cursor, there's Cowork. When should PMs be using which?

**Hannah Stulberg** (0:14)
There's not a right or a wrong answer, although for most advanced PM work, you should be using some type of a coding agent.

**Aakash Gupta** (0:20)
Hannah Stulberg is a PM at DoorDash and former Google APM. She spent over 1,500 hours in Claude Code, wrote the viral Claude Code for Everything process, and uses Claude Code all day at her work. Hannah, what's the biggest mistake PMs make when using Claude Code for product work?

**Hannah Stulberg** (0:36)
I think the biggest mistake is that people give up too early.

**Aakash Gupta** (0:39)
What's underhyped versus overhyped in AI for PM?

**Hannah Stulberg** (0:43)
I think that underhyped is following your curiosity.

**Aakash Gupta** (0:46)
I, for one, had never heard of this. I think it's a genius idea. Can you just unwrap the covers and show us exactly what this looks like?

**Hannah Stulberg** (0:53)
This is what I call Team OS or Team Operating System, which is your team's knowledge base that helps everybody on the team move faster.

**Aakash Gupta** (1:02)
You said Claude Code is the most misleading name in AI. Why?

**Hannah Stulberg** (1:07)
Because it's not just for...

**Aakash Gupta** (1:14)
Before we go any further, do me a favor and check that you are subscribed on YouTube and following on Apple and Spotify podcasts. And if you want to get access to amazing AI tools, check out my bundle, where if you become an anal subscriber to my newsletter, you get a full year free of the paid plans of Mobbin, Arize, Relay app, Dovetail, Linear, Magic Patterns, DeepSky, Reforge Build, Descript, and Speechify. So be sure to check that out at bundle.akashg.com, and now into today's episode. Hannah, welcome to the podcast.

**Hannah Stulberg** (1:47)
Thank you so much for having me here. I'm super excited.

**Aakash Gupta** (1:49)
So I've been thinking a lot about the future of product management, and one thing I'm noticing across companies in every geography is that PMs are supporting more and more people. One PM might have supported three or four engineers in the past. Now, they're often being asked to support 10 engineers, and on top of that, where they might have just mainly concerned themselves with design and engineering in the past, now, they have to interface with everybody. Sales, marketing, support, the list goes on and on. How are you dealing with this, and what does the future look like for PMs in this world?

**Hannah Stulberg** (2:19)
Yeah, so I think the future looks like exactly what you're saying, which is that a singular PM is going to be supporting a broader set of functional roles, and at a much higher number than in the previous team sizes. At the same time, I think we're seeing in the industry that roles are starting to merge together. So it used to be that generally all product decisions were made by the PM and then engineers were just writing code and design was just doing design. But now what we're seeing is engineers are building products and maybe even deploying them without a PM. Designers are prototyping and building products, and everyone on the team is starting to make product decisions. Similarly, as PMs, we're starting to do a lot more data analysis, also prototyping, making designs, and so we're starting to see a lot more blended functions where everyone needs to have the best context that used to be isolated within different roles on the team.

**Aakash Gupta** (3:12)
Your answer to this is to create a well-organized high-context repo. I, for one, had never heard of this until I saw you writing about it and talking about it. I think it's a genius idea. Can you just unwrap the covers and show us exactly what this looks like?

**Hannah Stulberg** (3:27)
I can. Okay, cool.
This is what I call Team OS or Team Operating System, which is your team's knowledge base and storing all of your team's shared context in one place that helps everybody on the team move faster and do their job to the best of their abilities, especially being able to get context across many different types of functional roles. What we see here is there's three main parts of the Team OS. You have the.Claude folder. This is the folder where you might put shared agents, commands and skills that are shared by everyone on your team, which we're going to talk about a little bit more. Then I have the product development folder. And here you're going to see a lot of different subfolders across different functions. And then we have a team folder where you might have team level documents, like onboarding guides or retros. And at the top, we have the Claude MD at the root level. This is the guiding route for Claude throughout your repository. And this has a few different key components. So the first is it has what's called a doc index. And this tells Claude how to navigate the repository. So Claude needs to know where to go to look up different types of information so that you can do natural language queries in the repo and get the answers that you need. The other two things that I like to have at the root level are who is on my team, along with their handles in key products, and then key Slack channels or DM groups. The reason for this is you really, when you're doing all of your work in this repository, you want Claude, and also to be clear, this works with any type of coding agent, it doesn't have to be Claude. You could do this with Codex, you can do this in Cursor. You want Claude to know who's on your team so that you can just write queries like Slack, Alex about the bug that came up on the customer call today. Because the Claude MD file is loaded every single time, it's going to load Alex's Slack ID, and it's going to be able to use the Slack MCP to send Alex a Slack. It's also really nice if you're talking about feedback or meeting notes because then when you're like, oh, I got feedback from Taylor, Claude knows that Taylor is your design partner and is going to be able to better contextualize that feedback without every single time you're writing, yes, Taylor, the designer on my team gave me this feedback. Similarly, for the Slack channels, by knowing all the channels and what the purposes are, you can write natural language queries like, hey, send this in the product channel, send this in the end channel, and Claude will know exactly what to do.