Editor: Yucheng
If you want to know how the top teams in the AI world are pushing themselves, Anthropic is definitely the "king of grind."
Recently, Cat Wu, the product lead for Claude Code and Cowork, appeared on the well-known podcast Lenny's Podcast. As the driving force behind Claude Code, she shared quite a few "exclusive secrets" from inside Anthropic. After reading this, you might exclaim: so this is what a top AI company looks like from the inside!
Within Anthropic, Claude Code's founder, Boris Cherny, is responsible for looking to the stars and proactively predicting future product forms, while Cat Wu is responsible for keeping feet on the ground and coordinating across departments to turn the vision into reality.
In Cat Wu's view, the core competency of a product manager (PM) in the AI era is shortening the time from idea to delivery to the user and defining the core "out-of-the-box" tasks. In the past, PMs were used to making 6-to-12-month roadmaps, but now, inside Anthropic, a feature can go from concept to launch in just a single day!
This rapid iteration isn't just supported by the powerful Mythos model but, more importantly, by a release process stripped down to the bare essentials. At Anthropic, every team member is fully "empowered" to transform ideas from inception into reality.
She also revealed that all professional roles at Anthropic are converging. In Cat Wu's own words, "PMs are doing engineering work, engineers are doing PM work, and designers are doing product management and committing code." This convergence places higher demands on talent, and the most scarce skill right now is "excellent product taste."
Many people are curious about how Anthropic managed to overtake the competition. Cat Wu's answer: the unified mission of the team members. When hiring, they only look for "people who care most about bringing safe AGI to all of humanity." She even stated that sacrificing her own product line (like Claude Code) for the company's overall AI safety mission is a trade-off she'd be completely happy to make!
In the interview, Cat Wu didn't dodge recent controversies. Regarding the source code leak incident, she mentioned it was human error when an employee was using Claude to write a PR, pointing to a process vulnerability. The employee was not fired, and protective measures have since been implemented.
On the issue of blocking OpenClaw from using Claude, Cat Wu explained that because the subscription plan for Claude Code wasn't designed for third-party products, and they need to prioritize their own first-party products and API, they took such measures.
This podcast contained many brilliant insights. The original interview transcript is as follows:
Boris Cherny excels at setting goals, while Cat Wu is responsible for cross-departmental collaboration to execute them
Lenny: Cat, welcome to the podcast.
Cat Wu: Thanks for having me.
Lenny: I have so many questions, and I'm very excited to have you here. I want to start by helping people understand the division of labor between you and Boris. Everyone knows Boris; his episode was the most popular on this podcast, no pressure. He created Claude Code, leads the team, and even submits countless PRs from his phone every day. I don't even know what that number is now. I feel like people don't give you enough credit for Claude Code, Cowork, and everything you're building. Help us understand your role within the team, how you collaborate with Boris, and how you divide responsibilities. What specifically does the PM role look like on the Claude Code team?
Cat Wu: I feel very lucky to be working with Boris; he's been a wonderful thinking partner. He is our tech lead and, to a large extent, the product's visionary leader. He is very good at setting goals, like "what the product should look like in three or six months"—in other words, the "AGI pill version" of the product. A big part of my role is figuring out how we get from our current state to that 3- to 6-month-out vision. I spend more of my time on cross-functional collaboration, ensuring that our marketing, sales, finance, and compute resource teams all buy into the plan, ensuring everyone is aligned in heart and effort, and making sure there are no obstacles to the launch process once a feature is ready. I think we work well together in many ways because we've achieved a kind of "mind meld" to some degree, but the boundaries are actually very blurred. I'd say we're synced about 80% of the time on ideas. For the remaining 20%, there are things I care more about than he does, so I take the lead there; and for another 20% that he cares more about, he drives those forward.
Anthropic's criteria for hiring PMs: ability to shorten timelines and define core features
Lenny: Before we started recording, you mentioned you've been interviewing hundreds of PMs. If I had a nickel for every time someone asked me to introduce them to Anthropic for a PM role, I'd probably have $30 billion in ARR by now. It's just the place everyone wants to work. So I can only imagine how many people you've interviewed. You told me you've found that many people are getting it wrong, their understanding of "how to be a successful AI PM" is off. Talk about what you're seeing, and what people need to understand about the recipe for success right now.
Cat Wu: I think before AI, technology iterations were much slower. So you could plan on a 6 to 12-month time horizon. Because the velocity of shipping features was slower, you put more emphasis on aligning with other partner teams, ensuring the features they shipped could pave the way for you, because the cost of writing code in that era was very high. I believe that now, with AI, as engineering efficiency accelerates and model capabilities improve, the development cycle for many of our product features has shortened from 6 months to 1 month, sometimes even a week or a day. Consequently, we need to ensure products can be released very quickly. This means that, as a PM, the focus should no longer be on aligning your multi-quarter roadmap with partner teams, but much more on: how do we figure out the fastest way to get something to market? How do we create a "concept corner" for the product suite, so that if an engineer or PM has an idea, it can be in users' hands by the weekend? I think the PMs who perform best on AI-native products are those who can shorten the time from "idea generation" to "delivering to users" and can define the most core, out-of-the-box required tasks for the product.
The PM's role in enabling the team to move fast: clear goals, repeatable launch process, building the product development system
Lenny: I love that point you made, that people haven't yet realized how fast they need to move, and that the role, to a large extent, is now "helping the team move fast." How do you actually do that? Besides having the most advanced models, what else have you and your PM team done to help people move this quickly?
Cat Wu: I think the first thing is setting clear goals. Because LLMs are so general-purpose, it actually creates a lot of ambiguity around "who are we building for," "what problem are we solving," and "what is the core use case." Therefore, a good PM is able to say: "OK, our core user is the professional developer; the main problem we want to solve with this feature is permission prompt fatigue; our goal is to enable professional developers at enterprises to safely achieve 'zero permission prompts'." This sets a very clear goal because it rules out many potential solutions for reducing prompt sounds and focuses on enabling people to do more work per prompt.
The second very important thing is establishing a repeatable launch process. For Claude Code, we launch almost all of our features under the label "Research Preview." We explicitly label this when launching, letting users know it's an early-stage product, just an idea, we're simply looking to get feedback and iterate, and it may not be permanently supported. Doing this lowers the launch bar for us; we can get something built in one to two weeks.
The third point is that PMs should create the framework for the team, letting them know when to bring in cross-functional partners and what those partners' expectations are. For example, we have a very tight process between our engineering, marketing, and documentation teams. When an engineer feels a feature is ready and has been internally dogfooded, they post in our "Evergreen Launch Room" channel. Sarah, who runs documentation, Alex from product marketing (PMM), and Tar, Lydia, and other DevRel members would immediately jump in, and the marketing comms announcement can be turned around the very next day. Because the process is so tight, it lowers the friction for any engineer to launch a product, and the PM is the person who should be setting up this system.
Internal alignment at Anthropic: rigorous metrics and a "team principles" checklist; PRDs only for multi-month projects
Lenny: What role does the PRD play in this process? You mentioned that goals are important, and getting alignment on "what success looks like" and "who it serves". Do you write PRDs? Or is it just a few bullet points? How is this evolving in the PM world?
Cat Wu: We do two things. One, we have very rigorous metrics, and we do a weekly metrics readout with the entire team. The goal is to ensure that everyone deeply understands every facet of the business, what the core objectives are, what the trends are, and what the drivers are. Second, we have a list of "Team Principles" that include who the core user is and why we picked them. We articulate these so that everyone on the team feels they understand the business logic, what matters to us, and what we are willing to trade off. This allows people to make decisions autonomously without feeling blocked by the PM or other stakeholders.
Lenny: I love this feeling, that we still need PMs in the future. There's a lot of talk now saying, "Why do you need PMs? Just build and ship, we need engineers."
Cat Wu: I think for those particularly ambiguous features, writing a one-pager is helpful, stating what the goal is, what the delightful use cases are, what the failure modes are that currently need fixing. Occasionally, there are also projects, especially those requiring heavy infrastructure, that genuinely take months. In those cases, we still write PRDs.
Rapid product releases aren't just Mythos' achievement
Lenny: I want to dig deeper into how you all move so quickly. I've never seen a pace like Anthropic's; someone made a calendar of your launch schedule, and it's like major features or products almost every day. People online are asking: you didn't just launch, you also built this incredible Mythos model (currently in preview), and because it's so powerful, people are almost scared of its capabilities. Are you all constantly using it? Is this the reason you can move so fast?
Cat Wu: Actually, we've been maintaining this high velocity for several quarters now. So, I don't think this is all Mythos' achievement. Mythos is an incredibly powerful model, and we do use these models internally, which has certainly boosted launch speed a little, but I don't think it explains the majority of the speed-up. I think it's more about the process and team expectations. Our process is very lean; we want to remove any obstacles that impede launching. We want everyone on the team to feel empowered to take an idea from inception to reality and push it out into the world in under a week, or even a single day.
The Claude Code source code leak incident: it was a process failure
Lenny: Having the best model while also building the product is such a huge advantage. I want to talk about a few vignettes; there's just so much happening at Anthropic. About a week ago, the complete source code for Claude Code leaked; someone posted it online. I think it was a mistake by someone. Is there anything you want to say about that? What happened? What went wrong?
Cat Wu: We investigated as soon as we saw it. We realized it was the result of human error. An employee was using Claude to write a PR, and it was just an update about how we release a software package. It actually went through two layers of human review. So it was the result of human error, and we have since hardened our processes to ensure this doesn't happen again.
Lenny: Is that person still at Anthropic?
Cat Wu: Yes. It was a process failure, and the most important thing is to learn from it and add more guardrails. That's what we've been focused on, and most of those protections are already live.
Claude cannot be used with OpenClaw: subscription plans weren't designed for third-party products
Lenny: Another question is about OpenClaw. There have been some recent moves to block people from using their Claude subscriptions in third-party tools. People are upset and confused. It feels like it's hurting the open-source community. People need to understand what the considerations were behind this decision?
Cat Wu: We saw huge demand for Claude, and we've been working hard to scale our infrastructure and make our framework much more efficient in terms of token usage. The subscription plans were not originally designed for third-party products; their usage patterns are just different from our own first-party products. We spent a lot of time thinking about what the smoothest transition path is that we can offer. So I'm happy to announce that everyone on a subscription will get some credits along with it. But we did have to make the tough call that we need to prioritize our first-party products and API. That's what this decision was about.
Lenny: That makes total sense to me. You were essentially subsidizing that usage at $20 a month, and it was almost unlimited. I think people don't understand that businesses also have to make money; we need to become profitable, and when there is this massive demand for compute, you can't just give it away.
Anthropic has 5 PM teams, and all roles are converging
Lenny: Back to the PM team, what does the PM organization look like at Anthropic? How many people are there, and how is it organized?
Cat Wu: We have a few PM teams, roughly 30 to 40 PMs right now. Diane leads the Research PM team, responsible for collecting user feedback on models and conveying it to the research team; she also handles model launches. Then there's the Claude Developer Platform team, which maintains the API that Claude Code is built on and launches products like "Managed Agents." Then the Claude Code team. There's also the Enterprise team, which focuses on making it easier for enterprise customers to adopt these tools, including cost controls, RBAC, security controls, etc. And finally, we have the Growth team, which works on growth across the entire product line.
Lenny: Speaking of growth, Amole mentioned a really interesting point when he was on the podcast: people always think the future will require fewer PMs, that engineers can just do it directly; but he believes that because engineers are moving so fast, PMs and designers are getting squeezed out, with no time to keep up with all the changes. So he thinks he needs more PMs, because it's just too hard to keep up. What's your take? Do you see PM hiring increasing? What happens to this profession long-term?
Cat Wu: I think all roles are converging. PMs are doing engineering work, engineers are doing PM work, designers are doing product management and committing code. You either hire more engineers with excellent product taste, or you keep the engineer headcount the same and hire more PMs to guide the work. On our team, we are very focused on hiring engineers with excellent product taste, which reduces the communication overhead of shipping product. Many engineers on our team are fully capable of handling things end-to-end: from seeing user feedback on Twitter to shipping the product by the weekend, with almost no PM intervention needed. I think that's the most efficient way. So the lines between engineer and PM are overlapping.
I believe product taste is still a very scarce skill, and anytime we feel someone has demonstrated that ability, we pretty much always hire them.
Lenny: Your background is engineering, right?
Cat Wu: Yes, I was an engineer for many years and briefly worked in VC before joining Anthropic. In fact, almost all the PMs on our team were previously engineers, or they commit code in Claude Code. This helps build trust within the team and allows us to move faster. Even our designer was a frontend engineer previously.
The most valuable core skill: product taste
Lenny: Here's a big question. Since the boundaries are merging, if you come from an engineering, product, or design background, which core skill is the most valuable?
Cat Wu: I still think it all comes back to product taste. As the cost of writing code goes down, what becomes more valuable is deciding "what to write." What is the right design (UX)? What is the most delightful user experience? We receive thousands of GitHub Issues asking for various features, requiring enormous patience and taste to figure out: which one is worth doing? What is the right way to do it? That skill can come from any background.
The reason why an engineering background is particularly useful in the coming months is because if you understand engineering, you have a better sense of how hard something is. That's often a significant factor in deciding what to build. If something is incredibly easy to do, then rather than debating it, you just spend an hour and get it done.
But if something is harder to build, knowing that upfront means you understand, OK, for our team, bringing this feature to market is going to cost more. So that helps a bit with prioritization.
Lenny: You say "in the coming months"—is that because models might get so good in the coming months that you won't even need to know that much about engineering?
Cat Wu: I think the valuable skill sets are changing very frequently, so it's hard to predict what things will look like months out. So it's less a comment on what specific shift I think will happen, and more a comment on my belief that there will be a significant shift.
Lenny: So you're not saying that's when Mythos launches, it changes everything, making us not need to understand any engineering?
Cat Wu: No, I'm just saying that every couple of months, coding capabilities seem to take a big step up, which subsequently changes the value of other roles.
Cat Wu: I think the most important thing is being able to possess this "first principles" thinking, where you can figure out how the technology landscape is shifting, what the team really needs you to do, and dive in to fill that void. Because I think jobs are getting increasingly blurry, and that means a good PM is able to understand where all the gaps are, figure out which ones are the highest priority, and then find a way to learn that skill, or think about what skills I already have that I can apply to this challenge. So I think the environment right now values people who can wear multiple hats, are very comfortable switching between roles, and have low ego about doing any type of work just to help the team go faster.
Humans still possess common sense that models lack.
Lenny: I love that answer. I keep asking people in your position—folks at the cutting edge of AI capability, building products with the latest tools—this question: on the path to superintelligence, where will the human brain continue to be useful and indispensable? What I'm hearing here is, essentially, choosing what to build, understanding where the market is going, and figuring out prioritization. And then judging whether what you've built is good and right, and getting it to market at least in some early version. Does that sound right? Where else is the human brain useful, at least for the next few months?
Cat Wu: I think humans still have a level of common sense that models don't possess. There are a thousand moving parts in any product launch, some tiny, but there are always so many potential things that could go wrong. I think models are not always great at sensing who all the stakeholders are, how they all relate to each other, what their preferences are, and what the right forums are for communicating and aligning with them. I think a lot of that more tacit kind of common sense, like EQ-type knowledge, is still very valuable. Of course, we expect models to get better at this, and I think they will, but for now, I think there's still a gap.
Shared traits of the Anthropic team: calm and optimistic.
Lenny: As a human at the center of this constant, relentless tornado of change, how do you cope? Maybe it’s calm there, but how do you grasp what's happening? How do you stay sane amidst this crazy process?
Cat Wu: I think our team is full of people who embrace the chaos. So we try to meet every challenge with a smile, because there's just always so much going on. There are always so many fires and tricky situations, and you know if you get too stressed about anything, you'll just burn out. So we look for people who can look at the challenge and think, "This is going to be hard, but I'm excited to go tackle it and I'm going to do what I can, and I know I won't be perfect, but I can sleep soundly at night knowing I gave it my best."
Lenny: That's a very interesting answer about which skills matter in the future. I forget who said it, maybe Ben Evans, who said this is the most normal the world will ever be again.
Cat Wu: Yes, and it's definitely only going to get harder. I think there are many weeks where maybe on Sunday night there's a P0-level fire, and by Monday there's another P0, and by Monday afternoon another P0000-level fire pops up, and you're just like, wow, I can't believe I was so worried about Sunday's P0. But you have to accept that there's only so much you can do, that you need to sleep well so you can make good decisions the next day, and be incredibly ruthless about prioritizing your time. What is the single most important thing that has to be correct? Andke acceptance of letting go. Some of the products we've shipped haven't been as polished as I would have liked, but you know, our North Star is to empower professional developers. If a product isn't as successful, as long as it's not blocking the core use cases, then it's OK, because we'll hear the feedback and fix it in the next iteration. Shipping a feature that has bugs used to be something that would keep me up all night, and I've now come to peace with it because I know we'll get fast feedback and we'll16 fix it later.
Lenny: The image in my head is that GIF, maybe from Pirates of the Caribbean, of the man walking down the stairs of a ship while the whole ship crumbles around him, and he's just so calm, just strolling down the stairs, even though everything is disintegrating. It's funny because every person I meet from Anthropic is so calm and optimistic.
Cat Wu: Yeah, I think it's a very interesting insight that maintaining that calm and optimism, rather than thinking "Oh my god, everything is crazy," if you don't have that, you will burn out very quickly. I think we also tend to hire people who've been in the industry for a bit, have seen a few cycles, and have a good sense of what gives them energy and how to sustain that energy long-term. I think that has really helped us a lot.
Users struggle to keep up with the latest AI product developments; they need guidance from tools.
Lenny: Interesting. I want to ask about the blurring of roles. Engineers becoming PMs, cats becoming dogs, everyone becoming everyone else. What do we lose in this world? Do we lose career ladders and clear career paths? Do we lose design consistency or code quality? You know, there are probably downsides. What are you finding is being sacrificed for the greater good?
Cat Wu: We are sacrificing product consistency. In the past, when the cost of writing code was high, you meticulously planned out everything in the product suite, how each product relates, what the use case is for every single one, how they fit together, and there was basically one product per use case. Now, with AI moving so fast and so many ideas to test, we do have feature overlap sometimes. Many times it's because internally there are two manifestations we both love and we want to let external users tell us which one is better. But for a new user, this means that they might not know what the best path is for accomplishing a certain task. We need to do more educational work, helping people understand what the core features are and what the best practices are for using them. I think this is the cost of releasing a huge number of features. Users also find it difficult to keep up with the latest developments. Usually, in a traditional PM model, you ship a feature once a month or once a quarter. It is very easy for a user to understand, "I just need to check in once a month and learn something new. Even if I ignore it for six months, it's fine; I won't feel like I missed anything." I think with these agentic tools, not just Claude Code and Cowork, but the whole ecosystem, people feel like they need to check Twitter every day to see what the latest thing is. I think there's more we can do to help people feel less like they're on a constantly accelerating treadmill. I want people to feel like they can just open these tools and the tool will guide them or teach them what they'd want to know.
Lenny: I saw you launched a very interesting feature the other day, I think /powerup, which essentially walks you through all the cool ways to use it and all the best practices for using Claude Code. Is that part of this category of efforts?
Cat Wu: Exactly. That's precisely what it is. In the past, we actually didn't want to build something like PowerUp because we felt the product should be intuitive enough that you wouldn't need to go through any tutorial. But over time, we realized there are just so many features and there's enormous demand for an in-product guidance experience. So we deviated slightly from our initial "no onboarding flow" principle to add this, because there were so many users asking, "There are 100 features here, what are the 10 I absolutely need to use?" So we bundled it together.
The reason for Anthropic's success as a latecomer: team members share a unified mission.
Lenny: What a bizarre world. Anthropic has been so successful in the B2B enterprise space, where traditionally you don't ship that much; you might just have a quarterly release. That's the exact opposite of having something new every single day. To follow this thread, the trajectory of Anthropic has just been otherworldly. Anthropic started out very far behind. It was one of the least funded companies, had no distribution, wasn't the first mover; OpenAI was way ahead. Pretty much everyone thought Anthropic had no chance of being a significant long-term competitor. And yet now it's performing incredibly well, beating teams from top companies with enormous resources, and the growth is just staggering. By the time this episode airs, the ARRs could be even higher. As an insider, what are the factors that allowed Anthropic to be this successful and14 catch up from behind?
Cat Wu: The two most important factors. The first is a unified mission. It's hard to overstate how big of a deal this is. We hire people who care most about bringing safe AGI to all of humanity. This is something we actually reference quite a bit as a norm when we make decisions about what the whole product organization should focus on shipping. Because we place this mission above any individual product line, we're able to make very fast decisions across the organization and execute them in a unified way. I think it's something I've never seen at a company of this scale.
Lenny: Just to be crystal clear: essentially, the top mission is safety alignment, making sure AI is beneficial to the world. Are you saying that having such a clear mission makes decisions much easier?
Cat Wu: If there are two conflicting priorities, we talk about which one matters more for the mission of Anthropic. It makes prioritizing which to go after much easier. And then everyone rallies behind the one we decide. So sometimes it means, hey, we want to ship something on Claude Code, but this other thing is more important, so we just delay that launch and do it later.
Lenny: Interesting point is that this kind of explains (a certain company) doing so many different things, and what I'm hearing here is: okay, well, we're not going to launch a social network, we're not going to launch an interesting feed, because it's not16 mission-aligned. This keeps Anthropic focused, which seems to be the core element of success.
Cat Wu: When I think about the mission, I think about placing the goals of Anthropic above any individual, any org, or any individual product. To me, I think the second thing we are very good at is focus. The mission, which feels slightly different to me, means that teams are willing to make sacrifices that hurt their own goals and KRs in service of Anthropic's goals and KRs. People are very happy to make those trade-offs. Using an extreme example, if Claude Code failed but Anthropic succeeded, I would be16 very happy, and the entire team is very willing to make decisions that follow that chain of thinking.
Lenny: I don't know if you can talk deeply about this, but do you feel like the decision about OpenClaw is part of that? Like "this is not furthering Anthropic's mission; we need to stop it because it's not working the way we want."
Cat Wu: I think one of the most important things for Anthropic is to increase the number of users we can reach. One of the ways we can do that is through our first-party product's Claude subscriptions, and so we very much want to double down there, and it sometimes comes at the expense of third-party products.
How Cat Wu uses products: ad-hoc coding tasks, Claude Code; frontend tasks, Desktop; non-code tasks, Cowork.
Lenny: We've been talking about Claude, Cowork, and all of this. I want to make sure people can follow along, and I'm also curious how you yourself use these tools. There's Claude Code, there's Claude Desktop, and there's Cowork. What's the best way to understand when to use which? When do you use each of the three?
Cat Wu: When I'm just spinning up an ad-hoc coding task and want all the latest features, I tend to use Claude Code in the terminal. The CLI is our original product surface and the platform where our features usually land first, so it's the most powerful of all the tools. That's the one I tend to use when I'm trying to spin up one or a small handful of tasks at a time.
Cat Wu: I think Desktop is brilliant when you're doing stuff that requires frontend work. One of my favorite things to do is use the Preview feature. If I'm building a Web app, I often use Claude Code and Desktop together. I'll have the preview panel open on the right side so I can16 see the Web app I'm building in real-time as I converse with Claude.
It's also wonderful for people who want a more graphical experience. The terminal can feel very foreign to nontechnical people; you see a bunch of scary pop-ups happening on your machine, and you can't just click around like you've done in almost every other product you've used. So there are a lot of people uncomfortable in the terminal, and if you're such a person, I'd highly encourage you to try Desktop. Desktop is also nice for you to have a glanceable dévelo all of the things that are happening. You can see your CLI terminal session in Desktop, you can see your other desktop sessions, your Web, and mobile-initiated sessions. So it's a one-stop control plane.
Cat Wu: I think the nice thing about Web and Mobile is that they're16 great for initiating tasks on the go. CLI and Desktop require you to have your local laptop. But that can be a little inconvenient because when you're out and about, going for a walk or being in nature, your computer isn't it running. I can't tell you how many people I've seen going outside for a walk with their laptop on hotspot, which just means we're missing a product that addresses that need. For me, mobile lets you initiate these tasks on the go so that you don't need to16 be16 right next to your laptop and ensure your laptop is15 running wherever you are.
Lenny: I love this so much. I've seen people on planes—it's become a thing now—where it's like, "I need to let this agent run; I can't shut down; I need Wi-Fi."
Cat Wu: And then I think for Cowork, the role it fills: so much of the work that every person does involves outputs that are not code. Whether it's cleaning up your Slack, clearing your inbox,16 or building a slide that you're going to dátummal present for an upcoming customer meeting, or writing up a brief document about a feature's goals or launch plan: all of these tasks produce non-code outputs, and Cowork is best suited for those. So my mental breakdown of the products is: if I'm working on something where the output is code, I'll use Claude Code or Desktop or Mobile; if the output is anything non-code, I'll use Cowork.
Cat Wu's use case: using Cowork to create meeting slide decks
Lenny: People might be underestimating the success of Cowork. It's growing incredibly fast, and I think people still don't fully understand what it does. Since you're a PM, can you give us a few use cases? What are some interesting16 or even unexpected ways you use Cowork to save time and get more done?
Cat Wu: If you're just getting started with Cowork, the first thing you really should do is connect all your data sources relevant to your role. Because Cowork can only curate a high-quality output for you if it has access to all the context it needs. For me, that means connecting it to my Google Calendar, Slack, Gmail, and Google Drive, so it has the flexibility to pull in relevant context, ask questions, pull in conversation threads, and that meaningfully improves the quality of results.
Cat Wu: So the situations I use it for include… Last night I was working, we have this upcoming "Code with Claude" conference, and I have a few talks. One of the talks16 is about the shift from assistants to full agents16 within Claude Code. I wanted to include in my talk all the products we've launched that enable this transition and figure out what internal success stories exist that could serve as demos. So I connected Google Drive and Slack. Alex, our Product Marketing Manager, had drafted a document with bullet points she thought we should cover. I fed all of this to Cowork, telling it the story I wanted to tell. It essentially worked on its own for an hour. It browsed Twitter for what we had launched,16 looked at our "Evergreen Launch Room," looked at our "Claude Code Launch" channel (where teams post demos16 showing how they extract maximal value from Claude Code). It synthesized all of this into a 20-page slide deck. I woke up this morning, read through it, and felt it was pretty good. There are some minor tweaks; I did give it a round of feedback. I like my slides to be extremely minimalistic in текст, and it was a bit too wordy. But you know, it's much faster than what I would have been able to produce. And because Cowork has access to our entire design system, it looked like it was made by an Anthopic designer, and when you see it visually, you just think, "Oh, this is incredibly polished." So, these things have gotten just so much faster. Making that slide deck would have taken me many hours, but now it ran a very high-quality draft, so I could focus on making sure the demos we're plugging in are really mind-blowing.
Lenny: That sounds like a PM's dream come true. Making slide decks is so annoying and slow. And I love that when people see this talk, this is the output; clearly, it's not just a one-click generated version; you iterated on it. To help folks try this themselves, the first step is connecting data. You mentioned Slack; what else do you recommend connecting?
Cat Wu: Slack, Google Calendar, Gmail, Google Drive. You should connect your communication tools andwhere your source-of-truth data lives for what your team cares about, what you care about, and what you're working on.
Lenny: Okay, so what did the prompt roughly look like when you generated this slide deck?
Cat Wu: I wrote: "Help me16 make a slide16 deck for the Code with Claude conference. Here's what our PMM16 suggested we cover. Here is a draft16 I have that I didn't like. Here is a draft that I had manually that I didn't like, but I've placed links. Can you first create a suggested outline with details? Also make sure it doesn't overlap too much with the Keynote, which is higher stakes." And then, Claude16 read through that pile of links I sent it and created a suggested outline. Then I read through its suggestions, and all the different ideas it generated about what we could cover, and I decided what to include in the final deck. I think this is a microcosm of what the PM role looks like today: Claude is a phenomenal thought partner for brainstorming, and it can synthesize massive amounts of information incredibly fast and show you the landscape of possibilities, but it's still the PM's role to make the final decision on what gets to remain in the end product.
For this particular talk, I ended up deciding to cover16 the progression from "Making Local Tasks Successful" to "Making Every PR Pass" to "Helping Engineers Ship More PRs," and deciding which demo was most compelling for each stage. After I decided on the outline, Cowork went off and did its thing for a few hours and16 built the entire deck.
Lenny: That's awesome. Not doing slide decks anymore is such a wonderful part of the job. It feels like you're talking to a slide designer, but one who not only can make it look beautiful but also has this genuine knowledge about your work that can tailor the content exactly. How did you handle the design spec part? How did it learn Anthropic's design style?
Cat Wu: The way we did it is that the company already has a set of standardized slide templates used for all external events. I gave Claude permissions to that template directly. This way, it could see the colors we use, the fonts, and15 all the possible slide formats. It had about 20 of these example slides on hand.
Lenny: Got it, so it's like uploading a template and saying, "go do it like this."
Cat Wu: Exactly. If you have your slide formats stored in Figma, you can also connect Figma's MCP to pull them in directly.
A flood of personalized "bespoke" software is emerging inside Anthropic
Lenny: Following up on this, I've always been curious about what's in the PM tool stack at Anthropic. Obviously, there's Claude Code, Cowork, and all the Anthropic tools. What else are you using besides that? You mentioned Slack; anything else?
Cat Wu: My tool stack heavily relies on Claude Code and Cowork. Anthropic runs largely on Slack; I feel like it's like our company's "core OS." In day-to-day work, about 30% of my time is pushing the boundaries of what Cowork can do, so that I can keep a sharp sense of what we aren't good at yet.
I spend a lot of time talking to the model and trying to understand why it makes those mistakes. We've actually built a lot of internal tools. I think the most significant thing Claude Code has done for the entire company is that it has dramatically lowered the barrier to developing any custom application. Therefore, we're seeing an explosion of personalized office software written by employees themselves for specific use cases, rather than settling for general-purpose tools that don't perfectly fit.
Lenny: I have to hear more about this. What are some examples? What are some popular or useful tools you or others have built?
Cat Wu: A sales colleague on Claude Code's team found that he was always making similar slide decks. So he used Claude Code to write a Web application, which was embedded with the core slide paradigms we've found work best (like 101, 201, and mastery courses). He designed a way to input specific customer background,16 pull information from Salesforce, Gong (sales call recording analysis tool), and other notes to customize the deck for that specific customer.
It would automatically extract things like: is this customer on Bedrock, Claude Enterprise, or Console? That determines which features are available to them. It also extracts what the customer cares about, for example: the customer is worried about the code review phase in the Software Development Life Cycle (SDLC), so it'll throw in a slide about our code review features. If the customer needs HIPAA compliance or specific security controls, it ensures relevant slides are included. If the customer is on Vertex or Bedrock and doesn't want Claude Enterprise, it will delete pages about enterprise-only features. Normally, such manual work takes 20 to 30 minutes, so people either grit their teeth and do it or just give up on customization. Now, a tailored document is16 available in seconds.
Lenny: Funny enough, Slack seems to be the tool no one wants to replace. It keeps winning; it's the "operating system" for so many companies. People keep saying we don't need SaaS software anymore, we'll build our own, but Slack is a durable tool that no one seems to want to compete with or create a better version of.
Cat Wu: I think it's very critical communication infrastructure, and they just do a phenomenal job at one core thing: helping everyone stay updated in real time.
Lenny: Exactly. People joke about Slack sometimes, but it is excellent at what it does. The top teams get hooked on it.
Cat Wu: Yes, and I also love the customizability it offers. We love building Slack bots, and the hackability means we can integrate with Slack the way we want. Really appreciate Slack going after that effort.
Anthropic's highest token-consuming teams: Engineering and Applied AI
Lenny: Okay. You've mentioned how all these different teams are using Claude Code and Cowork. Which teams are you finding are16 burning the most token besides Engineering? I'm guessing Engineering is the biggest consumer; if not, that would be interesting.
Cat Wu: Oh, Applied AI has been phenomenal at pushing the boundaries of what Claude Code and Cowork can do. A huge chunk of that team's time is spent helping our customers adopt the API. So they're sometimes prototyping on behalf of customers and using Claude Code to make that process so much faster than before. At the same time, they need to manage a huge amount of customer communications and historical meeting notes, so their usage is very substantial across both Cowork and Claude Code.
Lenny: To understand the Applied AI team, is it similar to a "Forward Deployed Engineering" role?
Cat Wu: Exactly. They help customers adopt the latest APIs and model capabilities across the entire company. Think of them as very technical go-to-market people.
Lenny: Got it. So you're saying that might be the second highest token-consuming department.