Anthropic Cuts Product Deadlines to Days as AI Reshapes PM Role
Lenny's Podcast
Traditional product management frameworks are obsolete in the AI era because plunging code generation costs shift the premium skill from managing dependencies to having refined product taste.
## Background
Published on YouTube on April 23, 2026, by Lenny's Podcast, this episode features an interview with Cat Wu, the Head of Product for Claude Code and Cowork at Anthropic. The discussion centers on how Anthropic's product team maintains an incredibly fast shipping cadence, the evolving skillset required for AI product managers, and how the company's core mission eliminates typical organizational friction.
## TL;DR
The conversation explores Anthropic's transition from multi-month roadmap cycles to rapid daily shipping, driven by a culture of low process and high engineer autonomy. Cat Wu explains how the drop in code generation costs has shifted the premium PM skill from managing dependencies to refining product taste and building strategic evals. She details the internal tools, structures, and advanced models like Opus 4 and Sonnet 4.6 that are fundamentally merging engineering and PM roles. Additionally, the episode highlights how Claude's distinct coworker personality and Anthropic's shared AGI safety mission serve as core drivers of their rapid execution and enterprise success.
## Atmosphere & style
The interview feels fast-paced, highly pragmatic, and energized by the chaotic nature of the frontier AI industry. Cat Wu brings a calm, optimistic, and first-principles energy to the conversation, contrasting the high-stakes pressure of sudden source code leaks and constant technical pivots with a grounded, 'just do things' attitude. The dynamic between host and guest is collaborative and deeply technical, giving listeners an authentic, behind-the-scenes look into a high-trust, mission-driven startup environment where team members routinely cross traditional role boundaries.
## Key takeaways
- [00:00](https://www.youtube.com/watch?v=PplmzlgE0kg&t=0s) Anthropic has compressed its product feature timelines from six months down to a single month, week, or day, replacing multi-quarter roadmaps with extreme agility.
- [00:00](https://www.youtube.com/watch?v=PplmzlgE0kg&t=0s) With the drop in code generation costs, the premium product management skill has shifted from managing dependencies to possessing refined product taste.
- [07:10](https://www.youtube.com/watch?v=PplmzlgE0kg&t=430s) Traditional PM frameworks built for slower technology shifts fail in the AI era; success requires setting narrow goals and utilizing 'research previews' to gather rapid feedback.
- [14:59](https://www.youtube.com/watch?v=PplmzlgE0kg&t=899s) Anthropic maintains a lean product organization of 30 to 40 PMs, and roles are heavily merging, with PMs dipping into engineering and engineers taking on PM responsibilities.
- [47:12](https://www.youtube.com/watch?v=PplmzlgE0kg&t=2832s) A unifying company-wide obsession with bringing safe AGI to humanity acts as the final tie-breaker for hard product choices, eliminating typical corporate bureaucratic friction.
- [01:09:07](https://www.youtube.com/watch?v=PplmzlgE0kg&t=4147s) The lowering of the software development barrier via LLMs has triggered an internal surge of hyper-specific, highly impactful tools built by non-engineers.
- [01:25:15](https://www.youtube.com/watch?v=PplmzlgE0kg&t=5115s) Top AI PMs identify future requirements by observing how users abuse current product limits, designing creatively for existing model constraints rather than waiting for hypothetical models.
- [01:28:39](https://www.youtube.com/watch?v=PplmzlgE0kg&t=5319s) Developing AI product taste involves asking models to introspect and reflect on their own unexpected behaviors to diagnose system prompt issues and agent delegation failures.
- [01:32:24](https://www.youtube.com/watch?v=PplmzlgE0kg&t=5544s) Claude's distinct, low-ego, positive, and action-oriented coworker personality was intentionally crafted with immense conviction and is core to its product success.
- [01:40:45](https://www.youtube.com/watch?v=PplmzlgE0kg&t=6045s) As underlying AI models grow smarter, product managers systematically remove programmatic features, tools, and heavy prompting interventions that were built as structural crutches.
- [01:48:32](https://www.youtube.com/watch?v=PplmzlgE0kg&t=6512s) The trend of 'multi-cloding'—running dozens or hundreds of Claudes simultaneously—necessitates a shift toward remote infrastructure due to local RAM constraints.
- [01:52:03](https://www.youtube.com/watch?v=PplmzlgE0kg&t=6723s) True automation requires reaching 100% accuracy, as 95% accuracy forces users to manually verify work and prevents them from fully trusting the automation.
- [01:59:58](https://www.youtube.com/watch?v=PplmzlgE0kg&t=7198s) The modern generation of AI tools has shifted from the chat-based models of 2024 to action-based agents that directly perform tasks on behalf of the user.
- [01:59:30](https://www.youtube.com/watch?v=PplmzlgE0kg&t=7170s) Operating effectively in a fast-paced AI startup requires a mindset of 'just doing things'—prioritizing quick execution and learning from mistakes over rigid structure.
## Detailed walkthrough
### [00:00](https://www.youtube.com/watch?v=PplmzlgE0kg&t=0s) Eliciting Maximum Capabilities and the Speed of Shipping
The challenge of building in the age of Artificial General Intelligence (AGI) is finding the right balance of alignment with future capabilities. It is deceptively simple to design a product aimed at a hypothetical, ultra-powerful "super AGI" model; the true friction lies in engineering for the reality of today. Product teams must figure out how to squeeze the absolute maximum capability out of current, existing models. At Anthropic, this philosophy translates into an unprecedented shipping velocity where product feature timelines have plummeted from traditional six-month horizons down to one month, a week, or sometimes a single day.
This hyper-accelerated environment is fundamentally shifting the role of the Product Manager (PM). When interviewing hundreds of PM candidates, there is a recurring theme of people approaching the discipline with an outdated mindset. In an AI-native ecosystem, multi-quarter roadmap coordination takes a backseat to extreme agility. Because code has become dramatically cheaper and faster to generate, the most critical skill a PM can possess is no longer managing complex alignment dependencies, but having the refined "product taste" required to decide exactly what to write and launching new features on a weekly cadence.
---
[00:56](https://www.youtube.com/watch?v=PplmzlgE0kg&t=56s) Welcome Kat Wu: Navigating the Blurry Lines of Product Leadership
Host Lenny Rachitsky introduces Kat Wu, the Head of Product for Claude Code and Co-work at Anthropic. Positioned at the absolute epicenter of the shifting AI landscape, Kat and her team are responsible for building tools that are fundamentally altering how the rest of the tech industry develops products. Stepping into the hot seat carries a playful level of pressure, as her close partner and tech lead, Boris, previously recorded the number one most popular episode in the history of the podcast. Boris is famous for his legendary engineering output, famously shipping a "bazillion PRs a day from his phone."
Kat provides a rare inside look at how responsibilities are actually divided between her and Boris on the Claude Code team. Describing Boris as an incredible thought partner and a visionary, she notes that he excels at painting the macro picture of what the product should look like in three to six months—the "AGI pill version" of their roadmap. Kat’s role is to construct the immediate tactical bridge from today's reality to that future state. She owns the heavily cross-functional machinery, aligning marketing, sales, finance, and compute capacity while eliminating any internal blockers to ensure features can ship instantly. Their working relationship operates with a remarkably fluid boundary: they share about an 80% "mind meld," while the remaining 20% splits naturally based on who cares more deeply about driving a specific initiative.
---
[04:30](https://www.youtube.com/watch?v=PplmzlgE0kg&t=270s) How to Avoid AI PM Failures: The Anthropic Playbook
Anthropic has become the most sought-after destination for product talent in tech, prompting Lenny to joke that if he had a nickel for every introduction request he receives, he would have "$30 billion in ARR." However, Kat observes that the vast majority of traditional PMs fail during interviews because they rely on frameworks built for slower technology shifts. In the past, expensive engineering cycles mandated rigid 6-to-12-month timelines focused on defensive dependency planning. Today, AI has supercharged engineering velocity to the point where PMs must optimize exclusively for reducing the time between a raw concept and getting it into a user's hands.
To keep a team moving at this breakneck pace without dissolving into chaos, Kat outlines three core pillars of the Anthropic product playbook:
* **Setting Laser-Focused Goals:** Because Large Language Models (LLMs) are inherently general, they introduce massive product ambiguity. A strong PM must sharply narrow the scope. For instance, instead of trying to be everything to everyone, Kat’s team might align on a singular objective: enabling professional developers at enterprise companies to safely reach "zero permission prompts" so they can accomplish more with a single interaction.
* **Leveraging Research Previews:** To lower the stakes and eliminate shipping friction, almost all new features are explicitly branded and launched as a "research preview." This signals to users that the feature is an early experimental concept designed for rapid feedback, shielding the team from a permanent support commitment and allowing them to ship ideas in a week or two.
* **Creating Frictionless Cross-Functional Frameworks:** Rather than relying on heavy oversight, they use an automated, self-serve pipeline. When engineers finish internal dogfooding, they drop the feature into an "evergreen launch room." Instantly, cross-functional partners spanning documentation, product marketing, and developer relations (DevRel) swarm the thread, frequently turning around public marketing announcements by the very next day.
---
[08:59](https://www.youtube.com/watch?v=PplmzlgE0kg&t=539s) The Evolution of PRDs and Navigating Internal Process
The hyper-velocity environment at Anthropic raises the existential question of whether traditional Product Requirement Documents (PRDs) are dead, a topic of heavy debate among critics who argue that engineering-heavy AI teams don't need PMs. Kat clarifies that they have replaced bureaucratic overhead with structural clarity. They run highly rigorous metric readouts every single week with the entire team so that every engineer deeply understands the business levers, trends, and core goals. This data is paired with a clear list of "team principles" detailing who their key users are and what trade-offs they are willing to make, empowering individual contributors to make autonomous decisions without waiting on a PM stakeholder.
However, PRDs have not been entirely abandoned. For highly ambiguous features or massive underlying infrastructure initiatives that require multiple months of core development, Kat’s team still writes focused one-pagers. These documents pinpoint the exact goals, ideal user experiences, and known failure modes that require fixing.
- **Anthropic PM Team Scale:** The product organization is relatively lean, consisting of roughly 30 to 40 PMs split across a few highly specialized teams.
- **Research PM Team:** Led by Diane, this group synthesizes customer feedback on model performance and coordinates directly with the core AI research teams to guide model updates and shepherd model launches.
- **Claude Developer Platform Team:** This team maintains the foundational APIs that power outward-facing tools like Claude Code, and handles infrastructure features like "managed agents" to host agents on behalf of developers.
- **Claude Code & Enterprise Teams:** These segments focus on the core Co-work and Claude Code products, alongside enterprise-grade guardrails including cost controls, Role-Based Access Control (RBAC), and security compliance.
---
[10:29](https://www.youtube.com/watch?v=PplmzlgE0kg&t=629s) The "Mythos" Model and Managing Recent Public Crises
Addressing online speculation surrounding a leaked calendar showing Anthropic dropping major features or products almost daily, Lenny asks if their velocity is driven by internal access to "Mythos"—a rumored, hyper-advanced frontier model currently kept in preview due to its raw power. Kat dispels the myth gently, noting that while they heavily dogfood their own frontier models internally and enjoy a structural advantage from doing so, Mythos is not the primary driver of their speed. The velocity is cultural and organizational: it is the result of a deliberately low-process environment where individual engineers are explicitly empowered to push an idea to the world in less than a week.
The conversation shifts to recent controversies, including a high-profile incident where the source code for Claude Code was leaked to the public. Kat addresses the mistake transparently, revealing it was entirely a "result of human error" involving a developer utilizing Claude to draft a Pull Request (PR) for a package release update. Despite passing through two distinct layers of human review, the code slipped through. Kat emphasizes that the engineer remains at Anthropic and that the company viewed it strictly as a process failure, responding by immediately hardening their automated safeguards.
Finally, Kat addresses the community backlash regarding "Open Claude" and the enforcement actions preventing subscribers from piping their consumer Claude subscriptions into third-party open-source interfaces. Acknowledging the frustration of the open-source community, Kat explains that consumer subscriptions were never architected to handle the aggressive, token-heavy usage patterns of third-party apps. With demand skyrocketing, the business had to make a tough strategic prioritization to protect infrastructure stability for their first-party products and official API users, though they attempted to soften the blow by bundling complimentary API credits with existing subscriptions.
[15:27](https://www.youtube.com/watch?v=PplmzlgE0kg&t=927s) The Blurring Boundaries of Product Management and Engineering
The organizational layout at Anthropic includes a growth team responsible for scaling users across the entire product suite, working tightly with other teams on Cloud Code, Co-work growth, and CDP growth (expanding the user base for the Cloud API). This discussion on rapid expansion prompts an exploration of the evolving role of Product Managers (PMs). A recent podcast guest, Amol, shared a contrarian insight: while the industry narrative often claims future tech companies will need fewer PMs because engineers can just ship directly, Amol argues the opposite. Because engineers are moving at a breakneck pace and features ship daily, PMs and designers are feeling squeezed and struggling to stay on top of the product velocity. Consequently, Amol believes companies actually need *more* PMs just to keep up.
When asked for her take on the long-term outlook of the profession, the speaker observes that traditional roles are fundamentally merging. PMs are dipping into engineering, engineers are taking on PM responsibilities, and designers are managing products while simultaneously landing front-end code. In this environment, a company faces a strategic choice: either hire more engineers who possess exceptional product taste, or freeze engineering headcount and hire a surge of PMs to guide the technical work. Anthropic's team intentionally leans into the former approach, prioritizing engineers with great product taste to radically reduce the operational overhead required to ship.
> "Like there are many engineers on our team who are fully able to end-to-end go from see user feedback on Twitter through to like ship a product at the end of the week with almost no product involvement. And this I think is actually like the most efficient way to ship something."
Because engineering and product management are overlapping, a company can derive immense benefits from having more of either skill set. However, "product taste" remains a remarkably rare commodity, and Anthropic will eagerly hire anyone who has strongly demonstrated it. This philosophy is deeply woven into the team's DNA; the speaker herself spent many years as an engineer followed by a brief stint in venture capital before joining Anthropic. In fact, nearly all PMs on her team possess engineering backgrounds or have written code for Claude Code, which builds deep technical trust and allows the team to move much faster. Similarly, the team's designers possess past experience as front-end engineers.
[17:54](https://www.youtube.com/watch?v=PplmzlgE0kg&t=1074s) Product Taste and Prioritization in an Age of Cheap Code
As the traditional Venn diagrams of tech roles combine, a pressing question emerges for industry professionals: whether an engineering, product, or design background will ultimately prove most valuable. While engineering is clearly king on highly technical tools like Claude Code, the speaker reiterates that everything ultimately anchors back to product taste. As AI makes the literal act of writing code dramatically cheaper, the premium shifts away from execution toward intent: deciding exactly *what* to write, designing the right UX for a feature, and crafting the most delightful user experience.
The necessity of strict filtering is highlighted by the scale of incoming feedback; the team receives tens of thousands of GitHub issues requesting "every single thing under the sun." Sorting through this noise requires immense care to isolate what is genuinely worth building. While this taste can emerge from any background, an engineering foundation provides a unique advantage for prioritization. It gives a builder a native intuition for how difficult a feature will be to implement. If a feature is incredibly simple, the team can bypass prolonged debate and just spend an hour building it. Conversely, if an idea is complex, knowing the high engineering cost upfront allows for smarter prioritization.
When pressed on why she specified that engineering backgrounds would be uniquely useful "for the next few months"—implying that rapidly improving models might soon make technical intuition obsolete—the speaker clarifies that it is less a specific prediction about a catastrophic shift and more a reflection of how volatile the AI landscape is. Value skill sets change so frequently that it is impossible to accurately predict more than a few months out. Every few months, a massive leap in coding capabilities fundamentally rewires which human roles carry the most value.
* **The Core Premium:** Deciding what to build and how to design the right UX is increasingly more valuable than the code execution itself.
* **The Influx of Feedback:** The team manages tens of thousands of GitHub issues, making ruthless filtering essential.
* **The Engineering Edge:** Knowing technical complexity firsthand allows a PM to choose between a quick one-hour build and an expensive, multi-week undertaking.
[20:03](https://www.youtube.com/watch?v=PplmzlgE0kg&t=1203s) Human Logic, "EQ," and Embracing the Inside of the Tornado
In an era of rapid technological displacement, the traits that preserve the utility of human brains center on first-principles thinking. The most successful contributors are those who can analyze how the tech landscape is shifting, identify shifting organizational gaps, and rapidly learn whatever new skill set is required to plug those holes. The current environment favors low-ego generalists who can seamlessly swap professional hats to make the team move faster. Furthermore, humans still hold a monopoly on a level of "common sense" and emotional intelligence (EQ) that AI models lack. Launching a product involves a thousand moving pieces, and models struggle to comprehend the delicate web of stakeholders, how they relate to one another, their individual preferences, and the correct structural venues needed to communicate with them effectively.
Operating inside this hyper-accelerated environment requires a unique psychological resilience. The speaker describes the Anthropic culture as a collection of people who actively "lean into the chaos" and meet intense challenges with a smile to avoid burnout. They look for experienced industry veterans who can acknowledge the difficulty of a situation, do their absolute best, and sleep soundly knowing they cannot achieve perfection.
> "Like I feel like there are a lot of weeks where maybe Sunday night there's some like P0, and then by Monday there's like a P00, and by Monday afternoon there's a P000, and you're like, 'Wow, I can't believe I was so worried about that P0 from Sunday.'"
Surviving this requires brutal prioritization and a willingness to let certain things go. The speaker admits that they frequently ship products that are less polished than she would ideally prefer. However, because their primary directive is to empower professional developers, launching a slightly buggy feature is acceptable as long as it does not completely block the core use case. The team relies on rapid user feedback loops to fix imperfections in subsequent releases—a reality that would have previously kept the speaker awake at night but is now a necessary cost of speed. The host jokes that this evokes a famous cinematic image of a captain walking calmly down a staircase while his ship is demolished around him, noting that everyone he meets from Anthropic is remarkably chill and optimistic. The speaker agrees, noting that without that calm energy, burnout is inevitable.
[25:21](https://www.youtube.com/watch?v=PplmzlgE0kg&t=1521s) The Sacrifice of Product Consistency for Market Velocity
While blurring professional roles and operating at breakneck speeds offers massive advantages, it demands an explicit sacrifice: product consistency. Historically, because code was highly expensive and slow to write, companies meticulously planned product suites, map out exact integrations, and ensure there was precisely one product dedicated to each specific use case. Today, the sheer speed of AI development and the volume of ideas that require live testing mean that features frequently overlap. At Anthropic, this often happens because the internal team falls in love with two different product form factors and intentionally chooses to let the external market decide which one wins.
The consequence of this strategy is a steeper learning curve for the end user. A newcomer may open the platform and feel entirely unsure of the optimal path to accomplish their task, placing a heavy burden of education back on the company. Furthermore, users struggle to keep up with the product velocity. In traditional software management, features roll out on a comfortable monthly or quarterly cadence, allowing users to check in periodically without fearing they have fallen behind. With modern agentic tools across the broader ecosystem, users feel chained to an "ever-increasingly fast treadmill," checking Twitter daily just to remain current.
To combat this anxiety, Anthropic recently launched a feature called `/powerup`, which guides users through best practices for Claude Code. The speaker admits that this marked a deliberate departure from their original product philosophy. Initially, they believed a product should be inherently intuitive enough to never require a tutorial. However, user demand for an onboarding experience grew too loud to ignore; with hundreds of features live, customers desperately wanted a guide isolating the top ten essential tools they absolutely needed to use.
[28:32](https://www.youtube.com/watch?v=PplmzlgE0kg&t=1712s) The Secret Ingredients of Anthropic's Sudden Success
Anthropic's operational velocity is particularly unusual given its massive success with enterprise and B2B clients, a sector that traditionally favors predictable, quarterly release cycles rather than daily feature drops. Reflecting on the company's trajectory, the host notes that its growth has been "other worldly." Early on, Anthropic was viewed as an underdog—it was less funded than its primary peers, lacked built-in distribution networks, and was racing against OpenAI's massive head start. Yet, the company has scaled aggressively.
When asked what internal ingredients allowed Anthropic to come from behind and achieve such dramatic success, the speaker points directly to their deeply felt, unifying mission: a collective obsession with bringing safe AGI to all of humanity. This mission is not a hollow corporate tagline; it is actively referenced in everyday product meetings to settle debates and dictate what the engineering organization ships. Because the team places this overarching mission above the success of any single product line, they bypass bureaucratic infighting and execute cross-organizational shifts with extreme speed.
If two product priorities conflict, the conversation quickly filters through which path better serves the safety and alignment mission. Once a decision is made, the entire team aligns behind it without ego. This structural focus prevents the company from chasing distracting side projects, ensuring that all energy remains directed toward their core technological goals.
- **Mission Alignment:** The existential goal of safe AGI acts as the final tie-breaker for hard product decisions, enabling rapid consensus.
- **Strategic Focus:** By tying everything to their central mission, Anthropic avoids fracturing their focus into unrelated consumer apps or side features, a pitfall that can slow down competing AI firms.
Sacrificing KRs for the Broader Mission
The speaker emphasizes that Anthropic's second major strength is focus, distinguishing it slightly from just having a mission. At Anthropic, "mission means that teams are willing to make sacrifices that hurt their own goals and their own KRs in service of Anthropic's goals and Anthropic's KRs." Employees cheerfully accept these trade-offs. To illustrate this mindset, an extreme example is shared: if Claude Code were to fail entirely but Anthropic as a company succeeded, the speaker would be "extremely happy," a chain of thought embraced by the entire team.
When asked if the recent decision regarding "open Claude" was part of this philosophy, the speaker confirms that growing user reach is a top priority for Anthropic. They explain that Claude subscriptions and first-party products are the best vehicles for this growth. Consequently, the company decided to double down on first-party products, even though it occasionally comes at the expense of third-party products.
---
Deciding Between Claude Code, Desktop, and Cohere
The conversation transitions to practical product usage, specifically contrasting Claude Code, Claude Desktop/Web, and Cohere (referred to interchangeably as co-work). The speaker explains their personal framework for choosing between them based on the task at hand. Claude Code in the terminal is their go-to for kicking off quick, one-off coding tasks where they want the absolute latest features, noting that the CLI is their initial product surface where new features "often land first" and is the most powerful tool.
In contrast, Claude Desktop truly shines for front-end web development. The speaker loves using the preview feature, keeping a preview pane open on the right-hand side to watch the web app update in real time while chatting with Claude. Additionally, Desktop acts as a friendlier alternative for non-technical users who find the terminal unfamiliar or intimidating with its "scary pop-ups" and lack of clickable elements. Desktop also serves as a "one-stop control plane" where users can view all their active sessions across CLI, desktop, web, and mobile at a glance.
Web and mobile products solve the constraint of needing a local laptop. The speaker laughs about the common "meme" of seeing people out in nature or on planes desperately holding their laptops open and tethered to phones, insisting, "I need to finish Let this agent finish. I can't shut this down. I need Wi-Fi." Mobile lets users touch grass and go for walks while kicking off tasks on the go. Finally, the distinction for co-work is simple: if the output of a task is anything other than code—such as reaching inbox zero, making slide decks, or writing product launch plans—co-work is the best tool.
- **Claude Code (CLI):** Best for one-off coding, features land here first, most powerful.
- **Claude Desktop:** Great for front-end work via the preview pane, non-technical users, and acts as a central control plane.
- **Web & Mobile:** Ideal for running tasks on the go without being tethered to a laptop.
- **Cohere / Co-work:** Designed for all non-code outputs (Slack, emails, slide decks, docs).
---
How a PM Uses Co-work to Build Slide Decks
The interviewer points out that co-work is growing incredibly fast, though many people are still "sleeping on" its success or misunderstanding its utility. When asked for a specific PM use case, the speaker shares that the crucial first step is connecting relevant data sources—such as Google Calendar, Slack, Gmail, and Google Drive—so the tool has the context required to curate high-quality outputs.
As a real-world example, the speaker describes working late the previous night on a presentation for the upcoming "Code with Claude" conference regarding the transition of Claude Code from an assistant to a full-on agent. To gather material on product features and internal success stories, they fed a rough outline from their product marketer, Alex, into Cohere alongside their connected Drive and Slack data. The tool ran autonomously for an hour, scanning Twitter, the company's evergreen launch room, and the Claude Code announce channel where teams share internal demos.
The speaker woke up the next morning to a polished, 20-page slide deck. While it required a round of feedback because it was a bit too wordy for their preference of "extremely minimal words," the process was profoundly faster than manual creation. Furthermore, because Cohere was connected to Anthropic's design system, the deck already looked like an Anthropic designer had put it together. This automation allows the PM to pivot away from annoying slide building and focus purely on making sure the plugged-in demos are amazing.
---
The Prompting and Iteration Process
Detailing the exact workflow used for the conference deck, the speaker shares their approximate prompt: "Make me a slide deck for the Code with Claude conference. This is what our PMM suggested it should cover. This is the current draft that I made that I don't like... Can you start by creating a proposed outline with details? Also, make sure it doesn't overlap too much with the keynote talk, which is more important."
Claude analyzed the provided links and generated an outline first, allowing the speaker to act as the final decision-maker on what content ultimately belonged in the product. The speaker decided the narrative should trace the progression from executing local tasks successfully, to making every PR green, to helping engineers land more PRs, picking the most compelling demo for each stage. Once the outline was approved, co-work spent a few hours building the entire deck.
To achieve the cohesive visual styling, the speaker uploaded a standardized 20-slide template that Anthropic uses for external engagements, allowing Claude to match their specific colors, fonts, and layouts. Users can also connect tools like a Figma MCP to pull in saved slide formats automatically.
---
Tool Stacks and the Rise of Custom internal Apps
The speaker’s day-to-day tool stack consists almost entirely of Claude Code, co-work, and Slack, describing Slack as the "core OS of our company." They spend roughly 30% of their time purposely pushing the boundaries of Cogram and Cogram Code to discover what the models are not good at and talking with the models to understand why mistakes happen.
A major unlock of Cogram Code across Anthropic is that it significantly lowers the barrier for anyone to create custom software. This has triggered a surge in hyper-specific internal tools. For example, a member of the sales team noticed they were repeatedly creating repetitive slide decks for customers (such as 101, 201, and Mastering Cogram Code presentations). Using Cogram Code, the salesperson built a custom web app that pulls specific customer context directly from Salesforce, Gong, and meeting notes to auto-tailor decks in seconds.
The automated app checks if a customer uses Bedrock or Console to toggle feature slides, highlights code review features if the client struggles with the SDLC review stage, and adds compliance slides if they require HIPAA controls. It also strips out Claude for Enterprise slides if the customer is strictly on Vertex or Bedrock. What used to take 20 to 30 minutes of manual work—or was skipped entirely in favor of a generic deck—now takes seconds. The speakers marvel at how Slack remains an undefeated, highly customizable piece of communication infrastructure that nobody wants to compete with, prompting a joke about it being "Time to buy some CRM stock."
---
Mid-Roll Sponsor: Vanta
The host introduces the season's supporting sponsor, Vanta, which helps over 15,000 companies—including Cursor, Ramp, Duolingo, Snowflake, and Atlassian—prove and earn trust with customers. While AI helps teams ship products faster than ever, it also introduces unprecedented risk to businesses and customer data. Security leaders often find themselves constantly reacting and guessing at priorities using outdated solutions. Vanta addresses this by automating compliance and risk management across more than 35 frameworks, including SOC 2, ISO 27001, and HIPAA. Listeners of the podcast are offered a $1,000 discount at [vanta.com/lenny](https://vanta.com/lenny).
---
Token Spending Beyond Engineering
Returning to the interview, the host asks about the distribution of AI usage within Anthropic. While engineering is naturally assumed to be the largest consumer of tokens, the host asks which non-engineering function takes second place. The speaker answers without hesitation, naming the Applied AI team as "amazing at pushing the boundaries" of what Claude Code and Co-work can accomplish.
[47:09](https://www.youtube.com/watch?v=PplmzlgE0kg&t=2829s) Inside the Applied AI Team: Token Giants and Technical Success
The Applied AI team plays a crucial role by working directly with customers to help them adopt APIs and implement new features. Their work is highly technical, essentially serving as a forward-deployed engineering and "technical go-to-market" group that drives both internal acceleration and customer product integration. Because of this high-touch responsibility, they are one of the heaviest token-consuming organizations within the company, relying heavily on tools like Co-work and Claude Code to build prototypes rapidly and manage massive volumes of customer inbound and historical context.
On a high-volume day, a team member might manage five to ten customer engagements. To stay on top of this workload, they use Claude to generate comprehensive "dossiers" or briefs the night before, asking the model to summarize upcoming meetings, remember historical action items, and recall top-of-mind customer needs. Furthermore, Claude acts as a research assistant, digging through platforms like Slack to find the latest ETAs for specific features so that the representative has absolute real-time knowledge during customer calls.
- Applied AI functions as a technical go-to-market and forward-deployed engineering team.
- Representatives use Claude to synthesize context from 5 to 10 customer meetings per day.
- Workflows include automated Slack research to retrieve real-time engineering ETAs for clients.
[49:25](https://www.youtube.com/watch?v=PplmzlgE0kg&t=2965s) The Economics of Token Consumption and Internal Governance
As models improve, knowledge workers and engineers steadily delegate more complex, multi-step tasks to AI, causing token spend per capita to spike with every major model jump. While some industry observers note a trend where individual token spend can theoretically exceed an employee's salary, internal usage remains lower than the average engineer's salary, though the percentage is growing. Interestingly, while team members have massive token access, they do occasionally hit limits, prompting lighthearted jokes internally to "shut it down" when boundaries are met.
Anthropic operates on a high-trust model regarding its internal computational resources. The company purposefully empowers its internal teams to build as fast as possible, operating on the assumption that everyone understands the true underlying cost of serving these advanced models. Because wasting tokens is heavily frowned upon, employees are expected to make responsible judgment calls, balancing creative experimentation with operational efficiency.
- Token cost per engineer increases with every major model jump or product improvement.
- Internal token consumption is managed via employee discretion rather than rigid, restrictive caps.
- Wasting tokens is culturally frowned upon due to a shared awareness of serving costs.
[51:15](https://www.youtube.com/watch?v=PplmzlgE0kg&t=3075s) Emerging Skills for AI Product Managers: Navigating Ambiguity and the "AGI Pill"
The hardest skill for a Product Manager in the AI space is the ability to define what a product should look like just a month into the future. Due to the rapid evolution of core models, PMs face extreme ambiguity regarding timeline capabilities and shifting user behaviors. The best product managers cut through this noise by watching how users "abuse the limits of the existing product" to spot emerging patterns, allowing them to set a steady direction while maintaining the flexibility to pivot if model capabilities overperform or underperform expectations.
A common pitfall is becoming inappropriately "AGI pilled." It is easy to design a product for a hypothetical, ultra-smart future model that needs nothing more than a simple text box because it can naturally ask clarifying questions and spin up its own tool integrations. The rare and truly valuable skill today lies in building for the *current* model—understanding how to elicit maximum capability, guide users onto the "golden path," and actively patch weaknesses while highlighting strengths.
- The baseline horizon for AI product definition is exceptionally short, often highly ambiguous month-to-month.
- Top PMs identify future product requirements by observing how users stretch and abuse current product limits.
- Designing for current model constraints is a rare skill compared to spec'ing for hypothetical super-intelligent AIs.
[53:19](https://www.youtube.com/watch?v=PplmzlgE0kg&t=3199s) Building Model Taste Through Self-Reflection and Evals
Developing strong product intuition or "taste" requires spending an immense amount of time interacting with models and investigating their quirks. One effective technique is asking the model to introspect and reflect on its own unexpected behaviors. For instance, if an agent makes a front-end change and runs tests but forgets to actually interact with the UI, a PM can ask it why it took that path. The model will often surface helpful diagnostics, admitting to confusing system prompts or noting that a sub-agent failed to verify its work, which reveals exactly how to fix the surrounding harness.
Beyond self-reflection, great product development relies on targeted feedback and structured evaluations. PMs need to identify a small, trusted group of about five "highly qualified" users who excel at articulating why a specific model-harness combination succeeds or fails. Additionally, building evals—even just ten high-quality ones—is an underappreciated but critical task for PMs and engineers alike, as it provides the team with a concrete way to quantify success and track progress.
- PMs use model introspection to diagnose system prompt issues and agent delegation failures.
- Fast feedback loops rely on a tight, curated group of roughly five highly articulate power users.
- Writing a small batch of 10 excellent evals is favored over managing hundreds of low-quality benchmarks.
[55:44](https://www.youtube.com/watch?v=PplmzlgE0kg&t=3344s) The Claude Team "Vibe Check" and the Power of Character
While the team collaborates with research pods to mathematically analyze Claude Code behaviors, a primary source of directional insight comes from casual team lunches. The team gathers and conducts a rapid "vibe check" on experimental models, collecting qualitative assessments on whether a model is being too abrupt, explaining its thinking thoroughly, or generating too many low-quality memories. This fast human evaluation yields explicit hypotheses that the team can later verify against larger datasets.
A massive differentiator for Claude is its distinct character, a highly ambiguous and difficult property crafted by a team member named Amanda. Unlike coding tasks that have binary verification passes, molding a personality requires immense conviction. Claude’s charm lies in being a low-ego, positive, and action-oriented coworker; if told it made a mistake, it reacts with an earnest "Oh, shoot... let me fix it," and if a task feels insurmountable, it breaks down the steps to help the user get started. This positivity and willingness to give earnest feedback rather than blindly agreeing is what makes it an enjoyable partner.
- Team lunches are leveraged as rapid human evaluation sessions to gather qualitative model "vibes."
- Model data analysis is driven by testing specific hypotheses generated from user feedback.
- Claude's low-ego personality traits—like apologizing and proposing collaborative next steps—are core to its product success.
[01:00:45](https://www.youtube.com/watch?v=PplmzlgE0kg&t=3645s) The Model Eating the Harness: Stripping Away Product Crutches
An ironic reality of building on cutting-edge AI is that as models grow smarter, product managers spend a lot of time removing features that were originally built as crutches. A classic example of this occurred during the early days of Claude Code. When tasked with large refactors across 20 different call sites, the early model would change five and abruptly stop. To solve this, a team member named Sid introduced a structural "to-do list" tool—mimicking a human developer's workflow in VS Code—and explicitly prompted the model to check off every item before finishing.
With the release of advanced models like Opus 4, this heavy prompting intervention became entirely obsolete. The newer models naturally execute thorough, multi-step changes across dozens of sites without needing to be constantly reminded of a checklist. While the to-do list remains in the UI as a nice visual anchor for users to monitor background progress, it has been heavily de-emphasized because the underlying model "eats the harness," simplifying the product scaffolding over time.
- Early versions of Claude Code required a programmatic to-do list to successfully complete 20-site code refactors.
- Advanced models like Opus 4 naturally execute complete refactors without explicit checklist prompting.
- Product evolution in AI involves systematically removing prompting interventions and structural crutches as core capabilities mature.
[01:03:10](https://www.youtube.com/watch?v=PplmzlgE0kg&t=3790s) Unlocking New Product Capabilities with Advanced Models
When launching a new model, the team systematically reviews the entire system prompt to determine if certain reminders are no longer necessary and can be removed. However, the most thrilling aspect of new models is how they unlock entirely new features that were previously impossible. The team often tests product ideas with older models, but the accuracy is frequently too low to justify a launch. A prime example is their code review product. They had attempted to build it several times and even launched simpler iterations, such as a `/codereview` command, but it was not until the arrival of the most recent models that the feature reached true viability.
The breakthrough occurred with models like Opus 4.5, 4.6, and Sonnet 4.6. The capabilities jumped so significantly that the company's own engineering team now relies on the automated code review to pass before merging pull requests (PRs). The team had long dreamed of Claude acting as a reliable reviewer that could confidently catch the majority of bugs. With these advanced models, they can now run multiple code review agents simultaneously to traverse the entire codebase and synthesize a concrete set of real issues an engineer must address before merging. This reflects a broader trend often discussed on the podcast: building products at the absolute edge of what is currently possible, knowing that the next model drop will close the gap and put you ahead of the competition.
- The team launched simpler versions of code review in the past using the `/codereview` command.
- The breakthrough in reliable code review was unlocked by models like Opus 4.5, Opus 4.6, and Sonnet 4.6.
- The company's own engineering team now requires this AI code review to pass before merging PRs.
---
[01:05:12](https://www.youtube.com/watch?v=PplmzlgE0kg&t=3912s) The Long-Term Vision of Building Blocks and Multi-Clouding
The long-term vision for products like Claude Code and Coda (referred to as "Cork") is anchored in fundamental "building blocks." The baseline building block is making individual, discrete tasks successful based on a clear prompt description, resulting in acceptable output that can be merged or shared. As models grow more intelligent, the task success rate skyrockets, prompting a shift toward executing multiple tasks simultaneously. This phenomenon, dubbed "multi-cloding," became a major trend toward the end of 2025 and has only accelerated since.
Looking ahead, the team is extrapolating this trend from running six tasks at a time to running 50 or hundreds of Claudes simultaneously. This shift requires entirely new infrastructure because users will no longer be able to run these processes locally due to RAM limitations; they will have to run remotely. The product challenge then becomes designing user interfaces that help a human easily monitor which tasks need attention, ensuring the agent fully verifies its own work so the user can trust it implicitly, and creating a self-improving feedback loop so the model never repeats a mistake.
- "Multi-cloding" emerged as a major trend toward the end of 2025.
- Future workflows will involve running 50 to hundreds of Claudes simultaneously, necessitating remote infrastructure due to local RAM constraints.
---
[01:07:23](https://www.youtube.com/watch?v=PplmzlgE0kg&t=4043s) Thriving in an AI-Driven World: Navigating the 100% Automation Gap
For product managers, founders, and cross-functional professionals worried about their career longevity, the core advice is to lean into the massive leverage AI provides. Whenever a professional catches themselves performing a manual, repetitive task, they should think about how to use tools like Claude Code or Coda to automate it. AI is perfectly suited to absorb the tedious, hated parts of a job, allowing humans to reallocate their energy toward creative pursuits or long-neglected "pet projects" that the company previously lacked the bandwidth to execute.
However, a common trap is getting an automation to 90% or 95% accuracy and giving up. "If an automation doesn't work 100% of the time, it's not really an automation." Reaching that final 5% to 10% requires a significant investment of time and "elbow grease" to teach Claude specific preferences and iterate on feedback, but a 95% automation holds very little practical value if it occasionally lets a critical error slip through.
The host admits to being deeply guilty of this, sharing an anecdote about a 95%-accurate email workflow designed to filter out podcast pitch spam into a "spammy" folder, which occasionally swallows important emails. The speaker relates, noting their own time-consuming and imperfect attempts to train Coda to get to inbox zero on Gmail. To fix this, the team is actively working to simplify the user experience for customizing commands, which currently requires users to understand complex, disjointed concepts like defining skills, applying feedback, and verifying that the skill updated correctly.
- True automation requires reaching 100% accuracy, as 95% accuracy leaves users unable to fully rely on the tool.
- The host uses an AI workflow to sort spammy podcast pitches into a specific folder but notes it occasionally misses legitimate emails.
- Current barriers to customization require users to manually manage skills, apply feedback, and read back the updated skills within the software.
---
[01:11:58](https://www.youtube.com/watch?v=PplmzlgE0kg&t=4318s) Action-Based Agents vs. The Obsession with Over-Customization
A critical mistake people make when tinkering with AI is building prototype apps that they don't actually use on a daily basis. True leverage and learning only happen through sustained, everyday utility; a one-shot prototype that doesn't consistently save time adds no real value. On the flip side of the spectrum, there is a distinct community—highly visible on Twitter—that becomes entirely obsessed with over-customizing their setups, adding endless skills, workflow improvements, and Model Context Protocols (MCPs). This hyper-optimization can ironically become a distraction from the core goal of launching an actual feature or product, proving that simple setups often work best.
This dichotomy aligns with a perspective recently shared by Andrej Karpathy regarding a massive cultural divide in AI adoption. On one side are the cynics who tried early LLMs in the past, deemed them terrible, and gave up. On the other side are the power users, particularly programmers, who see the intense power of modern tools. The core shift causing this divide is that the 2024 generation of products was entirely chat-based, whereas the modern generation of products is action-based. The true "aha moment" happens when a user experiences an agent performing actions directly on their behalf—such as the Claude Chrome extension filling out a web form automatically—rather than simply dispensing text advice.
- The 2024 generation of AI products was primarily chat-based, whereas the newer generation is entirely action-based.
- Hyper-customizing setups with MCPs and skills can become a productivity trap; simpler setups often perform better.
- Features like the Claude Chrome extension provide an eye-opening experience by physically interacting with user interfaces (e.g., filling out forms).
---
[01:15:22](https://www.youtube.com/watch?v=PplmzlgE0kg&t=4522s) The Lightning Round: Historical Transitions and the Purity of Sport
Entering the lightning round, the speaker shares three core book recommendations. The first is *How Asia Works*, which analyzes the government policies and economic development frameworks that establish long-lasting, successful economies. The second is *The Technology Trap*, a book detailing how previous technological milestones like the Industrial Revolution and the computer revolution impacted human workers, offering vital historical guardrails for navigating our current AI transition. On a lighter note, they recommend *The Paper Menagerie*, a collection of short stories weaving together coming-of-age themes, self-discovery, and AI.
When asked about favorite media, the speaker highlights the sports documentary series *Drive to Survive* and the documentary film *Free Solo*. They find immense satisfaction in watching individuals display total obsession toward a singular engineering or physical goal. As a rock climber themselves, the speaker notes that watching Alex Honnold climb El Capitan without a harness in *Free Solo* becomes even more terrifying and mind-blowing the more you actually know about the sport. The physical moves Honnold executes seamlessly on the rock face are feats the speaker feels they could never replicate in a safe climbing gym even one foot off the ground with a rope.
- *How Asia Works* focuses on the macroeconomics and policies of successful Asian economies.
- *The Technology Trap* explores worker impacts during the Industrial and Computer Revolutions.
- *The Paper Menagerie* is a fiction anthology featuring short stories about AI and self-discovery.
- The speaker is an active rock climber, giving them unique insight into the extreme difficulty of the route featured in *Free Solo*.
[01:17:50](https://www.youtube.com/watch?v=PplmzlgE0kg&t=4670s) The Secondary Order Effects of Waymo
Following a brief mention of a sad documentary about a young climber on ice mountains, the conversation shifts to rapid-fire questions, starting with recently discovered favorite products. Cat enthusiastically reveals that outside of cloud products, the absolute biggest life-changing discovery has been Waymo. Describing themselves as a "die-hard Waymo user," Cat relies on the autonomous ride-hailing service twice a day to commute to and from work. The host reflects on how fascinating these "second order effects of of technology" are as they dive into the specific behavioral shifts caused by autonomous vehicles.
Cat highlights two major reasons for this preference. First, there is no psychological guilt or pressure when the vehicle is waiting; unlike with a human driver, Cat feels no rush to be waiting "right at the curbside the moment it arrives." Second, the lack of a human driver drastically boosts personal productivity. When riding with a stranger, Cat feels too rude to open a laptop or take work calls. Waymo completely removes that social anxiety, eliminating worries about someone overhearing confidential information, talking too loudly, or needing to ask a driver to change the music. Cat notes that this freedom essentially gives back 30 minutes of productive time every single day. Interestingly, despite initially believing that autonomous vehicles needed to be priced lower than Uber or Lyft to succeed, Cat is now "very happy to pay a 2x premium" for the service. The host agrees wholeheartedly, noting how quickly people move from thinking the driverless technology is "insane" to completely forgetting about it. The trend is so prevalent at Anthropic that it has shifted the internal vernacular, with employees now casually asking, "is Waymo here?" instead of referring to a generic ride-share.
* **Commute Frequency:** Used twice a day for traveling to and from work.
* **Time Reclaimed:** Approximately 30 minutes of daily productivity saved.
* **Pricing Premium:** Willingness to pay a 2x premium over traditional ride-sharing apps.
---
[01:19:30](https://www.youtube.com/watch?v=PplmzlgE0kg&t=4770s) "Just Do Things" and the Startup Mindset
When asked for a favorite life motto, Cat offers a simple but impactful philosophy: "Just do things." The host notes that this completely tracks with Cat's personality. Cat explains that while first principles thinking is incredibly valuable for deducing the right course of action and articulating it to stakeholders, execution is where people get stuck. In Cat's view, "jobs are fake." Once you understand the baseline constraints, you should figure out what needs to happen, execute quickly, learn from the inevitable mistakes, and apologize or fix things if they go wrong.
This philosophy directly fights the rigid corporate structures where roles (PM, designer, engineer) and code base ownership are strictly partitioned. The "just do things" mentality empowers people to operate autonomously across rigid team boundaries to simply get things done. The host identifies this trait as "agency" or a "bias towards action"—the crucial skill of not waiting for permission. Cat credits their formative time at Scale, back when it was a lean team of just 20 people, as the life-changing experience that built this muscle. With no set processes and massive, hairy problems to solve, the leadership team, including Alex, empowered everyone to utilize any tool at their disposal without caring about traditional boundaries between sales, operations, or engineering. The host points out that this requires an active unlearning of the traditional schooling system, where students are conditioned to strictly do what they are told to get a good grade.
---
[01:21:46](https://www.youtube.com/watch?v=PplmzlgE0kg&t=4906s) Claude's "Thinking Words" and Post-AGI Aspirations
The host moves to a lighter technical query regarding the internal "thinking words"—which the host notes recently leaked in the source code—that Claude utilizes while processing a prompt. When asked if they have a favorite, Cat smiles and names "manifesting," revealing that they even have it as a custom sticker on their laptop. The host laughs, declaring it "clearly the winner."
Turning to a heavier final philosophical question previously asked to Boris, the host inquires what Cat plans to do with their time if artificial general intelligence (AGI) arrives in their lifetime and renders traditional work optional. Cat predicts that it will actually take a long time for AGI to fully diffuse across society, meaning the immediate phase will involve "helping bring the world along." However, on a non-serious, personal note, Cat plans to escape to the outdoors. The dream is to move to Fontainebleau, France, to live among "10,000 boulders" and do a lot of serious rock climbing. Additionally, Cat looks forward to tackling a massive reading backlog. Currently averaging about 0.5 books a week, Cat's ultimate goal is to read one to two books per week to absorb history and explore technical subjects like physics, robotics, hardware, and aerospace—learning them simply for the joy of it, even knowing an AGI would already master them.
* **Current Reading Pace:** Around 0.5 books per week.
* **Target Reading Pace:** 1 to 2 books per week.
* **Areas of Interest for Future Study:** History, physics, robotics, hardware, and aerospace.
---
[01:23:26](https://www.youtube.com/watch?v=PplmzlgE0kg&t=5006s) Sourcing Edge Cases and Community Feedback
As the conversation wraps up, the host asks how listeners can follow Cat online and support their work. Cat shares their Twitter handle, `_catwo`, noting that they actively read all of their DMs even if they cannot personally reply to every single one. When it comes to being helpful, Cat emphasizes that the Anthropic team is incredibly eager to receive critical product feedback. While they love positive reinforcement, the team truly "thrives on edge cases, errors," and specific, reproducible tasks where Claude Code and Co-work fail.
Sharing these failures directly enables the engineering team to build better testing harnesses and improve future generations of models. The host points out that the developer community on Twitter is never shy about sharing complaints, and praises the Anthropic team for being so visible and responsive on social platforms. Cat validates this, explaining that user interactions directly fuel the team's momentum. Inside Anthropic, they maintain two dedicated Slack channels: a "user love" channel where they cross-post community success stories to give the team energy, and a feedback channel where product issues are funneled so the broader team can immediately act on them. The episode concludes with warm thank-yous and the host's standard sign-off, directing listeners to subscribe on Apple Podcasts, Spotify, or visit lennyspodcast.com.
* **Twitter Handle:** `_catwo`
* **Core Products Mentioned:** Claude Code and Co-work.
* **Internal Communication Channels:** "User love" channel for success stories and a dedicated feedback channel for product errors.
## Notable quotes
> [15:27](https://www.youtube.com/watch?v=PplmzlgE0kg&t=927s) Like there are many engineers on our team who are fully able to end-to-end go from see user feedback on Twitter through to like ship a product at the end of the week with almost no product involvement. And this I think is actually like the most efficient way to ship something. — Cat Wu
> [20:03](https://www.youtube.com/watch?v=PplmzlgE0kg&t=1203s) Like I feel like there are a lot of weeks where maybe Sunday night there's some like P0, and then by Monday there's like a P00, and by Monday afternoon there's a P000, and you're like, 'Wow, I can't believe I was so worried about that P0 from Sunday.' — Cat Wu
> [28:32](https://www.youtube.com/watch?v=PplmzlgE0kg&t=1712s) mission means that teams are willing to make sacrifices that hurt their own goals and their own KRs in service of Anthropic's goals and Anthropic's KRs — Cat Wu
> [55:44](https://www.youtube.com/watch?v=PplmzlgE0kg&t=3344s) Oh, shoot... let me fix it — Claude
> [01:07:23](https://www.youtube.com/watch?v=PplmzlgE0kg&t=4043s) If an automation doesn't work 100% of the time, it's not really an automation. — Cat Wu
> [01:19:30](https://www.youtube.com/watch?v=PplmzlgE0kg&t=4770s) Just do things — Cat Wu
## Mentioned
Anthropic, Cat Wu, Claude Code, Cowork, Lenny Rachitsky, Lenny's Podcast, Boris Cherny, WorkOS, Vanta, Amol, Diane, Alex, Mythos, OpenClaw, Figma, Salesforce, Gong, Bedrock, Vertex, Slack, Opus 4, Sid, Opus 4.5, Opus 4.6, Sonnet 4.6, Coda, Cork, Model Context Protocols, MCPs, Andrej Karpathy, Claude Chrome extension, How Asia Works, The Technology Trap, The Paper Menagerie, Drive to Survive, Free Solo, Alex Honnold, Waymo, Scale, Fontainebleau
Cat Wu, Head of Product for Claude Code, explains that Anthropic maintains rapid shipping cycles by designing around current model capabilities rather than hypothetical future AGI, shifting the product management focus from long-term roadmap coordination to product taste, rapid validation, and lean execution.
Streamlined Playbooks and Compressing Delivery Timelines (4:30)
Anthropic compresses traditional multi-quarter feature cycles down to weeks or days. Wu attributes this velocity to three operational practices: defining narrow, single-purpose goals (such as enabling enterprise developers to safely reach zero permission prompts), labeling experimental releases as "research previews" to lower public support commitments, and routing dogfooded features into an "evergreen launch room" where marketing and developer relations deploy collateral within 24 hours.
Traditional Product Requirement Documents (PRDs) are largely reserved for complex, multi-month infrastructure projects. For routine feature iteration, the lean 30- to 40-person product organization relies on weekly metric readouts and clear team trade-off principles. This structural clarity empowers individual engineers to ship autonomously without waiting for consensus across layers of management.
Blurring Technical Roles and Prioritizing Product Taste (15:27)
Because AI-assisted development makes generating code dramatically cheaper, Wu argues the critical bottleneck in software development has shifted from execution to "product taste"—the ability to identify what to build, design intuitive user experiences, and ruthlessly filter through thousands of inbound user requests. Rather than freezing technical headcount and hiring more product managers to oversee acceleration, Anthropic prioritizes hiring engineers who possess product taste and can independently take user feedback directly to production within a week.
Technical backgrounds remain a significant advantage across the product organization: nearly all PMs and designers on Wu's team have engineering experience or write code. Direct technical intuition enables builders to immediately distinguish between a simple one-hour task and an expensive, multi-week undertaking, though Wu notes that rapid leaps in model capabilities make long-term role forecasting volatile beyond several months.
Designing for Current Models Over Hypothetical Super-AGI (51:15)
Wu cautions product teams against becoming "AGI pilled"—specifying software for hypothetical super-intelligent systems that require only a simple text box. The valuable skill today lies in understanding the limitations of existing models, observing how users abuse product boundaries, and guiding workflows onto a reliable golden path. Teams develop this intuition through model introspection, team lunch "vibe checks," and targeted test suites built around roughly ten high-quality evaluations rather than sprawling benchmarks.
As underlying models mature, product evolution frequently involves stripping away earlier scaffolding. For example, early Claude Code iterations required an explicit "to-do list" harness to prevent models from abandoning multi-site code refactors prematurely. With models like Opus 4, Sonnet 4.6, and Opus 4.5, models execute these multi-step refactors natively, rendering the heavy prompting harness obsolete and unlocking autonomous, multi-agent code reviews that Anthropic now requires before internal pull requests merge.
Mission Trade-Offs and the Reality of Scaled Automation (28:32)
Maintaining high shipping velocity requires structural sacrifices. Anthropic accepts feature overlap and product inconsistency, letting the market decide between competing form factors and deploying tools like the `/powerup` onboarding command when user education burdens escalate. Internal consensus is maintained by prioritizing the company's safe AGI mission above team-level key results (KRs), which Wu cites as the reason behind difficult prioritizations, such as restricting third-party "Open Claude" interface access to protect compute stability for first-party enterprise tiers.
Looking toward long-term workflows, Wu identifies a shift from local single-task execution to "multi-cloding"—running dozens or hundreds of Claudes simultaneously via remote infrastructure to bypass local RAM constraints. However, Wu warns that realizing true operational leverage requires closing the 100% reliability threshold, noting that automations hovering at 90% to 95% accuracy still require constant human supervision and fail to function as genuine automations.
While Anthropic's model demonstrates that low-process environments and high-trust engineering can sustain daily production releases, this velocity deliberately shifts the burden of feature consistency and workflow education onto users. An ongoing industry challenge remains closing the final 5% automation reliability gap and engineering remote infrastructure capable of managing hundreds of simultaneous agents.
[15:27] Cat Wu: Like there are many engineers on our team who are fully able to end-to-end go from see user feedback on Twitter through to like ship a product at the end of the week with almost no product involvement. And this I think is actually like the most efficient way to ship something.
[20:03] Cat Wu: Like I feel like there are a lot of weeks where maybe Sunday night there's some like P0, and then by Monday there's like a P00, and by Monday afternoon there's a P000, and you're like, 'Wow, I can't believe I was so worried about that P0 from Sunday.'
[28:32] Cat Wu: mission means that teams are willing to make sacrifices that hurt their own goals and their own KRs in service of Anthropic's goals and Anthropic's KRs
[55:44] Claude: Oh, shoot... let me fix it
[67:23] Cat Wu: If an automation doesn't work 100% of the time, it's not really an automation.
[79:30] Cat Wu: Just do things
Original transcript
[0:00] I think it is very hard to be the right
[0:01] amount of AGI pilled. It's very easy to
[0:04] build a product for the super AGI strong
[0:07] model. The hard thing is figuring out
[0:09] for the current model, how do you elicit
[0:12] the maximum capability?
[0:13] >> I've never seen anything like the pace
[0:15] you folks at Anthropic are shipping at.
[0:17] >> We want to remove every single barrier
[0:19] to shipping things. The timelines for a
[0:21] lot of our product features have gone
[0:23] down from 6 months to 1 month and
[0:25] sometimes to even 1 day.
[0:27] >> You're interviewing hundreds of PMs and
[0:29] you just keep feeling like they're
[0:30] approaching it very incorrectly.
[0:32] >> The PM role is changing a lot. It's
[0:34] changing really quickly. The thing that
[0:36] is extremely important for building AI
[0:37] native products is iterating so quickly.
[0:40] Figuring out a way for you to actually
[0:42] launch features every single week.
[0:44] >> What do you think are the emerging
[0:45] skills PMs need to develop?
[0:48] >> back to product taste. As code becomes
[0:50] much cheaper to write, the thing that
[0:52] becomes more valuable is deciding what
[0:54] to write.
[0:56] >> Today my guest is Kat Wu, head of
[0:58] product for Cloud Coding who work at
[1:00] Anthropic. Kat is at the center of
[1:02] everything that is changing in AI and
[1:05] product and building and she and her
[1:07] team are building the product that is
[1:09] most changing the way that we all build
[1:11] our products. She is so full of insights
[1:14] and wisdom and lessons. This is an
[1:16] episode you cannot miss. Before we get
[1:19] into it, don't forget to check out
[1:20] Lenny's product pass.com for an insane
[1:23] set of deals available exclusively to
[1:25] Lenny's newsletter subscribers. With
[1:27] that, I bring you Kat Wu.
[1:32] Kat, welcome to the podcast.
[1:35] >> Thanks for having me.
[1:37] >> I have so many questions. I'm so excited
[1:39] to have you on this podcast. I want to
[1:41] start with giving people an
[1:42] understanding of your role alongside
[1:45] Boris. Uh everybody knows Boris. This
[1:48] he's his episode is the number one most
[1:50] popular episode on this podcast. No
[1:51] pressure.
[1:52] He uh created Cloud Code. He leads the
[1:54] eng team, ships a a bazillion PRs a day
[1:57] from his phone just like
[1:59] I don't even know what the number is
[1:59] anymore.
[2:01] I think people don't give you enough
[2:02] credit for the success that Claude code
[2:05] has had and co-work and all the things
[2:06] y'all are building.
[2:08] Help us understand your role on the
[2:10] team, how you work with Boris, how you
[2:11] split responsibilities, just like what
[2:13] does the PM role look like on on the
[2:15] Claude code team?
[2:16] >> I feel very lucky to work with Boris.
[2:17] He's been an amazing thought partner.
[2:19] He's our tech lead, he's very much the
[2:22] product visionary, and he is great at
[2:25] setting like this is what the product
[2:27] needs to be in like 3 months, 6 months
[2:29] from now. This is like what the AGI pill
[2:31] version of the product is.
[2:33] And a lot of my role is figuring out,
[2:35] okay, what is the path from where we are
[2:37] today to like that vision 3 to 6 months
[2:40] from now. And I I spend more of my time
[2:44] on the cross-functional, so making sure
[2:45] that our marketing team, sales team,
[2:49] finance, capacity, etc. are like bought
[2:51] in on the plan and that we're all rowing
[2:54] the same direction. And that once the
[2:56] feature is ready, that there aren't any
[2:58] blockers to shipping it. I think in many
[3:00] ways it works well because we kind of
[3:02] like mind meld, but it is actually like
[3:04] remarkably blurry of a line. Like I
[3:07] think we're like 80% mind meld, and then
[3:09] there's like this 20% of things that
[3:11] like maybe I care a lot more about than
[3:13] Boris, so like I'll drive those and then
[3:15] like 20% where he cares a lot more than
[3:17] me and he just like drives those.
[3:20] >> This episode is brought to you by our
[3:21] season's presenting sponsor WorkOS. What
[3:24] do OpenAI, Anthropic, Cursor, Vercel,
[3:27] Replit, Sierra, Clay, and hundreds of
[3:30] other winning companies all have in
[3:31] common? They are all powered by WorkOS.
[3:34] If you're building a product for the
[3:36] enterprise, you've felt the pain of
[3:37] integrating single sign-on, SCIM, RBA,
[3:40] audit logs, and other features required
[3:43] by large companies. WorkOS turns those
[3:45] deal blockers into drop-in APIs with a
[3:48] modern developer platform built
[3:49] specifically for B2B SaaS. Literally
[3:52] every startup that I'm an investor in
[3:54] that starts to expand upmarket ends up
[3:56] working with WorkOS. And that's because
[3:58] they are the best. Whether you are seed
[4:00] stage startup trying to land your first
[4:02] enterprise customer or a unicorn
[4:04] expanding globally, WorkOS is the
[4:06] fastest path to becoming enterprise
[4:08] ready and unblocking growth. It's
[4:10] essentially Stripe for enterprise
[4:12] features. Visit workos.com to get
[4:14] started or just hit up their Slack where
[4:16] they have actual engineers waiting to
[4:18] answer your questions. WorkOS allows you
[4:20] to build faster with delightful APIs,
[4:22] comprehensive docs, and a smooth
[4:24] developer experience. Go to workos.com
[4:27] to make your app enterprise ready today.
[4:30] Something that you shared actually
[4:31] before we started recording is the fact
[4:33] that you're interviewing hundreds of PMs
[4:36] all the time. Like, if I had a nickel
[4:37] every time someone asked me for an intro
[4:38] to someone at Anthropic to go work at
[4:40] Anthropic as a PM, I'd be I'd be I'd
[4:42] have 30 billion in ARR.
[4:45] It's just like the number one place
[4:46] people want to go work at. So, I can
[4:48] only imagine how many PMs you're
[4:49] interviewing.
[4:50] You told me that you're just seeing
[4:52] people doing it doing it wrong. The way
[4:54] they're approaching what they think it
[4:56] takes to be a successful AI PM. Talk
[4:58] about what you're seeing and what people
[5:00] need to understand about what it is what
[5:02] it takes to be successful these days.
[5:03] >> I think before AI, technology shifts
[5:06] were a lot slower, so you could plan on
[5:08] these 6 to 12-month time horizons. And
[5:12] because you were shipping features at a
[5:13] bit of a slower rate, there was a lot
[5:16] more emphasis on coordinating with all
[5:18] the other partner teams to make sure
[5:20] that they're shipping features that
[5:22] unblock your features because code at
[5:24] that time was very expensive to make.
[5:26] Um I think now with AI and with how much
[5:29] that has accelerated engineering and
[5:32] with how quickly the model capabilities
[5:34] are improving, the timelines for a lot
[5:37] of our product features have gone down
[5:39] from 6 months to 1 month and sometimes
[5:41] to 1 week or even 1 day. And with that,
[5:44] we actually need to make sure that
[5:47] products ship quite quickly. And what
[5:50] that means is as a PM, there should be
[5:53] less emphasis on
[5:55] making sure that you're aligning your
[5:58] like multi-quarter roadmaps with your
[5:59] partner teams, and more emphasis on,
[6:02] okay, how can we figure out the fastest
[6:04] way to get something out the door? How
[6:06] can we figure out how to make like a
[6:08] concept corner of our product suite
[6:11] where we can just
[6:13] an engineer has an idea or a PM has an
[6:14] idea, and like by the end of the week,
[6:17] we are able to get into our users'
[6:18] hands. I I think the PMs who do the best
[6:21] on AI native products
[6:24] are are the ones who can figure out, how
[6:26] can I like shorten the time from having
[6:28] this idea to actually getting the
[6:30] product in the hands of users, and help
[6:32] define what are the most important tasks
[6:34] that need to work out of the box for my
[6:36] product.
[6:37] >> So, what I love about this is what
[6:38] you're saying is just like people
[6:40] haven't grasped how fast they need to
[6:43] move and what how much of the job now is
[6:45] just moving is helping the team move
[6:47] fast.
[6:48] What what helps do that? What do you
[6:51] What do you do? What does your PM team
[6:52] do to help them move this fast other
[6:55] than have access to the the most
[6:56] advanced models?
[6:57] >> I think the first thing is to set clear
[7:00] goals. Because LLMs are so general, that
[7:03] actually creates a lot of ambiguity in
[7:05] who we're building for, what problems
[7:06] we're trying to solve, what the top use
[7:08] cases are. And so, I think a great PM is
[7:10] able to say, okay, our our key user is
[7:14] professional developers. Uh the main
[7:15] problem uh the main problem that we want
[7:17] to solve for this feature is maybe
[7:19] there's like too many permission
[7:21] problems and people are feeling fatigue,
[7:23] and like the the use case is we we want
[7:27] professional developers at enterprises
[7:29] to safely get to zero permission
[7:31] prompts. And that actually sets a pretty
[7:32] clear goal because it it rules out a lot
[7:35] of potential approaches for reducing
[7:37] permission prompts so that people can uh
[7:40] I a lot more done with one prompt.
[7:42] And then I think the second thing that's
[7:44] very important is figuring out some
[7:47] repeatable process for getting these
[7:49] features shipped. So, uh for Cloud Code,
[7:52] what we do is we actually ship almost
[7:54] all of our features in research preview.
[7:56] We clearly brand this um when we ship
[7:58] something so that users know that this
[8:01] is an early product. This is just an
[8:02] idea. This is just something that we're
[8:04] trying to get feedback on and iterating
[8:06] on and that this might not be supported
[8:08] forever.
[8:09] And what this does is it reduces it
[8:11] reduces our commitment for shipping
[8:13] something. We can just get something out
[8:15] in a week or two.
[8:17] And the third thing that a PM should do
[8:19] is help create the framework for the
[8:20] team so that they know when to pull in
[8:23] cross-functional partners and what those
[8:24] cross-functional partners' expectations
[8:26] are. So, for example, we have a really
[8:29] tight process between engineering,
[8:31] marketing, and docs. So, when engineers
[8:34] have a feature that they feel is ready
[8:36] and that we've dogfooded internally,
[8:38] they post it in our evergreen launch
[8:40] room. And then Sarah, who leads our
[8:42] docs, and Alex, who leads PMM, and Tarek
[8:45] and Lydia on DevRel just like jump in
[8:47] and can turn around the the marketing
[8:50] announcement for it the very next day.
[8:52] And because we have this really tight
[8:53] process, it lowers the friction for any
[8:55] engineer to ship something. Um PM is the
[8:57] role that should be setting this up.
[8:59] >> How do PRDs fit into this? So, the fact
[9:01] that you said that goals are really
[9:03] important part of just like being
[9:03] aligned on what does success look like?
[9:05] Who is this for? Who is this not for?
[9:07] Are you writing PRDs? Is it just like a
[9:08] couple bullet points? How does How does
[9:10] that evolve in the the world of a PM?
[9:11] >> So, there's two two things that we do.
[9:14] One is we have very rigorous metrics and
[9:17] we do metrics readouts with the entire
[9:19] team every week. The goal of this is to
[9:21] make sure that everyone deeply
[9:22] understands all the facets of our
[9:24] business, what our key goals are, how
[9:26] they're trending, and what drives them.
[9:29] The second thing that we do is we have
[9:31] this list of team principles.
[9:33] And this includes who our key users are,
[9:36] why those are our key users, and the
[9:39] reason that we articulate all of this is
[9:41] so that everybody on the team feels like
[9:43] they understand how our business works,
[9:45] they understand what's important to us,
[9:47] and what we're willing to trade off, and
[9:49] it lets people make decisions by
[9:50] themselves without feeling like they're
[9:52] blocked on PM or any other stakeholder.
[9:55] >> I love how so much of this is like,
[9:56] okay, we still need PMs in the future.
[9:58] There's so much talk of like, why do we
[9:59] need PMs? We're just going to ship and
[10:01] build, we need engineers.
[10:03] >> Oh, we actually do PRDs sometimes. So, I
[10:05] I think for our features that are like
[10:06] particularly ambiguous, it it does help
[10:09] to write out just a one-pager on what
[10:11] the goals are, uh what the delightful
[10:14] use cases are, what the failure modes
[10:17] currently are that we need to fix. And
[10:19] there are occasionally some projects,
[10:21] especially things that require heavy
[10:23] infrastructure, that do take many
[10:25] months, and for those situations, we do
[10:27] write PRDs still.
[10:29] >> I want to drill a little bit further
[10:30] into just how you're able to move so
[10:33] fast. I've never seen anything like the
[10:36] pace folks at Anthropic are shipping at.
[10:38] Like, someone made this calendar of
[10:41] launches across Anthropic, and it was
[10:43] literally every day there was like a
[10:45] major feature or product. So, one
[10:48] question people had online is uh you
[10:50] guys just launched this uh incredible
[10:52] not launched but built this incredible
[10:54] model, Mythos, that is still in preview
[10:56] cuz it's so powerful people are a little
[10:58] afraid of what it can do.
[10:59] Have you guys been using this? Is this
[11:01] part of the reason you've been able to
[11:02] move so fast?
[11:03] >> We've been moving pretty fast for
[11:06] several quarters now, so I think it it's
[11:09] not fully Mythos. Um Mythos is an
[11:11] incredibly powerful model. We do use the
[11:13] models internally, and I think this has
[11:16] increased our rate of shipping a little
[11:18] bit, but I don't think it explains the
[11:20] bulk bulk of the increase. I I think a
[11:22] lot of it is the process and the
[11:24] expectation on the team. So, we're very
[11:26] low on process. We want to remove every
[11:29] single barrier to shipping things. We
[11:31] want to make sure every single person on
[11:32] our team feels empowered to take their
[11:35] idea from just an idea to like out in
[11:37] the world in less than a week. Sometimes
[11:40] even in a day.
[11:41] >> Cool. Oh man, what a what an advantage
[11:43] to have the best model and also be
[11:45] building product at Circle.
[11:46] >> We are very lucky to be able to work
[11:48] with the frontier models.
[11:49] >> Oh my god, what a
[11:51] what an awesome advantage. Just like
[11:52] build a thing and then use it and then
[11:53] accelerate faster. It's so interesting.
[11:55] There's a couple like these other side
[11:56] things I want to just kind of go on
[11:57] these like side quests what on this
[11:59] conversation. There's so much happening
[12:00] with Anthropic and I just I'm so curious
[12:02] to get your insight.
[12:03] One is uh a week ago or so the whole
[12:06] source code of Claude code leaked.
[12:08] Somebody got it out there. You think it
[12:09] was a mistake someone made. Is there
[12:11] anything you comment there? Just like
[12:12] what happened? What went wrong? What
[12:14] should people know?
[12:15] >> So we immediately looked into this when
[12:17] we saw it. Um we realized that this was
[12:20] the result of human error. There was um
[12:23] a human working with Claude to write a
[12:25] PR. This was just an update to how we
[12:27] release our packages. And it actually
[12:31] went through two layers of human review.
[12:32] And so that this was a result of human
[12:35] error and we've hardened our processes
[12:37] to make sure that it doesn't happen in
[12:39] the future.
[12:40] >> Is this person still at Anthropic? Are
[12:41] they doing all right?
[12:42] >> Yes, yes. It's it's a process failure
[12:44] and the most important thing is to just
[12:46] like learn from it and to add more
[12:48] safeguards so that doesn't happen again.
[12:50] And so that's that's what we've been
[12:51] focused on and most of those have
[12:53] shipped.
[12:54] >> Okay. Uh another question I had is open
[12:56] claw.
[12:58] Uh so recently there's been this move to
[13:02] keep people from using Claude's
[13:03] subscription with their open claws.
[13:06] People get I got really upset. They're
[13:08] confused why this is happening. It feels
[13:10] like you're there's like I know harm
[13:12] caused to the open source community.
[13:14] What what are people What do people need
[13:16] to understand about kind of what went
[13:17] into this decision?
[13:18] >> So we've been seeing a lot of demand for
[13:20] Claude.
[13:21] And we've been working very hard to both
[13:23] scale our infrastructure and also to
[13:25] make our harness more token efficient so
[13:27] that you can get more usage out of it.
[13:29] It wasn't designed for third-party
[13:32] products which have different uh usage
[13:34] patterns than our first-party ones. We
[13:37] spent a bunch of time
[13:39] trying to figure out what is the most
[13:42] seamless transition that we can offer.
[13:44] And so, I was very happy to be able to
[13:47] say that everyone gets some credits
[13:48] alongside their subscription.
[13:50] But yeah, we we did have to make the
[13:52] hard decision that we needed to
[13:54] prioritize our first-party products and
[13:56] our API. And so, this is the this is the
[13:59] decision that resulted from that.
[14:01] >> Yeah, this like to me it makes so much
[14:02] sense. Like you guys are subsidizing
[14:05] this usage at like 200 bucks a month and
[14:07] there's like it's like basically
[14:09] unlimited use of this and like I think
[14:11] people don't understand businesses are
[14:13] trying to make money. We're trying to be
[14:14] profitable here. We can't just like give
[14:16] away compute when it's so in demand. So,
[14:18] I get it. Coming back to the PM team,
[14:21] what does just like the PM team look
[14:23] like at Anthropic? How many PMs are
[14:24] there? How are they kind of organized?
[14:26] >> Yeah, so we have a few PM teams. Um I
[14:29] think we're maybe around 30 or 40 PMs
[14:31] right now. Uh so, we have the research
[14:33] PM team
[14:35] uh who Diane leads. And this team is
[14:38] responsible for understanding all of the
[14:40] feedback from our customers for our
[14:42] models and then feeding that to the best
[14:44] research team to act on it. And they
[14:46] also shepherd the model launch.
[14:48] Um there is the Claude developer
[14:50] platform team that maintains the APIs
[14:52] that Claude Code is built on top of. And
[14:55] they also release things like managed
[14:58] agents, which is a way for you to build
[15:00] your agents and we can host it on your
[15:02] behalf.
[15:03] And then there's Claude Code that works
[15:05] on both Claude Code and the Co-work core
[15:07] products.
[15:08] There's enterprise that helps make
[15:11] Claude Code and Co-work easier to adopt
[15:13] for all of our enterprise customers. And
[15:15] so, this is everything from like cost
[15:17] controls, RBAC, security controls, and
[15:21] just making sure that these enterprises
[15:22] feel very confident and comfortable Uh
[15:25] using using our tools.
[15:27] And then we also have our growth team
[15:29] that is responsible for growing across
[15:31] our entire product suite. So we work
[15:33] very closely with them on Cloud Code and
[15:35] Co-work growth. And I know they also
[15:37] work with
[15:38] our other teams on CDP growth, so growth
[15:41] of people who use the Cloud API.
[15:43] >> So speaking of growth, so Amol was just
[15:45] on the podcast. He had this really
[15:46] interesting insight that most people
[15:48] haven't been sharing. There's always the
[15:50] sense that we need fewer PMs in the
[15:52] future. What's the What do we need PMs?
[15:53] Engineers can do ship.
[15:55] His take is that because engineers are
[15:57] moving so fast
[15:59] PMs and designers are squeezed. There's
[16:00] less time to stay on top of everything
[16:02] that is happening. Every There's a
[16:04] feature shipping every day. So his take
[16:06] is he needs more PMs because it's hard
[16:08] to keep up. What's your take there? Do
[16:09] you feel like there'll be an increase in
[16:11] hiring of PMs?
[16:13] What do you think is going on with the
[16:13] PM profession long-term?
[16:15] >> I think all of the roles are merging.
[16:17] PMs are doing some engineering work.
[16:19] Engineers are doing PM work. Designers
[16:22] are PMing and also landing code. You can
[16:25] either hire a lot more engineers who
[16:28] have great product taste or you can
[16:31] keep your engineering hiring the same
[16:32] and hire a lot more PMs to help guide
[16:36] some of their work.
[16:37] On our team we're
[16:39] pretty focused on hiring engineers with
[16:42] great product taste. This This way we
[16:45] can reduce the amount of overhead for
[16:47] shipping any product. Like there are
[16:49] many engineers on our team who are fully
[16:52] able to end-to-end go from see user
[16:55] feedback on Twitter through to like ship
[16:57] a product at the end of the week with
[16:59] almost no product involvement. And this
[17:01] I think is actually like the most
[17:02] efficient way to ship something.
[17:05] So I I think like
[17:08] engineering and PM are kind of
[17:09] overlapping and you will get a lot of
[17:12] benefit from having more of either. I
[17:14] think product taste is still a very rare
[17:17] skill to have and we'll pretty much hire
[17:21] anyone who we feel has
[17:24] demonstrated this strongly.
[17:25] >> And your background was in engineering,
[17:27] right?
[17:27] >> Yeah, I was an engineer for many years.
[17:30] I was then a VC very briefly
[17:32] uh before joining Anthropic.
[17:35] And actually almost all the PMs on our
[17:37] team have either been engineers or
[17:39] shipped code uh here on Claude Code. And
[17:42] so that that's one of the things that I
[17:44] think helps build trust with the team
[17:46] and also just enables
[17:48] us to move a lot faster. And then
[17:50] actually our designers also have been
[17:53] front-end engineers before.
[17:54] >> Wow. Cuz that's that's the big question.
[17:56] Like there's definitely this emerging
[17:58] that's happening, the Venn diagrams are
[17:59] combining. I think the big question for
[18:01] a lot of people is if you're coming from
[18:02] engineering or product or design, which
[18:04] of those core skills is going to be most
[18:06] valuable? I could see it at Anthropic
[18:08] and on Claude Code, engineering is very
[18:09] valuable. I'm curious if other
[18:11] companies, if you have a design
[18:12] background becoming a PM is more
[18:14] valuable or just the PM PM.
[18:16] >> I still think it comes back to product
[18:18] taste. Like as code becomes much cheaper
[18:21] to write,
[18:22] the thing that becomes more valuable is
[18:23] deciding what to write. Like what is the
[18:26] right UX for this feature? What is the
[18:28] most delightful way that a user can
[18:30] experience it? What like
[18:33] we we get tens of thousands of GitHub
[18:35] issues asking for
[18:37] every single thing under the sun and
[18:40] it takes a lot of
[18:42] care and
[18:44] taste to figure out, okay, which of
[18:46] these is worth building and what is the
[18:47] right way to build it? And I think that
[18:50] that skill set can come from any
[18:51] background, but I think that's the most
[18:52] important thing. I think the reason why
[18:54] an engineering background is
[18:57] particularly useful, at least for the
[18:59] next few months, is if you have an
[19:02] engineering background, you have a
[19:04] better sense for how hard something
[19:05] should be and that's often a factor in
[19:07] what you choose to build. So like if
[19:09] something is very easy to build, then
[19:11] maybe instead of debating it, you just
[19:13] spend an hour doing it. But if something
[19:15] is harder to build, and you know that up
[19:17] front, then you know that, okay,
[19:19] uh
[19:20] this will just like cost a lot more for
[19:22] uh for our team to get this out the
[19:23] door. So, it helps a bit with the
[19:26] prioritization.
[19:27] >> You said uh in the next for the next few
[19:29] months, is that just like because the
[19:31] models will get so good potentially in
[19:34] the next few months, you may not even
[19:35] need to know that as much as much?
[19:37] >> I think the value skill sets does change
[19:40] quite frequently, and so it's really
[19:43] hard to predict more than a few months
[19:44] out. So, it's less a commentary on
[19:48] what shift I think will happen, and more
[19:50] of a commentary that I think large
[19:52] shifts will happen.
[19:53] >> So, you're not saying that's when Mythos
[19:54] comes out and will change everything,
[19:56] and we don't need to know anything about
[19:58] engineering.
[19:59] >> No, I'm just saying that every every few
[20:01] months it seems like there's a
[20:02] >> Yeah.
[20:03] >> there's a large increase in coding
[20:06] capability, which then changes what
[20:08] other roles are valuable. I think the
[20:12] the most important thing is to be able
[20:14] to
[20:17] to to have this like first principles
[20:18] thinking, where you can figure out
[20:21] how the tech landscape is changing, what
[20:25] the team really needs from you, and to
[20:27] like jump in and fix that hole, because
[20:31] I think the work is becoming more
[20:34] amorphous, which means that a great PM
[20:38] is able to understand what all the gaps
[20:40] are, to figure out what the highest
[20:42] priority ones are, and then to just like
[20:44] figure out, okay, how do I learn that
[20:46] skill set, or what is like the skill set
[20:49] that I have that I can like apply to
[20:50] this challenge.
[20:52] So, I I think the current environment
[20:55] values people who are
[20:57] who are able to wear a lot of hats, are
[20:59] able to swap them, and are like very low
[21:02] ego about what work they do to help the
[21:05] team move faster.
[21:06] >> I love this answer.
[21:07] There's this question I've been asking
[21:09] people in your in your shoes, folks that
[21:11] are kind of at the bleeding edge of what
[21:12] AI is capable of and building with the
[21:14] latest tools, which is just like where
[21:15] will human brains continue to be useful
[21:18] and necessary for a while until we get
[21:20] to super intelligence.
[21:22] What I'm hearing here is essentially
[21:25] picking the things to work on,
[21:27] knowing where the market's going and
[21:28] figuring out where what to prioritize
[21:30] essentially, and then it's knowing if
[21:32] the thing you've built is good and right
[21:34] and getting it out there in some early
[21:36] version at least. Does that sound right?
[21:37] Is there anything else of just like
[21:38] where human brains will continue to be
[21:40] useful for at least the next few months?
[21:43] >> I think humans still provide a level of
[21:46] common sense that the models don't.
[21:49] And there's like a thousand moving
[21:52] pieces to any product launch. Some of
[21:53] them are very small, but there's always
[21:56] a lot that could potentially go wrong.
[21:59] I think the model doesn't always have a
[22:01] great sense of
[22:02] who all the stakeholders are, how they
[22:04] relate to each other, what their
[22:05] preferences are, what are the right
[22:07] venues to communicate with them to keep
[22:09] them on board. I think a lot of this
[22:11] like
[22:12] more tacit common sense like EQ kind of
[22:15] knowledge is still very valuable.
[22:18] Of course, we want the models to get
[22:20] better at this and I think they will be.
[22:22] But right now, I think there's still
[22:24] gaps.
[22:25] >> How do you just kind of deal as a human
[22:26] going through this so much constant
[22:28] change just like just being on the
[22:30] inside of the tornado? Maybe it's calm
[22:31] there.
[22:32] But just like how do you how do you stay
[22:34] on top of what's going on? How do you
[22:35] stay
[22:36] sane through all this craziness that
[22:38] we're moving through?
[22:39] >> I think our team is full of people who
[22:40] lean into the chaos. So, we try to face
[22:44] every challenge with a smile because
[22:46] there's always so much going on. There's
[22:47] all there's always so many risks and
[22:50] tricky situations that you know, if you
[22:53] get too stressed about anything, you'll
[22:54] burn out. And so, we really look for
[22:56] people who
[22:58] can kind of like look at a challenge, be
[23:00] like, "Oof, that's going to be hard, but
[23:03] I'm excited to tackle it, and I'm going
[23:05] to do the best that I possibly can, and
[23:07] I know I won't be perfect, but I'll be
[23:10] able to sleep at night knowing that I
[23:11] did my best."
[23:12] >> That's an interesting answer to just
[23:13] like what skills will be important in
[23:16] this future cuz it's I forget who said
[23:17] this, maybe Ben Man, that this is the
[23:19] most normal this is the world will ever
[23:21] be.
[23:23] >> Yeah, it definitely gets harder. Like I
[23:24] feel like
[23:26] there are a lot of weeks where maybe
[23:28] Sunday night there's some like P0, and
[23:30] then by Monday there's like a P00, and
[23:33] by Monday afternoon there's a P000, and
[23:35] you're like, "Wow, I can't believe I was
[23:36] so worried about that P0 from Sunday."
[23:41] But I think you just have to acknowledge
[23:42] that there's only so much that you can
[23:43] do, that you need to sleep well so that
[23:45] you can make good decisions next day,
[23:47] and just like brutally prioritize where
[23:50] you spend your time, what's the most
[23:51] important thing to get right, and be
[23:53] okay letting things go. Like there's
[23:55] there's products that we ship that
[23:57] aren't as polished as I wish they were,
[24:00] but
[24:01] you know, our our top goal is to help
[24:04] empower professional developers, and if
[24:06] a product isn't successful, as long as
[24:09] it's not blocking the core use case,
[24:13] it's okay, because we'll hear the
[24:15] feedback and we'll fix it in the next
[24:16] release.
[24:17] Launching a feature that is buggy is the
[24:19] kind of thing that would have kept me up
[24:20] at night,
[24:22] but
[24:23] it is something that I'm now able to
[24:25] like live with knowing that okay, we're
[24:28] going to get that quick feedback, and
[24:29] we're going to fix it in the next
[24:31] release.
[24:31] >> What I'm imagining is there's that gif,
[24:33] I think it's maybe from Pirates of the
[24:34] Caribbean, where it's this guy walking
[24:35] down a pair of stairs on a ship, and the
[24:38] whole ship is just being demolished
[24:40] around him, and he's so chill, just
[24:41] strolling down the staircase as
[24:43] everything's falling apart. And that's
[24:44] interesting cuz everyone I've met
[24:46] through from Anthropic is just so chill,
[24:48] and just so like optimistic.
[24:51] >> Yeah, that's I think that's a really
[24:52] interesting insight is just like having
[24:54] this calmness and optimism versus just
[24:57] like, "Oh my god, everything's crazy and
[24:58] going going nuts."
[25:00] >> Yeah. I think if you don't have it,
[25:01] you'll get pretty burnt out.
[25:03] I I think we also tend to hire people
[25:05] who
[25:06] have been in the industry for a while
[25:08] and have experienced lots of ups and
[25:10] downs and have a good sense for
[25:14] what gives them energy and how to
[25:16] maintain their energy over time. And I
[25:18] think that helps us a lot.
[25:20] >> So interesting.
[25:21] Something that I wanted to ask about is
[25:22] so there's these roles blurring.
[25:24] Engineers are becoming PMs. Everyone's
[25:26] cats, everyone's everyone.
[25:28] What do What do we lose in that in that
[25:30] world? Do we lose like career ladders
[25:32] and clear career paths? Do we lose
[25:34] design consistency, code quality? You
[25:36] know, there's probably some downsides.
[25:38] What are some things you find are just
[25:39] like, "Okay, that's something we're
[25:40] sacrificing for the greater good."
[25:42] >> We're sacrificing product consistency.
[25:45] Historically when code was expensive to
[25:47] write, you would carefully plan out
[25:50] everything your product suite, how every
[25:52] product relates to each other, what the
[25:55] use case for every one is, how they
[25:57] integrate, and you would pretty much
[25:59] have one product for each use case.
[26:02] And now with AI moving so quickly
[26:05] and with so many ideas that we need to
[26:08] test out, we do sometimes have features
[26:11] that overlap with each other.
[26:13] A lot of times it's because there is two
[26:16] form factors that we love internally and
[26:18] we want to we want the external audience
[26:20] to tell us which one is better.
[26:22] What that means for someone
[26:24] who's a new user though is
[26:27] a new user might not know, "Okay, what
[26:29] is the best path to accomplish X?"
[26:33] There is
[26:34] more education we need to do to help
[26:36] people understand what the core features
[26:38] are and what the best practices are for
[26:40] using them.
[26:41] I I think this is the
[26:43] This is the cost of launching a lot of
[26:45] features.
[26:47] Um I think users also feel like it's
[26:49] hard to keep up with the latest.
[26:52] Usually in traditional PM, you ship a
[26:55] feature every like month or quarter, and
[26:58] so it's really easy for a user to
[27:01] to understand, "Okay, I just need to
[27:02] check in on this once a month, and I'll
[27:04] learn some new things. And if I ignore
[27:06] it for 6 months,
[27:08] it's fine. I don't feel like I'm missing
[27:09] out." I think with these agentic
[27:12] tools, not just Cloud Code and Cower,
[27:14] but like across the whole ecosystem,
[27:16] people feel this need to like
[27:18] check Twitter every single day to see
[27:21] what the absolute latest thing is.
[27:24] And
[27:25] I think there's more we can do to help
[27:27] people
[27:28] feel less like they're on this
[27:30] ever-increasingly
[27:32] fast treadmill, and that they feel like
[27:36] I I would love people to feel like they
[27:37] can just open these tools, the tools
[27:39] will educate them,
[27:41] um or like teach them what they want to
[27:42] know,
[27:43] and that they can
[27:45] just
[27:46] feel more ball along.
[27:48] >> Yeah, I saw you launch this really
[27:49] interesting feature the other day. I
[27:50] think it's {slash} powerup, where it
[27:52] basically walks you through all the cool
[27:53] ways to all basically all the best
[27:55] practices to use Cloud Code. Is that
[27:56] kind of all in these lines?
[27:57] >> Yeah, exactly. So, in the past, we
[27:59] didn't actually want to do something
[28:01] like powerup, because we felt like the
[28:02] product should be intuitive enough that
[28:05] you can
[28:06] that you don't actually need to go
[28:08] through any tutorial.
[28:09] And over time, we've just realized that
[28:12] there's just so many features, and
[28:13] there's so much demand for a built-in
[28:16] onboarding experience, that we we
[28:19] diverge a bit from our original
[28:20] principle saying, "No no onboarding
[28:22] flow." And added this because there's
[28:25] just so many users who wanted to know,
[28:27] "There's 100 features, what are the 10
[28:29] that I absolutely need to use?" And so
[28:31] we put that together.
[28:32] >> Yeah, it's such a bizarre world. So,
[28:34] Anthropic has been really successful
[28:35] with B2B and enterprises, where
[28:37] traditionally you don't launch a bunch
[28:38] of stuff. You just kind of have
[28:39] quarterly release maybe, and it's like
[28:41] the opposite of every day we got some
[28:42] new. So, just maybe following that
[28:44] thread, the run Anthropic has been on is
[28:46] just
[28:48] other worldly.
[28:49] Anthropic was way behind when it
[28:51] started. It was a mole shared this just
[28:53] like one of the least funded companies
[28:55] didn't have distribution wasn't the
[28:56] first to go. Open AI was way ahead. It
[28:58] was just like no way Anthropic has any
[29:01] chance to compete significantly long
[29:03] term. Now it's just killing it just
[29:05] beating the biggest companies teams with
[29:08] so much just like the growth is just
[29:11] like 11 billion dollars in ARR in one
[29:14] month.
[29:15] Drips and growth. By the time this comes
[29:17] out it'll probably be
[29:19] even higher.
[29:20] Just being on the inside what what are
[29:22] some ingredients that have allowed
[29:24] Anthropic to be this successful and kind
[29:26] of come from behind and do this well?
[29:29] >> The two most important things are one
[29:31] this unifying mission. It's hard to
[29:34] state how important this is.
[29:38] We hire people who care most about
[29:41] bringing safe AGI to all of humanity.
[29:44] And this is actually something that we
[29:47] reference frequently in our decisions
[29:50] about what our entire product org should
[29:53] focus on shipping.
[29:54] And because we put this like mission
[29:56] above any individual product line, we're
[29:59] able to make very fast decisions that
[30:01] cut across the entire org and like
[30:04] execute on them in a unified way. So I
[30:06] think this is
[30:08] this is like something I've never seen
[30:10] at a company of our scale.
[30:12] >> And so just to make sure that's clear.
[30:13] So essentially having the the number one
[30:15] mission is safety alignment making sure
[30:17] AI is good for the world and you're
[30:19] saying just having that as a clear
[30:22] mission makes decisions a lot easier to
[30:23] make.
[30:24] >> If there's two competing priorities,
[30:26] we'll talk about which one is more
[30:27] important for Anthropic's mission.
[30:29] And it makes it a lot easier to decide
[30:32] which of the two we prioritize and then
[30:35] everyone will stand behind the one that
[30:37] we decide.
[30:39] And so sometimes that means that like
[30:40] hey we want to ship something on Claude
[30:42] Code, but this other thing is more
[30:43] important, and so we deprioritize
[30:45] shipping this, and we just wait until
[30:46] later."
[30:47] >> What's really interesting about that is
[30:48] that explains, I think, versus uh
[30:50] another company, maybe rhymes with Open
[30:52] AI, uh did a lot of different things.
[30:55] And what I'm hearing here essentially is
[30:57] like, "Okay, we're not going to launch
[30:58] social network. We're not going to
[30:59] launch
[31:00] uh a feed of interesting information
[31:02] because it's not aligned to this
[31:04] mission." And and that has kept
[31:06] Anthropic focused, which is seems to be
[31:08] a core ingredient to the success.
[31:10] >> Well, when when I think about mission, I
[31:12] think about
[31:13] putting Anthropic's goals ahead of any
[31:16] individual org or any individual
[31:17] product.
[31:19] And so,
[31:20] for me, it's I think the second thing
[31:23] that we're very good at is focus. I
[31:25] think mission to me is slightly
[31:27] different.
[31:28] Mission means that
[31:31] teams are willing to make sacrifices
[31:33] that hurt their own goals and their own
[31:35] KRs in service of Anthropic's goals and
[31:38] Anthropic's KRs.
[31:39] And
[31:41] people are very happy to make those
[31:43] trade-offs. So, like an extreme example
[31:46] is
[31:47] if Claude Code failed, but Anthropic
[31:49] succeeded, I would be extremely happy.
[31:52] And like, we're like, the whole team is
[31:54] very willing to make decisions
[31:56] that follow that chain of thought.
[31:58] >> I don't know if you can talk about this
[32:00] in depth, but do you feel like the open
[32:02] Claude decision is a part of this? Just
[32:03] like, "Okay, this is not furthering the
[32:05] mission of Anthropic. We need to stop
[32:08] this cuz it's not working in the way we
[32:09] want it to work."
[32:10] >> I think one of the most important things
[32:12] for Anthropic is to
[32:14] grow the number of users that we're able
[32:16] to reach. One of the ways that we're
[32:18] able to do this is with the Claude
[32:19] subscriptions with our first-party
[32:21] products. And so, we just very much want
[32:23] to double down on that. But that does
[32:26] come at the expense of third-party
[32:27] products sometimes.
[32:29] >> So, we've been talking about Claude,
[32:30] Kwork, all these things. Something that
[32:31] I I want to make sure people get, and
[32:33] I'm curious just how you use these
[32:34] tools. So, there's Claude Code, there's
[32:36] Claude Desktop/Web, there's Cohere.
[32:39] What's the best way to understand when
[32:41] to use which? When do you use each of
[32:43] these three?
[32:44] >> So, I tend to use uh Claude Code in the
[32:47] terminal when I'm just kicking off like
[32:50] a one-off coding task, and I want all of
[32:53] the latest features.
[32:54] Uh the CLI is our initial product
[32:57] surface, and it's also the one where our
[32:59] features often land first. And so, it's
[33:02] the it's the most powerful of all the
[33:04] tools.
[33:05] So, that's that's what I tend to use
[33:07] when I'm just like trying to kick off
[33:09] one or like maybe like a handful of
[33:11] tests at a time.
[33:12] I think desktop really shines when
[33:14] you're doing something that requires
[33:16] front-end work. And so, one thing that I
[33:18] love to do is to use our preview
[33:21] feature. So, if I'm building a web app,
[33:23] I'll often use Claude Code in desktop.
[33:26] I'll have the preview pane open on the
[33:27] right-hand side, so that I can actually
[33:29] see the web app that I'm making in real
[33:31] time as I'm chatting with Claude.
[33:33] It's also really great for people who
[33:35] want something a bit more graphical.
[33:36] Uh a terminal can feel very unfamiliar
[33:39] to someone who's non-technical.
[33:41] Um you got a bunch of these like scary
[33:43] pop-ups on your machine, and you can't
[33:46] click around the way that you're used to
[33:47] in pretty much every other product that
[33:49] you use. So, there's a lot of people who
[33:51] just like don't feel comfortable in
[33:52] terminal. And if that's you, I would
[33:55] highly recommend checking out Claude
[33:56] Code on desktop.
[33:58] Desktop is also great for getting an
[34:00] at-a-glance view of everything that's
[34:02] happening. So, you can see your CLI
[34:04] terminal sessions in desktop. You can
[34:06] see your other desktop sessions. You can
[34:08] see your sessions that you kicked off on
[34:10] web and mobile. So, it's a one-stop
[34:13] control plane where you can see all of
[34:15] your tasks.
[34:16] I think the benefit of web and mobile is
[34:18] that it's really great for kicking
[34:20] things off on the go. So, CLI and
[34:22] desktop both require you to be on your
[34:25] local laptop.
[34:26] And this is constraining because
[34:28] sometimes you're out and about, you're
[34:29] like touching grass, you're going on a
[34:31] walk. And you don't have your laptop
[34:33] open, and you don't
[34:34] I can't count I can't count the number
[34:36] of people who I've seen like holding
[34:37] their laptop open like tethered to their
[34:39] phone while they're outside. And this
[34:41] just means that we're missing a product
[34:44] that solves that need. And so, for for
[34:46] me, what mobile lets you do is kick off
[34:49] these tasks on the go so that you don't
[34:52] you don't need to bring your laptop
[34:53] everywhere and make sure that your
[34:55] laptop's open wherever you are.
[34:57] >> I love that. I've I've seen people on
[34:58] plane like it's just like such a meme
[35:00] now. Just I need to finish Let this
[35:01] agent finish. I can't shut this down. I
[35:03] need Wi-Fi.
[35:04] >> And then I think for co-work, the the
[35:06] role that this fills is there's a lot of
[35:08] work that everyone does where the output
[35:10] isn't code. So, whether that's like
[35:12] getting to Slack zero or inbox zero, or
[35:15] whether that's creating a slide deck for
[35:18] some customer meeting that's coming up,
[35:20] or whether that's writing a quick doc on
[35:23] what the goals of a feature or or what
[35:25] the launch plan for a feature is. All
[35:27] these tasks produce outputs that are
[35:29] non-code, and co-work is best positioned
[35:32] for that. So, the way that I split the
[35:35] products in my mind is
[35:37] if I'm building something where the
[35:38] output is code, I'll use Cloud Code or
[35:41] desktop or Cloud Code on mobile. And if
[35:44] the output is anything that's not code,
[35:46] I'll use co-work for it.
[35:48] >> People are just like sleeping on the
[35:50] success that co-work is having. It's
[35:52] just like growing incredibly fast. And I
[35:55] think people still don't understand
[35:57] maybe what it's for.
[35:59] And so, what if you give us a couple of
[36:00] use cases just in your work as a PM?
[36:02] What are some like really interesting,
[36:04] maybe unexpected, ways you use co-work
[36:06] to save you time, get more work done?
[36:08] >> If you're getting started on co-work,
[36:10] the first thing that
[36:12] you really need to do is connect all the
[36:14] data sources that are relevant to your
[36:16] role. Because co-work can only do a
[36:18] great job if it has access to all the
[36:20] context that it needs to be able to
[36:22] curate the output for you. So, what that
[36:25] means for me is I connect it to my
[36:27] Google Calendar, I connected to my
[36:28] Slack, to my Gmail, to my Google Drive,
[36:31] so that it just knows it has the
[36:33] flexibility to
[36:35] find relevant context, to ask questions,
[36:38] to pull in threads.
[36:40] And this this like substantially
[36:42] improves the quality of the result.
[36:45] The kinds of things I use it for are
[36:47] like last night I was working where we
[36:49] have this Code with Cloud conference
[36:51] coming up and there's a few talks that
[36:53] I'm giving there. And one of the talks
[36:56] that we're doing talks about the the
[36:59] transition of Cloud Code from an
[37:01] assistant to like a full-on agent. And
[37:04] one of the things that I wanted to do in
[37:05] this talk was to showcase all of the
[37:08] products that we've been shipping that
[37:10] enable this transition and also to
[37:13] figure out, okay, what are the what are
[37:15] the success stories that people have had
[37:17] internally that we can use as demos. And
[37:19] so I I have my Google Drive connected, I
[37:23] have Slack connected.
[37:26] Um
[37:26] Alex, who is our product marketer, put
[37:29] together like a draft of what the points
[37:31] that we that he thinks we should cover
[37:33] are. And so I just like fed this all
[37:34] into Cohere, I told Cohere the narrative
[37:36] that I want to tell. And it actually
[37:38] just worked for an hour. It It walked
[37:41] through Twitter to see what we launched,
[37:43] it looked through our evergreen launch
[37:44] room, it looked in our Cloud Code
[37:47] announce channel, which is where our
[37:49] team posts demos of what how how they've
[37:52] been getting the most value out of Cloud
[37:53] Code. And it synthesized all this
[37:55] together to this 20-page deck that I
[37:57] woke up to this morning. And I read
[37:59] through it and it was like pretty good.
[38:01] There were there were a few tweaks, so I
[38:03] did have to give it a round of feedback.
[38:05] I I like my slides to have extremely
[38:07] minimal words and it was a little too
[38:09] wordy.
[38:10] But, you know, it it was far faster than
[38:14] like what I would be able to produce.
[38:16] And because Cohere has access to our
[38:17] whole design system, it actually looks
[38:20] like an Anthropic designer put it
[38:22] together. Like it when you visually see
[38:25] it, you're like, "Oh, this is like
[38:27] incredibly polished."
[38:28] So,
[38:30] uh these are the kinds of things that
[38:32] are so much faster. Like this making
[38:34] this slide deck would have taken me
[38:35] hours. But instead, it like turns out a
[38:38] draft that is actually quite good, so I
[38:41] can focus on making sure that the demos
[38:43] are amazing that we plug into it.
[38:45] >> This sounds like a dream come true to
[38:46] PMs that putting decks together is so
[38:48] annoying.
[38:49] >> It's so slow.
[38:51] >> I and I love people will see this deck
[38:53] whenever you present this. This will be
[38:54] out in the world this like obviously
[38:55] it's not the the one-shotted version,
[38:57] but you've iterated on it. So, just to
[39:00] help people try this for themselves. So,
[39:02] step one is connect their What did you
[39:05] say? Slack? What else do you suggest
[39:06] they connect?
[39:07] >> Slack, Google Calendar, Gmail, G Drive.
[39:11] You should connect your communications
[39:13] tools and where you store your source of
[39:15] truth data for what your team cares
[39:18] about, what you care about, and what
[39:20] you're working on.
[39:21] >> Okay. And then what was the prompt
[39:22] roughly that you put in there to
[39:24] generate this deck?
[39:25] >> So, I just wrote, "Make me a slide deck
[39:27] for the Code with Claude conference.
[39:29] This is what our PMM suggested it should
[39:31] cover. This is the current draft that I
[39:33] made that I don't like. This is one that
[39:35] I made manually that I don't like, but I
[39:37] linked it. Can you start by creating a
[39:39] proposed outline with details? Also,
[39:41] make sure it doesn't overlap too much
[39:42] with the keynote talk, which is more
[39:44] important."
[39:45] And then Claude read a bunch of the
[39:48] links that I sent to it and created a
[39:50] proposed outline. So, then I read
[39:52] through its proposal and all the
[39:55] different ideas that I had generated for
[39:57] what we could cover and I just made a
[40:00] decision on what I wanted to actually be
[40:02] in the final deck. And I think this is
[40:04] like an example of what the role of the
[40:05] PM still is today. It's like
[40:08] Claude is a great brainstorming partner.
[40:11] It's able to synthesize a massive amount
[40:14] of information really quickly
[40:16] and present all of the possibilities to
[40:18] you, but uh the role of the PM is still
[40:21] to make the end decision of okay, what
[40:23] what should belong in the final product?
[40:25] And so for this, what I ended up
[40:26] deciding was that I wanted the talk to
[40:29] talk to cover the progression from
[40:32] making local tasks successful to making
[40:35] every PR green to like helping engineers
[40:37] land more PRs. And for each of these,
[40:40] which demo would be the most compelling.
[40:42] And then
[40:43] after this decision about the outline,
[40:46] co-work just like went off for a few
[40:48] hours and built the whole slide deck.
[40:50] >> This is so awesome. What a What an
[40:52] awesome
[40:53] part of the job to not have to do
[40:54] anymore.
[40:55] Uh and it feels like you're talking to
[40:57] essentially a deck designer that also
[41:00] has like actual knowledge about what
[41:01] you've worked on and
[41:04] and can like make it actually the
[41:05] content what you want it to be, not just
[41:07] make it look really nice.
[41:10] How did you um How did you do the design
[41:11] system piece? How does that work? How
[41:12] does it know the design system of
[41:14] Anthropic?
[41:15] >> So, what I did for this is we actually
[41:17] already have like a standardized deck
[41:21] that we use across all of our external
[41:23] engagements. And so I just gave Claude
[41:24] access to that. And so it's able to see
[41:27] like what colors we use, what fonts we
[41:28] use, the different kinds of
[41:31] what's it called? Like slide formats
[41:34] that are possible. And so it has like 20
[41:36] of these example slides that
[41:37] >> an example, got it. So you like upload
[41:38] here's our template, work from this.
[41:40] Yeah.
[41:41] >> You can also connect like your Figma MCP
[41:43] if you if you have your slide format um
[41:46] saved there and it can pull that in.
[41:48] >> Along those lines, something I'm always
[41:50] curious about is what's kind of in your
[41:52] in your stack of tools as a PM at
[41:54] Anthropic? Obviously Claude Code and
[41:56] co-work and all the Anthropic tools.
[41:58] What else are you using? What other
[42:00] Slack you mentioned? Is there anything
[42:01] else?
[42:02] >> So, my stack is pretty heavily Claude
[42:04] Code, co-work, and Slack.
[42:07] Anthropic largely runs on Slack. Uh I
[42:10] feel like it's like the core OS of our
[42:12] company.
[42:13] And day-to-day, like
[42:16] a lot of I I would say maybe 30% of my
[42:20] time is
[42:23] pushing the boundaries of what Cogram
[42:25] and Cogram Code can do so that I have a
[42:27] very strong sense of
[42:30] what we're not good at. And
[42:34] I spend a lot of time talking with the
[42:35] model to understand why it makes
[42:38] mistakes that it does. We actually have
[42:40] a lot of internal tools that we make.
[42:43] Like I think one of the things that
[42:44] Cogram Code has really unlocked for our
[42:46] entire company is it really lowers the
[42:49] barrier to making any custom app that
[42:52] you want. And so we we've seen this like
[42:55] surge in crystallized work software that
[42:58] people are building for like custom use
[43:00] cases instead of
[43:02] um, using tools that don't perfectly fit
[43:05] the use case.
[43:06] >> I got to hear more. What are What are
[43:08] some examples? What are things you
[43:10] built, other people built that are
[43:11] really popular and useful?
[43:12] >> One of the sales folks on Cogram Code,
[43:15] he he realized he was making these like
[43:17] repetitive decks over and over and over
[43:19] again. And so he actually has this web
[43:23] app that he built with the examples of
[43:26] the core Cogram Code decks that we know
[43:28] work well. So like a 101, 201, and
[43:30] Mastering Cogram Code. And then he has a
[43:32] way to input specific customer context
[43:35] that pulls from Salesforce, that pulls
[43:37] from Gong, that pulls from other notes.
[43:39] So that we can customize the decks for
[43:41] specific customers. And so we'll pull
[43:43] out things like, "Okay, this customer is
[43:46] using like Bedrock or Cogram for
[43:49] Enterprise or Console." Which affects
[43:50] what features are available to them. Um,
[43:53] it will pull out things like, "Okay,
[43:54] this customer is concerned about
[43:57] like the code review stage of the SDLC."
[43:59] And so we'll add a slide about our code
[44:02] review features there.
[44:04] Um, it will pull out things It's "Okay,
[44:05] this customer needs to be like HIPAA
[44:07] compliant or needs XYZ security
[44:09] controls, and so we'll make sure to add
[44:11] a slide or two in their deck about that.
[44:14] And then, for example, if if this is a
[44:17] customer that's on Vertex or Bedrock and
[44:20] doesn't want to use Cloud for
[44:22] Enterprise, then we'll just take out
[44:23] some of the slides that are Cloud for
[44:25] Enterprise only features. And so,
[44:27] normally this is like manual work that
[44:29] could take 20-30 minutes.
[44:31] Or and so people will either like spend
[44:34] that time doing it or they'll just
[44:35] decide not to do it and use the general
[44:37] deck.
[44:38] Uh with this, it takes like a few
[44:39] seconds and you get a tailored deck.
[44:42] >> What's interesting about it's like Slack
[44:43] is like the tool that nobody's It's just
[44:46] like
[44:47] nobody's trying to create their own.
[44:48] Slack just continues to win and it's
[44:50] just like the way you describe it is
[44:51] kind of the OS of so many companies.
[44:53] It's so interesting. Like people talk
[44:55] about Salesforce as just like SaaS. We
[44:57] don't need SaaS software anymore. We're
[44:58] going to build our own. It's like Slack
[44:59] is an adorable tool that nobody wants to
[45:02] try to compete with and build a better
[45:03] version.
[45:04] >> I think it's pretty important
[45:06] communications infrastructure and I
[45:08] think they do the core task of helping
[45:10] everyone get real-time updates
[45:12] incredibly well.
[45:13] >> Yeah, like people hate on Slack, but
[45:14] it's really great at what it's trying to
[45:16] do. And like like most cutting-edge
[45:18] teams are are hooked on it. So
[45:20] interesting.
[45:21] >> Yeah, and I also love how customi- how
[45:23] easy they've made to customize it. And
[45:25] so it's We we love making Slack bots and
[45:30] the this kind of like hackability
[45:32] uh means that we're able to integrate
[45:34] with Slack the way that we want to. So,
[45:36] really appreciate Slack's work on that.
[45:37] >> Time to Time to buy some CRM stock.
[45:40] I am so excited to tell you about this
[45:42] season's supporting sponsor, Vanta.
[45:44] Vanta helps over 15,000 companies, like
[45:48] Cursor, Ramp, Duolingo, Snowflake, and
[45:51] Atlassian earn and prove trust with
[45:53] their customers. Teams are building and
[45:55] shipping products faster than ever
[45:57] thanks to AI. But as a result, the
[45:59] amount of risk being introduced into
[46:01] your product and your business is higher
[46:03] than it's ever been. Every security
[46:05] leader that I talked to is feeling the
[46:07] increasing weight of protecting their
[46:09] organization, their business, and not to
[46:12] mention their customer data. Because
[46:14] things are moving so fast, they are
[46:15] constantly reacting, having to guess at
[46:18] priorities, and having to make do with
[46:20] outdated solutions. Vanta automates
[46:22] compliance and risk management with over
[46:24] 35 security and privacy frameworks,
[46:27] including SOC 2, ISO 27001 and HIPAA.
[46:31] This helps companies get compliant fast
[46:33] and stay compliant. More than ever
[46:35] before, trust has the power to make or
[46:37] break your business. Learn more at
[46:39] vanta.com/lenny.
[46:42] And as a listener of this podcast, you
[46:43] get $1,000 off Vanta. That's
[46:46] vanta.com/lenny.
[46:48] Okay, uh so you talked about all these
[46:50] different teams that and how they use
[46:52] Quad Code and Co-work to operate. Which
[46:55] teams do you find, other than
[46:56] engineering, I imagine engineering is
[46:57] the biggest token spender, but if not,
[46:59] that'd be really interesting. What
[47:00] what's kind of like the second place
[47:02] function right now for tokens?
[47:04] >> Oh, Applied AI is amazing at pushing the
[47:07] boundaries of what Quad Code and Co-work
[47:09] can do.
[47:11] A lot of our Applied AI team spends time
[47:14] with our customers helping them adopt
[47:17] our API. And so, sometimes our Applied
[47:20] AI team will, for example, make
[47:21] prototypes on behalf of these customers,
[47:23] which Quad Code makes so much faster
[47:26] than it used to be.
[47:28] They also have the dual goal of needing
[47:31] to manage a lot of customer comms, a lot
[47:33] of like customer inbound, and historical
[47:37] context, call notes. And so, they're
[47:39] both extremely heavy on Co-work and on
[47:42] Quad Code.
[47:42] >> And just to understand Applied AI, is
[47:43] that like does that like forward deploy
[47:46] engineering sort of role? Like what do
[47:47] they How would you How would most people
[47:49] describe what a Applied AI Applied AI
[47:50] team is doing?
[47:51] >> Yeah, it's helping our customers adopt
[47:54] the latest API and
[47:57] uh features
[47:58] um across their company both for
[48:00] powering their company's products and
[48:02] also for internal acceleration.
[48:05] >> Got it. So, it's like customer success
[48:07] and go-to-markety kind of like
[48:08] forward-deployed engineering sort of.
[48:10] >> Exactly. It's like a very technical
[48:11] go-to-market person.
[48:12] >> Got it. Okay, awesome. So, that's So,
[48:14] you're saying that might be the second
[48:16] uh org that uses the most tokens.
[48:19] >> Yeah. And then we we also see them
[48:21] pushing the boundaries of what Cohere
[48:23] can do. So, for example, if So, a lot of
[48:27] these folks cover multiple customers and
[48:30] in any given day can have like five to
[48:33] 10 customer engagements uh on a high
[48:35] day. And so, what they often use Cohere
[48:38] to do is the night before, they'll ask
[48:41] it to summarize, "Okay, what are all my
[48:43] customer meetings that are coming up the
[48:44] next day?
[48:45] Um what are all the what are all the
[48:47] things that this customer has asked me
[48:49] for? Uh what's top of mind for them?
[48:51] What are the action items from the past
[48:52] meetings?" And Cohere will just put
[48:55] together this like dossier, this like
[48:57] brief of what they should be aware of
[48:59] going into the next meeting. And Cohere
[49:01] can also research answers. So, if if a
[49:04] customer asked, "Okay, when is feature X
[49:06] going to launch?"
[49:07] Um Cohere can help the PII person
[49:10] research through Slack to get the latest
[49:12] ETA, add that to the add that to the
[49:15] notes so that during the customer call,
[49:17] the PII person has the absolute latest.
[49:20] And these are just workflows that people
[49:21] are building for themselves and sharing
[49:23] with other people on their team.
[49:25] >> So cool. Something that kind of this
[49:27] question, this trend,
[49:29] uh I don't know, question topic comes up
[49:30] a lot recently, which is um
[49:33] token spend exceeding people's salary,
[49:36] where people just use AI
[49:38] uh and it costs more than how much
[49:39] they're making.
[49:40] Are there any numbers floating around
[49:41] Anthropic of just like how much token
[49:43] spend, say engineers,
[49:45] uh spend, I don't know, a month, a day,
[49:48] or PMs, anything like that?
[49:50] >> It's clear to us that as the models get
[49:52] better, people delegate far more tasks
[49:55] to it and they spend a lot more hours in
[49:58] tools like Claude Code and Co-work. And
[50:00] so, we do see the token cost per
[50:04] engineer or like per any knowledge
[50:06] worker increase every time that there is
[50:08] a model jump or like a substantial
[50:11] product improvement. I think it's
[50:13] still much lower than what the average
[50:16] engineer salary is, but we see the
[50:19] percentage increasing over time.
[50:21] >> It's such an interesting like we talked
[50:23] about how you have access to the most
[50:25] cutting-edge models and another
[50:26] advantage of working at Anthropic, uh I
[50:28] believe you guys have basically
[50:29] unlimited tokens. You don't You can use
[50:31] as much as you want. Is that right?
[50:32] >> We can use a lot of tokens. Some people
[50:35] do run into limits, so
[50:37] >> a limit. Okay. Boris, shut it down.
[50:40] Uh okay. It's like it's so interesting
[50:42] how many advantages come from having the
[50:44] most advanced model. It's such an
[50:46] interesting like flywheel that starts to
[50:48] kick in.
[50:49] >> I think we also believe a lot in
[50:51] empowering our internal teams to build
[50:54] as fast as possible and we also trust
[50:57] that everyone understands how much
[51:00] capacity that serving these models truly
[51:03] costs and we trust our team to use the
[51:05] tokens responsibly. So, it's very
[51:08] frowned upon to waste tokens.
[51:11] But, we do trust individuals to make
[51:13] that judgment call.
[51:14] >> Awesome.
[51:15] Coming back to the PM role, you talked
[51:17] We talked a little bit about this, but I
[51:18] think this will be really interesting
[51:20] for people to hear.
[51:22] Just What I want to understand is what
[51:23] do you think are kind of the emerging
[51:25] skills that PMs need to develop {slash}
[51:29] you most look for AI companies most look
[51:32] for when they're hiring PMs these days?
[51:35] >> I think the hardest skill is
[51:38] being able to
[51:41] define what the product should look like
[51:43] a month from now.
[51:45] I think there's a lot of ambiguity in
[51:47] what models are capable of in that
[51:49] timeline and how user behavior will
[51:50] change.
[51:52] But I think there are patterns that the
[51:54] best PMs can see based on how users are
[51:58] abusing the limits of the existing
[51:59] product.
[52:01] And the best PMs can sense that, can set
[52:04] a direction, and can steadily execute
[52:07] towards it, and change the path if the
[52:10] model capabilities are much better than
[52:12] or worse than what they'd originally
[52:14] expected.
[52:15] I think it is very hard to be the right
[52:17] amount of AGI pilled. Cuz I think
[52:19] everyone can see this like
[52:22] the this future where the models are
[52:24] extremely smart and can do almost
[52:26] everything, in which case
[52:29] you actually don't need that complicated
[52:30] a product. You can actually just have a
[52:32] text box again where you tell the model
[52:34] what you want. And it's so smart that it
[52:37] can add any tool or add any integration
[52:40] that it needs to like get the job done.
[52:42] It knows when it's uncertain, it can ask
[52:44] clarifying questions. Like it's
[52:46] kind of very easy to build the product
[52:48] for the super AGI
[52:51] uh strong model.
[52:53] I think the hard thing is figuring out
[52:56] for the current model
[52:58] how do you elicit the maximum
[53:00] capability? How do you help users
[53:04] go get onto the
[53:07] the golden path? How do you like guide
[53:09] users to interact with the model
[53:12] strengths and like patch its weaknesses?
[53:15] The this skill is like pretty rare.
[53:18] >> Mhm.
[53:19] And how do you build that skill? Is it
[53:20] just using each like basically
[53:22] understanding the limits of each model,
[53:24] having like
[53:25] Are you talking about taste,
[53:26] understanding having taste into what the
[53:28] model maybe is capable of, what it's
[53:30] great at, not great at, where it's
[53:31] changed?
[53:31] >> I think it's spending a ton of time
[53:33] talking and using the model.
[53:36] One of the things I really like to do is
[53:39] to ask the model to introspect on its
[53:40] own behaviors.
[53:42] So sometimes when I notice that the
[53:44] model does something unexpected, like
[53:47] for example, there's like situations
[53:49] where the model will
[53:51] make a front-end change and run tests,
[53:54] but not actually use the UI.
[53:56] It's actually pretty useful to
[53:58] ask the model to reflect on why it did
[54:00] this.
[54:02] And sometimes they'll say that, "Hey,
[54:04] there's like something confusing in the
[54:05] system prompts, or I didn't realize that
[54:09] um the front-end verification was like
[54:10] part of this task, or hey, I delegated
[54:12] the verification to this sub-agent, and
[54:14] the sub-agent didn't do the task, and I
[54:16] didn't check its work."
[54:19] A lot of times just like
[54:20] being very curious about why the model
[54:22] made the decision that it did will show
[54:24] you
[54:26] what misled it, so that you can fix the
[54:28] harness in order to close this gap.
[54:31] The other thing that helps is to figure
[54:34] out who the taste who are the users who
[54:37] you trust the most to give you accurate
[54:40] feedback about the model.
[54:42] Usually there's like a handful of people
[54:44] who are much better than others at
[54:46] articulating what makes a specific model
[54:48] or model-harness combination good.
[54:51] And
[54:52] there's a lot of people who will give
[54:54] you feedback, but not everyone's
[54:55] feedback is as qualified.
[54:57] And so, finding a group of those like
[54:59] five people you trust is really
[55:01] important for getting very fast
[55:03] feedback.
[55:04] I think the third thing that
[55:06] is useful, but not everyone loves doing,
[55:09] is building evals.
[55:11] You don't need to build hundreds of
[55:13] evals
[55:14] for them to be useful. Just building 10
[55:16] great evals
[55:18] is important for helping the team
[55:21] quantify what the goal is, and what
[55:24] their progress towards it is, and what
[55:26] they're missing. And so, I think evals
[55:28] is this like underappreciated thing that
[55:30] more more PMs, more engineers should be
[55:32] working on.
[55:33] >> We've covered evals a bunch. There's
[55:35] this trend of just like that is the
[55:36] future product management is writing
[55:38] evals because it and essentially it's
[55:40] what does success look like? Okay, cool.
[55:41] Let me actually concretely define it and
[55:43] then we'll know. How much of your time
[55:44] are you spending writing evals would you
[55:46] say?
[55:46] >> I I think the importance of evals varies
[55:48] a bit based on the feature that you're
[55:50] working on and or like what the problem
[55:54] you're trying to solve is. So there are
[55:56] a lot of folks on our team who do spend
[55:58] a lot of time working on evals. We have
[56:00] a small pod of folks who collaborate
[56:03] very closely with research to more
[56:05] precisely understand our Claude code
[56:08] behaviors and what the
[56:12] largest areas of improvement are and
[56:14] trying to measure those pretty
[56:15] concretely.
[56:16] I personally jump into evals when
[56:19] there's a feature that I think needs a
[56:21] bit more product definition and often
[56:25] the output of this is okay, here are
[56:27] like five evals that I made.
[56:30] Um this is how you run them. These are
[56:32] the ones that succeed and these are the
[56:33] ones that don't and this is like the
[56:35] prompt that I've used to increase the
[56:37] success rate.
[56:38] It varies a lot though based on the
[56:40] exact feature. Uh not every feature
[56:42] needs it but I think features such as
[56:44] memory benefit a lot from it.
[56:46] >> This uh point you made about people
[56:48] being very good at evaluating models so
[56:50] interesting. It's almost like a human
[56:51] eval of just like okay, they understand
[56:53] where it's spiking or it's maybe
[56:55] lacking.
[56:56] Uh is there anyone specific that you
[56:58] want to shout out that's very good at
[57:00] this?
[57:00] >> Uh two people who I think are incredible
[57:03] at this are
[57:04] um one Amanda who def who molds Claude's
[57:08] character. It's just like such a hard
[57:11] role because the task is so
[57:15] ambiguous.
[57:16] Even coding is easier because you can
[57:18] verify the success whereas crafting the
[57:21] character requires a very strong sense
[57:23] of conviction in what who Claude should
[57:26] be.
[57:28] And I think she has like an incredible
[57:30] ability to not only mold the character,
[57:32] but also to like articulate what the
[57:35] goals are, what the character what's
[57:38] successful and what's not.
[57:40] The other group of people who I really
[57:43] trust is just like the Claude team.
[57:45] So we often have team lunches and
[57:48] whenever there's a new model we're
[57:49] testing, one of the fastest ways for us
[57:51] to get feedback is to just like at these
[57:53] team lunches, just like go to every
[57:55] single person and just be like, "Hey,
[57:57] what is your vibe on the model?"
[57:58] And often times
[58:00] we'll we'll get feedback like, "Okay,
[58:02] this model is like
[58:04] not fully explaining its thinking. It's
[58:06] like too abrupt." Or like, "Hey, this
[58:08] model is like
[58:10] um
[58:11] just like loves writing a ton of
[58:13] memories, but like we're not sure if the
[58:14] memories are high quality or not." Or
[58:16] like some people will notice that,
[58:18] "Okay, this this model loves to test
[58:21] itself, which is great." Or like, "This
[58:22] model isn't testing itself enough."
[58:24] So that informs what data we look at to
[58:27] verify, "Okay, is this a larger
[58:28] pattern?" So we we have a ton of data,
[58:32] but it is very hard to extract insights.
[58:34] And so
[58:36] the the feedback from this group helps
[58:38] us inform, "Okay, what are the
[58:39] hypotheses we want to test?" And then
[58:41] we're able to extract
[58:43] data to test that.
[58:45] >> This point you made about the character
[58:47] of Claude, I had Ben Mann on the podcast
[58:49] co-founder
[58:50] and he talked about this just like the
[58:51] character, the constitution of Claude is
[58:53] such an important part of
[58:55] of
[58:56] of Claude and I didn't realize until
[58:58] afterwards just like
[59:00] like people like with Open Claude
[59:01] actually, one of the example one of the
[59:02] reasons people are sad is like the
[59:03] personality of your Claude is like
[59:06] because Claude's personality is so good
[59:09] and fun and
[59:11] and interesting unlike other models. And
[59:13] there's And the way he put it is the
[59:14] personality is what makes Claude so good
[59:17] at so many things. It feels like this
[59:19] like trivial side thing. Okay, it's
[59:20] going to be funny and interesting and
[59:22] talk in a fun way, but it's like so core
[59:25] to the success of Claude. Is there
[59:27] anything you'd share there about just
[59:28] like what people may not understand
[59:29] about why the character as you described
[59:32] and the personality is so key?
[59:34] >> When you reflect on everyone you've
[59:35] worked with,
[59:36] there's just some people where you're
[59:38] like, I really like their energy. Like,
[59:40] I really like their vibe.
[59:42] And when people think about Claude and
[59:44] Claude Code,
[59:45] this is one of the things that people
[59:47] bring up the most where they just really
[59:49] love that Claude is like
[59:52] it's it's like light-hearted and fun.
[59:55] Um but it also is extremely confident at
[59:59] your task.
[60:00] People really like that Claude's low
[60:02] ego. And so, if you tell it, "Hey, you
[60:04] did this thing wrong." it's like truly
[60:05] sorry. It's like, "Oh, shoot. Like,
[60:08] thanks for telling me. Like, let me fix
[60:09] it. Let's work together." It's also very
[60:11] positive. So,
[60:13] if you're feeling like, "Oh, this is
[60:14] like an insurmountable task. I don't
[60:16] know how to get started." Claude is
[60:19] like, "Okay. It's okay. These These are
[60:22] like the steps that I think we should
[60:23] take. Like, do you want me to get
[60:25] started on it for you?"
[60:28] I think part of what makes a great
[60:29] coworker is this positivity, this like
[60:32] bias towards action, this this ability
[60:35] to give you like earnest feedback, not
[60:38] just agreeing with every single thing
[60:39] that you say. And so, we try to imbue
[60:41] this into Claude because we think it
[60:43] makes it a lot more enjoyable to work
[60:44] with.
[60:45] >> There's something I want to come back
[60:46] to. You talked about how when new models
[60:48] come out, you often have to kind of
[60:50] revisit things you've built. That's so
[60:52] interesting and so like frustrating
[60:53] maybe. Just like, "Oh, god damn it.
[60:55] Reshift this thing. Now I have to
[60:56] rethink it." Talk about just like how
[60:57] often you have to come back with a new
[60:59] model and they're like, "Okay, we have
[61:00] to redo this product that we launched a
[61:02] few months ago."
[61:03] >> A lot of the changes that we make with a
[61:06] new model is removing features that are
[61:10] no longer needed. So,
[61:12] a lot of times we add features to the
[61:14] product as a crutch for the model
[61:16] because it's not naturally doing itself.
[61:19] So, the classic example for this is a
[61:21] to-do list. When we first launched Quad
[61:23] Code, people would ask it to do these
[61:25] large refactors and Quad Code would say,
[61:26] "Okay, cool. I need to change these like
[61:28] 20 call sites." And it would go and
[61:31] change five of them and then stop. And
[61:32] then we were like, "Okay, how do we like
[61:35] force it to remember to get every single
[61:37] one of these 20?"
[61:38] And so Sid on our team was like, "Okay,
[61:40] what if we just like think about what a
[61:42] human would do? A human would like make
[61:44] a list of everything that they need to
[61:45] change. Similar to how in VS Code you
[61:47] would look up all the call sites and
[61:49] it'll be a list on the left side and you
[61:50] would like go through them one by one
[61:52] and replace all. How do we give this
[61:53] kind of like a tool to Quad?" And so he
[61:55] added the to-do list. And we found that
[61:58] with that, Quad was actually able to fix
[62:00] all these 20 call sites. But then with
[62:02] Opus 4 and later models, we realized
[62:04] that we didn't need to
[62:07] force it to use this to-do list. It
[62:09] would like naturally use it itself.
[62:12] For the earlier models, we had to keep
[62:13] reminding it, "Hey, did you finish
[62:15] everything on the to-do list? You can't
[62:16] finish until you're done with everything
[62:17] on the to-do list." And for the later
[62:18] models, without prompting, it just like
[62:20] naturally thinks to do everything on the
[62:22] to-do list.
[62:23] Um these days, the to-do list is still
[62:27] nice to have as like a user
[62:29] um because then you can more clearly see
[62:31] what Quad is working on. But honestly,
[62:33] it's such a de-emphasized part of the
[62:35] product right now that um the model may
[62:38] use it, the model may not use it. It's
[62:39] like really not necessary for it to make
[62:42] thorough changes anymore.
[62:44] >> I forget who said this on the podcast um
[62:46] that the model will eat your harness for
[62:48] breakfast.
[62:49] And what I'm hearing here is essentially
[62:51] you
[62:52] you remove things over time that you've
[62:54] had to add on top of the model where it
[62:57] was not operating the way you wanted and
[62:58] essentially as the models get smarter,
[63:00] it just it becomes simpler and simpler
[63:01] for it just to do the thing you want it
[63:03] to do.
[63:03] >> Yeah, um we can move remove a lot of
[63:06] prompting interventions every time the
[63:08] model gets smarter. And we actually do
[63:10] this every time we launch a model. We
[63:12] read through the entire system prompt
[63:14] and we reflect on, "Okay, for each of
[63:16] these sections, does the model really
[63:18] need this reminder anymore? And if not,
[63:20] we'll remove it. The most exciting thing
[63:22] that new models unlocks though is just
[63:24] like entirely new features. So, there's
[63:27] all the features that we've been testing
[63:29] out with prior models and the accuracy
[63:31] wasn't high enough for us to want to
[63:33] launch them.
[63:34] And so, one example of this is code
[63:36] review.
[63:37] We tried to build a code review product
[63:39] a few times and we've launched like
[63:42] simpler versions of code review which is
[63:44] the slash code review command in the
[63:45] past. And it was only with the most
[63:48] recent models that we felt like, "Okay,
[63:50] this code review is so good that our
[63:53] engineering team relies on this code
[63:55] review to pass before we merge PRs."
[63:58] And we found that this was
[64:01] we've always dreamed of Claude being
[64:04] able to be a reliable code reviewer that
[64:06] can actually that we can like
[64:08] confidently feel catches the majority of
[64:10] bugs.
[64:11] And it was only with like Opus 4 5 and 4
[64:13] 6 that we and uh Sonic 4 6 that we felt
[64:16] like, "Okay, we are now able to like run
[64:20] multiple code review agents
[64:22] simultaneously to traverse
[64:25] traverse the entirety of the code base
[64:27] and
[64:28] to synthesize a set of
[64:30] like real issues that an engineer needs
[64:33] to address before merge. And so, this is
[64:35] like a new capability that the the
[64:37] newest models have unlocked.
[64:39] >> This is another trend that is very
[64:40] common on this podcast of build
[64:42] something that will possibly be possible
[64:45] in the next 6 months. You kind of at the
[64:47] edge of what's working sort of and then
[64:49] it'll catch up and then it'll be an
[64:50] amazing product and you'll be ahead of
[64:52] everyone.
[64:52] >> Yeah, exactly. Um it's pretty important
[64:55] to build products that don't necessarily
[64:57] work yet so that you know, okay, what is
[65:01] missing
[65:02] um for this product to work and then
[65:04] with the newest model, you can just swap
[65:06] it in to the prototype you've already
[65:08] made and see, okay, does this new model
[65:11] close that gap?
[65:12] >> How much are you able to speak to just
[65:13] kind of where things are going with Clod
[65:16] and Cork as kind of the vision of it? I
[65:18] imagine you don't want to give away too
[65:19] much about the goal, but it feels like
[65:21] you're There's all these awesome
[65:22] features being added on top. Dispatch,
[65:24] control from phone, and all these mobile
[65:27] app, all these things. What's kind of
[65:28] just like with a way to understand the
[65:30] vision for all these things long term?
[65:32] >> We think about this in terms of building
[65:34] blocks. So,
[65:35] for both Quad Code and Cork, the core
[65:37] building block is making individual
[65:40] tasks successful. So, you you want us to
[65:43] produce some output, you give it a clear
[65:46] prompt description. Is it able to
[65:48] consistently produce acceptable output
[65:51] that you're able to either merge or
[65:53] share with your colleagues or external
[65:54] audience? So, the task is the core
[65:56] building block.
[65:57] As the models get smarter, the task
[65:59] success rate gets a lot higher, and then
[66:01] we see people moving towards doing
[66:03] multiple tasks at the same time. So,
[66:05] multi-cloding was this big thing in
[66:07] towards the end of 2025, and it's only
[66:09] increased since then. And so, we see
[66:11] this as, "Okay, great.
[66:13] One task works, and now you can do like
[66:16] six tasks at a time."
[66:18] As the models get even smarter, the way
[66:20] that we were extrapolating this is,
[66:21] "Okay,
[66:23] next, maybe you're going to run like 50
[66:25] clods at a time or hundreds of clods at
[66:27] a time." And so, what is the
[66:28] infrastructure we need to build to
[66:29] enable that?
[66:30] At that point, you're probably not going
[66:32] to run everything locally on your
[66:34] machine anymore. There's just like not
[66:35] enough RAM
[66:37] to do it.
[66:38] And so, we're we're thinking about
[66:41] how do we make it easier for you to
[66:43] manage all these These will probably run
[66:45] remotely. How do we build the interface
[66:47] so that you as a human know
[66:50] which tasks you need to look look into.
[66:53] How do we make sure that the agent is
[66:54] fully verifying work so that
[66:57] when you look at a task and it says it's
[66:58] done, you like can very quickly verify
[67:01] and fully trust that it is done to your
[67:03] spec.
[67:04] And how do we make sure that this like
[67:06] process is self-improving? So that when
[67:08] you do see a task that isn't done to
[67:11] your liking, you can give it feedback
[67:13] and the model will know for every future
[67:15] run to incorporate that feedback so it
[67:17] never makes that mistake again.
[67:19] So, this is the progression that we're
[67:21] we're bringing our users along for.
[67:23] >> There's a lot of people listening, a lot
[67:24] of product managers, a lot of maybe
[67:26] founders, a lot of other
[67:27] cross-functional folks listening.
[67:30] There's a lot of worry about just how
[67:31] their role
[67:33] the future of their future of their
[67:34] careers.
[67:35] What advice would Juffer just people to
[67:39] not just survive this transition to this
[67:41] very AI-driven world, but to be really
[67:43] successful, to essentially just to
[67:45] thrive in this future? What are just
[67:46] like things people need to hear, need to
[67:48] be doing?
[67:49] >> I think AI gives everybody a ton more
[67:52] leverage than they used to. And so, I
[67:55] would push you towards anytime you
[67:57] realize that you're doing some manual
[67:59] task multiple times, think about how you
[68:01] can use Claude Code, Co-work, or other
[68:03] AI tools to automate that for you.
[68:07] Most people
[68:08] have like creative parts of their job
[68:10] that they absolutely love and then like
[68:12] tedious parts of their job that they
[68:14] really hate doing. I think the beauty of
[68:16] AI is that it can do those tedious parts
[68:19] for you. It can learn from every time
[68:22] that you've done that manual task and
[68:24] generalize and then run it
[68:26] automatically. And so that you can focus
[68:28] on the creative parts and that means you
[68:30] can do a lot more than you used to be
[68:31] able to do.
[68:32] So, I think my like immediate push for
[68:35] people is figure out the repetitive
[68:37] parts that you can pass to Claude.
[68:39] Iterate on those automations until the
[68:40] success rate is very high.
[68:43] And then focus on, okay, what more can
[68:44] you be doing for your team, for your
[68:47] product, for your company that like
[68:49] people haven't had the bandwidth to pick
[68:51] up so far? Or like, what is that like
[68:53] pet project that you always thought the
[68:55] company should do that like you've never
[68:57] had bandwidth to do? If AI can take care
[69:01] of
[69:02] the like front work, then you have you
[69:04] have this extra 20% time now that you
[69:07] might not have before. So, so my push is
[69:10] to lean into these tools, hand off the
[69:12] work that you're not excited to do,
[69:14] figure out how it can accelerate you,
[69:16] and then as a result, you'll be able to
[69:18] do so much more.
[69:19] >> Something core to what you just shared,
[69:20] which I fully agree with, is find
[69:22] problems to solve with AI. There's all
[69:25] this potential what all these tools can
[69:27] do.
[69:28] Some of the hard like For a lot of
[69:30] people, the hardest part is just like,
[69:31] "What should I actually do?" And what
[69:32] you're saying here is just pay attention
[69:34] to things that you are doing constantly
[69:36] you can automate. Pay attention to just
[69:37] like ideas that have been floating
[69:39] around that you haven't had time to do.
[69:41] Um it's basically it's like solve a
[69:42] problem for yourself. It's kind of the
[69:44] core advice there.
[69:45] >> Exactly. I I would also push listeners
[69:47] towards focusing on
[69:50] bringing your automations from, "Okay,
[69:52] this is a cool concept." to like, "Hey,
[69:53] this actually works 100% of the time."
[69:56] Like sometimes I see users trying to
[69:58] automate something, getting it to like
[70:00] 90-95% accuracy, and then giving up on
[70:03] it.
[70:04] And this
[70:06] If an automation doesn't work 100% of
[70:08] the time, it's not really an automation.
[70:10] And that last 5 to 10% does take
[70:14] more time.
[70:15] Also, building the automation is often a
[70:17] lot slower than you doing it yourself.
[70:20] I would encourage listeners to put in
[70:22] that time to scope some automation that
[70:25] you really want to get to 100%. Put in
[70:28] the elbow grease to teach Claude your
[70:31] preferences, to like give it feedback so
[70:33] that it can improve its skill, so that
[70:35] it can get to that 100%, and then like
[70:38] really then you'll be able to rely on
[70:40] it. There There's just not much value in
[70:42] a 95% there automation.
[70:44] >> I am super guilty of that. This is
[70:46] really good advice for me.
[70:48] >> I've been guilty of this, too. I've been
[70:49] teaching it. I've been teaching Coda to
[70:52] try to get me to inbox zero for Gmail,
[70:55] and it has not been It has been very
[70:58] time-consuming and it is definitely not
[71:00] there as you probably realized.
[71:02] >> Yeah, I funny enough that's exactly
[71:03] where my mind goes. I have this
[71:05] uh workflow I set up where every email I
[71:07] get it
[71:09] looks for things that are spammy which
[71:11] is just like all these like hey can I
[71:12] come on your podcast or what about this
[71:14] like all these things I'm just like I
[71:16] don't have time for these sorts of
[71:17] things and I have it categorized it into
[71:19] a folder called spammy. And it's just
[71:21] like it's 95% great but then there's
[71:23] like oh man I missed an email cuz it
[71:25] went in there. So this is a good push
[71:26] for me to like I'm going to work on
[71:27] this. I'm going to get it to perfect.
[71:28] >> Yeah. We also are working on making the
[71:31] flow for customizing these commands a
[71:33] lot easier cuz right now I think you
[71:35] have to like know too many concepts. You
[71:37] have to know to define a skill. You have
[71:39] to know to like use the skill and give
[71:40] it feedback. And then you have to know
[71:42] to tell Coda to update the skill based
[71:45] on all the feedback that you gave. And
[71:47] then you also have to know where to read
[71:49] the skill to like make sure that the
[71:50] feedback was incorporated the way that
[71:51] you want. The it's also our job to make
[71:54] this flow really seamless so that it
[71:56] doesn't feel painful to do.
[71:57] >> Amazing.
[71:58] Is there anything else Kat you wanted to
[72:00] to share? Anything else you wanted to
[72:01] leave listeners with? Anything you want
[72:03] to double down on
[72:04] that we haven't already touched on
[72:06] before we get to our very exciting
[72:07] lightning round?
[72:08] >> I see a lot of people playing around
[72:09] with AI
[72:11] and building like prototype apps and
[72:14] tinkering with building workflows.
[72:17] I would really push people towards
[72:19] building apps that you're actually using
[72:21] every single day cuz I think only
[72:23] through that usage are you actually
[72:25] getting the value. Like if you build a
[72:26] prototype app that
[72:29] isn't helping you get more done
[72:32] then the the AI isn't really adding
[72:35] value to your to your day.
[72:38] >> And there's only so much you learn from
[72:39] that when it's like okay I just did one
[72:41] shot at something oh that's cool and
[72:42] then you never come back to it. Like
[72:44] you're not learning a lot.
[72:45] >> And you're not getting like much
[72:46] leverage from it.
[72:47] >> And actual leverage yeah that's such a
[72:48] good point.
[72:49] >> I also think there's a lot of people who
[72:50] spend a lot of time like customizing
[72:52] their workflow. So, there's like I think
[72:54] there's like two ends of the spectrum.
[72:55] One is like people who never customize
[72:57] or never build automations, but there's
[72:59] like this polar opposite end of people
[73:00] who, like, obsess around
[73:03] customizing their tool, like, adding a
[73:05] ton of skills and MCPs and
[73:10] um these like workflow improvements.
[73:12] And I think sometimes that can even
[73:13] distract from your core goal of like
[73:16] launching some product or building some
[73:17] feature. I think there's a lot of fun in
[73:19] customizing and we definitely want to
[73:21] make our products very hackable so that
[73:24] you you can make it work really well for
[73:26] you, but there is a limit to
[73:29] how much it's useful.
[73:31] Um and I think there there's a camp of
[73:33] people who maybe spend so much time
[73:35] customizing that they're like not
[73:37] sleeping and not doing the like core
[73:39] task that they originally set out to do.
[73:41] >> I see a lot of that on Twitter.
[73:43] Just like, "Look at my setup. It's out
[73:45] of control. It's so optimized." And what
[73:47] are you What are What are you actually
[73:48] building? No, but my my setup is so
[73:50] awesome. Like, you can get so much done.
[73:52] >> I think the simple setups actually work
[73:54] better.
[73:55] >> Mm. Slash power up. Getting Take level
[73:58] up a little bit.
[73:58] >> Yeah, yeah.
[73:59] >> There's this Karpathy tweet that just uh
[74:02] came out on yesterday where he talked
[74:03] about this divide that's interesting
[74:05] between people that tried chat GPT cloud
[74:08] back in the day, it was like, "Okay."
[74:10] And they're like, "Nah, this is This is
[74:12] terrible." And they kind of gave up on
[74:13] like what AI could do for them and they
[74:15] just like so cynical of like, "No way,
[74:16] it's not actually that big of a deal."
[74:18] And then there's people that are
[74:19] using it to code, essentially, who see
[74:21] the full
[74:23] intense power of it and how good it is.
[74:26] And
[74:27] people on both sides don't understand
[74:28] the other side and why they like how
[74:30] much they how they see the world.
[74:32] And so, your advice is really good here
[74:33] of just like actually use it for real
[74:35] things and see how good it actually has
[74:37] gotten.
[74:38] >> Yeah. I think that big shift is that the
[74:40] 2024 generation of products were
[74:43] chat-based and the cloud code generation
[74:46] of products is action based and
[74:50] the like big aha moment people have is
[74:52] when Claude can just like do things on
[74:54] your behalf. It is It is an amazing
[74:57] feeling to know that the agent is
[75:00] capable of doing so much more than
[75:02] telling you what to do. Like the agent
[75:04] can actually just do it itself and when
[75:06] people feel that, I I think that's the
[75:09] eye-opening moment.
[75:10] >> Shout out Chrome extension, the Claude
[75:12] Chrome extension which you can just
[75:13] watch it doing stuff. You be like fill
[75:16] out this form for me and I'm like all
[75:17] right, here I go.
[75:18] >> Exactly.
[75:19] >> Okay. Anything else before we get to our
[75:21] very exciting lightning round?
[75:22] >> No, let's do it.
[75:23] >> Let's do it. Kat, I've got five
[75:26] questions for you. Welcome to the
[75:28] lightning round. There's this animation
[75:29] that plays so I have to make sure to say
[75:30] it.
[75:31] Are you ready?
[75:32] >> I'm ready.
[75:33] >> First question, what are two or three
[75:35] books that you find yourself
[75:36] recommending most other people?
[75:38] >> I really like how Asia works. It's a
[75:42] story about economic development and
[75:45] what are the like the policies and
[75:48] governments that make long-lasting
[75:51] successful economies.
[75:53] The other books that I'm really into are
[75:55] the technology trap. So this is actually
[75:58] about the past few technology
[76:00] revolutions, so the industrial
[76:02] revolution and the computer revolution
[76:04] and how this has affected workers.
[76:07] The The reason that I really like this
[76:09] is because I think we there's a lot we
[76:11] can learn from history to make sure that
[76:13] this transition goes well.
[76:15] And
[76:17] maybe on like a fun note, I really like
[76:19] Paper Menagerie.
[76:20] It's just like a book of short stories
[76:22] about like coming of age and AI and
[76:28] just like self-discovery.
[76:30] >> Favorite recent movie or TV show you
[76:32] have really enjoyed?
[76:33] >> I really like Drive to Survive.
[76:37] There's no like deeper meaning to it. I
[76:39] just
[76:41] There's just something very satisfying
[76:42] about people being so obsessed with like
[76:46] a singular engineering goal and
[76:49] just like the purity of the pursuit. Um
[76:52] and I also really love Free Solo, which
[76:54] is about Alex Honnold um climbing El
[76:58] Capitan without a harness. And I think
[77:01] similarly, it's just such a pure
[77:04] achievement to be able to climb this
[77:07] extremely challenging, dangerous route.
[77:10] And to be able to have the mental focus
[77:13] to do it knowing that if you make a
[77:15] single mistake, you die.
[77:17] >> It's insane. Yeah, that movie is out of
[77:18] control. And it's interesting how these
[77:20] relate in some way to the work you do.
[77:22] >> I actually am a rock climber. Um but I
[77:24] first watched Free Solo before I climbed
[77:26] rocks. And so
[77:28] I I thought it was impressive, I didn't
[77:29] understand how impressive it was. It's
[77:31] one of the rare movies where like the
[77:32] more you know about it, the more you're
[77:34] you're blown away by how insane this is.
[77:37] Like the kinds
[77:38] the kinds of moves he's doing on the
[77:40] wall are things that like
[77:41] I don't think I will ever be able to do
[77:43] in my lifetime if it were set in a gym
[77:45] like 1 ft off the ground.
[77:47] >> With a rope.
[77:48] >> With a rope.
[77:50] >> Did you see that documentary on that
[77:51] other guy, the younger one that went on
[77:53] like ice mountains?
[77:54] >> That one was very sad.
[77:56] >> But that was that was wild. Okay, uh
[77:58] favorite product you've recently
[77:59] discovered that you really love?
[78:00] >> The product that has like most changed
[78:02] my life outside of cloud products is
[78:05] probably Waymo.
[78:07] Like I'm a die-hard Waymo user.
[78:10] Um use it twice a day, get to and from
[78:11] work. So the two things that I really
[78:13] like about it are one,
[78:15] I don't feel bad if a Waymo is waiting
[78:18] for me. And so I feel like I feel less
[78:20] pressure to
[78:21] be right at the curbside the moment it
[78:24] arrives. And the second thing is, I feel
[78:27] like it lets me be a bit more
[78:28] productive.
[78:29] Um when when I'm in the car with another
[78:32] human, I I typically try not to like do
[78:34] any work calls. I I feel a little rude
[78:37] if I'm like on my laptop the whole time,
[78:39] but one thing I really appreciate about
[78:40] the Waymo is I can call into a work
[78:42] call, I'm not worried about someone
[78:44] overhearing me, I'm not worried about
[78:46] hey, is this like rude, am I talking too
[78:48] loud, do I need to tell ask someone to
[78:50] like change the music? And so this has
[78:51] been like I feel like this has given me
[78:53] back like 30 minutes every day.
[78:55] >> All these second order effects of of
[78:57] technology, it's so interesting.
[78:59] >> Yeah, I always thought Waymo needed to
[79:00] be priced lower than Uber and Lyft to
[79:02] succeed, but actually I'm like very
[79:04] happy to pay a 2x premium for it.
[79:06] >> I love Waymo. It's just like like once
[79:09] you see it, you're just like
[79:11] how this is insane and and then you get
[79:13] used to it. Like you get in there,
[79:14] you're like this is crazy and then you
[79:16] forget about it.
[79:17] >> Totally. I think it's also changed the
[79:19] vernacular. Like a lot of people at
[79:21] Anthropic love Waymo and I think in the
[79:23] past you'd be like, hey, like what's
[79:26] call like follow a ride share app and
[79:27] now like everyone's just like, okay, is
[79:29] Waymo here?
[79:30] >> Okay, two more questions.
[79:31] Do you have a favorite life motto that
[79:33] you often come back to in work or in
[79:34] life?
[79:35] >> Just do things.
[79:37] >> That tracks. That's a good one.
[79:38] >> lot of value in like first principles
[79:40] thinking and if if you like if you know
[79:44] what you're optimizing for and you have
[79:45] like strong first principles, then you
[79:47] can normally deduce what the right like
[79:48] course of action is and be able to
[79:50] clearly articulate that to all the
[79:52] stakeholders and then
[79:54] you should just like do it. Like I think
[79:56] jobs are fake.
[79:57] If you understand the constraints, you
[79:59] can figure out what you can do and then
[80:01] just like try to do it quickly, learn
[80:03] from the mistakes and
[80:05] apologize or fix them if you did
[80:06] something wrong.
[80:07] >> You You could just do things. Whoever
[80:09] said that?
[80:10] >> I think it's liberating actually to like
[80:12] tell people this. I think in a lot of
[80:13] companies like roles are very strictly
[80:16] defined. Like, okay, this is what the PM
[80:19] does, this is what the designer does,
[80:20] this is what the engineer does and then
[80:22] even team scopes are very rigidly
[80:24] defined. So hey, like this corner of the
[80:26] code base we touch and this corner like
[80:28] we're not allowed to touch and I I what
[80:30] just do things lets people do is they
[80:32] feel like empowered to make these
[80:33] decisions, empowered to operate across
[80:36] team boundaries just like get something
[80:38] done.
[80:38] >> That feels like a big
[80:40] important skill to be good at. People
[80:42] call it agency. Just like do the things
[80:45] that need to be done.
[80:46] >> Bias towards action. All these ways of
[80:48] describing just like don't wait for
[80:49] permission.
[80:50] >> Yeah, I think this is my favorite reason
[80:52] to work at a startup at some point in
[80:54] your life because like one thing that
[80:56] was like very life changing for me was
[80:58] actually working at scale when we were
[80:59] 20 people and so there was just no
[81:02] process and we had like really big
[81:04] problems that we needed to solve and
[81:06] it was like I really appreciate Alex and
[81:09] the rest of the team for like empowering
[81:10] me and the rest of the team to just like
[81:13] figure things out without any boundaries
[81:15] for what sales is supposed to do, what
[81:17] ops is supposed to do, what engineers is
[81:18] supposed to do. Just like you have all
[81:20] the tools at your disposal.
[81:22] You have some like ambitious hairy
[81:24] problem statement and you can do
[81:25] whatever you need to like get to a good
[81:27] solution.
[81:28] >> Like you almost need that experience to
[81:30] build that skill to feel comfortable
[81:31] doing that cuz a lot of people, you
[81:33] know, they go through school and college
[81:35] and all these like do the thing we tell
[81:36] you to do and then you will get a good
[81:38] grade. And you have to kind of unlearn
[81:40] that of like, okay, I'm just going to do
[81:41] the thing that needs to be done and even
[81:42] if people think it's dumb, I think it's
[81:45] the right thing to do.
[81:46] >> Yeah, exactly.
[81:47] >> Okay, I actually have two more quick
[81:48] questions. Two more final questions. One
[81:49] is uh when Claude thinks there's all
[81:51] these I don't know if you call them
[81:53] verbs. What's the term for these things?
[81:55] >> Uh thinking words.
[81:56] >> Thinking words and interestingly these
[81:58] all leaked in the source code. Uh is it
[82:00] do you have a favorite thinking word?
[82:03] >> Mhm, I really like manifesting. It's
[82:05] also like the sticker that
[82:07] I I have on my laptop.
[82:08] >> Oh, amazing. It's clearly the winner.
[82:11] Okay, final question. Asked Boris this
[82:13] too. With AGI
[82:15] potentially arriving in our lifetime
[82:18] when you don't
[82:20] potentially have to work, what are you
[82:21] going to do? What are you going to do
[82:22] with all your time?
[82:23] >> I think it it will take a long time for
[82:26] AGI to diffuse across society. So, I
[82:28] think that media thing is actually just
[82:31] like helping bring the world along. I
[82:33] think my like non-serious answer for
[82:34] after this happens is I'll probably just
[82:38] do a lot of rock climbing. I'll probably
[82:40] just like live in some
[82:42] I'll probably move to like Fontainebleau
[82:43] and just like live amongst 10,000
[82:45] boulders and
[82:47] climb for a bit. There's also so many
[82:49] books I want to read that
[82:52] my my goal is to be able to read one or
[82:54] two books a week and I'm currently at
[82:58] probably like 0.5.
[83:02] I the backlog is pretty big. I think
[83:04] there's just like so much we can learn
[83:05] from history and so much that I don't
[83:07] understand as well as I would love to.
[83:09] Like I don't know anything about physics
[83:11] and
[83:12] or like robotics or like
[83:15] any hardware or like aerospace or
[83:18] there's just so many interesting topics.
[83:20] So, I'm excited to learn even even
[83:22] knowing that the AGI will already know
[83:24] it.
[83:26] >> Cat, this was amazing. You're awesome.
[83:29] Two follow-up questions. Where can folks
[83:30] find you online if they want to reach
[83:32] out and just follow what you're up to?
[83:33] And how can listeners be useful to you?
[83:35] >> The best way to reach out is I'm _catwo
[83:39] on Twitter.
[83:40] Um feel free to like tag me in things.
[83:44] Feel free to DM me. I read all all my
[83:47] DMs. I don't always respond to every
[83:48] single one, but I will read them all.
[83:50] And then the thing that is most helpful
[83:53] is
[83:55] tell us where Claude Code and Co-work
[83:56] aren't working well for you. We we're
[83:59] very grateful for the amount of positive
[84:02] feedback, but the thing that we thrive
[84:05] on is
[84:06] edge cases, errors, like specific tasks
[84:10] that we can reproduce where Claude Code
[84:13] or Co-work fail. Because if you're able
[84:16] to share that with us and we're able to
[84:17] reproduce it, then this is something
[84:19] that we're able to actively improve for
[84:21] our next generations of models and for
[84:23] our next harnesses.
[84:25] >> Extremely cool. Everyone on People on
[84:27] Twitter are not shy with sharing this
[84:28] feedback, so
[84:30] keep it coming.
[84:30] >> Yes, share us share Please please share
[84:33] the problems that you're having with us.
[84:34] >> Yeah, and it's really cool to see all
[84:35] you your team being on so active on
[84:37] Twitter and responding to people.
[84:39] And so so like what I'm hearing like
[84:41] this is actually stuff you guys actually
[84:42] see and react to, so.
[84:44] >> Yeah, we appreciate everyone being so
[84:45] engaged with us. It gives the team a ton
[84:47] of energy. We we have this channel of
[84:50] like user love and so whenever you guys
[84:52] share a success story, we post it there
[84:54] and whenever you guys share like issues
[84:57] with our product, we put it into our
[84:59] feedback channel that way our broader
[85:00] team is able to act on it.
[85:02] >> That is so cool to know.
[85:03] Thanks for sharing that.
[85:05] Well, Cat, thank you so much for being
[85:07] here.
[85:07] >> Thanks for having me.
[85:09] >> Bye everyone.
[85:11] Thank you so much for listening. If you
[85:12] found this valuable, you can subscribe
[85:14] to the show on Apple Podcasts, Spotify,
[85:16] or your favorite podcast app.
[85:19] Also, please consider giving us a rating
[85:21] or leaving a review as that really helps
[85:23] other listeners find the podcast. You
[85:25] can find all past episodes or learn more
[85:27] about the show at lennyspodcast.com.
[85:30] See you in the next episode.
