High Signal Podcasts Evidence ledger
Method
Browse
← Back to evidence

Evidence receipt / evaluation

Published · transcript-backed

Kayvon Beykpour: evaluation

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

“That last one is a huge pet peeve of mine that I feel like we learned the hard way, and particularly it's a common pattern I think in highly functional organizations where you have different people making decisions on how to staff projects, and there's nothing inherently wrong with that. But I think in the situations, in the situation we found ourselves in where we had this sort of cultural evolution that we were going through where some people just didn't agree with the things that we were prioritizing, they were begrudgingly going along with it, but you would end up in a situation where the combination of that sort of cultural shift and strategy and the fact that the way teams were being staffed was not, there's ultimately no single decision maker other than the CEO and Jack is not going to get in the weeds and debate a staffing decision on the team, resulted in a situation where oftentimes we'd have projects, like the one I mentioned about hiding replies, where there wasn't even an agreement on the team about whether this was a good idea and whether this is worth trying or how to do it.”

— Kayvon Beykpour

Source trail

Everything needed to verify it.

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

Transcript context

…It feels like every big bet was one of these companies from the list that you just shared, and I'm glad you shared Periscope, obviously. That's a great example, too. I guess maybe just a follow-up question here, is there anything you learned about how to do this well? I know you talked about maybe creating a little silo for the team, because so many companies acquire and acquihire and they just go nowhere. So I guess just a two-part question, just like what are some tips for how to do this well at a company? And then, two, you also, we were talking offline about this previously and I think it's a really interesting point, that a lot of companies staff based on who's available versus who is right for the role, and let's wait until that person is there for us to bet on this. Can you just talk about lessons there? That last one is a huge pet peeve of mine that I feel like we learned the hard way, and particularly it's a common pattern I think in highly functional organizations where you have different people making decisions on how to staff projects, and there's nothing inherently wrong with that. But I think in the situations, in the situation we found ourselves in where we had this sort of cultural evolution that we were going through where some people just didn't agree with the things that we were prioritizing, they were begrudgingly going along with it, but you would end up in a situation where the combination of that sort of cultural shift and strategy and the fact that the way teams were being staffed was not, there's ultimately no single decision maker other than the CEO and Jack is not going to get in the weeds and debate a staffing decision on the team, resulted in a situation where oftentimes we'd have projects, like the one I mentioned about hiding replies, where there wasn't even an agreement on the team about whether this was a good idea and whether this is worth trying or how to do it. And imagine, it's hard enough to build something from nothing. It's even harder if the team doesn't believe in it. This is to the point of just being toxic. The startup would never succeed if all the people who are working on that startup aren't to the point of being perhaps irrational obsessed with that idea. And still willing to see truth, you need to be able to see whether the thing is working or not, but if you don't believe it in the first place, I'm not betting on that succeeding. And so this was common, and sometimes not as extreme as the examples that I mentioned, but I think one of the lessons I learned, and it's quite intuitive actually, is you need to staff projects with the team of people that are well equipped from a skillset standpoint, but more importantly have an obsession with the idea they want to pursue. It's going to make them work harder, it's going to make them be more creative. It's going to make them have the sufficient level of ambition and desire to will this thing into existence. Because every project, whether big or small, there is an element of you need to will this thing into existence because it's hard. The only way you're going to get through that pain is by having that desire, and I think a very easy cheat code for an organization to employ is to say, if you're going to work on something, especially if it's speculative or risky, staff it with a set of people who believe in it and really want to learn whether this solves a customer problem or not. Because if you don't have that ingredient, it's going to drag everyone down and it's just not going to be as successful. This episode is brought to you by Heap, the product analytics solution that shows you everything users do on your digital product, website, mobile product, or other digital services. We all know a great digital experience when we see it. It's intuitive, it anticipates your needs, and it makes it easy for you to do your job. If you're trying to build that kind of experience for your users, you need up to date, reliable information about what your users do in your product and why they do it. Want to know how your users behave across platforms, what keeps them coming back, what they're doing that you're not even aware of? Well, I have some great news for you. Heap captures all of this user activity for you automatically and then gives you definitive answers to all your questions about user behavior in seconds, not weeks. With Heap, it's easy to prioritize the product investments that improve conversion, engagement, and retention. Visit heap.io/lenny to get started with a demo. That's heap.io/lenny. This kind of touches on something I wanted to touch on, which is jobs-to-be-done. This is maybe one of the most recurring controversies of the podcast, is jobs-to-be-done amazing or is it really bad and not something you should do? We've had many guests share their opinions. I feel like at Twitter, jobs-to-be-done was implemented so strictly that it burned a lot of people out on it. It's like, oh my, this is not anything anyone should ever do. I'm curious, just your lessons and experience of just with frameworks in general, the jobs-to-be- done specifically, maybe even OKRs.…

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

Search evidence