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

I have spent now like 1,500 hours in quad and I am still iterating on my setup and improving it to literally every single day. So we've talked about quad. There's quad, there's chat you BT, there's cursor, there's co-work, when should PMs be using with? There's not like a right or a wrong answer, although or most advanced PM work, you should be using some type of a coding agent. Hannah Stahlberg is a PM at DoorDash and former Google APM. She spent over 1,500 dollars in cloud code, wrote the viral cloud code for everything, process and uses cloud code all day at her work. Hannah, what's the biggest mistake PMs make when using cloud code for product work? I think the biggest mistake is give that people give up too early. What's underhyped versus overhyped in AI for PM? I think that underhyped is following the curiosity. Hy 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? This is what I call team OS or team operating system, which is your team's knowledge base that helps everybody on the team need faster. You've said cloud code is the most misleading name in AI. Why? Because it's not just for- Before we go any further, do me a favor and check that you are subscribed on YouTube and following on Apple and Spotify podcasts. If you want to get access to amazing AI tools, check out my bundle. If you become an anal subscriber to my newsletter, you get a full year free of the paid plans of Robin, Arise, Relay app, Dovetail, Linear, Magic Pattern, Steep Sky, Reforge Build, Descript and Speechify. Be sure to check that out at bundled.ockustj.com and now into today's episode. Hannah, welcome to the podcast. Thank you so much for having me here. I'm super excited. 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? 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 like 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 like 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 kind of needs to have the best context that used to be kind of isolated within different roles on the team. So your answer to this is to create a well-organized high context repo. High for one had never heard of this until I saw him writing about it and talking about it. I can. Okay, cool. So this is what I call like team OS or team operating system, which is your team's knowledge base and storing all of your teams 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. So what we see here is there's three main parts of the team OS. You have the dot cloud 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 like team level documents like onboarding guides or retros. And at the top we have the clawed MD at the root level. This is the guiding route for clawed 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 clawed how to navigate the repository. So clawed 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 like key slack channels or DM groups. And the reason for this is you really when you're kind of doing all of your work in this repository, you want clawed or and also to be clear this works with any type of coding agent and doesn't have to be clawed. You could do this with codecs, you can do this in cursor. You want clawed 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. And because the clawed 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 like meeting notes because then when you're like, Oh, I got feedback from Taylor, clawed 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, like Taylor, the designer on my team gave me this feedback. And similarly for the slack channels by knowing like 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 clawed will know exactly what to do. So how has your clawed MD file changed over time? What have you learned in the 1500 hours you've put in through trial and error and making mistakes? So I think this is actually what a lot of people get wrong about clawed MD, which is you don't want very much in your clawed MD file. So clawed MDs should be very, very, very lean especially in a team repository like this. And generally if we start looking through the repository, what we see is that there's actually multiple levels of clawed MD files. And so we'll see here here's the root level. This one loads every session. The remaining files are going to start to load progressively as you type natural language queries, which is something that we're going to walk through. And this is really important because the way that this repo is structured is around the theory of context management. So I like to call this like context 101, but there's four like key concepts that you need to know about context. One is what is context context is the amount is the information that is in a given session with an LLM like what is the information that the LLM can access at a given point in time? The next is the context window, which is how much information can the LLM hold. And there's all the frontier labs recently up this to a million tokens, which sounds a little bit jargony, but basically means that it can hold seven to eight novels worth of text, which if you start thinking about it is a lot, but the amount of docs that are produced by a given team and company is a lot more than that. The next part is compaction. So when your context window gets full, all that information needs to get compressed down so that the LLM can keep going either in the conversation or in the work that it's going to do. But when that happens, you lose a lot of fidelity. And so you have kind of a compressed summary of the information, which is much less usable. And then the fourth concept is thinking room. And this is really important because thinking room is basically the difference between how much information you have in the conversation and how big the context window is. And so that is where the model can think and reason. And if you have a lot of information, the more and more information you have, just like a person, the less and less room, there is to think and reason. And so the whole repository, and so the whole repository is structured around helping, clawed, read and use the right information at the right time in order to effectively work on the task at hand. And a lot of people don't know this, but I like, so I have this little bar in my status line. And it's actually going to monitor how much context I'm using as we write queries throughout the repo. And this is going to help us kind of see how much context is being consumed by the conversation. Awesome. I hadn't actually seen the nested clawed MD files before. So what do those look like inside there? Yeah. So what we're going to see in the repo is that the clawed MDs are generally just doc indexes. So this is just telling clawed like what is in this folder and what is the purpose of it. And the reason for that is if you didn't have these doc indexes, clawed would actually need to be running explore agents like search the repository for any queries that you write. So I actually want to do like a couple examples to kind of show how this works. So in the product folder, you know, one of the things we might have is what customers are. And what's really cool about how you structure this repo is I'm going to say like who are my top customers. And what we're going to see here is we're actually going to be able to see how clawed navigates it. So it's loading these clawed MD files and using the doc indexes to navigate throughout the repository and find the exact information needed to answer my query. Right. And now it's starting to read, okay, and the customer's folder, who are my customers. What is the account context that I stored on them. And what you can see here is that we've only used 3% of the context window and clawed is not looking in the wrong places, right. Clawed didn't go into the analytics folder. It didn't go into the data engineering folder. It didn't read a single unnecessary piece of information to answer my query, which means we still have a ton of room to think. So the art of having good clawed MD files is actually minimizing the amount of context that clawed needs in order to answer a given question. It's minimizing the amount of time you're using. amount of context that's consumed and making sure that you're only consuming context that's relevant to what you are actually trying to do. Right? Like if I 'm asking about my customers, I don't need to go read a bunch of SQL queries. Very cool. And we can also start to do like more interesting things here. So you know, I can say, what who did I meet with over the last two weeks? And what did I learn? Because I store all my customer information inside the repository in a really structured manner. So if we go under my customers folder, I have a file for each of my customers. And in here, I actually have a clot MD on the customer. And in here, this is where I'm saying, okay, what's the key con like what you want in a clot MD is things that you need on 80% of sessions. And so generally for like a customer, you might want to know, okay, who are the key contexts of that customer and what are they do? What's their segment? What are and then again, I have a doc index here. This is how to find key resources on this customer account. Now, clot is like primed to know where to go for everything about this customer. And so now, clods doing an analysis and saying, okay, today is March 25th, what was the last two weeks? There's a lot of calls. It's going to read them, but actually look here at what it's reading. It's only reading the summary files. It's not going into like every single transcript, which I don't know about you, but like my customer calls can be like more than an hour, right? Claude would not be able to go and quickly and easily synthesize, you know, 50 transcripts really quickly at high finality, which is why the repo set up that it only needs to go into the transcripts if the summary doesn't have what it needs to like answer my question. Here's the dirty secret about prototyping. You spend two weeks building a prototype, you validate your assumptions, engineering loves the direction. Then what happens? You throw the whole thing away. Bolt changes this completely. When you prototype in bolt, you're not building throw away markup. You're building real front end code that integrates with your existing design system. So when you hand it to engineering, they don't throw it away. They ship on top of what you've built. I use bolt every single day. I host my land PM job cohort on it. And honestly, I'm up till 2 a.m. some days, just vibing in the tool, having fun and building. That's when you know a product is good. When you're using it past midnight, not because you need to, but because you want to check out bolt at bolt.new/acash. That's bolt.new/aksh. Link in the show notes. Today's episode is brought to you by Jura Product Discovery. If you're like most product managers, you're probably in Jura, tracking tickets and managing the backlog. But what about everything that happens before delivery? Jura Product Discovery helps you move your discovery, prioritization, and even road mapping work out of spreadsheets and into a purpose built tool designed for product teams. Capture insights, prioritize what matters, and create roadmaps you can easily tailor for any audience. And because it's built to work with Jura, everything stays connected from idea to delivery. Used by product teams at Canva, Deliveroo, and even the economist, check out why and try it for free today at at lasian.com/product-discovery. That's atlascin.com/product-discovery. Jura Product Discovery build the right thing. So some adding some more files in the form of summaries is actually going to help it collect the relevant information faster. Correct. So you basically are always wanting to think about how to structure information so that cloud can quickly and easily find what it needs to know in a format that's really easy to use, which kind of goes to another topic within the repository, which is your shared agents, commands, and skills. So when if you want well-alums like Can work really well with unstructured information, it is obviously easier if information like shares a common structure. And so teams that are using this system ideally should try to organize information in a structured way for cloud. So that for example, all customer call summaries follow the same format. That means that when cloud needs to do a synthesis on like hundreds of different customer calls, they're all following the same format, which makes it much easier for cloud to work with. And so that's why for example, you might have a customer call skill. And this and then you would have everyone on your team who's summarizing a customer call, summarizing it in exactly the same way, put it in exactly the same place. Then when you need to do cross-customer analysis, even though maybe you had 10, 15, 20 different people taking those different calls with different customers, everything is organized in a very consistent fashion that cloud can work with super easily and super quickly. So you're multiplying leverage by creating these skill files to take unstructured inputs, maybe people have different ways of interviewing, but then structure the summaries in a similar way. Exactly. So then all of your summaries come out with the exact same format, even if maybe you know your company has a ton of different account managers who would all synthesize things differently. Very cool. And so now we see, okay, we got like a pretty detailed analysis of the last few weeks. So it's going to tell me, okay, who I met with, who did, what was the customer, when did I meet with them, who was in the meeting, what happened on each of them, super fast. And then it also gave me like a quick cross-cutting theme analysis. And all of that was just off of a natural language query. I just said, you know, what happened in the last two weeks? What did I learn? Super powerful. So kind of continuing to walk through the repository. So as you can see, there's a lot of different parts that you might have in a product folder. You might have some competitive research. Maybe you have your launch emails, meeting summaries, your PRDs, processes that you need to run, context about how your product works, things for sales enablement, strategy docs. Here you might keep like business context about the company or the landscape that you're operating in, who your users are and what they need to be doing, your roadmaps, vision docs, and then workflows is actually a concept from Carl, who has also been on your podcast. These are like multi-step processes, like preparing for a bi-weekly update that you might want to run on like a, that you might need to run. Sorry, let me try it again. A workflow is like a multi-step repeatable process that you need to do often on some cadence. And Carl has like a great system for getting the STEM that I've actually applied in a lot of my own workflows as well. Got it. And what is that system briefly? Yeah, so basically when you need to do like a complex like multi-step operation, the way to do the operation is stored in the cloud and D of the folder. And it has, it's kind of similar to having a command. And then there's different files that says how to execute like each part of the process to then synthesize something into a final document. And so I find this to work really well for like meetings where you might need to pull a bunch of different information together. And then put it in a document in a repeatable workflow that you want to run on some cadence. Got it. What else do we need to know about this repo if we were trying to create our own? Yeah, so we're, we talked about the product portion. And we can go, we can go deeper into like what each of the different folders are and like why you might use them. But I think it's actually also really important to talk about the other functions as well because this is how everyone scales themselves and get the most out of the repository. I don't view the team OS as like something to help everyone become a better VM or to be better at doing product. I really view it as a way for everyone on the team to scale themselves and help everyone to leverage what's best about all of their teammates. So for example, in your analytics folder, you might have like a links to all your dashboards. All of your experiment analyses and the results of them, investigations that were done. And then I think the most important part is metrics, playbooks, queries, and schemas. So this is how you scale data analysis across the team. So I like to generally organize by topic area and then product area. So in this dummy repo, I made up a company called Forge Labs. They're bringing another AI product type in product to market. And so these are different parts of the Forge Labs product. And here we start to see, okay, so here we've outlined all of like the metrics for the billing part of the Forge Labs product. And what's and then here and what you'll see here is that here we've linked all of the dashboards that are relevant to this. And then we also have a link into where the queries are for these metrics. And then if you go under queries, under billing, then you would have all of the SQL queries for how to query the metrics related to billing. And then here in the schemas, we would have all of the table schemas that actually back these metrics. And so if I wanted to do data analysis, I would have all the references that I need as a PM to do correct analysis. And have all of like, I basically get to have access to like the analyst on my team's brain and everything that she's so amazing at and set me up for success in doing analysis correctly. And so we can do some pretty cool stuff here as well. So for example, I might say I'm just going to use whisper flow. So how do we calculate generation success rate? Show me the metric definition, the SQL query and the table schema. And so now I get to know everything about how to calculate this metric, what data tables to use, how it's defined, what tables it comes from. And it's going to be able to give me all of this. And I think this is really important because especially if you're once you have anything that's more than like a very, very early stage product, your data tables can get really complex. The right way to query different metrics is not always obvious. And if you don't have the right guidance for cloud and you just point it at a database and say, hey, hold this stuff, it might not do it correctly. And so now here we see, okay, I'm going to see if we can expand this. Yeah, so here and this kind of goes to how the repository is structured. When I put that query, in, it knew exactly what files to reference. So it went in the SQL, it went in the table schemas, it went in the metrics, and then it started reading everything about this part of the product, and then it actually was able to tell me, OK, how is this metric defined? And then what is the way to query for this? And then what is the schema that backs all of this? And if this was not like a dummy repo and like a demo instance, like you can actually have this hooked up to like Snowflake MCP or another Analytics MCP, and you could actually start having Claude do the analysis for you. Similarly, we could say, OK, you know, what do we know about why users drop off during custom domain setup? And because in the repo, I have a playbook that would be an example of what an analyst might add into the repo for how to do the funnel analysis. And so Claude is going to be able to know, OK, like how do we do this funnel analysis? Maybe this is already been investigated. It's going to find all the information in the repository, and then use that to answer my question and answer it correctly. And so we become a lot less concerned with like hallucinations, inaccurate data, inaccurate analysis, because everything that you're using as a PM to do the analysis is something that's actually been checked into the repository by an analyst or a data scientist on your team. And you know that you're using like verified approaches to get the metrics. Very cool. So you'd have like an analyst or data scientist really audit some of these playbooks and some of the table descriptions and join keys that we saw earlier. Exactly. So the repo is something that like the whole team should be building together. So on my team at work, like the data scientists that I work with owns our analytics folder. And every time that we're building a new feature, her and I are aligning on, OK, what are the metrics for this feature? What are the backing queries for the metrics? What are the tables? And then we're making sure that all of it's documented in the repository. So that when we roll out a feature, I can actually check how it's doing without being reliant on a data scientist. Or our engineers can also check on how it's doing because they're empowered with all of the queries that they need to also do like validation of the feature in production. And the organization here is really important. And there's a reason to split out like the metrics queries and schemas. And again, it goes to this theory of context management. So you might just have a question about metrics, right? You might just want to say, you know, what are the metrics for the billing feature? And you don't want Claw to then go pull all the queries and all the schemas to answer that question for you. You just want it to know what the metrics are. And I find this really helpful for when I'm writing a PRD, for example, I can have it-- I can have Claw easily look up like every metric I've ever defined for my product, figure out, OK, which metrics might we want to update, which ones do we need to add in? Because I have all that context like really well structured by feature in the repository. Love it. This is really speaking to kind of the future of how engineers don't want to have to be reliant on a PM to get a data report. Here, the PM is actually becoming the glue making sure that analytics has agreed on these are the right things, put the right things into the repository before a feature starts. But then once a feature is launched, if an engineer is on call and the whole team is asleep, they can just query it all by themselves. Exactly. And I think-- and we actually make this part of our feature launch process. So when we're rolling out a new feature, the feature is not rolled out until the repository is updated. Because that's how we know that we're continuing to create that shared context so that everyone has what they need to do their job effectively as our product grows more and more complex. Awesome. Are there any other nooks and crannies people should know about of this repo? So I think the repo really benefits every function. So I just put an example of what you might have in an engineering folder here. So I put some bug investigations. And then we use the term RFCs for technical design documents. And again, this goes to helping everyone to do their best work, helping everyone to have shared context and historical context. So you might store all the bug investigations across your product in the repository. Because unfortunately, we usually have bugs more than once, oftentimes, in the same part of the product. And so it's really helpful for the person investigating that bug to be able to see, OK, what are all the bugs that have happened here? What was the approach? Or so here, like I saved a bug investigation plan. And we can see, OK, when did this happen? What were we investigating? What was the scope? What parts of the infrastructure did it touch? How was this analyzed? What was the root cause? How was it fixed? All the data examples and all of the queries. And so then if someone has to go investigate another bug here, they have all the context of how every bug was ever investigated. And this helps them and helps them to like work with a cloud or another type of coding agent to really effectively investigate another bug. Very powerful. And who owns basically the engineering folder, like your tech lead? So on my team, everyone is an owner of our knowledge repository. So each of the functional leads kind of takes ownership of, OK, how do we want certain things done within this area? But the team as a whole needs to agree on the way to the structure, the information, because LLMs don't work as well with unstructured information. And then it becomes the onus on everyone to be updating the repository and making the team's shared context even better. And I think that this is how teams become really high performing in an AI native era is everyone is working to improve the repository to make the team faster. Everyone should be writing shared skills that benefit the team, shared commands that benefit the team, agents that help the team. We as PMs, but also everyone on the team can also set up shared automations, which I kind of think of as the third color of this. This could be, for example, using the information in the repository to run a weekly report that synthesizes all the customer research and what you learned. And with the way that this repo is structured, you can actually have that just be an automation that runs every week, synthesize all the research, post a message in your Slack channel so that everyone stays up to date on customer learnings. So I think we got the high level, the 80/20 of the setup of the repo. You check in all your day to day product work into the repo. What does that look like tactically? So tactically, I only work in cloud code these days. So I write every single doc first in cloud. And then I check it into the repo for and my team to review. And so and that's how everyone on my team works as well. So my whole design team works in cloud, the engineers working cloud, we're all working in the shared repository. My data scientist is also working this way. Even like, and I think, sorry. People think that this is only for technical roles. And I think that that is a very, very wrong assumption. So actually all of my business operations, product operations, strategy and operations partners are also participating and sharing in this shared context repository. Putting up PRs, adding their context into the repo. We're all collaborating together in this space every day. What would that look like? So where would I, let's say, I just completed the first draft of my strategy document for next quarter. What, where would I put that and how would I check that in? Yeah, so you would likely, if you or me, have actually written that whole doc in cloud. And if not, you could pull it in from a Google doc using the MCP. And then under, you'd probably have a strategy docs folder here. Or I had my call it like vision. And you can start organizing it by quarter. So I would have different folders under here. And I would say, OK, Q2, 2026 vision. And I would like have all the docs for that under there. And then when you check it in or something like that, how do I put this up into GitHub so that other people can see it? Yeah, so you would just put up what's called a pull request or a PR. And that is how you-- so first, you would commit your work. When you're ready, when all the work is ready to review, you would put up a pull request. And then you would put that up for your team to review. Generally, you'll have certain people that you would want to review certain types of work. So for example, if I'm writing a PRD that I know a certain engineer on my team is going to implement, I would put up the PRD within a pull request. And I would put them as the reviewer on the PR. And something that's really nice about doing all this in cloud is that you can have the GitHub command line interface or MCP hooked up. And because cloud knows who everyone on my team is, all usually it-- I would literally write a query that's like, put up a PR for Morgan to review this PRD with the name of the PRD. And everything would just work. Never leave in cloud at all. Wow. Actually awesome. And then because-- and we also have, like, for my team configured that we have shared commands for creating PRs and our shared commands actually auto-post a Slack message to our team's channel with, like, certain structures, depending on who put up the PR, what is the contents of the PR, who should review it. So we actually automated a lot of this. This is pretty mind-blowing. So you're basically saying that you don't just have a code base. Oh, it's-- You essentially have a code base of your team's context for cloud. And you are, like, pulling and sending PRs for that context. And it's not just PMs doing it. It's analysts doing it. Designers, engineers, go-to-market partners. Everybody is participating in that overall product team's OS. Exactly. So, like, for example, my strategy partner takes even more customer calls than I do. And she checks every customer call that she takes into the repository so that I can review what we learn. And that helps us to work super, super well together. And she's completely non-technical. Like, she had never opened GitHub in her life two months ago. And now she is putting up PRs every single day. I think that's something that I feel like very passionately about. I feel like I see a lot of chatter online, like, oh, this way of working is only for PMs or it's only for engineers. It's only for technical people. And I think that's very incorrect. I think this is something that anyone can learn how to do and that when everyone does learn how to do this We can all work so much better together and just so people We're scared of GitHub like the command at least how I do it I'm not sure how you do it is I would literally just tell it like am I logged into GitHub? Do you have access under my name? It'll say yes, and then I'll say commit this pull request for this issue and tag this reviewer all in natural language That's all you basically have to do right? Yeah Basically, I would also say I have an amazing GitHub 101 guide on my substep that has helped thousands of people learn how to use GitHub confidently So I would also probably wrap you to that cool. What's the 60-second summary of that that I didn't cover of how to use GitHub? Yep, so The 60-second summary is all of your work should be on a branch when and the process is basically you put all of your work onto a branch as you're working every time you finish a certain milestone you're gonna commit it and this means you're saying I reached a stopping point and I want to save all my work when a given item is done Let's say you know you might write your PRD in chunks and when the whole PRD is done You're gonna open a pull request and you are going to then open a pull request and ask for review This is where you would tag a reviewer They might give you some feedback that you might address and then when everything is good said and done You will merge it into the main branch which means that now everyone in all of their local repositories has access to your work Today's episode is brought to you by the experimentation platform Camille Un 9 out of 10 companies that see themselves as industry leaders and expect to grow this year say experimentation is critical to their business But most companies still fail at it. Why? Because most experiments require too much developer involvement Camille Un handles experimentation differently. It enables product and growth teams to create and test prototypes in minutes with prompt-based experimentation You describe what you want Camille Un builds a variation of your web page Let's you target a cohort of users, choose KPIs and runs the experiment for you Prompt-based experimentation makes what used to dig days of developer time turn into minutes Try prompt-based experimentation on your own web apps visit Camille Un.com/promp to join the waitlist That's K-A-M-E-L-E-O-O-N.com/promp Today's episode is brought to you by amplitude Replays of mobile user engagement are critical to building better products and experiences But many session replay tools don't capture the full picture some tools take screenshots every second leading to choppy Replays and high storage costs from enormous capture sizes others use wireframes But key moments go missing creating gaps in your understanding neither approach gives you a truly mobile experience Amplitude does things differently their mobile replays capture the full experience every tap every scroll and every gesture with no lag and no performance It's the most accurate way to understand mobile behavior see the full story with amplitude I hope you're enjoying today's episode are you interested in becoming an AI product manager making hundreds of thousands of dollars more Joining open AI and an entropic then you might want to do a course that I've taken myself the aipm certificate Ran by open AI product leader mcdad jaffer if you use my code and my link you get a special discount on this course It is a course that I highly recommend we have done a lot of collaborations together on things like AI product strategy So check out our newsletter articles if you want to see the quality of the type of thinking you'll get one of my frequent collaborators Pavel hern is the build labs leader so you're going to live build an air product with pavel's feedback if you take this aipm certificate So be sure to check that out be sure to use my code and my link in order to get a special discount and now back into today's episode Awesome that covers the main elements of the repo. I want to talk a little bit about creating high quality documents How does someone use this repo to create a 10x PRD or product strategy document? Yes, so I think this type of I think having a shared context repository helps with writing really high quality docs But that's not the only piece of the puzzle the other piece of the puzzle is knowing how to plan effectively with quad Okay, cool. So let's talk about plan load I'm just going to clear this For those who don't know clear is a way to wipe the context of your current session And it's really important to do this when you're switching tasks because again clawed is going to use the information in that conversation to guide its work And so if you're starting a completely fresh task you either want to open a different terminal window or you want to clear and wipe the context so that you're really focused only on the task at hand Got it I want to show kind of the difference between not using plan mode and using plan mode So I'm going to split my terminals here and And because we're kind of doing this like we have this imaginary AI prototyping company I'm going to use like Google stitch as an example since they just had like a major release this month So what I'm going to put in here is I'm going to put a basic prompt I'm going to say you know Research the most recent Google stitch release and tell me about what happened And then in here I'm going to say the same thing research the most Google the most recent Google stitch release Tell me about what happened and give me a proposal for what you're going to do And now we're going to kick both of these off at the same time And so here this is just a basic prompt and when you're doing this You don't really know like what clawed is going to do right clawed is making all the decisions here And you're going to get back something and I really like the junior employee metaphor for clawed So I think of working with clawed like working with like a really really eager and highly talented junior employee And if you don't give that when you have a good junior employee and they're not trained and they don't know what you like And how you like to work then you don't totally know like what you're going to get back from that employee When you don't give them any guidance and that's what basic prompting happens So you're going to get back something But you don't know if that something is going to be useful for you if it's going to be in the format that you want And so that's why I don't generally recommend this approach So here So there's a more lightweight version of prompting where before clawed does anything you just say like what is your plan Right, you're kind of asking your employee Okay, like what are you planning to do and you're going to assess Are you like generally aligned on the direction? So here clawed did a little bit of research told me what happened and it's giving me a proposal Right and it's actually using the context from the repo to generate the proposal Remember this was a completely fresh session I didn't load in any context but here at saying this is a significant shift in the design to code tooling landscape Here's what I suggest for the forge team Right, we should evaluate stitch for rapid prototyping We should see how it hooks up with our workflow We should see if this is like competitive to what we're doing and we should share the findings in these two slack channels Right, and it did this the it came to all these conclusions itself Using the context from the repository against this natural language query that I had asked Now if I was writing a doc This is still probably not what I would have wanted And so that's where we go into plan mode So to get into plan mode You press shift tab twice and then you're going to see that plan mode is on And so now I would say okay, so now let's pretend right that I need to write some maybe like a strategy doc Around this most recent Google stitch release So again, I'm going to start and I'm going to say okay Research the most recent Google stitch release And what I'm going to want to do is write a strategy doc about how this impacts us as a company And what we should do now the difference between plan you might be wondering Well, you know in that other terminal Cloud gave me a proposal of what it was going to do We could like go back and forth and keep chatting in the terminal And that is like a totally valid thing to think The difference in is that in when you're using think of LLMs are trained to have a bias for action in order to be helpful And so the goal of the LLM is to get into action to help you as the user But it's kind of like a horse that's like chomping at the bit and it's like please like let me just go run and like help you And that's not very good when you want to be in planning mode And so what plan mode does is it takes away that bias for action It's kind of like taking away the keys and saying hey, we're not going into action right now We are going to only plan and you're going to get a lot better results But people still don't like totally use plan mode effectively, which is what we're going to talk about So now to think it's going to research Google search and my product context in parallel So that it can plan the strategy doc effect and so here it's actually researching the release And it's researching my code base at the same time And this is how you can start to see that okay When you have all this context in your repository Then you're already set up to load a lot of that context into your documents Now we're going to like wait for this run It's interesting it also shows like how much potential tokens are there like 25k and 98k But it's not like burning through 130k tokens It knows where to look within those Yes and I think that's something that's really important Because I talk to people a lot who were like you know I put some queries into cloud And I've burned like hundreds of thousands of tokens And I hit my usage limit within 30 And that's generally because people's work is not organized and optimized We're clawed to easily traverse and so you're very very inefficient in your conversations And look again, cloud is only loading the stuff that's relevant to my query It didn't go into the analytics folder It didn't go into the engineering folder It went into my competitive research folder where it has access to my competitors It looks like I have some information on Google stitch Now it's checking my writing guide And my existing vision docs to understand like the expected tone informat And so we're going, you can see that Claude is already having a big head. start in probably getting to what I would want. And it's also identified that my knowledge, like what I have in the repository, is outdated because of this release. It's probably going to suggest that I make some updates. Cool. So now, Claude is actually using something called Ask Usor Question Tool, where it's asking me some questions about what I want to do here. So who is the primary audience for this doc? Let's just say it's for leadership. And what's the focus of the doc? I think that we should maybe do like a competitive analysis. I think that would be pretty interesting, or maybe we should do both. So let's just do a full talk. And then, yes, we also want to update our existing file. So this is a very important practice, which is you need to keep the context or repository updated. Otherwise, you have what's called context raw, which means Claude is going to use context that's outdated. So we're going to update those. And now it's starting to form the plan. And so when you're probably checking in this PR, it'll have two components-- the strategy doc and the update to the competitive intel. Exactly. The PR is going to contain every single thing that I've changed in the repo as it relates to this task. So now it's going to read these. And then we're going to kind of go into the next part of planning. And I also think you actually raised a good point there, which is, in order for your work to be reviewable, you want to generally put like chunks of work together. So something that contains 85 file changes is going to be really hard for anyone to review. And so generally, I like to segment my work for the person who's reviewing it. So let's say, at the same time, I might be working on a design brief for my designer. I might be working on a PRD for an engineer. And I might be updating a metrics file for the analyst on my team. I would actually open three separate PRs for those. And I would tag each different person as the reviewer on that work. That makes it much easier for the person to review and approve and then meet and merge all that information back into our central repository. Fascinating. Cool. It's almost done. Now it's writing the plan. And we're thinking with high effort here, you can change that. But I generally try to keep it at the MAC settings. Looks like you do too. Yeah, I pretty much am always thinking with high effort, especially-- I mean, you can use medium for some stuff. But generally, if I found for anything that involves writing or reasoning, you're going to get the best results with high effort. And so it's worth waiting for the purposes of this demo. I might put us down to a lower effort, depending on how long something stick. But I also know we can cut this down. And then I think if you're feeling frustrated about that, what I usually do in this downtime is I spin up my second agent. Yes, but usually I wouldn't have this downtime because I would go start working on something else. Oh, the other thing-- I'll cover this afterwards, actually. OK, so here, again, is where I see people not go right with plan mode. So these files can be pretty long. It's pretty hard to read them in the terminal. But what you can actually do is open it up and read it. And the most important part of having a good plan for cloud to execute is actually reading the plan. If you're going to send-- which I have found that not a lot of people actually do. And if you're going to send someone off to burn a bunch of your tokens and have really high usage, you, again, probably want to know what your employee is going to do. And so I will always actually read through the plan and make sure that I am aligned on it. And now we're going to talk about how we get into some more advanced planning techniques. So here-- OK, so here it's having a structure for my strategy doc. And then it's going to update some competitive Intel files. Well, if I'm writing a strategy doc, I might not just want to research this most recent release. And so what I might do is I might want to say, OK, actually what I want to do is I want to research anything that any of my competitors have shipped in the last three months. And I want you to do a sentiment analysis on the news coverage that these launches received. And help me understand which publications cover these releases. I then want to get a deeper comparison of basically how the landscape has changed in order to inform the strategy doc. And I want this research to be parallelized. Once the research is done, let's have a check-in to review it, and then we'll write the doc afterwards. So what I'm doing there is a couple of different things. So one cloud does not naturally parallelize plans. And I'm creating phases of work that I'm going to have cloud start to work through. And I'm kind of broadening the scope of what I'm going to do here so that I can get more work done at once. The other thing is like, for this plan, after the research comes through, I might want to actually review that research to sort of shape what goes into the strategy doc. So sometimes I'll create a checkpoint in the plan where I like to check in with cloud before we continue to the next phase. While we're talking through this, there are some other parts in the plan that I think are very important. So another part is verification. So verification is how cloud knows that the work was done and done well. I wish that it was not doing the search. Now I should have prompted that differently. Verification is how cloud knows that the work is done and done well. So here, what we can see here is there's actually no verification on how the research is being performed. So if I was doing this in real life, I might actually talk to Claude about how I want that research to be verified. If it's making claims, I might ask for the sources to be cited. I might ask for URLs to the news releases or something like that. It's important that I know how to check Claude's work and that Claude knows how to self verify its own work before giving it back to me. Another example of self verification is if you are building a front-end feature, for example, you can have Claude use something like playwright MCP to go in a loop and actually check the front-end and validate its own work before telling you that the work is done. So the ability to tell Claude what good work looks like and how to know that the work is done is a very key part of planning. I want to cancel this and it's not going to let me do that. So we can see here that Claude is actually using six agents at once to do this research. I'm so happy they created the automatic parallel subagents. It's so useful. It is useful when this didn't happen every time I practice. So other things that I would do if this was a real plan that I was executing is I would actually go through the strategy doc structure. So Claude is proposing a structure for this doc, but that might not actually be the way that I want the doc structured. And so I would continue to give feedback to Claude about, OK, what are the sections that I want in the doc? What is the narrative of those sections in order to make sure that what I ultimately get back is what I actually desired. The other thing, while we are waiting for this to run, the other concept that I'm going to talk about is actually storing plan files within the repository. So what we're going to kind of see is when you're doing a longer and more complex plan, you're going to be putting time and effort into writing that plan. And what teams are starting to do, what teams are starting to do is actually store the plan file itself in the repository. So what you'll see in the repository is I actually have folders for plans. And I have these in most of the core folders, like in my strategy folder, I also have a file for plans for other strategy docs that I've written. And the reason to store these in the repository is again to help speed up everyone's work and have that historical context. If you're going to spend a couple hours with Claude figuring out how to do something, you might need to do something similar again in like a month or two months. And you don't want to start from zero again. You would like to have a previous plan to reference for how you did that to save yourself time in the future. Or maybe somebody on your team needs to do something similar. And then they can go off of your plan. When you're doing agent coding, this is also a way to track the work that's in progress as coding agents are working through different parts of the plan. So OpenAI actually published this recently in an article they wrote on Harness Engine Ring, where they talked about how they made the plan file, first class artifacts of the shared repository. Very cool. So you and your plans, not just the final strategy docs, when you're, again, checking in that PR, you'd include the plan document in there. And do plan documents get summaries like customer calls? - No, you don't want to summarize the plan because you want another session to be able to build off of that plan in its entirety of every single thing that you did. And when this finishes, I'm going to show you, I might actually just pull up. I have a different, I have a pre-built plan for writing a strategy doc. Another concept that I want to talk about as it relates to planning is actually asking Claude to show you the agent prompts that it's going to use. So think about it. We're saying, okay, Claude is like a junior employee. You want to be able to check its work and understand, are you aligned on the outcome that you guys are going to achieve together? And so when Claude, as part of a plan, is kicking off other agents, now you have a junior employee, kicking off even more junior employees. And again, you might want to know how this employee is going to direct the work of the other employees because again, you might be misaligned or you might not have the same goals. And so in my plan files, I actually like on complex plans. I don't do this on every plan. I like to have Claude write out what it is going to prompt every single agent with. And so here I see the agent prompt in the plan file. What is that agent writing? It's going to use my writing guide. Okay, what's the context that this agent is going to get? What files is that agent going to read? And then how is it going to write that section? And this is really important because especially on writing tasks, if not all, agents get the same context, or if you don't know what files that agent is going to read, you don't know that they're going to have the right context to effectively write that part of the document. And the reason to split doc long doc writing across multiple agents is again because of the size of the context window. Writing is actually a pretty expensive operation, and when you're writing a very, very long form doc with all the thinking and reasoning and all the docs that you need to synthesize in order to write the doc, you generally cannot have one singular agent, you know, read already context files and go write a great doc. And so I like to be pretty directive of, okay, what are the different sections of my doc? What is the context that you need in each section? And then who's going to write that section, and then synthesize them all together with the orchestrating agent? Another big planning tip for this type of a plan is that you want all of the agents to write their output to temporary files, which you usually have to prompt on into, Claude will not do this always automatically. And so it's something that I always check for as I'm planning with Claude. And the reason for this is that two things. So again, going back to the theory of context, Claude can only hold a certain amount of information. If you have maybe 10 agents running at the same time, and they all at the same time return their work to the parent agent, everything is going to crash and you will lose all the work that you just did. And so it is very important that you have each agent actually store its work in temporary files and then have your parent orchestrating agent work off of those files to like compile the final synthesis, for example. Got it. Okay, so we finished some research. It's asking me more questions. And then the last thing that I wanted to quickly show, yes, we're going to save all of these, is how I like to invite Claude as a thinking partner. So you saw throughout the planning process that Claude was using the Ask Use Or Question tool to ask me questions that it felt like it needed to ask in order for us to build out this plan together. But what I like to do is actually invite Claude to push my thinking and help me to be like a better PM or consider things from different angles. And I'm going to show you how I do that if it will finish rewriting this. Another technique that I like to use because I find that having a lot of terminal windows open is very confusing is I actually name all of my terminals. So I would call this strategy doc. And then like I would actually you know, I would name this like prompt example. And I like my work to be really pretty. So I will also usually like change the color of them. And I also might like set an icon as well. You can set custom icons too. I usually have like 20 or more terminals open at a given point in time. And so if they're not like named in color coded, then I usually can't find my work. And I found that a lot of people like don't know that you can do this. I don't color coded or add a custom icon. I think I need to get to that level. Yeah, I really like picking the different icons. And sometimes I use it to like I have like you know, maybe this is like where I'm opening on my PR. So I put like get hub icon or something like that. Yeah. But yeah, I really like I like to color code to know be able to keep track of things and then also name everything. Okay, so now I'm going to open up the plan final again. And here is where I really like to invite cloud to be a thinking partner for me. So now what I'm going to say is use ask user question tool to push me on my thinking and help me consider other angles that we might want to pull into this document. Different sections that we might want to add to the final doc or other questions that you need to clarify my goals or why do we're doing this? This is by far the most comprehensive planning process I've ever seen. And so now cloud is going to ask me questions. And you can have cloud interview you like pretty in depth like I might say I didn't do it for the demo. But I might say take as long as you need ask me as many questions as you need. And we're going to now it's going to start to ask me a lot more questions about what I'm trying to do here, which is going to help us to further refine the plan. And by the time all of this is said and done, we're going to have a really really robust plan. Okay, so yeah, now it's saying you know what's driving the timing of this document. It's going to change the framing depending on why we're doing this. I'm just saying this strategic inflection point. And then it's saying you know there's some hard questions missing. What are other angles that we should have this doc address? Maybe there's fights that we want to walk away from. There's a lot of pushes here. So let's just cover some of those. And then it's also calling out like other areas that we might want to add in. Okay, yeah, I'm just going to say yes to this. And so yeah, now it's like pushing my thinking right. It's catching gaps in my reasoning. It's pushing me to consider you know, did I intentionally leave something out? Did I not? And now, Claude and I are getting very crisp on what is going to be done here. And now it's asking me more questions. So I'm just hitting enter here for like the point for the purposes of this demo. But usually I would read them. I would think about it. I would usually give more feedback on these questions and like usually dictate my thoughts until Claude really understands how I'm thinking about this problem. So most people they're rushing in. They're just letting it write the first draft of the strategy document. Then they're yelling at it and saying you got this wrong. You forgot this frame. Your approach is let me spend two to three hours. It's not always the plan right. Then iterate on it. Exactly. Yeah, so now it's asking me more questions. And I think the other thing which we touched on very briefly is that I have different. So I have in this repo like an example of your user level dot Claude folder. And here I have different like writing guides for different types of docs that I would write so that Claude can better write in my voice. These are just dummy guides. So whenever I'm doing writing I make sure always that in the plan the agents are given my writing guide because they might not auto invoke the skill. Skills only have like a 70% or so like auto invoke rate. And when you're going to let something run for a long time I don't see why you would leave anything to chance. And so I will always usually explicitly in the plan. If I want a certain command run or a certain skill called I will make sure that that is specified in the plan document. Yeah, I always say use x skill and triple check that that's there. The skill is like a lot of the alpha if you guys haven't realized quite yet. So those dummy ones that she has right now aren't actually going to be super useful. It's like the value is when she has that skill and she goes to a product review, sees some other PM at DoorDash wrote an amazing strategy doc. She tells her skill hey, and you should go improve. Here's another good example and then she runs a whole process using this skill and she says I fell apart at this point go iterate and improve and then your skill itself improves over tons of iterations. Exactly. And so yeah, now we're going to have a much more detailed plan. I don't want anybody scared. You don't generally dispend to the three hours planning, but I think generally people are under planning. And that's why you're not getting the output that you want because you left a lot of room for interpretation about what you were hoping to get. And so now you know we have a much more detailed plan file and we're not going to read the whole thing here, but this is where I would keep going. I would read through all the changes. I would make sure I'm aligned with them. And then kind of a last important technique is, so this should, oh, it already did the research. That's why. If a plan has phases, which this one doesn't totally because we didn't fully set up having it do the full research, I would actually outline the different phases in the plan and have Claude track when each phase is complete. This way, if you need to have a long running plan over multiple days and you have to compact or stop in the middle, Claude knows exactly how to pick up. So I have quite a lot of progress mark down files that you talked about earlier. Exactly. I usually keep this all in the plan file because the plan file gets reloaded after compaction. And what we'll notice here, so the natural plan files, they have these like really cute names from Anthropic. They all have like three words, but they are ephemeral. So they're stored in your dot Claude folder at the user level. You can actually open it up and see them, but they are wiped every 24 to 72 hours. So again, if you spend a lot of time on a plan and you want to save it, I will actually as part of that plan, usually save the plan file down so that I can reference it in the future even after the plan has been completed. So I'm likely going to be doing similar work. Does everything get a plan? Every strategy doc, every feature results right up, every PRD are some things well enough defined to be a skills in other contexts that you don't need a plan? I don't think that there's a right or wrong technique. I have generally found that anything that is relatively complex and requires synthesis or deep thinking where you want a certain output and you don't benefit from having a plan. Yeah, makes sense. And it sounds like things that you're maybe a little bit less certain about. Like we kind of approach this is like we're not exactly sure even like what's relevant about stitch and the other competitors last three month launches. So it has to go out and do that first phase. There's more undefined so that's where planning comes a little bit more useful. Sometimes you have a PRD where basically the team has already agreed on the whole feature and you have a meeting transcript, you can feed it, then you might not need as much in depth. Exactly. If it's like a pretty straightforward task, you probably don't need. And also this is a very in-depth plan file. I don't do this for like all of my work. I try to tailor the level of planning to exactly what you're saying. What is the level of complexity and ambiguity? And then the higher, the more ambiguous and the higher complexity that something is, the more time and effort you should be investing in the plan. And that's also why I showed the technique here of just asking for a lightweight alignment proposal. I have still found that just doing this, you will get a lot that it results. Because you can still be misaligned even on very like straightforward tasks. And so I I really like cloud to just quickly tell me, if there's any level of vagueness, I like cloud to tell me. what it's going to do. Usually I'll give a very quick correction and then sign on on it. And I feel like you get much better and much more consistent results with this methodology. One of the practices you have that I think is really genius is how you are applying a beginner's mindset to learning and improving in Cloud Code. Can you walk us through that? Yeah, so I think honestly getting started in these areas can be like it can feel very overwhelming and you can feel like, wow, I'm so behind and like I don't know anything. But I think it's really important to have that beginner's mindset where you just feel really comfortable asking questions. And so to do that, like I will usually ask Cloud about anything. I don't understand and ask it to teach it to me. So for example, I literally might say, you know, explain to me the benefits of why this repository is structured the way that it is and also things that could be improved about the structure. And I would like do this and then Cloud is going to like explain things to me. This is also how I improve what I'm doing. So Cloud is like now going to analyze the repository. And it might tell me some things that we can actually cover on this podcast about what could be improved. But I think that's the point. Like, well, I you know, I've spent a lot of time using Cloud Code. I'm still learning every single day. And I like to use Cloud to help me learn and make sure that I understand why things are working, why things are not working. So I use this similar prompt every day. And I will say I have a slight tweak on hers, although hers is great. So what I do is I tell it first, I want you to go research everything that I'm throwing because shipped in the last 90 days and create a calendar of all the features. Then I want you to go read the top Cloud Code influencers and the top posts that they've had in the last 90 days. Then I want you to compare my setup to the latest features and what influencers are recommending. And tell me how I can 10X my setup. And that prompt has just been huge for me because it's taking some of what we were doing with the planning on the strategy. Where it's going on and doing the research. And we know that a lot of Clod's data training data is quite still. It's like from 2024 at this point. And so it doesn't even know about its own latest features. Sometimes I find. So I think that that can also help it. Yeah. And I think here's like another good example. So what something we didn't cover in the earlier walkthrough is that I have a feature index in the repo. And it's actually a gamble file. And so, you know, if someone was opening this repository and they didn't understand like why this was a gamble file, I would actually ask Clod to explain to me like the benefits of why this is a gamble file and why this structure is used. And also what a gamble file is. And I would use this to like learn along the way. So I think oftentimes, you know, I see, you know, people right now online are like sharing their skills and commands and agents with it, which is amazing. But then people are downloading them and using them and not, you know, in why these things work. And so I always, whenever I'm using anything, I always start by having Clod teach me why is this thing good or not good? And then that also makes me more comfortable iterating on the thing because if you're just downloading and copying things and not understanding them, when it doesn't work the way that you expect, you won't know how to iterate on it or update it or improve it. And so now, Clod gave me a really detailed explanation of what YAML is. Why YAML is the right format for a feature index in your repository and helped me to understand this topic. And why this matters within the structure of the context of your repository. This is how you all should be approaching these things. You're going to find more files that HIN and I upload, other people upload that you're downloading. You're going to start cloning repos on GitHub. Make sure you do this process of learning about it. And that's why we included this segment in the episode because the beginner's mindset is really important. Now we're going to cover a couple of the hot topics to make sure that you have a really well-rounded understanding of this. So Hannah, what's the biggest mistake PMs make when using Clod Code for product work? I think the biggest mistake is that people give up too early. Like, I think like learning anything new, it takes some time to learn how to use Clod effectively to get really good at using Clod Code. And like you saw, building out this type of a context repository is not something that you're going to be able to do overnight. And so I think people try it for like a day. They don't get good results and they're like, oh, like, this isn't for me. You know, I'm I have spent now like 1,500 hours in Clod and I'm still iterating on my setup and improving it literally every single day. And with the pace that this team ships that, they're constantly adding in new features, new things. And so just staying on the top of it, there's a lot to be done in terms of that constant iteration. So we've talked about Clod. There's Clod, there's ChatchyBT, there's Cursor, there's Co-Work. When should PMs be using which? I think there's not like a right or a wrong answer, although for most advanced PM work, you should be using some type of a coding agent. I think for chat, it's generally just if you need a quick answer that doesn't need like super high context, otherwise ideally you're really building a context repository that you can use, that you can leverage with any coding agent. If a PM only has two hours this weekend, what step should they take to setup Clod Code? So what I like to recommend for people is that the single biggest piece of leverage you have is freeing up your time to learn. Like I think especially right now, the most important thing that we can be doing this learning. And so if I had two hours this weekend, my question would be what can I do to create six hours for myself next week? And I would find something to automate so that I can free up six hours to go learn things. And so generally that's what I recommend for people is you should be trying to carve out at least an hour a day to just play with AI. And in order to have that hour a day, you need to automate work in order to free up your time so that you can learn and also help to uplevel your teams. Amazing. What's underhyped, reverse overhyped in AI for PMs? I think that underhyped is following your curiosity. So I feel like there is a lot of pressure to always be on top of the exact latest news, like the exact latest release. And you know, get really good at whatever is being posted online on a given day. I think that we're all going to have a lot more fun and learn better if you're following the things that you're curious about. And so, you know, if AI eVals don't get you out of bed in the morning, like don't start there, like start with automating something that frees up your time or start with if you love design, like start playing with prototyping. And then yeah, I think that the other thing that I think is underhyped is building expertise in one area. So I think right now a lot of people are very shallow at like many different things, but it actually does take time and investment to like really learn a topic. And so I would say the other underhyped thing is spending the time to go deep. Even if that means maybe you're not learning some of these other areas right now. Why? I think because it's not just for coding, which I hope is what everyone took away from this from this podcast episode. While I do code in cloud code, most of my time is not spent coding. It's spent writing docs or doing analysis or building a local HTML prototypes for my team or other types of prototypes, which actually we didn't get to show on this episode. I had a really fun window. But I think it is not just for coding and it's not just for people who are technical. And you want like, I got like my operations partners are also spending all day in cloud. They're contributing to our repository. It's really the like best tool I think right now for doing knowledge work. What should they have called it? Well, that's why I called my series cloud code for everything. I don't know what I don't I don't know what they should have called it. I do like the name co-work. I think that was like a really great branding on their part. But yeah, I don't know if I have a snappy name for it. What would you tell a PM who's scared of the terminal, scared of IDEs? I would tell them like, don't be afraid to be a beginner again. And there's I mean, I hope what folks saw on here is in my mind, there's not a big difference between typing into a chat bot and like typing into the terminal. Once you've done it for like an hour or two, you'll probably start to feel pretty comfortable. What MCPs do you need to hook your team OS up into in order to make it effective? Every single MCP that you can access. The limit does not exist. I am adding like a new MCP every couple days at this point. But generally, right, most companies are going to operate on like a certain stack, right? You're going to have a certain set of software vendors that hopefully have either MCPs or what's often under discussed are command line interfaces or CLI tools. Cloud works really well with both of them. But the goal is any core piece of software that you use in your day to day work should be hooked up to. This has been a master class. I have done I think it's seven or eight cloud code episodes and I was learning every single minute of this one. We covered how to create a team OS, how to set up that repo, how to write really amazing documents by creating a comprehensive planning process and how to have a beginner's mindset with cloud code. Hannah, thank you so much. If people want to find you online, where should they go? They should go read my sub-sac, which is called in the leads. You can find it at hannastolberg.substac.com. Awesome. I hope you enjoyed that episode. If you could take a moment to double check that you have followed on Apple and Spotify podcasts, subscribe to YouTube, left a rating or review on Apple or Spotify and comment it on YouTube. All these things will help the algorithm distribute the show to more and more people. As we distribute the show to more people, we can grow the show, improve the quality of the content and the production to get you better in the future. sites to stay ahead in your career. Finally, do check out my bundle at bundle.akushji.com to get access to nine AI products for an entire year for free. This includes dovetail, mobin, linear, reforge build, descript, and many other amazing tools that will help you as an AI product manager or builder succeed. I'll see you in the next episode. [BLANK_AUDIO]