Author: Digital Initiatives
Recently, Anthropic publicly submitted an S-1 prospectus to the U.S. Securities and Exchange Commission (SEC). The prospectus states that enterprise customers have embedded Claude into critical business processes, bringing stronger retention and higher monetization compared to consumer-grade AI. Focusing on the enterprise market and incubating Claude Code are two product practices of the Anthropic research and lab team. Recently, Anthropic's research and lab team product manager Dianne Na Penn appeared on the podcast The Skip, where she leads the core model products from the Claude 2 to Claude 5.5 family and participates in the incubation and expansion of products such as Claude Code, MCP, Skills, and Claude Design. The discussion explored topics such as the monthly planning and long-term assumptions of research-driven companies, the transition of Claude Code from grassroots exploration to product, the trade-offs between research priorities and user feedback, the culture of product managers within Anthropic, and the role of frontline deployment engineers (PDE).
Dianne Na Penn stated that Anthropic does not spend three months devising an annual plan that becomes obsolete two weeks later, but instead plans on a monthly basis, based on high-level assumptions about industry trends over the next 6 to 12 months; the product team also avoids getting caught in a short-term cycle of “someone released a feature, and we must do the same by tomorrow.”
In product incubation, Claude Code did not suddenly appear one day, but was the result of long-term trial and error with API customers and both internal and external personnel. The interaction paradigm of command-line terminals combined with allowing the model to execute more Agent loops truly created a chemical reaction. The team had intense discussions about whether to provide fine-tuning API, with the core consideration being that the model iterates too quickly; by the time enterprises figure out how to train, optimize, and deploy the model themselves, they may already be two to three generations behind.
Moreover, balancing research priorities with user feedback primarily relies on continuous discussions with research leaders. The value of product managers lies in clarifying the impact of issues on users, rather than specifying training parameters for the research team; the team also tackles a high-intensity work rhythm through practices such as collective vacations and pairing two people responsible for the same business line.
01 Research-Driven Strategic Rhythm: Monthly Planning Plus 6 to 12 Month Assumptions
In the face of a rapidly changing industry, one significant advantage for the product team is that Anthropic's research organization also possesses mid- to long-term strategic thinking. Dianne Na Penn explained that the company's research mission and guiding star goals focus on the long term, creating a beneficial pull that prevents the team from falling into a short-term reactive cycle of “we released X, Y, Z features today, so we must replicate that tomorrow.”
Specifically regarding planning methods, the team focuses more on monthly units, concentrating on what goals to achieve that month, but this is built on high-level judgments about industry trends in the next six to twelve months. Dianne Na Penn said the team does not spend three months drafting an annual plan that becomes irrelevant after two weeks. In the past, they tried to align everyone with the same OKR through a complete OKR process, but as the assumptions regarding usage and adoption rates proved to be significantly underestimated, those OKR goals were quickly discarded.
The ideal working method is to first define core assumptions over three to six-month dimensions, then break them down month by month, advancing towards long-term goals while maintaining an agile response to the market. In the life sciences sector, for example, Dario and others often talk about how AI will play a huge role in helping life science institutions tackle diseases. This is not a short-term project but needs to be translated into specific actions, such as what model training or product investment testing needs to be conducted each month, and how to ensure that scientists and researchers can access these models while also responding to early-stage market dynamics.
02 Product Incubation: Grassroots Exploration Driven, and What Not to Do
The birth of Claude Code serves as a sample for understanding Anthropic's product development approach. Dianne Na Penn believes that product development is more driven by grassroots exploration since there are countless generalization possibilities with the technology and its ecosystem. Long before Claude Code emerged, API customers were already using the model for code autocompletion; writing code did not suddenly acquire Agent attributes, as it underwent various stages of trial and error by internal and external personnel. The command-line terminal interaction paradigm combined with allowing the model to execute more Agent loops, coupled with the product experience provided by Harness, truly created a chemical reaction.
Determining priorities largely depends on the core themes that the team insists on betting upon and whether they can quickly validate if the current tech stack is feasible in terms of experience or results. Currently, the strategy is more focused on To B and enterprise-level markets because, compared to the rapidly changing consumer market, enterprise demand is more stable.
What not to do is equally important. The team had intense discussions about whether to offer fine-tuning API, which led to the product philosophy that the core model iterates too quickly; by the time enterprises navigate how to retrain, optimize, and deploy the model themselves, they may be two to three generations behind, ultimately resulting in a reset. Dianne Na Penn thus questioned whether this is a wise investment for the company, users, and clients. Continuously asking “what changes will occur in three or six months” helps the team clarify which products are worth pushing to market; many internally developed prototypes ultimately went unpublished because the primary goal was to ignite creativity or validate technology.
03 Research Priorities and User Feedback: How Product Managers Collaborate with Research Teams
Researchers do not only focus on current users. Dianne Na Penn noted that researchers in leading AI labs consider not just the immediate existing user base, but often look to future users yet to emerge and the secondary effects of technology, especially in areas like model safety and alignment. When the internal team reaches a consensus that their service is not just for current users but also for the future user ecosystem, many issues become easier to resolve.
For example, when the product team asks, “Why can’t Claude perform better in outputting JSON or Schema formats?” it may mean the researcher needs to pause work on developing computer control or optimizing reasoning capabilities. This is not something that can simply be improved step-by-step in a traditional PM roadmap, but rather requires weighing long-term technical bets against current training investments. When assessing a problem, it’s also necessary to judge whether, with the natural evolution of model intelligence, it might automatically downgrade and no longer be a P0 level issue. Dianne Na Penn acknowledged that this can be a frustrating answer for PM who are used to planning perfect paths.
Taking memory functions as an example, two years ago, the team often received broad feedback like “Claude does not perform memory functions well.” Although similar feedback is still heard today, the underlying technical complexity has evolved significantly. If poor memory performance directly leads to user attrition, the team will not just stand by; they might find alternative angles from a product perspective. For instance, by appropriately limiting usage scenarios, users can still have a reasonable experience while waiting for the next generation model capabilities to advance. In summary, there are three points: different lifecycle users must be considered; it must be acknowledged that such uncertain development can sometimes be frustrating compared to developing based on mature technology; and most importantly, a cognitive model must be established, clarifying the ultimate goal and controllable means, rather than relying solely on modifying underlying research as the only and optimal solution.
Decision-making primarily relies on discussion. During the training of each new version of Claude, the team holds regular stand-up meetings with research leaders to track training progress, discussing what needs to be adjusted and which aspects are well understood. The value of product managers lies in explaining why a particular problem is a P0: its significant impact on users means that if not solved, expected results cannot be delivered; conversely, if only a handful of users report complaints or if the frequency of using related features is already declining, it may be deemed P2, leading to the design of alternative paths. Dianne Na Penn emphasized that PM do not have the authority to demand that the research team modify a training parameter, just as no engineering team would accept a requirement to write code line-by-line based on orders. What PM should do is clearly articulate how a problem impacts users and then collaboratively seek solutions; only when prompts and other means do not alleviate the situation should adjustments to model training be considered.
04 Internal Talent Culture and Training System
When hiring, diversity in backgrounds is a common trait of the team. Many product managers’ career trajectories are not linear progression within the same company, but rather a cross-disciplinary exploration, endowing them with strong adaptability as technology rapidly changes, and past assumptions are continuously challenged. Among them are individuals who excel at quickly mastering new things or who have previously served as product managers in startups. Dianne Na Penn believes that such backgrounds are highly competitive since initial product managers often have to wear multiple hats, including customer success, IT operations, and even business development, and this multifaceted experience fosters the agility that the team demands. The team has also hired former researchers and long-time employees looking to break their inherent understandings of products and workflows.
After joining, the threshold is equally high. Being part of the team does not mean that new employees can smoothly return to their old roles on the first day. Dianne Na Penn has clearly stated in the onboarding plan that the first two months should be the most excruciating period of their career; if one feels pain, it indicates they are in the right state because the pace is extremely fast, requiring balance between short-term goals and rapidly changing mid- to long-term planning, while also formulating product plans, strategic roadmaps, and delivering results for the business line they are responsible for.
The team deliberately arranges highly challenging initial adaptation tasks. Those who can quickly adapt enter a fast development lane, while those complaining “it’s too difficult” and find various reasons for not managing usually struggle more and are likely to clear up their potential within a month or two; ultimately, it tests a growth mindset.
When asked where those who feel struggling usually get stuck,Dianne Na Penn pointed out that particularly product managers from large companies are accustomed to a hierarchical work model: directives are issued by vice presidents, and the execution chain blindly follows orders, with few pausing to question whether such directives are still the correct choice. This is in stark contrast to academia, where even first-year PhD students dare to question their advisors.
At Anthropic, employees are required to break from ingrained hierarchical views and dare to express opinions to chief scientists Jared; for example, after reading his article on a certain technology, they might point out that several assumptions were overlooked and propose adjustments that would provide more value to users. This requires speaking up and participating in discussions early on, rather than assuming executives have already thought through everything; expression must be founded on curiosity and mutual trust rather than arbitrarily accusing others of being wrong without providing detailed justifications. The team seeks individuals who can integrate into deep discussions, supplement new perspectives, iterate upon existing bases, and push implementations forward. The initial ideas shared might be those considered two or three years ago but set aside. Yet, if someone is willing to put in the effort to delve deep, questioning established assumptions in a respectful manner and offering unique insights, they often achieve great success.
The origin of this atmosphere, Dianne Na Penn believes, is related to the frequent iteration of models but fundamentally stems from corporate culture: the company began as a research lab, and many co-founders highly value first principles. The breakthroughs achieved today are due to not being limited by past assumptions, along with a willingness to question these assumptions and validate them through hands-on experimentation—the core operational logic among top researchers. Internal communications are highly transparent, with most channels completely open; when discussing a product detail in a group, someone you may not have noticed can politely interject, asking if everyone has considered another solution. The team appreciates collaboration that affirms each other and extends thinking.
Regarding successful product managers, another point is an almost obsessive enthusiasm for the technology: engaging deeply in their own product functions during the prototype phase or repeatedly testing the latest models and openly sharing evaluation insights, demonstrating through action—not just words—how to optimize products and models. Instead of hiding in a corner writing requirement documents, actively pushing model and product implementation is the hallmark of top product managers.
Many junior product managers complain about the poor environment and scarcity of good positions, but Dianne Na Penn’s observation is quite the opposite: relatively inexperienced product managers in the team demonstrate high efficiency and limitless potential limits, as they do not need to deliberately escape the constraints of traditional organizational structures. Here, there is no need to wait for others to issue commands or for the boss to sign off on requirement documents before moving forward. Energetic, proactive individuals think, “This is my module; I must ensure its implementation,” proactively engaging with customers and liaising with researchers regardless of whether they are research leaders or not.
Compared to product managers with backgrounds from large companies, these individuals do not need to go through so many preliminary processes of aligning various teams step by step; entering the fray with a light load is often highly efficient. However, this does not mean that mid- to senior-level product managers lack these traits; the team includes former senior product managers who have launched businesses as well as those who have tackled challenging projects internally and have successfully navigated the efforts.
In Dianne Na Penn’s view, the core lies in whether one has accomplished something that needed to overcome significant organizational inertia and resistance. That kind of relentless perseverance and attitude to achieve the mission often proves to be more lethal than any other trait, meaning they will always remain curious, seeking answers in every possible way, and driving themselves in the face of unknown challenges rather than waiting passively.
In terms of development, the team’s starting point is the definition of product management. Dianne Na Penn stated that it should return to the initial state of a new technology, rather than mechanically defining job responsibilities. The core principles still revolve around the users, specifically how to create value for users in a way that possesses compound effects, with other actions deriving from this. It might be that a year later, documenting model evaluations is no longer the best way to define user outcomes; perhaps everyone needs to write code directly to prototype, but the guiding star goal remains unchanged.
The onboarding process is extremely high-pressure: new employees are to complete user research, write model evaluations, and formulate product roadmaps within the first two to three weeks. Many ask if an additional two weeks can be granted, but this is precisely to push out execution capabilities, ensuring they enter the practical state where they must keep up with the company’s pace, which has proven to be very effective. Meanwhile, newcomers are placed directly in the highest-priority core business lines. The team prefers to maintain a small scale, allowing each person to manage two to three directions simultaneously, which forces inter-departmental communication, collides ideas, and promotes rapid learning, also bringing a strong sense of urgency for delivery.
The team holds a training camp once a year, focusing on sharing how to create products capable of handling exponential growth, meaning that as the underlying model capabilities improve, the product value will also experience exponential surges. The content includes how to optimize Claude, craft high-quality prompts, and conduct model evaluations; recordings of the course become required learning for every new employee. This initiative began in 2024, when the team had only about four or five people, and daily work began to resemble more of a research-oriented PM role, such as analyzing user-licensed feedback data and writing evaluations. Believing it beneficial for product functionality, they wanted more people to be equipped with this knowledge; thus, they documented operational steps, key indicators, and less valuable parts—initially aimed at PM outside the research-oriented product team, but now it is open to all Anthropic staff.
The training camp is also an opportunity to build an open Q&A platform. Dianne Na Penn emphasized that PM do not necessarily have to wait for model iterations; they can achieve desired results by modifying prompts. Live demonstrations lowered the thresholds and broke the technical mystique, with even sales teams participating remarking, “So this is evaluation, this is prompting; I can do this.” These methods can be replicated and scaled, which any company can achieve.
Regarding the mentorship system, new employees are paired one-on-one with experienced team members, using internal tools like Claude Tag to assist with onboarding. Newcomers are often advised to review group chat records from the previous two months since joining the company feels akin to joining a vigorously ongoing conversation; the most efficient approach is to do ample homework first, then express their understanding of the business context and solicit opinions, actively integrating rather than waiting for the company to spoon-feed knowledge.
05 Frontline Deployment Engineers: Trade-offs Between Depth and Breadth
Regarding whether product managers should deeply engage at the forefront and embed into customer scenarios, Anthropic has equipped frontline deployment engineers and a dedicated deployment team to assist enterprise clients with large-scale implementations on platforms or applications. Dianne Na Penn agrees that these hands-on skills are essential, but the reality is that digging too deep on one end necessitates compromises on the other. This often leads to feelings of conflict: wanting to closely follow every iteration of research models while also wanting to hear every client’s feedback, and with the current scale, it's impossible to attend every client conference call.
The key issue is how insights from the business frontline can effectively feed back upward and inform the products they are responsible for. The team directly collects feedback from API customers and early adopters testing new model capabilities, but limited resources and capacity prevent them from being fully dedicated to front-line deployments. Therefore, they tightly coordinate with frontline business teams, using their insights as complementary validations. The current model emphasizes panoramic business context sharing rather than requiring each PM to be thoroughly rooted in customer frontlines while also aligning with top-tier research teams, making it extremely difficult to achieve deep expertise on both ends.
An effective experience is that the team later selected some individuals from internal application and frontline deployment engineering teams to transition into PM roles, with impressive results: they possess a profound business sense, deeply understand the principles of Harness, the application architectures on the user side, and the motivations for use, enabling them to smoothly convey frontline voices to the research team. Dianne Na Penn recalls that when Claude.ai was first launched in 2023 and was the only product in beta, she personally wrote the system prompts for a long period before handing it over to new PM, which reflects the daily practice of frontline deployment engineers. Discussing technical depths abstractly often feels empty, and sometimes the most solid method is to become a frontline deployment engineer, closely listening to customers, which may provide an answer for reshaping the PM career path.
免责声明：本文章仅代表作者个人观点，不代表本平台的立场和观点。本文章仅供信息分享，不构成对任何人的任何投资建议。用户与作者之间的任何争议，与本平台无关。如网页中刊载的文章或图片涉及侵权，请提供相关的权利证明和身份证明发送邮件到support@aicoin.com，本平台相关工作人员将会进行核查。
