Nikhyl Singhal: evaluation

Transcript context

…There's so many directions we can go here. One thing I want to throw out, it's kind of a hot take, and this came from a chat I just had with Amol, a Head of Growth at Anthropic. So he's Head of Growth, he's a PM and he had this really interesting point that as engineers can do so much more, PMs are getting squeezed because they have to stay on top of so many things, so many features, so many ideas, so much talk, so many things being said at them. And there's this push for PMs at companies to ship PRs, build stuff themselves. And what we took away from that chat is the leverage that PMs often have is a lot higher, not spending time coding and shipping, but instead just staying on top of all this stuff. And he's like, "We need more PMs now. There's so much for PMs to do because engineers are so fast." So there's still need for prototyping to explore ideas and ideate and get feedback and align. But he had an interesting take that it's better I don't spend time shipping stuff. It's better I do higher leverage work as a PM. It depends what he means by shipping stuff because I think that if you have an engineering team of 50 people building things for your customers and you're like, "Hey, I want to be the 51st because that's how I get leveraged. " I'm like, "Eh, it's kind of a cheap knockoff of an engineer." If on the other hand, the thing that you're building is ways to stay on top of what the 50 people are doing when in the past that was building tickets and backlogs and all of the things that we used to do to figure out organizations, manage standups, that's the information overload that's happening. What we saw when the CPOs got together is all of the things they're building are ways to drive efficiency out of their product organizations. They're inside the building kind of development efforts. And I'm not sure that for the next five years, we'll continue to build software that way, but I think in the next two years, people are going to change the product operating system that they're working on. And we're already seeing companies that stand up and they say, "Hey, we've fully automated the way we do product reviews. We've fully automated the way we do product standups." So to his point, look, if there's 15, 10 times the amount of stuff happening, we need judgment to determine whether it's good. These are good or bad changes. And right now, if it's manual, we're cooked. So it's a combination of hiring good product builders with judgment and then hiring increasingly folks whose entire job is to build the internal tools necessary to improve the decisioning, but it's not through hiring of humans and building management ethos, which is what it used to be in Zurp. It's actually through technology, but it's a totally different way of building software. And that's what gets people excited because they're like, "Wow, if I do this, I don't have to ever do a status report." I mean, that was a comment that was made. I hate doing status reports. So now I just wrote something and my boss is happier because they get more detail. And that to me is incredibly exciting, but it is a different direction of what you're trying to deliver than something that goes out the door. That is such a good distinction and it makes all the sense. Basically, it's make yourself scale through software as much as possible. There's a big opportunity and it's fun. It's like you're building your own thing.…

Stored transcript either side of the excerpt. The highlighted words are the published quote; the surrounding text is unedited source, never generated.