Lenny Rachitsky: belief

Transcript context

…The earlier that you can understand the belief system and the things that are important to them, the better off you're going to be. So very, very early on in this process, what is top of mind for them? I can count on one hand when I was chief of staff, how many people asked me for advice before going into a product review with our CPO or our other executive team to say, "What do you think is most important to them right now?" Use the people around them, their EA, their chief of staff, the people who have successfully pitched ideas in the past and say, "What worked? What do you think they're worried about? What are the risks?" And in an age of the tools of AI that we have, this is so much easier than it's ever been, right? You can ask Slackbot, "What has Rachel been posting about lately? What do you think is most important to her?" A colleague of mine, a peer on our product leadership team, trained at GPT on a bunch of transcripts from past product reviews that are all publicly available, and we expect that our PMs are running their PRDs or their pitches through that, to say, "What's Rachel going to push back on? Where are their weaknesses in these ideas?" You can also train things on, "Where are your own weaknesses? I know I've gotten feedback in the past that my data is a little thin or that this kind of UX thinking is thin. Give me feedback on that." Claude's amazing for this. And so, I think that the first step is actually just saying, what's important to them? What do they want to hear and anchor on that? I think the second piece is going in to learn not to convince. And the earlier on you do that, the better. So we have something at Webflow called Office Hours. As early as you can, you are having these conversations to align on strategic direction, maybe even before you have a one-pager. We implemented something at Slack with Stuart, because we realized we were coming to him with done designs and he was like, "What the fuck is this? This is completely different than how I had this in my mind." So Allie Rail, early Slack employee implemented something called, "Hey, Stuart, what do you think?" And we would just sit with him for half an hour and say, "What do you think on this topic? What's your belief system? What's your past experience?" And we started with a user interview, right? We started with, "We actually want to download your expertise here." And I think that when you engage execs in that way, it's really, really valuable. One of the things I see people do poorly is, they don't ask for the time. This is sort of in counterpoint to what we were talking about before with how busy their calendars are, but they're afraid to ask for more time to get that insight. But sometimes if you don't, you miss the point. Something that we hear a lot on this podcast, is as a product leader, as a leader of any kind, you want to have a point of view, you want to come into a discussion with, "Here's our options, here's what I think is the right solution. " And then at the same time, as you're describing, you want to come across as, I want to learn. I'm not here to convince you. I'm here to just help understand your worldview and where you think the right path is. How do you think about just those two, that balance of, I have something I believe is right and, okay, but I'm here to learn and get your feedback and see what you think makes sense. Okay. So my advice on this may be a little paradoxical, because I think people make mistakes in both directions on the polls here. On the one hand, I think there's an error people make of trying to show too much work, trying to tell too much upfront proof point. We talked to 16 participants from these 15 GOs and this is the statistically significant and the exec is like, "I'm so bored, I'm going to die." I remember I did this in a review once and literally the person I was most trying to convince glazed over, got on their phone and I totally blew the meeting because I was trying to prove that I had done my homework. Put it in the appendix, right? They don't need to know every single detail. The baseline expectation is that you did your job, and that this is built on a solid foundation of your domain expertise. On the flip side, I think there's some balance of showing your work, that helps elucidate why your solution is best. So one of the mistakes I see people is doing is giving only one option. I think that people, if you say, I mean, this is also like classic pricing and packaging strategy, give three options and the Goldilocks in the middle is the perfect one, right? But I think that what that actually allows you to do is say, "Hey, we considered. We are not dumb. We did not miss something. You think we missed something, but no, no, no, we actually considered this." So we had a recent product review with my manager, Rachel Woolen, she was a recent guest on How I AI, and- ... she was a recent guest on How I AI, and we brought a doc, a sort of reasonable approach to what we thought was the sort of problem and strategic space we were going after. It didn't go well. It really didn't match her expectations. And the feedback she gave us, which was really, really the right feedback, was I don't understand how you're thinking about the permutations if possible here because we had only given one option set. And so what we did following that review is we said, "Hey, we really want to sort this out. We want to get moving. We want to show that we can really get building on this product. And alignment is the next stepping stone for that. Can you meet in two days?" And we turned around a new doc in two days that actually showed all of the options we had considered, but hadn't brought to that first review. And once we elucidated all the things we considered, and why we thought they would or wouldn't serve the outcomes we were driving and the technical complexity behind them, she was like, "Oh yeah, okay. I see why the solution that you're proposing makes the most sense for what we're trying to accomplish." But in the first version, in the first meeting, we hadn't shown that and we hadn't workshopped it through her. And so sometimes really tactically you want to have that available to you. It's not necessary to put all 15 options you considered, but at least be ready to show them. Have them in an appendix, have them in a draft Figma file, whatever it is.…

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