EVERY SPOKEN WORD
70 min read · 14,241 words- 0:00 – 1:45
Intro
- HSHannah Stulberg
I have spent now, like, 1,500 hours in Claude, and I'm still iterating on my setup and improving it literally every single day.
- AGAakash Gupta
So we've talked about Claude. There's Claude, there's ChatGPT, there's Cursor, there's CoWork. When should PMs be using which?
- HSHannah Stulberg
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.
- AGAakash Gupta
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?
- HSHannah Stulberg
I think the biggest mistake is give, that people give up too early.
- AGAakash Gupta
What's under-hyped versus over-hyped in AI for PM?
- HSHannah Stulberg
I think that under-hyped is following your curiosity.
- AGAakash Gupta
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?
- HSHannah Stulberg
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.
- AGAakash Gupta
You said Claude Code is the most misleading name in AI. Why?
- HSHannah Stulberg
Because it's not just for-
- AGAakash Gupta
[gentle music] 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 wanna get access to amazing AI tools, check out my bundle, where if you become an annual subscriber to my newsletter, you get a full year free of the paid plans of Maven, Arise, Relay app, Dovetail, Linear, Magic Patterns, DeepSky, Reforge Build, Descript, and Speechify. So be sure to check that out at bundle.aakashg.com. And now into today's episode.
- 1:45 – 3:50
What is a Team OS
- AGAakash Gupta
Hannah, welcome to the podcast.
- HSHannah Stulberg
Thank you so much for having me here. I'm super excited.
- AGAakash Gupta
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?
- HSHannah Stulberg
Yeah, so I think the future looks like exactly what you're saying, which is that a singular PM is gonna 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, you know, engineers are building products and maybe even pro- like, deploy- like, deploying them without a PM. Designers are prototyping and building product. And the whole... Everyone on the team is starting to make product decisions. Similarly, like, 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.
- AGAakash Gupta
So your answer to this is to create a well-organized high-context repo. I, for one, had never heard of this until I [laughs] 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?
- HSHannah Stulberg
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 team's shared context in one place that helps everybody on the team move faster, um, and do their job to the best of their abilities, especially being able to get context across many different types of functional roles. So
- 3:50 – 6:34
Live folder walkthrough
- HSHannah Stulberg
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', uh, commands, and skills that are shared by everyone on your team, which we're gonna talk about a little bit more. Then I have the product development folder, and here you're gonna 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. Um, and at the top, we have the CLAUDE.md at the root level. This is the guiding, uh, 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. Um, 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, uh, 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 Claude, or... And also to be clear, this works with any type of coding agent. It doesn't have to be Claude. Um, you could do this with Codex. You can do this in Cursor. Um, 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." And because the CLAUDE.md file is loaded every single time, it's gonna load Alex's Slack ID, and it's gonna 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," Claude knows that Taylor is your design partner and is gonna be able to better contextualize that feedback without every single time you writing, "Yes," like, "Taylor, the designer on my team, gave me this feedback." Um, 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 eng channel," and Claude will know exactly what to do.
- AGAakash Gupta
So how has your CLAUDE.md file changed over time? What have you learned in the 1,500 hours you've put in through trial and error and making mistakes?
- HSHannah Stulberg
So I think this is-This is actually what a lot of people get wrong about CLAUDE.md, which is you don't want very much in your CLAUDE.md file. So CLAUDE.mds should be very, very, very lean, especially in a team repository like this. And generally, if we start looking through the repository, um, what we see is that there's actually multiple levels of CLAUDE.md files. And so we'll see here, here's the root level. This one loads every session. The remaining files are gonna start to load progressively as you type natural language queries, which is something that we're gonna walk through. And this is really important because
- 6:34 – 8:27
Context management theory
- HSHannah Stulberg
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 different tier labs recently upped 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 to think 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. Um, 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 gonna do. But when that happens, you lose a lot of fidelity, and so you have kind of a, like, compressed summary of the information, which is much less useful. 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. Um, and if you have a lot of informa- 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 Claude read and use the right information at the right time in order to effectively work on the task at hand. Um, 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 gonna monitor how much context I'm using, um, as we write queries throughout the repo, and this is gonna help us kind of see how much context, um, is being consumed by the conversation.
- 8:27 – 11:36
Nested CLAUDE.md files
- AGAakash Gupta
Awesome. I hadn't actually seen the nested CLAUDE.md files before. So how, what do those look like inside there?
- HSHannah Stulberg
Yeah. So what we're gonna see in the repo is that the CLAUDE.mds are generally just doc indexes. So this is just telling Claude, 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, Claude would actually need to be running explore agents to, like, search the repository, um, for any queries that you write. So I actually wanna do, like, a couple examples to kind of show how this works. So in the Product folder, um, you know, one of the things we might have is who our customers are. And what's really cool about how you structured this repo is I'm gonna say, like, "Who are my top customers?" And what we're gonna see here is we're actually gonna be able to see how Claude navigates it. So it's loading these CLAUDE.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, in the Customers folder, who are my customers? What is the account context that I've stored on them? And what you can see here is that we've only used 3% of the context window, and Claude's not looking in the wrong places, right? Claude 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.
- AGAakash Gupta
Hmm. So the art of having good CLAUDE.md files is actually minimizing the amount of context that Claude needs in order to answer a given question.
- HSHannah Stulberg
It's minimizing the 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.
- AGAakash Gupta
Very cool.
- HSHannah Stulberg
Um, and we can also start to do, like, more interesting things here. So, you know, I can say, um, "What, who did I meet with over the last two weeks? Um, 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 CLAUDE.md on the customer.
- AGAakash Gupta
Mm-hmm.
- HSHannah Stulberg
And in here, this is where I'm saying, okay, what's the key con- Like, what you want in a CLAUDE.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 contacts at that customer and what do 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 Claude is, like, primed to know where to go for everything about this customer. And so now Claude's doing an analysis and saying, "Okay, today's March 25th. What was the last two weeks?" There's a lot of calls. It's gonna 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 fidelity, um, which is why the repo's 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.
- 11:36 – 13:37
Ads
- AGAakash Gupta
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 throwaway mockup. 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 LAN PM job cohort on it, and honestly, I'm up till 2:00 AM 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/aakash. That's B-O-L-T.N-E-W/A-A-K-A-S-H.Link in the show notes. Today's episode is brought to you by Jira Product Discovery. If you're like most product managers, you're probably in Jira tracking tickets and managing the backlog. But what about everything that happens before delivery? Jira 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 Jira, 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 atlassian.com/product-discovery. That's A-T-L-A-S-S-I-A-N.com/product-discovery. Jira Product Discovery, build the right thing. So some, adding some more files in the form of summaries is actually gonna help it collect the relevant information faster.
- HSHannah Stulberg
Correct. So you basically are always wanting to think about how to structure information, so that Claude can quickly and easily find what it needs to know in a format that's really easy to use. Um, which g- kind of
- 13:37 – 17:24
Shared skills and commands
- HSHannah Stulberg
goes to another topic within the repository, which is your shared agents, commands, and skills. So when, if you want struct... While LLMs, 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 are, ideally should try to organize information in a structured way for Claude so that, for example, all su- all customer call summaries follow the same format. That means that when Claude needs to do a synthesis on, like, hundreds of different of, of customer calls, they're all following the same format, which makes it much easier for Claude 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 summarize 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 Claude can work with super easily and super quickly.
- AGAakash Gupta
Hmm. 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.
- HSHannah Stulberg
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, uh, synthesize things differently.
- AGAakash Gupta
Hmm. Very cool.
- HSHannah Stulberg
Um, and so now we see, okay, we got, like, a pretty detailed analysis of the last few weeks. So it's gonna 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, um, super fast. Um, 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?"
- AGAakash Gupta
Hmm. Super powerful.
- HSHannah Stulberg
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, um, 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. Um, your roadmaps, vision docs, and then a workflow is like a multi-step repeatable process, um, that you need to do often on some cadence. And Carl has, like, a great system for getting this done that I've actually applied in a lot of my own workflows as well.
- AGAakash Gupta
Got it. And what is that system briefly?
- HSHannah Stulberg
Yeah. So basically, when you need to do, like, a complex, like, multi-step operation, um, the way to do the operation is stored in the CLAUDE.md of the folder. And it has, it's kind of similar to having a command. Um, and then there's different files that says how to execute, like, each part of the process, um, to then synthesize something into a final document. Um, and so I find this to work really well for, like, meetings where you might need to pull a bunch of different information together, um, and then put it in a document in a repeatable workflow that you want to run on some cadence.
- AGAakash Gupta
Got it. What else do we need to know about this repo if we were trying to create our own?
- HSHannah Stulberg
Yeah. So we're, we talked about the product portion. Um, and we can go to, we can go deeper into, like, what each of the different folders are and, like, what you might use in them. Um, 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 PM 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, uh, links to all your dashboards, all of your experiment analyses and the results of them, the investigations that were done, and then I think the most important
- 17:24 – 25:24
Scaling analytics
- HSHannah Stulberg
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 prototyping product to market. Um, 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, um, here we've linked all of the, um, 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, um, 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, um, 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. Um, and so we can do some pretty cool stuff here as well. So for example, I might say, I'm just gonna use, uh, Whisper Flow. Um, 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, um, what tables it comes from, and, um, it's gonna be able to give me all of this. And I think this is really important because especially if you're, once you have a, 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, um, is not always obvious.And if you don't have the right guidance for Claude, and you just point it at a database and say, "Hey, pull this stuff," it might not do it correctly. And so now here we see, okay, um, let's 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, um, and then it started reading everything about this part of the product. And then it actually was able to tell me, "Okay, 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 in, 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. Um, similarly, we could say, "Okay, 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, um, Claude is gonna be able to know, "Okay, like, how do we do this funnel analysis? Maybe this has already been investigated." It's gonna 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.
- AGAakash Gupta
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.
- HSHannah Stulberg
Exactly. So the repo is something that, like, the whole team should be building together. So, um, on my team at work, like, uh, the data scientist that I work with owns our analytics folder. And every time that we're building a new feature, we, her and I are aligning on, "Okay, 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, 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. Um, 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 wanna say, you know, "What are the metrics for the billing feature?" And you don't want Claude 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. Um, and I find this really helpful for when I'm writing a PRD, for example. I can have it, I can have Claude easily look up, like, every metric I've ever defined for my product, figure out, "Okay, which metrics might we wanna update? Which ones do we need to add in?" Because I have all that context, like, really well structured by feature in the repository.
- AGAakash Gupta
Love it. This is really speaking to kind of the future of how engineers don't wanna have to be reliant on a BM to get a data report. Here you're, 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.
- HSHannah Stulberg
Exactly. Um, 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, like, do their job effectively as our product go, g- as our product grows more and more complex.
- AGAakash Gupta
Awesome. Are there any other nooks and crannies people should know about of this repo?
- HSHannah Stulberg
So I think the repo really benefits every function, so I just put an example of, like, what you might have in an engineering folder here. So I put some bug investigations, and then we use the term RFCs for, like, 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. [laughs]
- AGAakash Gupta
[laughs]
- HSHannah Stulberg
And oftentimes in, like, the same part of the product. And so it's really helpful for the person investigating that bug to be able to see, "Okay, what are all the bugs that have happened here? What was the approach?" Or, so here, like, I saved, um, a bug investigation plan, and we can see, okay, like, 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 Claude or another type of coding agent to really effectively investigate another bug.
- AGAakash Gupta
Very powerful. And who owns basically the engineering folder, like your tech lead?
- HSHannah Stulberg
Um, so on my team, like, everyone is an owner of our knowledge repository. So each of, like, the functional leads kind of takes ownership of, like, okay, how, you know-How do we want certain things done within this area? But the team as a whole needs to agree on the way to structure the information, because LLMs don't work as well with unstructured information. Um, 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, right? Everyone should be writing shared skills that benefit the team, shared commands that benefit the team, agents that help the team. Um, we as PMs, but also everyone on
- 25:24 – 31:10
Shared automations
- HSHannah Stulberg
the team, can also set up shared automations, which I kind of think of as the third pillar 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 be- if the, 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.
- AGAakash Gupta
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?
- HSHannah Stulberg
So tactically, I only work in Claude Code these days. [laughs]
- AGAakash Gupta
[laughs]
- HSHannah Stulberg
Um, so I write every single doc first in Claude. Um, 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, like, my whole design team works in Claude, the engineers work in Claude. We're all working in the shared repository. Um, my data scientist, uh, is also working this way. Even, like... And I think... Sorry. [laughs] People think that this is only for, like, technical roles, and I think that that is a very, very wrong assumption. So actually, all of, like, 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.
- AGAakash Gupta
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?
- HSHannah Stulberg
Yeah, so you would likely, if you were me, have actually written that whole doc in Claude.
- AGAakash Gupta
Yeah.
- HSHannah Stulberg
Um, and if not, you could pull it in from a Google Doc using the MCP. Um, and then under, you'd probably have a strategy docs folder here, or I might call it, like, vision, and you can start organizing it by quarter. So I would have different folders under here, and I would say, okay, you know, Q2 2026 vision, and I would, like, have all the docs for that under there.
- AGAakash Gupta
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?
- HSHannah Stulberg
Yeah, so you would just put up a, what's called a pull request or a PR, um, 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 gonna 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 Claude is that you can have the GitHub command line interface or MCP hooked up, and because Claude knows who everyone on my team is, I'll usually j- 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 leaving Claude at all.
- AGAakash Gupta
Wow. [laughs] Actually awesome.
- HSHannah Stulberg
Um, and then because, and we, I also have, like, for my team configured that we have shared s- uh, 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. Um, so we actually, like, automated a lot of this.
- AGAakash Gupta
This is pretty mind-blowing. So you're basically saying that you don't just have a code base.
- HSHannah Stulberg
Oh. [laughs]
- AGAakash Gupta
You essentially have a code base of your team's context for Claude, and you are, like, push it, 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.
- HSHannah Stulberg
Exactly. So, like, for example, my strategy partner, uh, 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 learned. Um, and that helps us to work super, super well together. And she's completely non-technical. Um, like, she had never opened GitHub in her life two months ago, and now she is putting out PRs every single day. I think that's something that I feel, like, very passionately about. Um, 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," or, "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.
- AGAakash Gupta
And just so people who are 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?
- HSHannah Stulberg
Yeah, basically. I would also say I have an amazing [laughs] GitHub 101 guide on my Substack, um, that has helped thousands of people learn how to use GitHub confidently. So I would also probably route you to that. [laughs]
- AGAakash Gupta
Cool. What's the 60-second summary of that that I didn't cover?
- HSHannah Stulberg
Of how to use GitHub?
- AGAakash Gupta
Yeah.
- HSHannah Stulberg
So [laughs] 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
- 31:10 – 33:32
Ads
- HSHannah Stulberg
to your work.
- AGAakash Gupta
Today's episode is brought to you by the experimentation platform Kameleoon.Nine out of ten 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. Kameleoon 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, Kameleoon builds a variation of your webpage, lets you target a cohort of users, choose KPIs, and runs the experiment for you. Prompt-based experimentation makes what used to take days of developer time turn into minutes. Try prompt-based experimentation on your own web apps. Visit kameleoon.com/prompt to join the waitlist. That's K-A-M-E-L-E-O-O-N.com/prompt. 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 hit. 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 OpenAI and Anthropic? Then you might want to do a course that I've taken myself, the AI PM Certificate ran by OpenAI Product Leader Miqdad 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 gonna live build an AI product with Pavel's feedback if you take this AI PM 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
- 33:32 – 49:47
Plan mode for docs
- AGAakash Gupta
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?
- HSHannah Stulberg
Yes. So I think this type of r- 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 Claude. Um, okay, cool. So let's talk about Plan mode. Um, I'm just gonna clear this. Um, 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, Claude is gonna 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.
- AGAakash Gupta
Got it.
- HSHannah Stulberg
I want to show kind of the difference between not using Plan mode and using Plan mode. So I'm gonna split my terminals here and, um, and because we're kind of doing this, like, we have this imaginary AI prototyping company, um, I'm gonna use, like, Google Stitch as an example since they just had, like, a major release this month. So what I'm gonna put in here is I'm gonna put a basic prompt. I'm gonna say, you know, "Research the most recent Google Stitch release, and, uh, tell me about what happened." Okay. And then in here, I'm gonna 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 gonna do." And now we're gonna 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 Claude is gonna do, right? Claude is making all the decisions here. Um, and you're gonna get back something. And I really like the junior employee metaphor for Claude. So I think of working with Claude like working with, like, a really, really eager and highly talented junior employee. Um, and if you don't give that, when you have, like, a 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 gonna get back from that employee when you don't give them any guidance, and that's what basic prompting happens. Um, so you're gonna get back something, but you don't know if that something is gonna be useful for you, if it's gonna be in the format that you want. Um, and so that's why I don't generally recommend this approach. Um, so here, so there's a more lightweight version of prompting where before Claude 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 gonna assess, are you, like, generally aligned on the direction? So here, Claude 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 it's saying, "This is a significant shift in the design-to-code tooling landscape. Here's what I'd 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, um, if this is, like, competitive to what we're doing, and we should share the t- the findings in these two Slack channels. Right? And it did this. It, 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, um, you press Shift+Tab twice, and then you're gonna see that Plan mode is on.
- AGAakash Gupta
Mm-hmm.
- HSHannah Stulberg
Um, and so now I would say, um, 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 gonna start, and I'm gonna say, okay, um, research-The most recent Google Stitch release, and what I'm gonna wanna do is write a strategy doc about how this impacts us as a company and what we should do. Now, the difference between pla- You might be wondering, "Well, you know, in that other terminal, Claude gave me a proposal of what it was gonna 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, um, 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 gonna get a lot better results. But people still don't, like, totally use plan mode effectively, which is what we're gonna talk about. So now what it's saying, it's gonna research Google Stitch and my product context in parallel so that it can plan the strategy doc effectively. 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, um, you're already set up to load a lot of that context into your documents. Now we're gonna, like, wait for this to run. [laughs]
- AGAakash Gupta
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.
- HSHannah Stulberg
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 Claude, and I burned, like, hundreds of thousands of tokens, and I hit my usage limit within 30 minutes." And that's generally because people's work is not organized and optimized for Claude to easily traverse. And so you're very, very inefficient in your conversations. And look, again, Claude 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. Um, it looks like I have some information on Google Stitch. Now it's checking my writing guide, um, and my existing vision docs to understand, like, the expected tone and format. Um, 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. Um, and it's also identified that my knowledge, like what I have in the repository, is outdated because of this release. It's probably gonna suggest that I make some updates. Um, cool. So now Claude is actually using something called Ask User Question tool, where it's asking me some questions about what I wanna do here. So who is the primary audience for this doc? Um, let's just say it's for leadership. Um, and what's the focus of the doc? Um, 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 doc. Um, 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 repository updated, otherwise you have what's called context rot, which means Claude is gonna use context that's outdated.
- AGAakash Gupta
Mm-hmm.
- HSHannah Stulberg
Um, so we're gonna update those, and now it's starting to form the plan.
- AGAakash Gupta
And so when you're probably up- checking in this PR, it'll p- have two components, the strategy doc and the update to the competitive intel.
- HSHannah Stulberg
Exactly. The PR is gonna contain every single thing that I've changed in the repo as it relates to this task. Um, so now it's gonna read these, and then we're gonna kind of go into the next part of planning. Um, and I also think you actually raised a good point there, which is it is, in order for your work to be reviewable, you want to generally put like chunks of work together. So, you know, something that contains 85 file changes is gonna 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 me to merge all that information back into our central repository.
- AGAakash Gupta
Fascinating.
- HSHannah Stulberg
Um, cool. It's almost done. Now it's writing the plan. [laughs]
- AGAakash Gupta
And we're thinking with high effort here. You can change that, but I generally try to keep it at, like, the max settings. Looks like you do, too.
- HSHannah Stulberg
Yeah, I pretty much am always thinking with high effort. Um, especially, I mean, you can use medium for some stuff, but generally I've found for anything that involves, like, writing or reasoning, you're gonna get the best results with high effort, and so it's worth waiting. Um, for the purposes of this demo, I might put us down to a lower effort depending on how long some things take, um, but I also know we can cut this down. [laughs]
- AGAakash Gupta
And then I think, like, if you're feeling frustrated about that, what I usually do in this downtime is I spin up my second agent.
- HSHannah Stulberg
Yes. Yeah.
- AGAakash Gupta
And then I start doing two things at once.
- HSHannah Stulberg
So 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. Okay, 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. Um, but what you can actually do is open it up and read it. And ha- the most important part of having a good plan for Claude to execute is actually reading the plan.
- AGAakash Gupta
[laughs]
- HSHannah Stulberg
Right? If you're gonna send some- [laughs] Which I have found that not a lot of people actually do. Um, and if you're gonna, you know, send someone off to burn a bunch of your tokens and have really high usage, you, again, probably wanna 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 gonna talk about some... how we get into some more advanced planning techniques. So here, um, okay, so here it's having a structure for my strategy doc. Um, and then it's gonna update some competitive intel files. Well, you know, 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 wanna say, "Okay, actually what I wanna do is I wanna research, uh, 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, um, and help me understand, like, which publications cover these releases. I then wanna get a deeper comparison of basically how the landscape has changed, um, in or- order to inform the strategy doc. Um, 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." Um, so what I'm doing there is, like, a couple of different things. So one, Claude does not naturally parallelize plans, and I'm creating phases of work that I'm gonna have Claude start to work through. Um, and I'm kind of broadening the scope of what I'm gonna 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, like, 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 Claude before we continue to the next phase.
- AGAakash Gupta
Mm.
- HSHannah Stulberg
Um, while we're talking through this, there are some other parts in the plan that I think are very important. Um, so another part is verification. Um, so verification is how Claude knows that the work was done and done well. Um, hmm, I wish that it, it was not doing the search now. I should've prompted that differently. Um, [laughs] verification is how Claude knows that the work is done and done well. So here, what we can see here is there's actually, like, no verification on how the research is being performed. So if I was, like, doing this in real life, I might actually talk to Claude about how I want that research to be verified, right? If it's making claims, I might ask for the sources to be cited. I might ask for URLs to, like, 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, like, 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, um, and validate its own work before telling you that the work is done. So the ability to tell Claude, like, what good work looks like and how to know that the work is done is a very key part of planning. Um, I want to cancel this, and it's not gonna let me do that, so. We can see here that Claude is actually using six agents at once to do this research. Um-
- AGAakash Gupta
I'm so happy they created, like, the automatic parallel sub-agents. It's so useful. [laughs]
- HSHannah Stulberg
It is useful when this [laughs] didn't happen every time I practice this. [laughs]
- AGAakash Gupta
[laughs]
- HSHannah Stulberg
Um, but we will get there. Um, so other things that, like, I would do if this was a real plan that I was executing is I would actually go through the strategy doc structure. So, you know, 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, okay, what are the sections that I want in the doc? What is the narrative of those sections, um, in order to make sure that what I ultimately get back is what I, what I actually desired. The other thing... While we are waiting for this to run, the other concept that I'm gonna talk about is actually storing plan files within the repository. So what we're gonna kind of see is, like, when you're doing, like, a longer and more complex plan, you're gonna be putting time and effort into writing that plan. And 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, like, most of the core folders. In my strategy folder, I also have a file for plans for other strategy docs that I've written. Um, 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 gonna 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 in two months, and you don't wanna 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 agentic coding, this is also a way to track, like, the work that's in progress as coding agents are working through different parts of the plan. Um, so OpenAI actually published this recently in an article they wrote on harness engineering, where they talked about how they made the plan file first-class artifacts of the shared repository.
- AGAakash Gupta
Very cool. So you and your plans, not just the final strategy docs. When you're sh- when you're, again, checking in that PR, you'd include the plan document in there. And do, do plan documents get summaries like customer calls?
- HSHannah Stulberg
No, you don't wanna summarize the plan because you want another session to be able to build off of that plan, uh, in its entirety of every single thing that you did.
- 49:47 – 59:50
Parallel agents
- HSHannah Stulberg
write that part of the document. Um, 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 40 context files and go write a great doc.
- SPSpeaker
Hmm.
- HSHannah Stulberg
Um, 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 gonna write that section and then synthesize them all together with the orchestrating agent? Um, 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.
- SPSpeaker
Hmm.
- HSHannah Stulberg
Which you usually have to prompt Claude 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, um, to, like, compile the final synthesis, for example.
- SPSpeaker
Got it.
- HSHannah Stulberg
Um, 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 gonna save all of these, um, is how I like to invite Claude as a thinking partner. So you saw throughout the planning process that Claude was using the ask user 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 gonna show you how I do that if it will finish rewriting this. Um, 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 maybe name this, like, prompt example. And I like my work to be really pretty, [laughs] 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. Um, I usually have, like, 20 or more terminals open at a given point in time. And so if they're not, like, named and 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.
- SPSpeaker
I don't color code it or add a custom icon. I think I need to get to that level. [laughs]
- HSHannah Stulberg
Yeah, I really like picking the different icons. [laughs] Um, and sometimes I use it to, like... I have, like, you know, maybe this is, like, where I'm opening all my PR, so I'd put like a little GitHub icon or something like that. Um-
- SPSpeaker
Yeah.
- HSHannah Stulberg
But yeah, I really like, um, I like to color code to know, be able to keep track of things and then also name everything. Okay, so now I'm gonna open up the plan file again, um, and here is where I really like to invite Claude to be a thinking partner for me. So now what I'm gonna say is, um, use ask user question tool to push me on my thinking and help me consider other angles that we might wanna pull into this document, different sections that may- we might wanna add to the final doc, or other questions that you need to clarify my goals for why we're doing this.
- SPSpeaker
This is by far the most comprehensive planning process I've ever seen. [laughs]
- HSHannah Stulberg
[laughs] Um, and so now Claude is gonna ask me questions. And you can have Claude interview you, like, pretty in-depth. Like, I might say, I didn't do it for this demo, but I'm gonna say, "Take as long as you need. Ask me as many questions as you need." And we're gonna now... it's gonna start to ask me a lot more questions about what I'm trying to do here, which is gonna help us to further refine the plan. And by the time all of this is said and done, we're gonna 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 gonna change the framing depending on why we're doing this. Um, I'm gonna say this is a 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? Um, maybe there's fights that we wanna 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 wanna add in. Okay, yeah, I'm just gonna 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 gonna be done here. Um, and now it's asking me more questions. So I'm just hitting enter here for, like, the point, uh, uh, 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.
- AGAakash Gupta
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."
- HSHannah Stulberg
Yes. [laughs]
- AGAakash Gupta
Your approach is, let me spend two to three hours-
- HSHannah Stulberg
It's not always two to three hours
- AGAakash Gupta
... getting the plan right and then iterate on it.
- HSHannah Stulberg
Exactly. Um, 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 .claude folder. Um, 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. Um, and 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. Um, skills only have, like, a 70% or so, like, auto-invoke rate, and when you're gonna let something run for a long time, I don't see why you would leave anything to chance. Um, 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.
- AGAakash Gupta
[lip smacks] Yeah, I always say use X skill [chuckles] 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 gonna be super useful. It's like the value is when she has that skill, then she goes to a product review, sees some other PM at DoorDash who wrote an amazing strategy doc. She tells her skill, "Hey, I need you to go improve. Here's another good example." And then she runs a whole process using this skill, and she says, "Ah, it fell apart at this point. Go iterate and improve." And then your skill itself improves over tons of iterations.
- HSHannah Stulberg
Exactly. Um, and so yeah, now we're gonna have a much more detailed plan. I don't want anybody scared. You don't generally need to spend two to three hours planning, but-
- AGAakash Gupta
[chuckles]
- HSHannah Stulberg
... I think generally people are underplanning, 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.
- AGAakash Gupta
Mm-hmm.
- HSHannah Stulberg
Um, and so now, you know, we have a much more detailed, um, plan file, and we're not gonna 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. Um, and then kind of a last important technique is, um, oh, a couple of things. So this should... Oh, it already did the research, that's why. Um, if a plan has phases, which this one doesn't totally because we didn't fully set up having it do the full research, um, 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.
- AGAakash Gupta
Mm-hmm.
- HSHannah Stulberg
Um, so I have put in-
- AGAakash Gupta
Kind of like writing those progress markdown files that you talked about earlier.
- HSHannah Stulberg
Exactly. I usually keep this all in the plan file because the plan file gets reloaded after compaction.
- AGAakash Gupta
Mm-hmm.
- 59:50 – 1:04:22
The learning flywheel
- AGAakash Gupta
a beginner's mindset to learning and improving in Claude Code. Can you walk us through that?
- HSHannah Stulberg
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. Um, and so to do that, like, I will usually ask Claude 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 Claude is gonna, like, explain things to me. This is also how I improve what I'm doing. Um, so Claude is, like, now gonna analyze the repository, and it might tell me some things that we didn't actually cover on this podcast about what could be improved. But I think that's the point. Like, while I, you know, I've spent a lot of time using Claude Code, I'm still learning every single day. Um, and I like to use Claude to help me learn and make sure that I understand why things are working, why things are not working.
- AGAakash Gupta
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 Anthropic has shipped in the last 90 days and create a calendar of all of the features. Then I want you to go read the top Claude 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 doc, where it's going out and doing the research. And we know that a lot of Claude's data, training data, is quite stale. 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.
- HSHannah Stulberg
Yeah. And I think here's, like, another good example. Um, 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 YAML file. And so, you know, if someone was opening this repository and they didn't understand, like, why this was a YAML file, I would actually ask Claude to explain to me, like, the benefits of why this is a YAML file, um, uh, and why this structure is used, and also what a YAML file is.
- AGAakash Gupta
[laughs]
- HSHannah Stulberg
Um, [laughs] and I would use this to, like, learn along the way. So I think oftentimes, you know, I see, you know, people right now on- 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 knowing why these things work. And so I always, whenever I'm using anything, I always start by having Claude teach me why is this thing good or not good.
- AGAakash Gupta
Mm-hmm.
- HSHannah Stulberg
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. Um, and so now Claude gave me a really detailed explanation of what YAML is, why YAML is the right format for a feature index in your repository, um, and helped me to understand this topic and why this matters within the structure of the context of the repository.
- AGAakash Gupta
This is how you all should be approaching these things. You're gonna find more files that Hannah and I upload, other people upload, that you're downloading. You're gonna 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 gonna 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 Claude Code for product work?
- HSHannah Stulberg
I think the biggest mistake is, um, gi- that people give up too early. Like, I think, like learning anything new, it takes some time to learn how to use Claude effectively to get really good at using Claude Code. And like you saw, building out this type of a context repository is not something that you're gonna 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." Um, you know, I've [laughs] I've spent now, like, 1,500 hours in Claude, and I'm still iterating on my setup and improving it literally every single day.
- AGAakash Gupta
And with the pace that this team ships at, 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 Claude.
- 1:04:22 – 1:09:11
Which AI tool when
- AGAakash Gupta
There's Claude, there's ChatGPT, there's Cursor, there's Cowork. When should PMs be using which?
- HSHannah Stulberg
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. Um, I think i- 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, um, that you can leverage with any coding agent.
- AGAakash Gupta
If a PM only has two hours this weekend, what steps should they take to set up Claude Code?
- HSHannah Stulberg
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 is 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 up-level your teams.
- AGAakash Gupta
Amazing. What's under-hyped versus over-hyped in AI for PMs?
- HSHannah Stulberg
I think that under-hyped 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, um, and to, you know, get really good at whatever is being posted online on a given day. I think that we're all gonna have a lot more fun and learn better if you're following the things that you're curious about. Um, 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. Um, and then, yeah, I think that, the other thing that I think is under-hyped 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, it actually does take time and investment to, like, really learn a topic. And so I would say the other under-hyped thing is spending the time to go deep, even if that means maybe you're not learning some of these other areas right now.
- AGAakash Gupta
You said Claude Code is the most misleading name in AI. Why?
- HSHannah Stulberg
I think because it's not just for coding, which I hope is what everyone took away [laughs] from this, uh, from this podcast episode. Um, while I do code in Claude Code, most of my time is not spent coding. It's spent writing docs or doing analysis or building, uh, local HTML prototypes for my team or other types of prototypes.Um, which actually we didn't get to show on this episode. I had a really fun one built. Um, [laughs] um, but I think it is not just for coding, and it's not just for people who are technical. Anyone, like, again, like, my operations partners are also spending all day in Claude. They're contributing to our repository. It's really the, like, best tool, I think, right now for doing knowledge work.
- AGAakash Gupta
What should they have called it?
- HSHannah Stulberg
Well, that's why I called my series Claude Code for Everything.
- AGAakash Gupta
[laughs]
- HSHannah Stulberg
[laughs] Because I don't know what... I, I don't, I don't know what they should have called it. Um, I do like the name Cowork. Um, I think that was, like, a really great branding on their part. Um, [laughs] but yeah, I don't know if I have a snappy name for it.
- AGAakash Gupta
What would you tell a PM who's scared of the terminal, scared of IDEs?
- HSHannah Stulberg
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 chatbot and, like, typing into the terminal. Um, once you've done it for, like, an hour or two, you'll probably start to feel pretty comfortable.
- AGAakash Gupta
What MCPs do you need to hook your Team OS up into in order to make it effective?
- HSHannah Stulberg
Every single MCP that you can access. [laughs] Um, the limit does not exist. I am adding, like, a new MCP every couple days at this point. Um, but generally, right, most companies are gonna operate on, like, a certain tech stack, right? You're gonna 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. Claude 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 Claude.
- AGAakash Gupta
This has been a master class. I have done, I think it's seven or eight Claude 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 Claude Code. Hannah, thank you so much. If people wanna find you-
- HSHannah Stulberg
Sure
- AGAakash Gupta
... online, where should they go?
- HSHannah Stulberg
Um, they should go read my Substack, which is called In the Weeds.
- 1:09:11 – 1:10:00
Outro
- HSHannah Stulberg
You can find it at hannahstulberg.substack.com.
- AGAakash Gupta
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, subscribed on YouTube, left a rating or review on Apple or Spotify, and commented 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 insights to stay ahead in your career. Finally, do check out my bundle at bundle.aakashg.com to get access to nine AI products for an entire year for free. This includes Dovetail, Mobbin, 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.
Episode duration: 1:10:10
Install uListen for AI-powered chat & search across the full episode — Get Full Transcript
Transcript of episode 0UArKLQ6bXA
Get more out of YouTube videos.
High quality summaries for YouTube videos. Accurate transcripts to search & find moments. Powered by ChatGPT & Claude AI.
Add to Chrome