High Signal Podcasts Evidence ledger
Method
Browse
← Back to evidence

Evidence receipt / belief

Published · transcript-backed

Kayvon Beykpour: belief

28 Apr 2024 Lenny's Podcast Twitter’s former Head of Product opens up: being fired, meeting Elon, changing stagnant culture, building consumer product, more | Kayvon Beykpour

“Either you have an incentive problem but the team did what they were incentivized to do or that there was bad judgment and that's a different problem obviously. But I think in the situation we found ourselves in where the team was again understandably hyper focused on driving DAU because that was the strategy for so long.”

— Kayvon Beykpour

Source trail

Everything needed to verify it.

Speaker
Kayvon Beykpour
Attribution
Verified speaker
Claim type
belief
Recorded
28 Apr 2024
Publisher
Lenny's Podcast

Transcript context

…I think that's really important advice and I love hearing the details if I actually think about this stuff. Actually finding this balance is very hard in practice. I'm curious if there's something you could recommend or have learned about how to know when you've gone too far with a framework like signs like you have implemented this to religiously and maybe you should be thinking a little more broadly. There's two, I think, simple and obvious ones. One is if the result of your framework is that subjectively bad decisions are being made, then something's got to change. Assuming the person who's making this assessment has good product taste, which is in of itself subjective obviously, but my personal view on this would be in the role that I had, if I saw that our organization was being incentivized to make decisions that to some non-trivial degree of the time were just bad decisions that I don't like as a user, I can't stand by as a user or builder, then something's got to change. Either bad judgment was made in following the process or the process was wrong, or if that framework, it didn't even lead to the right debates, then that's how you know. Either you have an incentive problem but the team did what they were incentivized to do or that there was bad judgment and that's a different problem obviously. But I think in the situation we found ourselves in where the team was again understandably hyper focused on driving DAU because that was the strategy for so long. It left so little room for even taking ambitious bets that in the short term wouldn't drive DAU, like some of our bets that I still to this day believe in hurt DAU in the short term, but you had to squint and believe over time would improve some metric DAU or otherwise, like a product like Spaces. In order for Spaces to be actually used, you needed to make sure that when Lenny starts a Space that people would join. And how do you get people to join Lenny space when they're used to having an asynchronous feed of tweets? Well, you can send push notifications, you can occupy really trying real estate at the top of the app that lets people know, "Hey, Lenny's live right now. He's in a space, there's people here, come join." Guess what happens when you put a bar at the top of the app that tells people when they're live? You move tweets down, you move ads down, DAU goes down, revenue goes down. And so if you have an organization that's just hyper focused on the thing that matters is driving DAU quarter over quarter, then that doesn't leave enough room for nuance to accommodate new speculative bets that might hurt one metric, but over time have other consequences that are positive and beneficial, like enabling an entire new vector of content creation and conversation on the platform. I guess the other answer to your question in terms of how do you know when the framework's not serving you right? When you start imagining and planning for a bunch of bets that the organization then sees is disincentivized to make successful, then something's got to change. Either your strategy is just not the right strategy because it doesn't abide by the frameworks or the framework needs to accommodate the fact that actually we're going to try some things that in the short term either might not show up as blips on our DAU radar or are going to help some other metric that's important. to accommodate the fact that actually we're going to try some things that in the short term either might not show up as blips on our DAU radar or are going to help some other metric that's important. And so that took us some time to get, and we tried a variety of schemes to make that work. Community Notes, the project that I was mentioning Keith started, we intentionally structured that like a startup. It was literally like we made a seed bet on Keith and his team and we were like, don't worry about the OKRs. We're not going to judge you on the basis of your OKRs. And there's some pros and cons to that. A lot of our projects worked that way. Fleets started that way. Community Notes started that way and some other projects started more part of the core organization because they were so intertwined with how we were the nature of the product that it just made sense to... Separating it was going to do more harm than good. So you just have to figure out based on how execution is going, whether you've got the right framework and you've got to be willing to make adjustments when it's not working.…

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

Search evidence