The Skip Podcast
00:13:17 · Nikhyl Singhal
[00:13:17] S1: So what strategy look like in your day job today? You know, when you and I worked together, we were talking about, Hey, these are the three year, five year plans because we have this data. We want to be able to help users that have this challenge. You know, it was pretty, pretty long term in orientation. And these were industries that had existed for like a hundred years. You're describing now, you know, an industry that shifts every six weeks. You know, you could find yourself in hyper reaction mode because you're getting all the feedback you mentioned and the research in and of itself is driving some of the product plans. How have you remained strategic or is the strategy to be nimble and to be I'm curious as to how those two skills kind of come together at a company like Anthropic.
00:14:04 · Dianne Penn
[00:14:04] S0: One thing that has been helpful is because our research org is also very medium to long term thinking. And so there's almost like a helpful pull to not just be in the short term of like X, Y, and Z got shipped. We must do the same thing because like the research and like the company like mission and North Star is like very more long term and forward thinking. The way that it manifests, I think in how my team plans, how like we collaborate across like our roadmaps on the model or on the lab side is there are specific, like we do more almost monthly planning on just like a here's what we want to accomplish lens, but that's in the context of some high level assumptions or perspectives about the state of the world in like a six month to twelve month timeframe. What I mean is we don't spend, let's say three months doing an annual plan that goes out of date within like two weeks. We tried that for a little bit in the early years of we must do a full OKR process. Everybody must review the same OKRs, but then the OKRs quickly got like thrown out the window when our assumptions about usage or adoption were just completely underestimates. Right? And so what we ended up or the way that, like, I like to have on my team is what are some key assumptions in three to six months? And then what is a one month plan of how we accomplish continuing to navigate towards that while still being agile to the immediate dynamics? So what this means is right now we're thinking about things like life sciences. I think we are like Dario, etcetera, have talked a lot about like how this technology could be really beneficial for helping companies, life science organizations with curing diseases. That's not like a short term thing at all. But at the same time, we need to translate that into, okay, what are training or product investments or bets that we want to experiment with on a monthly basis? How do we make sure things like scientists and researchers get access to the models? How do we respond to initial dynamics in the market while trying to still make progress on that medium to long term?
00:16:30 · Nikhyl Singhal
[00:16:30] S1: You know, your team, for example, was the team that birthed, you know, Claude Code. And I think that, you know, when I look back at the sort of last year, you know, things like Claude Code, Claude Design were products and maybe arguably bets using your term that you decided to invest in. But then there may be product line areas like say Muse Open Claw, where there is less perhaps proactive work being done, at least from the visible sense. I'm just curious, again, going back to this planning, like how does both the research organization and the company decide what ends up maturing into something that is like a product, like say today's dash or yesterday's announcement around the dashboard products. Like how do you get something that's more capital P versus something that's a behavior and an area that one could build, but isn't necessarily a product that service. You mentioned life sciences might be there in twelve months or six months. How does that type of decisioning get made?
00:17:34 · Dianne Penn
[00:17:34] S0: I think it's relatively product development is relatively more bottoms up because there are so many ways that this technology and products around it can generalize. For example, even on something like Claude Code, there were customers or there were API customers who utilized some models for autocomplete for a long time before it. Right. So it wasn't that just one day coding became agentic. It was that there was a different sequence into people experimenting both internally and externally. What you saw was in particular the paradigm of the terminal and having allowing the model to actually do more agentic loops really started working with a combination of a product experience harness and also the model. I think in terms of product priorities, I think it's very around like what are some themes or areas that we are really stubborn about and how do we quickly get learnings into is the user experience or the outcome with the current set of technologies feasible? And are people finding like the magic, like we call it like finding the magic enough? And we have been also much more concentrated in terms of our approach on prioritizing for business, for enterprise, which tends, I think also to have a more stable set of needs and requirements compared to, let's say consumer, which is very dynamic and changing quickly. But even within the enterprise side, like there were times where we debated, should we have a fine tuning API? And one of the philosophies that we ended up with was, well, the model, the core models are improving so quickly. So by the time it takes a team to figure out how to post train themselves to then make it really good and then deploy it, you might be two to three model generations behind. So you'll have to start over. So is that the right investment for us or the users and customers? And so allowing to kind of asking ourselves a question, what might change in three months? What might change in six months? Helps us figure out like what might be worth shipping. But I think a lot of the actual prototypes, like there's a lot of prototypes internally that actually we don't end up shipping externally because we're trying to mostly create ideas or experiment, first.
00:20:05 · Nikhyl Singhal
[00:20:05] S1: You know, I love this term that you used around we want to be stubborn in certain areas. I think that's to some extent a better phrasing than we know we need to be opinionated as strategists, product leaders, executives. Your comment, I can imagine, you know, asking our audience, like, what are you stubborn about when it comes to areas of investment in the next six to twelve months, and then perhaps what are you more loosely held on, or perhaps what you know is going to change and you have to be more dynamic. This notion around stubborn opinions and deep execution are two areas that I think come through with both your career, as well as maybe the type of team that you're building. I'm curious around, you know, there's a number of folks that are listening to the call. Some are early in career, some are maybe ten, fifteen years, and they have held a product management role that they know is changing quite a bit. And, you know, one goal of today's conversation would be to help counsel them both on what you see within Anthropic and what has succeeded when it comes to product management, but also how does that influence your opinion on what product management maybe you need to do in other companies? So when you think about what's worked and what may have not worked as you've hired people over now several years, you know, give us a little bit of a flavor of, you know, the skills that you look for and maybe what resonates in an organization like yours.
00:21:37 · Dianne Penn
[00:21:37] S0: A lot of my PMs actually come from pretty diverse or different backgrounds. There's actually many people who have kind of similar to me, what might seem like a like meandering walk of different careers rather than like one clear, this is the ladder of like done the same job, but at higher levels within the same company. I think what that allows people to bring is like adaptability, agility, because we're constantly learning. Our assumptions are constantly being challenged. And so there's a layer of folks who are really good at learning or picking up new things or have a track record in their career of either being the first product manager at X startup. I tend to find that to be like a really powerful profile because you're a product person, but you're likely also the first customer success person. And you're also potentially have been the IT person. And you've also might have had to do business development. Just a number of hat wearing that somebody has to do as a first PM with an x has been like a profile that's worked really well because of that specific, like, agility. I've hired folks who were former researchers, folks who actually have been at the same company for a long time, but with the recognition that like they want to try to lean really far out of a set of assumptions about how product or how work and having impact for users could look like. I think it's not necessarily day one where you come in and you do the exact same job. And what I tell the team in their onboarding plan is the first two months here should feel like some of the hardest of your career. That actually means you're doing it right because of the velocity and pace that we're working, the ways of working to how to hold the short term with the medium to long term. And with a medium to long term that is changing dramatically. And to deliver on a product plan or a set of outcomes or a strategy for your area, a roadmap for your area. That type of challenge is stretched, especially stretching people in the beginning. What I've seen being successful are those who really try to rise to the challenge. And I try to give actually really hard initial ramp ups. And for folks who really then ramp up quickly, then they kind of get onto the acceleration. And for folks who are like, this is really hard. I have these reasons why I couldn't do X, Y, and Z.