Anthropic's First Technical PM on Evals, Emergent Capabilities, and Why Product Judgment Still Matters

Open on YouTube ↗
Overview

Dianne 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.

29 min read
2:49

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.

9:08

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.

12:22

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.

13:56

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.

20:09

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.

23:45

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.

27:42

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?

35:21

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.

39:44

"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.

44:22

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.

50:06

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.

53:54

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.

58:13

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.

1:07:12

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.

1:21:56

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."