Anthropic's First Technical PM on Evals, Emergent Capabilities, and Why Product Judgment Still Matters
Lenny's PodcastDianne Penn joined Anthropic in 2023 as its first technical product manager, when the product team was five engineers. Today Penn is head of product for Anthropic's AI research and Labs teams. In this conversation with Lenny Rachitsky, Penn traces how Anthropic went from an apparent underdog to a company Rachitsky describes as reportedly making around $50 billion in annual recurring revenue. Penn also describes how product work changes when the thing you're building is a model whose capabilities can't be fully predicted in advance. Penn's central argument is that the fundamentals of product management still hold: stay close to users, reason from first principles, and be hands-on. What has changed is the artifacts. The most important of these, in Penn's view, is the eval.
The early days: a strong culture and Golden Gate Claude
Rachitsky opened by recalling how hopeless Anthropic looked when its first model launched: OpenAI seemed too far ahead. Penn said much of what makes Anthropic work today was already present in 2023. The company had five product engineers, and one engineer covered the entire API business. What stood out to Penn was the culture: the company "really do[es] walk the walk" on its mission and values, and it had startup energy. Anthropic was also still searching for its identity. It had the technology, but it was unclear how that technology would create value for users and for society. The company started with Claude.ai, another chat assistant, and gradually moved into areas like tool use.
Penn pointed to Golden Gate Claude as one moment when the company began "to get into our groove." In early 2024, Anthropic published interpretability research showing that models contain internal "features" corresponding to themes, such as writing in bullet points, people and places, or the Golden Gate Bridge. When researchers dialed up the Golden Gate Bridge feature, Claude became obsessed with it. Ask for a spaghetti recipe, and it would note that the sauce's orange color resembled the bridge's international red. Engineering, product, design, and research teams worked together to put this experience on Claude.ai within 24 hours, and it stayed up for roughly a day. Penn admitted it may have reached only about 2,000 people. Still, Penn called it a "hidden inflection point." It showed the team could ship user experiences that were authentic to Anthropic's research, looked different from what competitors offered, and moved at startup speed. Penn also stressed that the project was bottom-up: engineers and designers donated their own time to it. Penn says that culture has stayed the same since.
Opus 3 and the early bet on coding
Asked about the major inflection points, Penn named the training and testing of Claude 3 Opus first. At that point the company had fewer than 200 people, and it had become clear that it needed a frontier model, both to reach users and to showcase its research. The recurring question from outsiders was "why should somebody choose Claude?" The model launched in early March 2024, after months of work across inference, pre-training, fine-tuning, and research. Penn remembered a video call around December with the research leads, everyone at their parents' homes with their childhood bedrooms in the background, working hard to check whether the model was turning out the way they intended. According to Penn, the trust built in those months still shapes how product and research collaborate. Several of the research leads from that period now lead reinforcement learning, character work, and alignment.
The second inflection point was recognizing that coding mattered. "In 2023 when I started, nobody said Anthropic and Claude and coding in the same sentence," Penn said. Competitor models like GPT-4 were used for coding, but only as one use case among many. Penn noticed that people were starting to use models not just for autocomplete but for writing long-form code, and saw a chance to train Opus 3 to be better at it. Penn described this as a relatively small change from a training perspective. But it differentiated Claude early and attracted the first wave of enthusiastic developers, because Claude delivered value they hadn't thought was possible yet.
Opus 4.5 and Claude Code: frontier products for frontier models
Rachitsky pointed out that Opus 3 now seems modest, and raised Claude Opus 4.5, which arrived about a year later, again around winter break, "when everyone was home able to code." Penn agreed it was another big moment. What was different this time, Penn said, was that the model had a vehicle: Claude Code. A phrase the team uses often is that you need frontier products for people to feel the magic of frontier models. Internally, the team had felt Claude Code's magic for months. With Opus 4.5, the model's intelligence reached a level where a broad set of users could run things end to end, agentically. Penn saw the two as dependent on each other: Opus 4.5 wouldn't have had that moment without Claude Code, and Claude Code's adoption wouldn't have accelerated the way it did without Opus 4.5.
Living inside the exponential
Rachitsky noted that Dario Amodei had predicted AI would write essentially all code. Many people dismissed that, and in Rachitsky's view, Amodei turned out to be right. Amodei now describes the industry as being on the steep part of an exponential curve. Rachitsky asked what that feels like from the inside and how people should prepare.
Penn compared the moment to the internet's shift from novelty to something everyone uses, a transition most of the current team wasn't yet working through. Penn drew two lessons. The first is adaptability. Anthropic has evals, safety testing, red-teaming, and new prototypes, yet it's still very hard to predict exactly when a given capability will arrive, or in which model. So the critical skill is making better decisions when new information arrives, instead of sticking with the original plan. The second is first-principles thinking about the "so what": which new products to invest in, and how to explain the differences to users. In practice, a plan the team expected to execute months from now may get pulled forward because a new model can already handle it. Penn cited Cowork, Skills, and Tag as examples, and called this a positive, self-reinforcing loop. Penn also named a softer requirement. Some teams feel the exponential sooner than others, so a growing organization needs trust and "the grace" to bring everyone along.
Emergent capabilities and "overhang"
Penn connected the unpredictability to the original scaling-law papers. Most people know those papers for the smooth curve showing loss from next-token prediction falling as compute and data grow. But the papers also include graphs of emergent capabilities that jump discontinuously. A model goes from being unable to compute one plus one to doing it reliably. Penn said this lack of predictability has always been part of how the technology works. It is also part of what makes safety hard: without the evals and systems to test for them, these jumps can happen without anyone noticing.
Penn put this in PM terms as "product overhang and user overhang." Even today's models, including the current Opus models and Fable, can do much more than has been explored. Discovering those capabilities, Penn said, has been part of Anthropic's DNA from the start and remains central to how product, Labs, and research operate.
Token maxing versus experimentation as a team sport
Rachitsky brought up Garry Tan's argument: if you're willing to spend $100,000 a year on tokens now, you're living the way someone will live in 2028, when that compute will be cheap. Penn approached the idea from a product angle. Token spend is an input. The outcome you actually want is experimentation, and if you set goals around experimentation, there may be other ways to get there. Penn did agree that the most creative thinkers and best prototypers inside Anthropic spend a lot of time with every new research version of Claude. "You have to be using the models to then come up with good, then great, then better ideas, and there's no substitute for that." With the technology moving this fast, Penn argued, it's very hard to write a strong strategy without touching it.
Penn's main addition was that experimentation shouldn't be solitary. In the early days, when Anthropic had fewer product surfaces, a Slack channel let almost the entire company test early versions of Claude in public. People asked it to edit essays or draft emails without calling these "use cases." What Penn saw happen, almost magically, was that one person would try an idea, others would try variations of it, and within about ten requests a new use case would emerge. "Experimentation is not always necessarily an individual sport," Penn said, and suggested the industry could do more to encourage that kind of shared discovery. Broad capabilities like long-form writing are known. Turning them into answers to specific user pain points takes exploration.
Anthropic Labs: strong opinions on themes, weak opinions on prototypes
Penn described Labs, whose alumni and members include Ben Mann and Mike Krieger, as a group that pulls on the thread of "discontinuous large bets" that might not fit the core roadmap. The question Labs asks is whether there's "a there there," and if so, what the 10x, 100x, or 1,000x version of it would be. Claude Code, Skills, MCP, and most recently Claude Design came out of this model.
Penn said the approach this year is to hold strong opinions about a theme or area and weak opinions about the specific prototype. Engineers are self-driven and test ideas bottom-up. Sometimes the team has a thesis that doesn't work yet and revisits it one or two model generations later. Prototypes that only produce learning still count as valuable, and that lets Labs "see around corners" for the rest of the company.
Asked what makes Labs work, Penn named culture, Ben Mann's vision and push to think about the 10x or 100x version of an idea, and small pods. Some ideas start with a single engineer. Penn believes large teams chasing very ambiguous ideas tend to slow down. Labs also selects for people who want to do zero-to-one work. Penn acknowledged that this is hard. The team turns down or shuts off many bets, and "you're acting as a founder for a bet and it's not working yet," after pouring your heart into it.
What researchers do, and how PMs make feedback actionable
Rachitsky offered his mental model of researchers: form a hypothesis, find data, adjust algorithms and training, test, and iterate. Penn said that describes the day-to-day well. But strong researchers also have a long-term vision with "very founder-like energy." Even when the company was founded, researchers were already asking how AI could use a computer or navigate a screen. Research runs on two loops: a medium- and long-term view of where the technology can go, and near-term improvements to the Claude that people already use.
Penn's team embeds in those loops wherever users feel the impact most: vision, computer use, coding and agentic coding, tool use, and test-time compute. A big part of the job, and sometimes the hardest part, is turning user feedback into something researchers can act on. "Claude hallucinated" is too vague to hand to a researcher. So the team examines the trajectory behind feedback that users have consented to share. Should Claude have called a tool instead of answering from its own knowledge? That would be a tool-use failure. Did it look at the right document but pull the wrong facts? That would be a search and synthesis problem. Or is it an alignment issue? The team then judges whether the problem is big enough to prioritize and builds evals that can show whether it has improved. Penn described this as learning researchers' day-to-day language and shortening the distance between users and model training.
What makes a strong researcher, and the "Claude 8" question
Penn described Anthropic's most successful researchers and research leaders as strong first-principles thinkers who are passionate about their area, can describe a bold version of what it could become, and stay close to the details. According to Penn, the chief scientist and the heads of fine-tuning and RL look directly at training runs, evals, and the underlying data. Researchers who enjoy the details develop taste. They also think big over time. Penn's example was Dario Amodei's belief that software engineering could be transformed. In Penn's view, you learn a great deal by aiming for the stars.
Rachitsky noted how often "be more ambitious" comes up these days, and how hard that advice is to act on. Penn suggested grounding it. Think an idea through end to end once or twice, be stubborn about the area, and stay loose about the approach. One question Penn often asks the team: "Let's say Claude 8 comes around. What changes in what users do?" And what does that mean for what you build today? Is it forward-compatible with that future?
Safeguards for more capable models
Rachitsky observed that the Fable release (he also called it Mythos) broke the old pattern of releasing a model to everyone. It faced scrutiny and restricted access, and companies had to check that it couldn't break into their systems. Penn left policy and export control to the people who own them and spoke only to the product side. As frontier models get more capable, safeguards, red-teaming, and the pre-release process have to evolve quickly. The goal is to make sure the technology's benefits clearly outweigh its risks and to minimize severe downside. Before Fable, the team didn't have strong fallback UX and systems. Now, when a request is blocked, users can still get a good response from an Opus model. Penn said there's more to do on both safety and user experience, and that Anthropic will be improving what it now calls its "model safeguards package" in the coming weeks and months.
Rachitsky suggested that restricted access could create an unfair advantage for labs and for the few companies with access. Penn said Anthropic's goal is to make these systems as inclusive as possible, to avoid that outcome for general-purpose technology, and that reducing it is currently one of the company's top priorities.
"Evals are the new PRDs"
Asked how hiring has changed, Penn said the team hasn't changed its PM hiring process in three years. The top trait is still first-principles thinking: working out what creates user value for this user group, with this technology, right now, instead of pattern-matching from consumer or B2B SaaS.
Penn's example of first-principles thinking was the team's saying: "Evals are the new PRDs." A PM owns product strategy and user value. Traditionally, PMs expressed that through PRDs and vision documents. For research PMs, the way to drive user value is to capture the right user feedback as evals that embody the user's need. The first-principles move is to ask what activity actually achieves the goal, instead of repeating the familiar activities.
Penn refined Rachitsky's summary: the first step is still understanding the user's pain point, but the way you access it is different. User interviews used to walk through pixels. Now "you have to sweat the tokens as much as you sweat the pixels." The team reads transcripts of failed trajectories and classifies them carefully. Was it a hallucination? Was Claude overconfident? That nuance becomes a durable description of the pain point, which becomes an eval. The eval also needs to be "on distribution": it should cover cases where the model fails and cases where it should not fail. The eval then goes to research, so that, in Penn's hypothetical example, the team can check whether a future Opus 5.5 finds the right part of a document and synthesizes it correctly.
A concrete eval: JSON and instruction following
Penn said the team pioneered this practice at Anthropic and gave an early example. In the Claude 2 era, users complained that Claude was bad at following instructions. Penn asked users for specifics: what situation, what exact prompt, what response. About 80% of the complaints turned out to mean that Claude wasn't producing correct JSON. That mattered because following output schemas is fundamental to being a good agent. If a model can't produce a required format, it can't call APIs or tools. The team started by generating roughly 30 to 40 examples of the failure, each with a prompt and a "golden answer," and that became the eval set. It went into the eval repository and runs on every new version of Claude. Penn said it now scores essentially 100%, or 99.9%, so it's no longer a pain point. The process was: take user feedback, figure out what users actually mean, check whether it can be reproduced consistently and whether it's a big issue, then standardize it so researchers can use it.
Rachitsky called this test-driven development for PMs. Penn said it's becoming a broader skill beyond model teams, because many products sit at the intersection of models, harnesses, context, and users, and "you can't improve what you can't measure." Penn added that the work is still tactile and judgment-based. Rachitsky noted it's also non-deterministic, so evals have to describe behavior more broadly than an exact-match test would.
PRDs aren't dead
PRDs still matter for two purposes, Penn said. First, they align large groups. Every model has a PRD, written less for researchers than for the growing set of product surfaces, engineering teams, and stakeholders such as legal and safety, so that everyone "rows in the same direction." Second, they help with ambiguous opportunities. Before something like computer use ships, there's no body of user pain points to draw on, and the product-vision part of a PRD helps figure out how to make an immature technology work well for some group first. Rachitsky noted that this matches what the head of OpenAI's Codex app told him on the podcast.
Managers have to ship
For mid-career people and leaders, Penn feels strongly that you can't manage teams working with this technology well unless you're hands-on yourself. That means shipping, not just tinkering, and sweating the tokens alongside your PMs and engineers. Experienced PMs who join Penn's team get the same onboarding plan as early-career hires: understand users, read consented feedback, and talk to customers. Without building something yourself, Penn said, it's hard to recognize what a good or great AI feature looks like. Penn personally takes ownership of one or two workstreams for each model to keep an accurate "theory of mind" about how quickly the models are improving.
Penn added that you also have to enjoy it. The people most likely to succeed at any level love working with AI and set aside time for hands-on, end-to-end shipping and gathering user feedback.
Finding joy, and not burning out
Rachitsky asked what to tell people who feel tired and pressured to use AI. Penn returned to the point that experimentation isn't a solo sport. Penn has worked with nearly every research version across roughly 20 production versions of Claude, and says much of the joy comes from watching other people discover use cases. Penn's suggestion: pair with someone enthusiastic on a use case you care about, instead of trying to find the perfect use case alone, which can start to feel like work. Rachitsky mentioned a survey he ran with his colleague Noam, which found that people were happier when they went deep on a few AI uses that genuinely improved their lives, instead of scattering across many half-working ones. Penn agreed. There are too many prototypes to keep up with, so Penn goes deep on one or two, and treats it as a question of prioritizing time and energy.
On burnout, Penn gave a sense of the pace: Anthropic shipped four model series in all of 2024, and Penn says it shipped more than that in Q2 of this year alone. The work can feel like a high-performance sport, with critical decisions made quickly on new information about users and training, and "nobody can do that sustainably by themselves." Penn credited the team. The night before a launch, people who aren't the directly responsible individual for that model stay up to review the blog post and improve demos. Penn referred to an article that described this as Anthropic's "hive mind." Because of it, Penn said, taking time off doesn't mean returning to triple the workload. You can take PTO knowing the team will make the right calls. Penn also mentioned a supportive partner, and noted this is Penn's sixth year working in AI, first at Amazon and now at Anthropic.
Rachitsky noted that Fiona Fung had said software engineering feels lonelier now that people work with fleets of agents. Penn responded that because the technology gives each person more leverage, people are making decisions on very large things. Colleagues who share your first principles and assumptions can back you up or challenge you and sharpen your thinking. That's why Penn hires for low-ego, team-oriented people who care about contributing to the team's impact more than building a large org.
How Penn uses Claude, and how to avoid overreliance
Besides Fable and Claude Tag, which Penn described as an early-stage shift toward letting an agent go off and bring work back, Penn highlighted an older use: becoming a better manager. Penn loves the book Crucial Conversations and built a Skill based on it. The Skill helps check whether Penn is going into the right level of detail for a difficult conversation. Penn described it as personalized coaching: brainstorming how someone might react, going deeper faster, building trust, and being more direct. Penn doesn't always take Claude's suggestions, but finds the process helpful and has been sharing it with other managers.
On cognitive atrophy, Penn said thinking and writing are closely tied for Penn personally. When personal judgment matters most, Penn forms a point of view first, then works through it with Claude, keeping Penn's own sense and tone. For standardized work like monthly business reviews, the writing is worth much less than the thinking, so Penn wants to delegate the writing fully to Claude, supported by a Skill that's still being refined, and act as reviewer and verifier. The deciding question is whether delegating to Claude gives asymmetric value in that context.
Why pushback makes Claude better
Rachitsky raised Ben Mann's point that Claude's constitution and alignment focus make it more interesting to talk to, not less, and noted that OpenClaw users reportedly disliked switching away from Claude. Penn tied this to thinking. You don't want an AI that just agrees with you, any more than you'd want a coworker who never pushes back on half-formed ideas. For Claude to be as capable as possible, it has to push back at the right moments. Penn gave a somewhat meta example: using a research version of Opus to help decide how the next version of Claude should be priced. The goal is a better outcome, not an assistant that just executes delegated tasks. Penn linked this to proactivity. Being proactive isn't doing what you were scheduled to do. It's knowing when to offer a new idea, and knowing when to push back is part of that. The target, Penn said, is that you leave a conversation with Claude with better ideas than you'd have had alone, not ideas that are just 10% better.
AI writing, verification, and jaggedness
Rachitsky asked why AI writing is still so recognizable. Penn first asked what the goal of detecting it would be ("what's the eval?"). Penn thinks it should be clear whether a given idea came from a particular person. For something like a monthly business review, though, Penn would be happy for Claude to write it end to end. The key question may be less who wrote something than who verified it and signed off.
On why models still write in recognizable ways, Penn said the technology is jagged. When models were good writers but weak agents, the focus was on making them more agentic and better at calling tools. Now that agentic behavior has improved, other areas show up as the rough edges, and writing is one of them. Penn said there are very active efforts on Penn's team and in research to make Claude write better, and that tone and character are a priority. Once writing improves, Penn expects the next frontier to be something like greater proactivity. Rachitsky compared people's frustration with AI writing to Louis C.K.'s bit about complaining about airplane Wi-Fi, and Penn agreed that wanting to keep improving the technology is simply human nature.
Where human judgment remains, and what to teach kids
Asked where human brains will stay most valuable on the way to AGI, Penn pointed first to judgment. Anthropic has started working on making models better at judgment over roughly the past year. But Penn sees human judgment as an accumulation of nuance and experience that these systems haven't had. With so many things AI could build, deciding what a lab should build still takes human judgment, along with persistence and proactivity. Penn called these behaviors and characteristics that go beyond general capability. Penn also pointed to subject-matter expertise. In Penn's view, software engineering is already on the exponential, but fields like biology and the life sciences are still near the bottom of it, which is why Anthropic is shipping efforts like Claude for science.
For Penn's two children, ages four and eight, Penn emphasizes the same traits previous generations needed: curiosity, persistence, and developing and trusting their own inner voice, including taking opinionated stances with their parent. Rachitsky connected this to Penn's advice on avoiding overreliance, since both come down to protecting your own point of view. Rachitsky shared an idea he heard from another parent: keep kids on early, weaker models so they still have to struggle. Penn mentioned that Ben Mann's answer, curiosity and Montessori education, had stayed with Penn, and that Montessori is what Penn's family is choosing.
Do we still need PMs?
When Rachitsky invited any final points, Penn raised a question Rachitsky hadn't asked: do we still need PMs when models are this capable and engineers are leaning in? Penn's answer was yes, and more of them. Penn described the core of the role as being user-centric, digging into what users are trying to accomplish, surfacing that in an actionable form, and doing the relentless work to make it happen. As work becomes more technology-driven, Penn argued, making it matter requires going deep, being curious, and being very hands-on. Rachitsky added that when building is easy, the hard part is deciding what to build and whether it's good.
In the lightning round, Penn recommended How to Raise an Adult, for its framing that parents are raising adults, not children, and Eric Ries's Incorruptible. Penn was especially interested in its idea of measuring culture alongside revenue, and has been thinking about how to apply that to team norms. Penn named Fallout on Prime Video as a recent watch and Claude Tag as a favorite product, noting that Anthropic uses several internal versions of it. Penn's motto comes from the grandfather who raised Penn for the first ten years while Penn's immigrant parents were students in the US: "No matter how far you go, there's always another level." Penn comes back to it whenever something new or unprecedented happens.
Penn's years as a high-yield bond trader at JP Morgan also left a lasting lesson. As the only woman, and the only person with Penn's background, on the trading desk, Penn learned that even as the most junior person, the best ideas and conviction in them matter more than anything else. Penn now tries to help anyone on the team with a great idea pursue it, regardless of level or tenure: put the idea out there, have conviction in it, and do the detailed follow-through work. Penn closed by asking listeners for feedback. Thumbs up or down in Anthropic's products, or feedback through a salesperson, reaches Penn's team, which tracks favorability closely for each research model. Penn also noted that the team is hiring curious, first-principles thinkers who question assumptions and have a "tinkering, hackery spirit."
In 2023 when I started, nobody said Anthropic and Claude and coding in the same sentence.
I want to go back to the beginning of Anthropic. I remember feeling, man, these guys have no chance. OpenAI is so far ahead.
At the time, I saw people were starting to use these models not just for code autocomplete, but actually writing long form code and saw an opportunity for us to train Opus 3 to be better at. That was the inflection.
I always think about Opus 4.5 a year later during winter break when everyone was home able to code.
What was magical about Opus 4.5 is we also now not just had a model but a vehicle, a great product experience like Claude Code. Opus 4.5 wouldn't have had that moment without a product like Claude Code and Claude Code wouldn't have had that type of adoption accelerated without Opus 4.5.
I want to talk about how the product role is changing.
For my team, the way to drive user value is to figure out the right user feedback. The evals, we actually have a saying on the team of evals are the new PRDs.
Something Garry Tan's been talking about. If you are willing to spend $100,000 a year right now in tokens, you are living the way somebody in 2028 is going to live.
You have to sweat the tokens as much as you sweat the pixels. You have to be using the models to come up with good and great and better ideas. And there's no substitute for that. People need to be more ambitious with AI tools these days because they're just capable of so much.
One thing I ask the team is let's say Claude 8 comes around. What changes in what users do? What does that mean for how you're building today?
Today my guest is Dianne Penn, head of product for the AI research and labs teams at Anthropic. She joined Anthropic as the first technical product manager over three years ago, which is a lifetime in AI time, when the product team was just five engineers. She's helped ship every model at Anthropic from Claude 2 through Fable. She's also helped incubate and launch Claude Code, MCP, Skills, Claude Design, and also core capabilities like computer use, tool use, and reasoning.
It is always such a treat and so mind expanding to get to talk to someone who's at the very center of AI and product management. It's hard to imagine someone who has seen more of where things are going than the head of product for Anthropic's research and labs teams. Before we get into it, don't forget to check out lennysproductpass.com for a year free of the hottest and most beautifully crafted AI products in the world, available exclusively to Lenny's Newsletter subscribers. With that, I bring you Dianne Penn.
Dianne, thank you so much for being here and welcome to the podcast.
Thank you, Lenny. It's so nice to see you again.
I want to go back to the beginning of Anthropic, the early days. I remember when Anthropic first launched, this was, I don't know, years, the first model when it launched years ago, three years ago, something like that.
It was three years.
I remember just like feeling that, man, these guys have no chance. OpenAI is so far ahead. Like, what are they thinking? How is this possible? OpenAI has won. It's too late. Things are very different now.
The latest number I saw was Anthropic was making like, I don't know, $50 billion in ARR. That's like what companies used to go public at. Like, very successful companies went public at 50 billion in valuation. Anthropic reportedly is making that every single year.
You joined as one of the earliest PMs. There were something like five engineers when you joined. The model hadn't even launched when you joined. What was it like in those early days of Anthropic? What's something that might surprise people about what it was like at the beginning?
I think a big part of what's made Anthropic today actually has been very much the core of even the early days. So I joined in 2023, like you said, we had five product engineers. There was one engineer for the entirety of our API business, if you believe. And I think a big portion of it was the culture was really strong, and I think this is something I emphasize for folks who are interested in the company. Really do walk the walk of the mission and the culture and the values.
And the energy was very much like a startup. And I think you're right. We were very much trying to find our identity in the early years. Like, I think there's one piece around the technology, but how does that technology bring value to users, bring value to society, and what could it possibly be? And I think the early years were us exploring that in different ways. Like, we did start with like claude.ai, like another chat assistant, and evolving into things like tool use.
I think one of the moments where really we started to get into our groove was shipping things like Golden Gate Claude. I don't know if you like remember that.
No.
So this was actually up for about 24 hours or so. We had just published one of our early interpretability research in early 2024. And one of the examples was essentially you could have what's called like features of the model within the layers, which express certain types of thematics. So one of the themes that the researchers were able to identify was, let's say, bullet point writing. Another one was people and places. And one that really came up frequently that resonated was the Golden Gate Bridge.
And so when you actually essentially dialed up that feature, Claude would obsess about the Golden Gate Bridge. So meaning in every one of its responses, it would come back and talk about the Golden Gate Bridge. So if you said like, "Give me a recipe for making spaghetti," it would say, "Here is a recipe, and the orange color is just like international red that the Golden Gate Bridge looked like."
And so it was like really quirky, and we very much wanted to, in that situation, just bring it to the masses and bring it to people who are starting to use Claude. And so the entire experience actually we spun up on our claude.ai website within 24 hours, and that took like engineering, product, design, our like research teams all working together, and we were really, really proud of it. I think it maybe reached only 2,000 people, to be honest. But it made us feel like, oh, we can actually bring new user experiences, showcase our research in a way that's different and authentic to us, and in a very startupy like pace.
That to me was like one of those, like, maybe hidden inflection points of we were starting to find our identity, that we could build products, build experiences that were different from what our competitors had, what was already out there. And I think that obviously Labs, Claude Code, etc. Like, we then started to identify ourselves as what we actually think, how to think about AI, how to bring that closer to the public.
But it was a very bottoms up culture. And so that entire experience was very bottoms up. I see engineers, I see designers donating time to work on. And so I like to always use that as an example of what the early days were like, but the culture and the values have very much, I think, stayed the same since those early days.
This episode is brought to you by our season's presenting sponsor, WorkOS. What do OpenAI, Anthropic, Cursor, Vercel, Replit, Sierra, Clay, and hundreds of other winning companies all have in common? They are all powered by WorkOS. If you're building a product for the enterprise, you've felt the pain of integrating single sign-on, SCIM, RBAC, audit logs, and other features required by large companies. WorkOS turns those deal blockers into drop-in APIs with a modern developer platform built specifically for B2B SaaS.
Literally, every startup that I'm an investor in that starts to expand upmarket ends up working with WorkOS. And that's because they are the best. Whether you are a seed-stage startup trying to land your first enterprise customer or a unicorn expanding globally, WorkOS is the fastest path to becoming enterprise ready and unblocking growth. It's essentially Stripe for enterprise features. Visit workos.com to get started or just hit up their Slack, where they have actual engineers waiting to answer your questions. WorkOS allows you to build faster with delightful APIs, comprehensive docs, and a smooth developer experience. Go to workos.com to make your app enterprise ready today.
What are some of the other big inflection moments as you think about just Anthropic going from just this like lab that's trying to compete with this juggernaut of OpenAI at that point to what it is today? What are some moments that stick out of like, wow, that really changed things?
Definitely when we were training and testing Opus 3. I think that was the moment when the company, I think we were less than 200 people still at that point, and it was very clear that we needed and wanted to create a frontier model, and that was very important in terms of like our ability to reach users, consumers, and to showcase our research.
And we were looking for ways for also, why should somebody choose Claude? And that was like a core question, and that was a core question we were getting asked in the early days. And I think with Opus 3, you know, it launched, I think, early March 2024. But there were many, many months of various teams across inference, across research, fine-tuning, pre-training that rallied at different points and towards a common goal.
And I think everybody that was involved was really proud. I remember being the PM, the research leads, myself, we were all in our, this was around December, so we were all at home in our various parents' homes, and seeing everybody's background of like their childhood room, and everybody was working really hard to figure out, like, what are we training the model for? Is it showing up the right way? So I think that was really powerful in terms of just building a lot of trust, and a lot of our research leads from that time are now leading reinforcement learning, leading our character work, alignment work. So that foundational trust, I think, also helped us work well now with any of our production models across product and research, because we were working just so much in the trenches together in the early days.
And then I think there were things like identifying that coding was important. Right? In 2023 when I started, nobody said Anthropic and Claude and coding in the same sentence. I think competitor models like GPT-4 at the time were used a bit for coding, but it was one of many use cases.
And one thing that, for example, I saw was people were starting to use these models not just for code, not just like code autocomplete, but actually writing long form code, and is that an opportunity for us to train, you know, Opus 3 to be better at? And it ended up being a relatively smaller change from a training perspective, but it ended up helping us differentiate in the early days competitively for users, and actually bring a lot of the very early Claude enthusiasts and developers, because we were providing a value that they didn't really think was possible at the time.
It's so interesting you talk about Opus 3. Like, that's so long ago, and it's hard to think that was a big inflection, and so this is really interesting to hear that that was internally a big milestone. It almost feels like this confidence you all built that, wow, we could really ship a frontier model, which today is not great if you compare it to what we've got today. What I always think about is Opus 4.5, which was, and interestingly, like a year later, also during winter break when everyone was home able to code. Was that another big milestone?
Yeah. Opus 4.5 was definitely another large moment. I think what was magical about Opus 4.5 is we also now not just had a model but a vehicle, which is like a great product experience like Claude Code. One thing we say a lot on the team is you need frontier products in order to have frontier models, and for people to feel the magic of frontier models. And I think, you know, we felt the magic of Claude Code for many months before that.
But the fact that the model essentially got to a level of intelligence where, at a very broad level, users can experience both frontier intelligence in new use cases, allow it to run things end to end in an agentic manner, I think that was the inflection. It was actually both. I think Opus 4.5 wouldn't have had that moment without a product like Claude Code, and Claude Code, I think, wouldn't have had that type of adoption accelerated without Opus 4.5.
So kind of speaking on this thread, Dario, interestingly, if you look back at all his predictions, he's just like, okay, coding is going to be solved 100% in like a year, something like that. He kept talking about how AI is going to do all our code. And I remember everyone being like, "There's no way. This is way too complicated. How is AI ever going to get really good at this very complex thing that humans do? No, this is going to be humans for a long time." He was completely right.
Something else that he talks a lot about is this exponential that we're now on. That's the way he describes it now. We're on the exponential curve. I remember not long ago new models were being released and everybody was like, "Okay, we're done. There's no more upside. It's plateauing. It's over. There's no more room to grow." And now it's like the opposite. Now we're inside, like if you think about the curve of the exponential, we're like inside of the exponential now, which by definition means every improvement is a massive jump because we're like on that hockey stick part. What's it like just being on the inside of this crazy historic moment when AI is improving so fast, so much is being unlocked? What is it like, and how should people prepare for the coming acceleration of more and more improvement from AI?
One thing I like to say on the team is most of us weren't actively working yet when the internet transitioned from this novelty to something that everyone can use, and it feels like that's just taking humans. I think analogies are helpful, and so like the analogy of that is, I think, a couple of things.
Number one is adaptability becomes very important. I think we have evals. We have, you know, on the safety side, safety testing, red teaming, on the capabilities and product side, new prototypes, products like Claude Code, Tag, and others. But it's very hard to predict the exact moment or the exact model, and so the adaptability of when you're faced with new information, how do you then make better decisions versus keeping the same plan. And so like that agility is really important.
I think another piece is with that, how do you actually be thinking very first principles and reason through what's next? What's the so what? How do we invest in new products? How do we invest in explaining the differences to users?
So a lot of the experiences, I think, of being in that exponential is that pace, understanding how you operate and make better decisions, and then applying that first principles thinking to then do something that maybe we pull up a plan that we were expecting a few months from now, but now the model can actually do and work on, and actually bring that to users. So this is things like Cowork, Skills, Tag. You know, it's a very positive self-reinforcing loop.
And I think a big part of it also is just having the trust in each other, like making sure we're thinking through the right decision making. We're bringing folks along. Some teams might see the exponential, feel it faster than others. So how do we kind of have the grace to bring the organization, the growing organization and company, along on that?
So what I'm hearing here is you almost don't know what will be possible with every model release. And so the important thing to focus on is being adaptable as things emerge. To your point, the product itself has to stay up
to has to catch up to what is possible. To your point again, just like it can do so much, but people may not understand how to do it and may not be able to do it. So the product making it easy and even just like telling you here's something you could do feels like an important part. Is that roughly what you're describing?
I think so. I think there's some really interesting graphs in the original scaling law papers, and I think folks are very familiar with the scaling laws in the lens of: as you add in more compute and data, what's called loss, aka the loss from next token prediction, goes down. And so it's a very smooth linear curve of like the models get more intelligent as you scale them up.
What's actually also interesting in that paper is there are these like very different emerging capability graphs. And so for example, as you add in more data and you train the models with more compute, you essentially see these actually discontinuous emerging capabilities jump. So the models go from 1 + 1 being a thing that it can't calculate to a thing that it can reliably calculate. And so these emerging capabilities, this like some nature of like predictability, is not necessarily, everyone knows the exact moment, like you need the evals to be able to assess that, has actually always been a part of how this technology works and also what makes things like safety harder, because unless you have the evals, unless you have the systems to test, these jumps might actually happen and you don't know.
That's so interesting that you may have developed this like AI brain that can do something you're not even aware of, and so part of the job is just uncovering, wow, we just got really good at this thing, what can we do with that?
I think there's like product overhang and user overhang, to maybe put it in our PM language, even on today's models. And I think there's like a lot that we could be exploring on like our current Opuses and definitely with like Fable, for example, temple, and that discovery is actually another part of what's been in the early days of Anthropic's DNA, and I think is also continuing to be a big part of how we operate in product, in Labs, and across research.
This makes me think about something Garry Tan's been talking about, president of YC. I don't know what his title is. He had this interesting point that if you're willing to spend $100,000 a year right now in tokens, you are living the way somebody in 2028 is going to live, because by then it'll be really cheap. Everyone can work this way. But there's this alpha opportunity right now to just live in the future, go crazy on token spend. And so there's a big opportunity for people to learn what the future's like and also just build much faster. Thoughts on this idea of and the value of token maxing, let's call it?
Yeah, I think I take more of like an almost product lens. It's almost like token spend is more the input, and really the output is what you described of experimentation. And I think if we were orienting like goals around experimentation, I feel like that might be the better framing of the outcomes, and therefore there might be different ways of achieving that outcome.
I will say internally some of the most creative thinkers, the best like prototypers, do spend a lot of time with Claude with every new version of a research model that we have. And so there is something around you have to be like using the models to then come up with good, then great, then better ideas, and there's no substitute for that. It's very hard to come up with a perfect strategy without touching the technology when it's moving this quickly.
At the same time, I think there's other things that we could be doing. So one thing that we do a lot is actually working in public internally within Anthropic. And so in the early days, when we had less product surfaces, there was a Slack channel where almost the entire company was testing early versions of Claude and trying different use cases. Like people were not calling them use cases, but you might be asking it to edit an essay or to come up with the right way to send this email. Like they were all different use cases, but we all worked in public.
And then what you would see magically is different users or different folks on the team coming up with an idea and then other people trying different variations of that idea, and then within maybe 10 or so requests there was something magical or potentially a new use case that emerges. And I think there's a lot in not just individuals figuring out by themselves how to use this technology. I think we could be doing more to actually bring like that communal discovery when we do experimentation. Like experimentation is not always necessarily an individual sport.
It's so interesting. Yeah. This idea that we're not sure what this is capable of or what we could do with it, and it takes all this poking around and people trying things, hearing what other people are trying, to figure out what's possible. Such an interesting, I don't know, technology, or just like, okay, here's what, oh, I figured out it could do this thing, what are you gonna do with that?
I think at a broad theme we know, right, we know that the models to write great essays or you can write long-form writing, but individual pain points of what can you actually solve with that and bring it to like a user level that people can use, I think is something that is more exploration or experimentation based.
Following this thread, you oversee product for the Labs team, which is extremely cool. We've had Ben Mann on the podcast, Mike Krieger, who both work on Labs now, talk about Labs. What is Labs? What's come out of Labs? Many people have heard of these things. And how do they work that enables them to create such innovative ideas outside of even the core Anthropic product team?
The thesis of Labs in many ways is identifying and pulling the thread on the thread of discontinuous large bets that might not be in the core roadmap, and figuring out is there a there there, and also what is the 10x, 100x, a thousandx of the there there. And so for example, things like Claude Code, I think—
I've heard of.
Things like Claude Code, things like Skills, and most recently Claude Design, MCP. The thing that we really try to emphasize within the teams is, especially right now, there are so many things that could be built, what does it mean then to have a discontinuous bet? And I think one approach that we're taking this year is you can be very strongly held opinion about the theme or the area and then more weakly held about the exact prototype. And so like there is a culture of experimentation. There's a lot of the bottoms up, like engineers on the team are very selfable, self-driven to test out different ideas, and sometimes we have a thesis and it might not work yet, and so we then might revisit it in one to two model generations. And so this idea of like these prototypes that actually end up just helping us learn, like that's also valuable even if it doesn't lead to something immediately shipping. And so I think that allows the incubation and like the charter of Labs to really accelerate and see around corners more broadly for Anthropic.
It's so funny to think about a Labs within an Anthropic, which is already so innovative and creative and just, you know, shipping like crazy, that there's value to still creating a Labs team within Anthropic. What enables Labs to work as well as it has? Because you listed all these products and it's like, what else has Anthropic shipped? It feels like all the biggest wins almost. I'm sure there are many that I'm not thinking about right now. What's kind of core to creating a successful labs within a larger company?
I think that team culture, like similar to broadly at Anthropic, I think that team culture is very valuable. I think Ben sets an incredible vision and pushes people to think about the 10x, 100x of the idea, and, you know, the teams, the pods within Labs, are small. Sometimes these ideas start with one engineer, right? And I think sometimes when there's really large teams pursuing very ambiguous large ideas, you end up actually being slowed down because of that.
So I think it's culture. I think, you know, we actually also select for folks who actually want to do that zero to one experimentation, and it's not easy. There's a lot of bets that we end up turning down or turning off, and maybe, you know, we revisit them in the future. But that's hard. That's hard when you pour your heart and soul. You're acting as a founder for a bet and it's not working yet. So I think it's like selecting for that type of personality, folks who are really passionate and deep about the zero to one.
So you lead product for the research team. You work with the researchers at Anthropic. A lot of people kind of get a sense of what is research, what researchers do. I think a lot of people don't totally understand these very valuable people at all the AI labs. The way I think about it, and I want to help people understand, help me understand, just what are researchers doing all day. What I imagine is they have a hypothesis for how to improve the model. They find data, they tweak some algorithms, they check, adjust how it's trained, and they test it, see how it did, keep iterating, and keep trying to find ways to improve the model. Is that roughly right, slash, help us understand what researchers are doing all day?
I think that's a lot of maybe the more day-to-day. I think one piece around researchers and research organizations like at Anthropic is there's also a vision of the future more broadly. So for example, things like, I think even at the founding of the company, researchers were talking about how do we get Claude to use a computer, how do we get AI to like navigate a screen, right? So there's a lot of actually very founder-like energy, is how I describe it, within researchers, or really bold and ambitious researchers, and we have a ton of those at Anthropic. So there's one layer of vision of what this technology can go, and then I think on this other side of the loop there's also, now that this technology or Claude is in people's hands, how do we make it better today? So it's a medium and long term, and a lot of energy thinking about that lens of the future, and also in the immediate and short term, what are the improvement areas we can make. And so like I think you're describing a really good sense of how do we make iterative improvements on different versions of Claude.
The way that my team works with researchers is kind of being very integrated and embedded in those loops, particularly areas where there's a lot of impact on users. So this is things like vision, computer use, coding, agentic coding, tool use, test-time compute, things where there's a direct user impact, and then figuring out what are the ways to bring the user feedback and ground it in a level that is understandable for researchers and also actionable for researchers.
And I think that second piece is actually a big part of the job and sometimes a hard part of the job. So for example, we might get feedback on claude.ai: Claude hallucinated. It's very vague. If you bring that to a researcher and you say, "Please fix Claude from being hallucinated," it's not very actionable. And so part of the time of the team is understanding, okay, what's the trajectory of why that user gave that feedback, and it's like consented. And so we look at, okay, what should Claude have called tools in that moment, or from its current knowledge, or it looked at the right document but it looked at the wrong facts. In the first case, that would have been a failure on tool use. In the second case, it would have been a failure on, let's say, search, or knowledge and search and search synthesis, or it could be something around alignment.
And so bring that level of detail to researchers, coming up with like is this a big enough problem, figure out things like evals to then describe how we've improved it. Like those are the levels of actionability, and it's the day-to-day language of the researchers. And so we try to stay very close to how to bring that in an actionable manner between users to the core model training and the research development loop.
I was talking to someone the other day about how it feels like AI research is the place to be now if you want to be very successful in life. What does it take to become a really successful researcher, from what you can tell? You know, not everyone can get in, not everyone's brain is going to work this way, but just say people are like, hey, I want to explore this career path. From what you've seen, what does it take to make it there?
Researchers generally, or product managers working with research, or both?
Let's do both, but the researchers. Like, you know, PMs working with researchers are also going to be very successful, but it feels like everyone's trying to, you know, poach all the top researchers across every company. So just, I know you're not an AI researcher, but just from what you've seen, just like what does it take to make it in that career path?
Yeah, I think a lot of the most successful researchers and research leadership at Anthropic are folks who are really strong first principles thinkers about problems. Like they reason through problems really well, who are just passionate about their research area and have a bold description of what that could look like, and then who are actually close to the details. And so, you know, our leadership, our chief scientists, our heads of like fine-tuning and like RL folks, are actually really close to the training runs and actually look at things like how the training run is eval'd, looking at the underlying data. So like actually staying really close and being excited to be in the details, I think, have been like a sign of really strong researchers and developing taste.
And I think like another piece is just their ability to think big over time and be very ambitious, right? Like the Dario, like we can transform software engineering, and I think going in that direction you learn so much. You had to shoot for the stars in many ways across your ideas, I think, in order to be a successful researcher.
I love just this meme of just be more ambitious comes up so often now, which is so hard. Like it's easy to say that, it's hard to actually, just like how big can you... And that's so much of what AI now unlocks. Just be more ambitious.
Yeah.
Yeah.
I think it's thinking through it once or twice end to end and then being, I think, stubborn about the area and maybe more loose around the exact approach. It is a question we challenge ourselves with, but the technology is moving so quickly, and so how do you make sure what you're building is actually forward compatible? And so it's also actually part of, I think, the core product development loop to think bigger, right? One thing I ask the team frequently, or how I think about when we're building a product, is let's say Claude 8 comes around, what changes in what users do, and then what does that mean for how you're building today? Is it going to be forward compatible to that experience, right? So like just grounding, I think being ambitious is very broad, and so trying to ground it in some ways of describing that.
And also, yeah, everything heading in a direction that all is cohesive and makes sense versus just ambitious in a completely different direction. Speaking of ambition and Claude 8, Fable Mythos recently feels like it hit this very new kind of tipping point with models, where it used to be you have an awesome model, release it. Hey everyone, welcome, Opus 4.5 is out, everyone can use it. Mythos went in a very different direction. It got blocked. There was a lot of scrutiny, a lot of concern about what it was capable of. All the companies had to go make sure it wasn't going to hack into all their systems. And it feels like now every model
because they continue to get better will now have a lot more scrutiny and there will be more restrictions on who can use them, which feels like a big deal. How do you think about that? How does that change the way you operate?
I'm going to maybe leave the policy and the export control side to folks that own that and work on that. I think the product question and how we interact with these internally is, I think, as you mentioned, as frontier models become more capable, the safeguards and the ways of red teaming and testing and the pre-release process also need to evolve and adapt quickly to address that.
And so one example is, you know, before Fable models we didn't have as strong of, let's say, fallback UXs and systems, because our goal was to make sure that there is asymmetrical benefit for this technology and to minimize the downside or a severe risk of it. And so we ended up building fallback systems so that users will still get a great response from Opus 4.
And so I think there's a piece around, as we evolve and improve safety systems, how do we continue to develop and deliver great user experiences? I think there's more that we can do on both sides. And so you'll see us innovating, improving on what we call now the model safeguards package more and more in the coming weeks and months.
What's really interesting and just unexpected here is it creates this really interesting advantage for Anthropic, where you have access to the latest stuff, and this is going to happen at every lab. Everyone's going to keep improving, and it creates this unfair advantage within the labs to have access to the best stuff that other people can't yet, outside of your control. You'd prefer everyone use it. So it's a really interesting new feedback loop that's going to start, where models that are so advanced are only accessible to certain companies, and that's going to be a whole new unexpected... it's like a second-order effect of all these restrictions.
Our goal is to develop these systems and the models to be as inclusive as possible. I think our goal is to not have that happen for the general-purpose, general-use technologies and to make it more accessible. I think, you know, this is one of our top priorities right now, to kind of reduce what we're seeing there.
Yeah, that makes sense. I would imagine you'd want as many customers, people using this thing, as possible.
This episode is brought to you by Mercury, radically different banking, loved by over 300,000 entrepreneurs and now with Command. I've been a customer of Mercury's for over 6 years. I have never once thought about leaving. Mercury is basically what happens when banking is built by product people, not by bankers. They make it so easy, dare I say fun, to send invoices, move money around, set up virtual cards for folks on my team. Does your bank have an API, a terminal-native CLI or an AI-ready MCP server? I don't think so. And just recently, they launched Command, a conversational interface built directly into Mercury, which acts as your financial operator. I've been using Command to transfer money around, to figure out what categories I've been spending the most money in, analyze my cash flows, and just today I used it to find out how much I've made from a specific sponsor over the past year. I just ask, "How much have I made from X over the past year?" 10 seconds later, I have an answer. It is so freaking cool. Visit mercury.com to learn more and apply online in minutes. Mercury is a fintech company, not an FDIC-insured bank. Banking services provided through Choice Financial Group and Column N.A., members FDIC.
I want to talk a little bit about how the product role is changing and who is doing well in this new world, now that AI is such a core part of our life. When you're hiring PMs, product people, when you're looking at people that do well in today's world, what are some things that you notice? What are you looking for most? What are you looking for more? What's kind of trending up in what you find is important, and what's kind of trending down?
We actually, on my team, have not changed our hiring loop for three years now. So what we actually look for, and the traits, and how we evaluate generalists like PMs, generalists like research product managers, have actually been the same. So I think some of those traits, number one is first principles thinking. And this is really, rather than pattern matching what you used to do in, let's say, consumer product or B2B SaaS, actually figuring out, in this moment, for this user group, with this technology, what is the user value.
Is there an example? A lot of people hear first principles thinking, they're like, "Yes, I... I'm good at this." What's an example of someone having really demonstrated really good first principles thinking?
I think one example is, I think you think of a product manager as: I own product strategy and delivering user value, but I demonstrate it day-to-day by writing a PRD or writing a product vision doc. And for my team, as research product managers, the way to drive user value is to figure out the right user feedback, the evals, right? That then can be a personification of that user need. So we do write some product documents and PRDs, but we actually have a saying on the team: evals are the new PRDs, right? Because in order to deliver that user value, it's not that exact artifact that people used to write in the last one to two decades, it's a new way of working. And so the first principles thinking would be, let me figure out what is the thing I should do to achieve my goals, rather than, here is a set of activities that I've done and therefore I will continue to do.
So the idea here is, it used to be: have kind of an idea, create a PRD, talk to people about it, align on the plan, design it, build it, ship it, see how it goes, iterate. What I'm hearing here is it's like, okay, here's some feedback about something that's wrong or an opportunity. Step one is the eval is now how you define what the work is, versus a PRD.
Maybe step one would be understanding the user pain point. And so the way to even access that user pain point is different, right? In the past, we might do a user interview, and I think if you go deep enough, you might have the user walk you through their user flow, the pixels. Here, you have to sweat the tokens as much as you sweat the pixels. And so one activity we have on the team is reading the transcripts and understanding very deeply what were the trajectories that failed, to then say, was this a hallucination? Was this Claude being overconfident? So the theme of the failure actually has a lot of nuance, and then that allows you to build a description, a sustained description of that pain point.
So that could be essentially a new eval, and is the eval on distribution, right? Is it capturing both the positive situations where this is failing and also areas when it should actually not fail? And then bring that back to, let's say, research, so then we can make the improvements and actually measure the quality of, okay, when we have Opus 5.5, is this area improving or not? Is Claude now able to identify the right places in the document and pull the right synthesis out? So it's just the actionability, and shortening the distance to actionability for our stakeholders and partner teams, like researchers, to take action on.
Is there an example of something like this where you found an issue or opportunity and then wrote the eval? And what is the eval looking like in most cases? When people want to picture an eval, what do they picture?
We actually pioneered this concept within Anthropic. So one of the early examples is the early Claude models were not very good at following specific schemas, so things like outputs in JSON. And now that is fundamental to Claude being able to be a good agent, right? If you can't output a certain format, you don't know how to access APIs, you can't call tools, etc. And so the initial end to end was, I was hearing feedback around, you know, Claude 2 days, Claude was not very good at following instructions. So then digging in with users: what do you mean by Claude is not good at following instructions? Give me what situations this was happening. What's the exact paragraph? What did you ask? What was Claude's response? Going to that level of detail. And what I saw was something like 80% of what people meant in the early days for this failure was Claude would not write the right JSON.
And so then, okay, let's generate, maybe to start, just 30 to 40 examples of when Claude was not doing this thing correctly. And then that actually is your eval set. And you could have essentially a prompt and a response, and if that is not working in the right golden answer that you might have, then that means that the eval essentially is beneficial, because it's identifying a pain point consistently. And so then we added that to our repositories for evals. And when we have versions of Claude, we actually run that eval and just check. I think at this point it's always 100% or like 99.9, and so it's no longer a pain point. But in the early days it was taking the user feedback, figuring out actually what they mean, can we reproduce it, is it consistent, is it a big issue, and then figuring out how to standardize it in a way that can be consumable for researchers.
It's basically test-driven development for PMs, is the world we're living in now, where you write the test first. So is this just a core part of the product management job now at Anthropic, writing evals?
I think so. I also think it's something I've talked to other PMs at other companies about, and I think it's also more and more of the skill set more broadly, because a lot of the products that we're building are at the intersection of models with harnesses, with a set of contexts, for a set of users. And so having things like evals is a way, not just for folks working on models but generally within product, to get to better user experiences, because you can't improve what you can't measure. And a lot of this is still very tactile-based. It's still very judgment-based, and so you have to stay close to the details.
And also very non-deterministic, which is a big part of this. It's not going to give you the same answer every time, so you've got to describe it kind of more broadly. It's not going to be an exact match. So this is a really interesting change in the way product happens and will happen: evals are a big part of this. Do you guys still do PRDs? Is there still a one-pager describing a problem, or is it... Okay, now you're shaking your head. Yes.
We do. I think when there's a very defined problem, things like evals might be almost a shorthand. I think there's other cases where PRDs are really valuable. PRDs are great vehicles for getting a very large group of people aligned on a set of sources of truth about experience and setting up goals. So when we do have a model, we actually, for every model, do have a PRD, less necessarily for our researchers, but more for our growing product surfaces, for our engineering teams, for our stakeholders like legal and safety and others, as just a source of truth of putting together what we're aiming to achieve, so that a big group of people can row in the same direction.
The other place where I do think PRDs are valuable is on the more ambiguous problems and opportunities, right? So if we haven't shipped a thing like computer use, we don't necessarily always have a set of user-specific pain points, and I think there's value in the product vision portions of a PRD to explore, even if a technology is not yet ready to work for everyone, how do you get it to work well for some group, so you can explore the value, you can actually bring something that is coherent to a user group. So we do have PRDs. I think the application is a little different now.
Okay, this is great. I just had Andrew, he's the head of the Codex app at OpenAI, and you guys are aligned. The PRD is not dead. Still very useful for specific projects and ideas. Great. Okay, we've closed the book on it: the PRD is still kicking. Okay, so we've been talking a bit about just what kind of skills are emerging for product people. Is there anything else that you find has shifted in what patterns are common across people that are doing well in this new AI world, in terms of product managers and folks on the product teams? Is there anything else where you're like, okay, this is something you've got to shift, or something you look for more in people?
I think maybe specifically for folks who might be mid-career, or folks who have been more in a managerial, product leadership seat, one thing that I feel pretty strongly about is, in order to be good managers of teams and PMs working with this technology, you have to be really hands-on yourself and have spent not just time tinkering but actually shipping with this technology, and again being in the details and sweating the tokens along with your PMs and your engineers and your teams.
And so even for folks that I hire who have more tenured PM experience, the onboarding plans are exactly the same as for somebody who is more early career, and it's around understanding users, reading consented user feedback, talking to customers. I think there's something around being able to understand what to do with this, what good looks like, and having developed that in a very hands-on manner. That's important. It's not necessarily easy for someone to agree or be able to see what a good or great AI product or AI feature could look like if they haven't kind of experienced building themselves. So I think I do feel pretty strongly that, you know, if you're a manager, you have to be hands-on. You have to spend a portion of your time actually shipping. You have to kind of walk in the shoes of your teams. And I always try to carve out a portion of time to actually own one to two work streams when we have models, in order to keep my theory of mind, keep my sense of how the models are moving, how quickly they're improving, so I can help the team make decisions and make better decisions.
So what I'm hearing here is, no matter where you are in the ladder of hierarchy at a company, if you're not building yourself, if you're not actually talking to Claude, talking to Codex, building stuff, you're not going to make it.
And you should have fun working with this technology. I think that's the other piece. I think the folks that would be most successful, regardless of their level, are people who love working with AI and are exploring and experimenting and carving out the time not just for the experimentation, but actually hands-on shipping end to end. Getting the user feedback, I think, has to be fundamental for everyone.
I 100% know what you mean there. Just like me, sitting on my newsletter and this podcast, just talking about stuff, and like, yeah, that sounds great. Every time I actually build something, and I tinker with all kinds of little projects, you're just like, "Okay, I see what's happening here." And you just get so much more. It's hard to exactly describe what you experience actually working with the models and building stuff, but it's a whole different world of, "Okay, I see. Here's what they're talking about with computer use. Here's what they're talking about with this limitation, this UX situation."
Yeah.
So, yeah. And you made this really interesting point that you have to have fun with it, which is not easy for a lot of people, because they're pushed to use AI or they just don't know exactly what to do with it. For people that are just like, I don't know, it's just so annoying. I just have to do this. I don't know what's so like,
I hate this freaking thing. Why do I have to work with this? Things are changing so much. I'm tired. Advice for helping people find that joy in this work.
I think maybe I'll reemphasize something I said earlier around just that experimentation is not an individual sport. Like some of the moments where I think I've touched practically every version of research models across 20 versions of production Claude at this point, and I think part of the joy comes from seeing other people discover use cases too.
And so maybe one idea here would be pairing with somebody who is excited and seeing what on a use case that you care about and working together versus identifying or trying to figure out the perfect use case yourself, because that might feel like work. Working with others feels like joy a lot of the time.
And is there more that we could do to bring other people along? That's something like a lot of times internally we have somebody who is very curious, and them sharing an idea of a new prototype actually brings a ton more people who are like, oh, I didn't know this could work now with Claude. And so there's just some virtuous cycles here and ways of, yeah, continuing to have joy with this technology.
That's such a good point. I think that's also why Twitter's so useful for a lot of this, is you see other people sharing what they've done and it inspires you to come up with your own little ideas, and also it's just fun to share your own thing that you've done.
So that's a really good point, just find other people to kind of play around with and look for use cases. The thing I've also heard a lot is just find a problem you want to solve in your life or work and just open up Claude, Claude Code, tell it here's what I want to do, and it's incredible how far you can get just with a vague idea of a problem you want to solve.
Yeah. I think it gets hard in that there's so many different things that you could try. And so just narrowing in on either pairing with someone, working with somebody who has a lot of joy about this technology, or figuring out something that you could immediately find value in. Either of those things allow you to go deeper rather than more high level about too many things. I find it hard to keep pace with the number of prototypes or products that are out there, and so my lens has been how do I go deep in one to two of them myself.
That's so interesting you say that because that's exactly it. We just had this survey that I ran with my colleague Noam asking my readers just how they're feeling about all the things going on in tech right now and AI, and one of the most interesting takeaways we had was to find that happiness is exactly what you said: go deep in a couple things versus trying to do just a ton of little things. Find a couple things to really solve well and then go deep, and that is a source, because a lot of the happiness people feel is when they finally unlocked a way for AI to actually make their lives better versus just a couple messed up, broken, half-working things.
Yeah, it's how do you go from this being a check the box, right? And so like us as product people, it's then an exercise of product prioritization of your time and your energy. And if the goal is to experiment with joy, then what are the inputs that you need for that?
But yeah, I think the secret sauce of Anthropic is the culture and the bottoms-up nature of how people work and this experimenting in public. And by doing that, it's very much about how to bring other people along. That ends up being, I think, really valuable.
Yeah, I've heard this so many times from all the labs, just like no one's exactly sure how some of this is going to be used, and a lot of it is just putting stuff out early, seeing how people use it, seeing what's possible, and then using that information to build the actual product to lead in.
I'm curious, kind of on this thread of finding ways for AI to help you in your work and life, are there any interesting ways you've been using Claude lately in your work as a PM?
I think there's a lot of things with Fable and things like Tag. So there, I think Tag is in the very early days. I think there's something around how you work in a different paradigm of allowing an agent to go off and work and then bring back product and experiences to you.
I think one area that's not very recent, but one that I bring up a lot with the team and I think we could do more on using AI, is just how to use it to also have better conversations with each other, to be better managers. I don't think it's necessarily just about raising the IQ of experiences we build, but also I used it a lot actually prepping for how to have better conversations in the moment during crucial conversations.
So, I love that book, and so I actually have a skill that helps me figure out am I going in the right level of detail given the situation at hand, and actually helping me be a better manager and better supporter for the team. So for managers on the team, that's actually a thing that I've been sharing more with our managers of, okay, how do you actually use Claude to make you a better coach, because it's hard sometimes to find the right perfect words, and the models have a lot of perfect and right words, and I think there is something about how it can actually augment us from an EQ perspective in addition to IQ.
Oh man, there's so much interesting stuff there. So just to understand what you're doing there. So you built a skill. You're just like, Claude, build a skill pulling in lessons from Crucial Conversations, the book, which it knows enough about. You don't have to even give it the content. And then you use that skill to talk to Claude: hey, I have this very difficult conversation coming up with a colleague. Give me some tips on how to approach it.
Yeah. And it's almost like coaching, like individualized, personalized coaching of just how to make you, and there's so much context switching that we do all day, and having Claude help me pair and help me, and maybe there are times where I end up not using suggestions from Claude. But it actually ends up being very helpful for just coming up and brainstorming. Am I thinking about reactions in the right way? How do I actually go a bit deeper faster, build trust faster, be more direct?
Yeah, man. I have so many questions here. This is so interesting. One is just there's concern people are going to start talking the way AI writes because they're talking to AI so much, and it's going to be like, Dianne, it's not this, but it's that. I know that you're not doing that, but that's a concern people have. Let me just ask about that, I guess. Do you fear this? There's this brain rot atrophy stuff people talk about. We're just so reliant on AI now and we stop learning and thinking and, you know, overly AI. Thoughts on that, being so close to it and being so integrated with AI constantly?
A lot of actually thinking process and writing process are tied together for me personally. And so I think there are ways where I use Claude to augment my thinking. But what I want to make sure, and maybe this is what you're describing, is Claude doesn't take over all of my thinking for me. And so I think depending on the situation, depending on how much more personal judgment I want to have in a situation, I might come up with my own POV first and then work with Claude through that, and making sure that I maintain my sense and tone throughout.
I think there are then other things like updates, right? We have monthly business reviews, and then in those cases it's much more, I actually want it to be standard and I want it to be much more like it gets crystallized information in the right way. And I have a skill, and we're augmenting and improving our skill for that, but I want to get to a place where the monthly business review, the writing of that is potentially asymmetrically less valuable than the thinking. And so how do I get that piece delegated to Claude fully and I'm more of a reviewer and a verifier of that information. So I think it depends on what you're using Claude for and what you're trying to convey, and is there asymmetrical value in delegating more to Claude.
What I'm also hearing, the first tip is really great, which was think first, have a point of view, and then kind of use Claude as a sparring partner almost to evolve the idea, push back on the idea.
Yeah. And I think this is where things like actually our alignment research and safety research is helpful, because what you don't want is an AI that just agrees with you, right? What you want is this technology to actually augment and grow and get to a better outcome. And so sometimes having Claude push back makes me better. And so that's great. Like a coworker, I want somebody to push back when my ideas are not fully formed.
I want to hear more about that. But I've heard, when Ben Mann was on the podcast, he talked about the constitution that is built into Claude, and how unintuitively the work and the focus on safety and alignment, as you said, and this constitution that describes how Claude should think and operate, you would think that would limit the abilities of Claude and make it less fun and interesting. It's exactly the opposite. Claude is the most interesting personality. I hear that constantly. It's just like I much prefer talking to a... like OpenClaw famously was built on Claude, and then people were forced to, we won't get into it, were forced to switch, and they're like, this is so bad, this is not who I'm used to talking to. So that is, I think, a really interesting point I just want to make sure we spend a little time on. Why is that the case, just this focus on alignment, safety, having this clear constitution? Why does that make Claude better and more interesting to talk to also?
In order to make Claude as intelligent and as capable as possible, being able to have Claude actually push back at the right points and then add, it's like a yes or no, and actually helps you come to a better conclusion. So, I've used Claude to help with things like, are we making the right pricing decision on the next version of Claude? It's a little bit meta, but using a research version of Opus, asking it to figure out how it should price, and being able to come out with better outcomes is a goal at the end of the day.
And so having AI not just be an assistant, not just be a doer and being delegated tasks, but figuring out is it doing the right thing, that's actually very integrated with knowing when to push back, right? That's part of knowing when you should be proactive. Proactivity is not necessarily always doing a thing that you are scheduled to do. It is knowing when to come up with a new idea. And so in order for Claude to be more useful, the general approach has to be that it knows when to push back. It's a core part of the characteristics together of the models.
That is so interesting. It's so interesting that that is a big part of it, it being less compliant is almost what makes it better and more useful, because we need that. I've had so many people where they're like, "Hey, AI told me I was right," and like, no, I wish, I wish to other people.
Yeah. And it comes back to our earlier point around thinking, right? How do you protect your thinking? If you have an AI that can be a thinking partner, a thinking partner doesn't just agree with you. It should add to you, and you should come away at the end of the day having better ideas because you worked with Claude. That should be the hero goal, not just making your ideas 10% better.
Yeah, I love this, since it used to be think 10x. It used to be the way founders push people, like what if we 10x this, and I love what I keep hearing is, how do we go thousandx from this idea? What is the most ambitious version of this?
I want to come back to something that I was thinking about as we were talking about talking to Claude constantly. It's very clear when AI has written something still. It's funny that it's a large language model. You would think of all things it would be very good at writing, and interestingly, just no, AI is very good at writing, it's always very clear this was AI written. Do you think we'll get to a place where we will not know this was AI?
I think it depends on what's the goal that you're looking to achieve by knowing. Yeah, what's the eval? I actually do think there's more that we could be doing on making Claude write better. There's actually very active efforts on my team and on the research side about making Claude write better. Just generally, I think it should be clear where an idea is being led by you, Lenny, or me, Dianne. I think it really depends on what's the goal of that writing. Like for something like a monthly business review, I would actually love to have that end to end be written by Claude.
And obviously not make it feel like it was written by a human. It's such an interesting point you're making, like is it actually better for us to know that it's AI versus not.
Yeah. But it's also, maybe the lens is more around verifiability, or who's verifying the output. Right. Right. Like who's signing off. Maybe less around who's writing, but who's verifying, who's signing off. That becomes more what matters than who's writing it.
Why do you think AI is not great at writing? My guess is it has studied all of the best writing in all of humanity. It's figured out here's the best way to write. And there's only so many ways to write. And so we've just recognized, okay, this is what AI does. It has these tropes. Is that the core of it? Is there something else that's keeping it from being a great writer? Ironically, being a large language model of all things, you'd think it'd be really great at language.
I think part of it is also we need to invest more in training improvements to make AI continuously strong on areas like writing. I think it's also that the technology is jagged edged, like we mentioned. So sometimes when the models were good at writing but not agentic, our thesis is how do we make the models more agentic or call the right tools. Now that that's improved a bit, then it's, well, now these other areas actually become more of the rough edges. And so I think we're in one of those moments with writing where we need to actually just focus and prioritize on training the models to be great at this area, and that is a very active area for us that you mentioned.
Okay. I'm glad. And also, it's going to be interesting once AI is so good we're like, I don't know who wrote that, but to your point, sometimes we actually want to know that it's AI. That's really interesting. I never thought of it that way. The other interesting part of this is that there's that comedian who was joking that we're on a plane and the Wi-Fi is down and we're just like, "What the hell? The Wi-Fi is not working on this plane. This sucks. How dare you?" When you're in a tube in the sky flying like a bird, and how dare you complain that the Wi-Fi doesn't work. Your point is there's so much advancement and so much power. We can't fix it all. We can't make it all work the best possible. And so basically AI writing has not been the priority, and it feels like there's more investment happening there.
Yeah, I think tone and character is a priority. I think this advancement of the technology is a work in progress, and so we see a leap or emergence of a jump in agentic behaviors, and so that is a new normal, and then these other capabilities
needs to continue, like, improving.
And I think once we improve, let's say, writing and, like, tone and character, we probably will say, like, how do we have Claude be even more proactive? Like, productivity is an opportunity, and that's human nature. Like, we want to make ourselves better. We want to make this technology better. So yeah, I think we're applying it to AI, which is the right thing. We should be making it better.
I want to ask you a couple questions I'd like to ask folks working at the very center of the future that is coming. One is, where do you think human brains will continue to be most valuable over the years? I know Anthropic's mission and vision is we'll reach AGI, superintelligence. So in the future, maybe nowhere, but before we get there, where do you think human brains will continue to be most valuable as we've approached that timeline?
We started to talk about making Claude and models better at judgment, especially in the last year or so. I think judgment is one, and is an area where it's an accumulation of so much nuance and so much experience, and these systems haven't experienced as much as humans have. And so I think that hard-earned, like, judgment is an area for product leaders, and just generally, will continue to be really critical.
There are so many things AIs can build. Which ones are the things that, you know, an AI lab should build, right? A lot of that requires, like, human judgment, persistence, proactivity. These are all traits that are beyond just general capabilities, but just behaviors and characteristics of, like, people at that level of, like, how do you get to the best solutions, how do you create the best experiences. So I think those types of traits are actually the tactile traits that I think will continue to be important.
I think there is also still a lot of, like, capabilities and subject matter expertise as well. I think, you know, software engineering has been really transformed by AI. I think there's areas like biology, life sciences. These are all things that we're just kind of at, like, the foot of the exponential on. Like, maybe software engineering, we're on the exponential; on some of these other areas, we're not quite there yet. And so I think you're seeing us ship things like Claude Science, investing in these areas, because those are areas that I think just bring this technology to society and have a positive benefit for society. So I think there's a lot more to go there.
Another question I want to ask is, as someone with kids, how do you think about what you are encouraging them to learn, or how do you think you're going to nudge them to be successful in this wild new world that we're entering?
I actually think it's a lot of the same traits, like, you and I probably grew up with, which is curiosity for learning, persistence, believing in your own inner voice, developing and then believing in your own inner voice. Like, I have a four-year-old, I have an eight-year-old. It's on us to help, it's on me to help them develop their inner voice, and whether that's being opinionated and taking a stance to me, right, and developing that, encouraging that. I think that those types of skill sets are things that are important in the future, and, like, having their own individual voice.
That is so interesting. It's so related to the answer you had when I asked about how to avoid brain rot, essentially, and over-relying on AI, which is just keep focused on your own point of view and your own perspective before you over-rely on AI. And just this idea you're describing of building that in kids is really important. That is so interesting, and I love how all this kind of connects: judgment, persistence, and a point of view of your own.
Yeah.
Both for kids and also adults.
Yeah. Anything you think about for yours?
Oh man. Well, like, the question I'm thinking about is just when to get them on, like, some AI thing, you know. I have a three-year-old, so it's pretty early for that, but, you know, how do you onboard them to this crazy thing? I was at an event recently, and a bunch of parents were talking about how they think about AI and their kids, and one person had a really interesting approach, which is keep them on the very early models so that they still have to struggle a bit and not get all the answers immediately. I thought that was interesting. Like an open source local model.
Not stable.
Yeah.
Yeah.
Yeah. And curiosity is something... I keep mentioning Ben Mann, but his answer actually to this question has always stuck with me, which is curiosity, and also just, like, he's a big fan of Montessori, which is what we're encouraging for our kids. So there's something there.
Maybe a last question, just kind of along these lines, something Fiona Fung actually suggested to ask you, who was recently on the podcast. How do you stay recharged and not burn out being in the center of this crazy storm of AI as a mom, working in, you know, the research work at Anthropic? I just, like, we're living through the most unprecedented time. Just, like, being, you know, on the outside of Anthropic, it's crazy. I don't even know what it's like to be on the inside. What have you learned about avoiding burnout, staying recharged, staying sane during the middle of all this?
In 2024, we shipped four models in the whole year, or four series of models, and I think we did more than that volume in just Q2 of this year.
I think I've been really lucky with the team that we've grown and built, both the stakeholders on the research side and within our research product management team. I think that one of the magical parts about approaching all of this is that it's not an individual sport. There's, like, a sense of radical ownership and team collaboration that I think... Sometimes it does feel like a high-performance sport, because you're in very critical decisions. There's new information about users, about training, and you have to make recommendations and judgments and decisions very quickly, and nobody can do that sustainably by themselves.
And so I think what's really helped is having a team that is incredible, who looks out for each other, who, you know, the night before a launch, even if they're not the core DRI on that model, will stay up and help the DRI to review the blog post and make edits and come up with better demos, and knowing to be each other's sort of extra hand.
I think it's very easy, if you take all of this change on your own shoulders, to feel like you're alone and to feel like you have to do everything. But I think one of the, like, magical parts of Anthropic is this ability for us to figure out what are those opportunities to help each other, and actually then taking the next mile of, like, mind-melding. We called it, like, entering the hive mind. There was an article about this. And I think, like, part of that is just that allows the team to replenish. I was just on PTO in June. It's not just that you can take PTO and you come back to, like, 3x the amount of things to do. It's actually that you can take PTO and know the team can figure out the right things to do, and that we individually can, like, watch out for each other.
So I think that's a big part. I'm really lucky, just personally; also, my partner is really supportive. This is year six of me working in AI, so Amazon and then Anthropic, and so he sees how much I just love the technology and what this can do, and that really helps, I think, also from, like, a personal perspective as well.
I love how many of these answers connect. So what I'm hearing here is just having other people, working with other people, relying on other people, helping each other out when things get crazy, which is a similar answer you had for just how to find the joy and fun in this work. Just be inspired by other people, see what they're doing,
work together.
Yeah. And it's interesting, when Fiona was on the podcast recently, I was asking her just, like, what's changed in the world of software engineering, and she pointed out it's a lot lonelier now, because now we're working with agents instead of other humans. Teams are smaller, people have all these fleets they're talking to constantly. And so this is just a reminder of the power of actual other humans around you.
We're asked to work and make decisions on really big things because you have more scale from the technology, right? And I think having individuals, having other folks who can have some level of, like, mind meld with what you work on, how you approach, maybe not exactly every detail, but what are the first principles, what are the assumptions you make, then helps them, you know, back you up, or push your decision and sharpen your thinking. So I think, you know, I really try to look for that when, like, building the team, growing the team, hiring. Like, is this person going to care about their own ego and building out a big org, or are they going to care about contributing to Anthropic and contributing to the, like, impact of the team, and orienting towards folks who are, like, low-ego, team-oriented. I think that's, yeah, a big part of, I think, the sustainability.
Yeah, a lot of it always just comes back down to culture and hiring. And I know, I've heard a lot about just the reason Anthropic is able to move so fast. I remember that moment when, like, something shipped every day of the month. There was, like, a calendar of launches, and people were talking about how is this possible, and what I heard a lot is just because everyone is so aligned around the mission and the values, it allows people to make decisions really quickly. Before we get to our very exciting lightning round, is there anything else, Dianne, that you wanted to share? Anything else you wanted to touch on? Anything you want to maybe double down on of things we've talked about?
This was actually really fun, because I feel like your questions actually sharpened some of my thinking around how the dots kind of connect. I'm your real human Claude over here.
One thing that I really want to, like, convey, or have people take away, is, I think, one, in the ways of working, but also just, two, that, like, this is a lot of, like, growth and change, and having the joy in using this technology. And, like, if you're feeling like in this moment you don't have as much of that feeling of initial joy, how do you find people who do, if this is an area that you're excited about and, like, want to work on. And I think developing skill sets, replenishing skill sets in many ways, of things like thinking in a first-principles manner about what you solve.
I think fundamentally, you didn't ask me this, but there is this question in the community of: do we still need PMs when the models are so capable, when engineers are leaning in? I think the role of people who are user-centric, who go into the details of understanding what users are trying to accomplish, bubbling that up in an actionable manner, and doing the relentless work to do that, like, that to me is the core of a product person, and I actually think we need more of that. I think we are becoming very technology-layer driven, and actually, to make that impactful, you have to go deep, you have to be curious, you have to be super hands-on. And those are things that I think are also traits that have, I think, helped Anthropic from a product development and model development perspective, and as part of the culture, and hopefully that's valuable for others as well.
Amazing. What an inspiring way to end it. Oh man. Yeah. And I've been saying this too for a long time, just now that building is easy, the hard part becomes, as you said, what should we build, and is the thing we have built correct and good and worth leaning into? And to me, that's what PMs do and what PMs are good at.
Yeah. Yeah. Yeah. And it's getting into the details of the user.
Yeah. Empathy. Okay. Great. PMs are going to make it. Okay. PRD is not dead. [laughter] All kinds of important lessons here. Dianne, with that, we've reached our very exciting lightning round. I've got five questions for you. Are you ready?
Yep.
First question. What are two or three books that you find yourself recommending most to other people?
One personal one I really like: How to Raise an Adult. So I'm a mom. I think a lot about what are the things that I want to instill in my kids, and that book is really helpful for describing: we're not trying to raise children, we're trying to raise adults. So just the framing of what does that mean, and what are the characteristics that we want to hone and, like, harness and foster in our kids. The other book that I was listening to on Audible recently is Incorruptible by Eric Ries. So the...
Incorruptible. Incorruptible. Yes. Yes.
Yeah. His recent podcast guest.
Yeah. And I just think the question of how to build great companies is important. I personally have just been most fascinated with how to keep great teams and great companies going further. And it was very interesting to just kind of see his framing and reframing of the question. I loved some of the examples around having metrics around culture. If you only measure revenue, then that's kind of how you're going, but if you have other, better metrics, that's actually the way to sustain the values you care about. I've been kind of trying to think about how to actually bring that to the team level, of, like, how do we better articulate, right, our norms, a lot of the things we talked about on the team. So I think that's also a really good read.
There you go. That'll be your next watch, everyone, as you're listening to this: the Eric Ries episode. Yeah.
Such a good episode. Yeah.
And his book just came out. Incorruptible.
Yes.
And I think it was, like, a New York Times bestseller. Like, it's actually doing incredibly well, which I was really happy to see.
Yeah, exactly.
Next question. Favorite recent movie or TV show you really enjoyed? Most people at Anthropic don't have time to watch things, but I'm curious if you have an answer.
I would say, during some time off last month, I did get to, like, binge-watch Fallout on Amazon Prime. So that was actually... I kind of like... it's kind of... Have you heard of it?
Yeah. Yeah, it's based on the video game.
Yes, it's based on the video game. I think it was really... it's witty, it's humorous, it's also, like, super action-oriented. So highly recommend.
Okay, next question. Do you have a favorite product you recently discovered that you really love?
I really do think, like, Claude Tag is very interesting in terms of a product experience. We actually have, like, different versions of this within Anthropic, and I think it's actually been a really, really powerful tool.
Yeah, it feels like, I think some people are like, what's the big deal? The fact that everyone at Anthropic is, like, raving about it tells me something important is going on here. And I'm trying to actually get it working within my Slack community that I have for paid newsletter subscribers. How cool would that be?
Yeah.
Yeah. I'm trying to figure out how it works when it's not a company, when it's just a bunch of people that don't know each other, and how that might work. But we're trying it out. Okay. Two more questions. Your favorite life motto that you find yourself often coming back to in work or in life?
So I was actually raised by my grandparents for the first 10 years of my life, and my parents were immigrant college and master's students in the US.
Oh wow.
And my grandfather always says, "No matter how far you go, there's always another level." [laughter] Which is, I think, a really good way, though, like, a pretty intense way, of describing his life philosophy. But I go back to that whenever there's something new or unprecedented that we experience. And I think, you know, the first half of this year, there was definitely a lot of that. Like, there were a lot of new things that we were learning. I was learning, so just
feeling like there's always another mountain, another opportunity to—
Not good enough, Dianne, we need to go better.
We need to go bigger. Makes me think about actually another Ben Mann line from his podcast episode, that this is the most normal it's ever going to be. It's only going to get weirder and crazier.
Yeah. Yeah. No, we're good.
Okay, final question. I was poking around at your LinkedIn. You were a high-yield bond trader at JP Morgan Chase early in your career. You have this redacted hundred million dollar trading portfolio of some kind. What did you learn from that time in your life that has stuck with you, and/or is there a crazy story from that period? It was four years of your life.
I think I learned actually a lot that I apply here at Anthropic and other jobs thereafter. So when I was at JP Morgan, the trading floor, you could kind of envision sort of The Wolf of Wall Street, that's very different. Most traders I think are in front of a terminal. They're much more doing analyses on their computers. But it's still very, I would say, male-dominated.
And so I was the only woman. I was the only person with my background on the trading desk. And I learned that it was a very good environment to kind of build, one, my sense of authentic self, and two, that even if I was the most junior person, even if I may look different, the best ideas and having conviction in the best ideas, irregardless of all of those other factors, is the most important thing.
And so I think just bringing that sense of how I show up more at work. I'm pretty vulnerable and authentic with my team. I try to really make sure that regardless of people's levels or tenures, if they have a great idea, how to help them pursue that, and to do also the same. So to put the idea out there, to actually have conviction in it, to do the follow-through, to do the nitty-gritty work to make it happen. So those were all things that I learned from trading, and yeah, I think it applies to any job in many ways.
That is beautiful. Where can people find you online if they want to follow you, and how can listeners be useful to you?
I don't have a large presence on social. I think the best way to find my work, my team's work, is really the Anthropic blog and when we're publishing new models, new product experiences.
I think in terms of useful for me, I think the best thing, number one, is your feedback. If you thumbs up or thumbs down on any of our product surfaces, if you contact your salesperson with feedback about the model, it will make its way to me. With every research model, I actually get pretty close into understanding favorability and feedback. So giving us that feedback, pushing Claude, telling us where it's falling down, those help us make Claude better.
The other thing is, if you have folks in your network who seem like this type of profile of person that I just talked about, I'm hiring, the team is growing. We really will love just people who love this technology, who are deeply curious first-principles thinkers, who are fearless in questioning assumptions, and who have a tinkering, hackery spirit.
Wow, dream job. So basically open PM roles at Anthropic on the research team.
Yes.
And they apply, I assume, on the website, the careers page.
Yes.
Holy moly. All right. Here we go. Enjoy the flood of resumes you're about to receive.
Thank you.
Dianne, thank you so much for being here.
Thank you so much for having me. Thank you for really helpful, thought-provoking questions, helping me even connect the dots on how we work, how this whole technology is coming together, and being product people in it.
I really appreciate that. But thank you, Dianne, for real. Okay. Well, bye everyone.
Thank you so much for listening. If you found this valuable, you can subscribe to the show on Apple Podcasts, Spotify, or your favorite podcast app. Also, please consider giving us a rating or leaving a review, as that really helps other listeners find the podcast. You can find all past episodes or learn more about the show at lennyspodcast.com. See you in the next episode.
Article published · Updated
