Kayvon Beykpour: evaluation

Transcript context

…I've only seen one interview on your show that covers this. Sriram was particularly spicy when he talked about jobs-to-be-done, which is unsurprising because. I spent a lot of time talking to Sriram about jobs-to-be-done. I mean, I guess I'll just start by saying I was not a fan of how we leveraged jobs-to-be-done at Twitter. I thought it was exhausting and not particularly helpful, and so it's a particularly sore subject for me because I was sort of charged with defending it and rolling it out. It's hard to do that when you don't really believe in something. But... It's hard to do that when you don't really believe in something, but to me the critique is less about Jobs-to-be-Done though there are many critiques of it and more about every framework at its limit is followed to such a religious extent it's just unhelpful. You need to have nuance in how you leverage these frameworks. Otherwise, you lose the forest through the trees and you end up following a process for the sake of following a process. And that's what happened with Jobs-to-be-Done. So I think that's my real critique of it. It's not the... I mean listen, the premise of Jobs-to-be-Done and my most charitable take on Jobs-to-be-Done, which is actually useful is that it forces you to look at things through the lens of customers and understanding what their needs are and understanding what their true alternatives are outside of the narrow lens of your product. And I think that's just healthy product thinking. You don't need a framework called Jobs-to-be-Done. You don't need to think about milkshakes in order to be able to do that. It's like you could employ common sense or you could leverage something like Jobs-to-be-Done, to be able to force your mind to think of things through that lens. So I think that's my charitable view on what Jobs-to-be-Done can help you do, but as a framework into and of itself as a sole governing principle of what to build, it's just not useful. By the way, in the same way as, and I think Twitter had this problem as well prior to our detour around Jobs-to-be-Done, if the only way the organization is trained to think about what to build and what not to build is OKRs, it's equally unhelpful at the limit because sure, you can have a good sense of what you should build to drive metrics, but by the way, you might be focusing on the wrong metrics or that might not help you have the right balance of things to build. That might not help you see when the things that you're building are actually hostile to customers. So just as an interesting example, the thing that I remember about your interview with Shriram, if I'm not mistaken, I think he mentioned, and I love Shriram, I'd be happy to debate him about this on his podcast, but he mentioned one of the examples I think was the Amazon. When you get order confirmation from Amazon, they intentionally bury the order details. You have to click the link and authenticate to go see what you ordered. of the examples I think was the Amazon. When you get order confirmation from Amazon, they intentionally bury the order details. You have to click the link and authenticate to go see what you ordered. I don't give two shits what metrics that drive for Amazon. That is one of the most customer hostile things I experience in my daily life. I order a lot of things from Amazon. I hate the fact that I can't search my email to see what I ordered. And so I think the problem with these frameworks is that you lose nuance and ultimately, and this is where I agree with Shriram, he actually mentioned this on your podcast as well, you need to be able to make trade-off decisions that balance what's right for the organization and what's right for the customer. And sometimes based on how you devise your frameworks, your metrics aren't actually aligned with the customer's benefit. Like the Amazon example, and we had many famous examples in Twitter's history, which were the same. One of our key metrics that we always optimized Shriram growing was DAU and we had obviously the rank timeline did wonders for growing DAU and it was a great experience for many customers, but we often had features that would not lead to a good customer experience and the team would just be blind towards leaving hostile customer experiences in place because it was good for metrics and aggregate. And the famous example of this is we had this toggle, which we called Swish very affectionately, but it was like a sparkle icon. Before you could switch between the rank timeline and the following, that reverse chronological timeline, which is still in the product right now, it was just the toggle. You would press a button and it would turn your feed reverse chron, which very few people use as a percentage of our users. But you had power users who really cared about having a reverse chronological timeline and we took so many baby steps on the evolution of this product. The very first baby step was you press the toggle, it turns you to reverse chron and then we would pull the rug out from underneath you and make the experience go back to the rank timeline after, I don't know, 24 hours or something like that. Oh, wow.…

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