Scott Williamson: Hiring the Best Product People in Five Steps, Why the Best PMs are Writers | E1118

1. 0:00 – 0:52

   Intro

   1. SWScott Williamson0:00

      There's four buckets for an individual PM. One is around valid- I call it validation. Customer interviewing, product usage data, kinda like gathering insights. Two is build, which is how well do you work with engineering? How, uh, can you make trade-offs? Can you tee it up for them in a language they understand? Three, the business. Do you know which KPI to set? What's this thing you're working on? And third is communication skills. You need to manage up-to-dates, you need to talk to customers in their language, you need to speak to engineering in their language.

   2. HSHarry Stebbings0:32

      Scott, I am so excited for this. I heard so many great things from Giler. So, thank you so much for joining me today.

   3. SWScott Williamson0:38

      Thanks, Harry. Uh, I've listened to the show a bunch of times, so I'm really excited to be, uh, take a turn as a guest.

   4. HSHarry Stebbings0:45

      Listen, I totally get it, my accent is shit and British, but I can't change it, so you can leave a review on iTunes. (laughs)

2. 0:52 – 2:31

   Background

   1. HSHarry Stebbings0:52

      Um. But I wanna start, you know, you've worked and led product teams at GitLab, at SendGrid. How did you make your way into the world of product and come to lead some of these incredible product teams?

   2. SWScott Williamson1:02

      Well, it, it was actually a long road to get into product. I started my tech career in sales, and spent four years doing that. Really quickly into that role, learned that I was very excited of, about what the product people were doing, so I endeavored to position myself to get into the role. Uh, and among other things, there wasn't much product management content back in the day, so I decided to get an MBA with a management of technology specialization to prove to hiring managers that I was serious about getting into product and gain some experience that I hadn't really had having kind of a traditional business background. Unfortunately, when I came out of grad school, it was '03, sort of the nuclear winter of tech. There had been a dot-com bust. And so, I was still competing with people who were trained product managers, so I took a job in alliances, which sat very close to product at this particular company. And after a few years of working very closely with the product teams, finally able to kind of get in the door, get my first PM role, and then from there, it was off to the races, because, uh, I, you know, I- I had a very broad background up until that point, and it was a role I was supposed to be doing, and so from there, have had an a- amazing career in product leadership at YLCA, SendGrid, Twilio,

3. 2:31 – 3:35

   Is MBA Still Worth it Today?

   1. SWScott Williamson2:31

      and GitLab.

   2. HSHarry Stebbings2:32

      Okay. So I have to touch on a couple of things there. Number one, are MBAs still worth it today? I asked Brian Halligan at HubSpot this in, on the show that came out on Monday. What do you think?

   3. SWScott Williamson2:41

      I think it depends on what, where you wanna end up. If you wanna be a badass PM, I don't think you really need it. You can learn the skills that you need to learn through product-focused training, through being in the right situation, through learning from Jedi masters at your company. If you wanna be a CPO, a VP, if you want to really connect the dots between the product as a function in the rest of the company, I do think it can have long-term payoffs from that standpoint. So, I think it can have return for people with a very long view, but in the short term, you, there may be a faster path to a really cool PM job.

   4. HSHarry Stebbings3:26

      Yeah. I totally agree. And they're fucking expensive-

   5. SWScott Williamson3:29

      Yeah.

   6. HSHarry Stebbings3:29

      ... but brilliant businesses to run.

   7. SWScott Williamson3:31

      Yeah.

   8. HSHarry Stebbings3:31

      Uh, I want, I- I wanna start with the hardest question of all in product, okay?

4. 3:35 – 5:32

   Product as Art or Science

   1. HSHarry Stebbings3:35

   2. SWScott Williamson3:35

      (laughs)

   3. HSHarry Stebbings3:35

      And it's, you know, art or science, we have a f- ton of data today, and it drives a lot of decision-making. How do you think about whether product is art or science when done well?

   4. SWScott Williamson3:47

      I think it's, for most roles, about 50/50.

   5. HSHarry Stebbings3:52

      Oh, that is a cop-out, Scott.

   6. SWScott Williamson3:53

      I know. Let me explain.

   7. HSHarry Stebbings3:54

      (laughs)

   8. SWScott Williamson3:55

      Let me explain. And I will s- and there are certain roles where it's a different mix. I think for most roles, what, what I've come to learn is this, uh, is that if you have a systematic approach to how you capture inputs for product, so do you do inter- customer interviews in a systematic, thorough, professional way? Do you instrument your application in the right way to where you get the right kind of product usage data and answer real questions? Do you have the right KPI that connects what you're doing to the business outcome? These are just examples of sort of having a systematic mindset to how you go and you do the job and how you capture the inputs. But then, you gotta derive insights from it. You have to figure out where to take that data, how to turn that data into a user experience that actually solves the problem that you're intending to solve, that actually drives the business outcome you're trying to drive, and I feel like that piece of it is quite artistic, quite creative. And I think in most roles, it's about half and half. If you're a growth PM at Facebook, you got shit-tons of data, the, the path for the product is pretty clear, you're mostly just running A/B tests, maybe it's more like 80/20, 90/10 data to art. If you're a startup, you have very little data at your disposal. You're mostly working on early qualitative feedback, really deeply understanding a problem, and then trying to go iterate your way into it, and that might be more like 20 data, 80 art. So, that's how I, I think about

5. 5:32 – 6:20

   Balancing Science & Art in Leadership

   1. SWScott Williamson5:32

      that mix.

   2. HSHarry Stebbings5:32

      Are product leaders generally a science-led product leader or an art-led product leader? Is the unicorn the one that does both?

   3. SWScott Williamson5:39

      I think, uh, yeah. Uh, uh, if I think about my own career, I've been more of the later stage, let's bring some science to this thing, let's bring some rigor to how the PM job is done so that we can raise the average performance level for PMs on a, on a medium to large team. It's more of, like, thinking of your product team as the product, because they have to go do the individual work, versus if you're a very early stage either founder or person who's come in to run it, a lot less data, maybe it's just you.You gotta be scrappier. You gotta work on less data. You gotta use your gut a lot.

6. 6:20 – 7:40

   Transitioning to Science Mode

   1. SWScott Williamson6:20

   2. HSHarry Stebbings6:20

      Can I ask, when does a product need to be more science? Like for founders that are listening today and that are a million in ARR, and they're more intuition-based, they're more creative, they're more artistic, when do they need to go, "Huh, we should instill more scientific structure, processes, rigor into our product talk"?

   3. SWScott Williamson6:38

      Basically it's when you've found repeatable product market fit. You know who your ideal customer profile is. You generally know the problems they need you to solve. You generally have confidence that your product experience can both attract and retain them at a reasonable, sustainable level. Once you get to that point then you're gonna need to start adding nodes onto your PM machine. You're gonna need to break up the product experience. You're gonna need be able to bring on individual PMs and designers and engineering managers to own pieces of it. And when you get to may- maybe when it's still three PMs, there's still not a, a big need for big structured process. But when you get up to 10 plus, you're only as good as sort of the average PM's performance, and if you don't think about the broader system that each one of these people are plugging into, you're gonna get this huge variance in performance.

   4. HSHarry Stebbings7:36

      Mm-hmm.

   5. SWScott Williamson7:37

      And so that's, that's generally how I think about that, that transition.

7. 7:40 – 9:47

   Defining the Role of Product Manager

   1. SWScott Williamson7:40

   2. HSHarry Stebbings7:40

      We're gonna talk about PM performance. First, I just wanna touch on PM. It's a kind of ever-changing role. I'd love to understand, how do you define the role of PM and how is it changing in your mind?

   3. SWScott Williamson7:53

      Well, I define the role as a hub function between the outside world, the market itself, the customers, the com- competitive moves, technology changes, and then the company. You've got engineers, your marketers, salespeople. They all need... Both sides of that need to interact with your product. And so PM is the function that sits in between those e- external and internal worlds, sets direction, makes the priority calls, decides where this thing should go and what we should invest in and what ultimately what the user experience should be. That's roughly how I think about it. Now, to do that well, you need about half your time to be out of the building. Most PMs spend about 95% of their time facing engineering, and zero to five talking to customers and being out in the world. What that means is the work that they tee up for engineering is oftentimes very ill-informed, maybe based on instinct or what the sales team told 'em to do, or what the CEO told 'em to do, or what customer, the $5 million customer told him to do, and you end up with a work product that s- ultimately misses the mark. For progressive teams that do product well, they've changed in that they've given team- PMs more time to be customer-facing. They, uh, start with the problem rather than the solution or what internal people think you need, and they routinely connect the work you're trying to do on product to the business outcome you're trying to drive. Which customer is gonna use this? What action do we think is... What's go- what is going to change? And if you operate that way, you get more outcome-focused and a lot less output-focused and, I don't know, maybe 20% of teams work this way. Still

8. 9:47 – 11:35

   When to Hire the First PM

   1. SWScott Williamson9:47

      a minority.

   2. HSHarry Stebbings9:48

      I, I wanna dig in, uh, after this next question into kind of how do we hire those people with those qualities. Before we... When, uh, sorry, before how do we hire them, just in case of when, you know, you said before we chatted... before we started recording that you advise sometimes founders who are focused on product as early as that. When is the right time to make your first product hires, your first PMs, your first product leader?

   3. SWScott Williamson10:10

      Uh, it's a similar answer to the one I gave before about when you start shifting into more, like, science mode. Uh, when you've found repeatable product market fit, where you know the ICP, you've got decent retention, and you've, you've seen a repeatable ability to go acquire that target customer.

   4. HSHarry Stebbings10:27

      Quite late though.

   5. SWScott Williamson10:28

      Yeah.

   6. HSHarry Stebbings10:30

      I mean this is like-

   7. SWScott Williamson10:30

      Yeah.

   8. HSHarry Stebbings10:30

      ... two, three million in ARR.

   9. SWScott Williamson10:32

      Yeah. I think you're right. And I think if you hand it off before then, it can be very problematic because it's... These decisions, which ICP, what are we gonna prioritize to build for them? What's the core user experience? These things are so central to a company, especially if it's a PLG company. Handing that off before that's fairly clear feels like a recipe for disaster because you're actually either gonna wanna still be super close to it and you're gonna s- squeeze 'em out, or you're gonna delegate too early and you're gonna have someone without the core context of founder making these critical decisions. I could get behind hiring a fairly junior PM maybe to do some of the core day-to-day backlog management maybe, but nothing more than that until you have a decent product, uh, decently repeatable product market fit.

   10. HSHarry Stebbings11:28

       Okay. So decently repeatable product market fit. Uh, now we know when we need to actually do it.

9. 11:35 – 12:59

   Structuring the Hiring Process

   1. HSHarry Stebbings11:35

      Um, I think it's really fricking hard to find these great people, and so I do wanna unpack the structure of your hiring process. If we break down that structure, what does that look like? How do you structure the hiring process for these product hires that you just mentioned?

   2. SWScott Williamson11:50

      Five interviews total. First one's a 30-minute recruiter screen, or hiring manager screen if you don't have a recruiter, just checking for the basics. Then the hiring manager should spend an hour with them, checking on sort of d- uh, do they clear the bar for the core competencies of PM, and I can get into what I, I think those are; an engineering manager interview for an hour or so where you're testing for...... clearing the bar on the domain and the minimum level of technical knowledge they're gonna need, and their ability to work with engineering. One peer interview. If you have other PMs, they should be doing this. Uh, I can get into tactics and techniques for that, but I'd typically like to see that be a little more hands-on, where they work on something together. And then one more, sort of finalist interview, either with the hiring manager again, or a bar raiser interviewer, if you have someone else in the org who's very good at interviewing, where you get into more, like, a case question.

   3. HSHarry Stebbings12:52

      Okay. I mean, listen. There's, there's so much I wanna unpack there, so that's really helpful. I, when I write on my hand, it, it's good sign.

10. 12:59 – 14:18

    Core Competencies of PMs

    1. HSHarry Stebbings12:59

       Uh-

    2. SWScott Williamson13:00

       (laughs) .

    3. HSHarry Stebbings13:00

       Um, so you said there about the core competencies of being a PM. Just so we actually understand them, when we are in this process, what are those core competencies that we're searching for in PMs?

    4. SWScott Williamson13:10

       A lot of ways to break up the function, but how I bucket it is there's four buckets for an individual PM. One is around vali- I call it validation. So, customer interviewing, product usage data, kinda, like, gathering insights. Two is build, which is how well do you work with engineering? How, uh, can you make trade-offs? Can you tee it up for them in a language they understand? Can you iterate? Can you work with them to break stuff down? Three, the business. Do you know which KPI to set? Do you know what this thing you're working on is going to drive? So, linking the activity to the potential outcome. Can you, like, think about the business of your product and what you're trying to do? And third is communication skills. You need to manage up-to-exacts. You need to talk to customers in their language. You need to speak to engineering in their language. Every one of them involves different vocabulary, different altitude, and you need to be clear to each one of those constituents. So, that, that's how I'd break it all

11. 14:18 – 15:42

    Effective Peer Interviews

    1. SWScott Williamson14:18

       down.

    2. HSHarry Stebbings14:18

       Okay. Fantastic. Uh, and then you said about, um, peer interviews was another one where I wanted to dig in. So, how do we structure them in the right way, and what are the nuances and complexities there that we should know about?

    3. SWScott Williamson14:31

       I think GitLab did this well. We had, uh, what was called the Think Big: Think Small, was the exercise. And the PM would partner with the interview candidate. And ahead of time, they would ask them to come prepared with a topic that was sort of pertinent to the area they were interviewing for, and we would ask them to write down what's, sort of, the vision for this thing, and then how would you iterate your way to it? Iteration was a hu- was a company value at GitLab. I think it's a very underrated aspect of great PM and great product development, is this act of breaking things down into small chunks so that you don't over-complicate what you ship. So, this exercise tested a few things. It tested their ability to think about something on a fairly large scale. It tested their ability to break it down into, like, actionable steps that the engineering could absorb. And it tested their verbal skill and their writ- written skill, 'cause they had to write it down. GitLab's all remote. You're dead in the water if you can't write clearly at GitLab. So, it was testing all those things at

12. 15:42 – 16:53

    Importance of Writing Skills for PMs

    1. SWScott Williamson15:42

       once.

    2. HSHarry Stebbings15:42

       Is writing a core skill of PMs? I remember I had Kevin Naparco on from Twilio, uh, and seg- segment. But he said, like, writing's the most important skill. Do you agree, and, and why so?

    3. SWScott Williamson15:52

       I, I tend to agree, especially at a place like GitLab, where it was all remote. We did ve- PMs did very little synchronous work. And so, if you can't rely on, sort of, verbal agility to get things done, you'd better be a good writer. And I think relying on verbal is, is fine. It's helpful. Like I said before, you have to communicate clearly to different levels and different audiences. But that written artifact is just essential to driver alignment. Uh, there were two that we used at SendGrid and GitLab that I think were essential. One was a one-pager called an opportunity canvas, which asked PMs to outline, sort of, the concept they wanted to, to build. And the other one is, like, a two to six pager. I think Kevin might have mentioned this. It's, sort of, borrowing from Amazon, this concept of a, a six pager, sort of, a longer arc strategy doc. Those are two that I feel like you

13. 16:53 – 26:07

    Creating Strategy Documents

    1. SWScott Williamson16:53

       have to write down.

    2. HSHarry Stebbings16:54

       Okay. Sorry, just br- breaking those down, who do you present those to? How are they used internally? Can you just share that? If I'm a founder listening, and I'm like, "Ooh, that's a good point," one pager and a six pager...

    3. SWScott Williamson17:06

       Well, I'll start with the six pager because that's, sort of, the longer arc one that, that should help you drive more focus. Uh, at GitLab, we had these things at my level for the whole product line. The directors had them for product areas. If you think about GitLab, there's dev, sec, and ops. So, we had a dev strategy, a sec strategy, and op strategy. And then each PM underneath those directors had their own strategy for their area. Maybe it was agile planning, or road mapping, or, or continuous integration, or whatever. And when you have these laddered strategies, it helps each level make sure that the things they're working on are connected to other levels. I don't wanna over-complicate it. You're mostly dealing with startups here, so you probably just need one of these. The point is you want a little bit of a longer arc than your typical planning cycle. So, at GitLab, we had a one-year planning cycle. Plenty of companies have quarterly planning cycles. Make sure it's two or three, uh, iterations larger than a planning cycle. So, if you plan every quarter, make sure it's at least a year. If you plan every year, make sure it's two.So that you can kind of get out and over the planning cycle into, like, where we're going over a longer R. And it should make trades. It should say, "Hey, we're going after this segment and not this segment. We're gonna focus on these use cases and not these use cases." It should narrow your focus rather than having an overly broad... And that kind of a doc and that kind of alignment's tough to get to. And I think the only way you get to it effectively is through long-form writing.

    4. HSHarry Stebbings18:49

       Why is it tough to get to?

    5. SWScott Williamson18:51

       Because words matter. And if you're projecting your strategy verbally or in s- full bullet points on a slide, people can hear what they wanna hear. They can read, they can interpret what they want to interpret. When it's written down and you actually read it, and it's off ten degrees from what you think, I think it's easier to map to, "Hey, here's what I really think we should do, and here's what this person's saying we should do." And just that fidelity of alignment is so much higher in a long-form doc on something like a strategy.

    6. HSHarry Stebbings19:29

       Okay, let's take this further. So you- we're in the same product team, you write one of these six pages. How do we have an internal debate/discussion on your six-pager? What does that... Is that commenting? Is that a cool... What does that discussion look like?

    7. SWScott Williamson19:44

       I'll use GitLab as an example. Uh, it, it was a fairly async process, given the, the all-remote nature. I did it at my level in sequential, kind of, uh, concentric circles that got bigger. I reviewed it with the CEO first. I reviewed it with my product leadership team second, the executive team third, broader product team fourth, whole company fifth. Each time, I took comments, essentially. Uh, I actually used GitLab for it. We have, uh... Or we have a merge request feature in GitLab where you can get comments, people can make change suggestions. It's essentially like doing it in Google Docs. Each time, I would refine it until that group understood it, and then I would move out from there. If this is an individual PM, maybe you start with your design and engineering manager or your, your boss, your boss probably, then your immediate peers, then the broader team, then the company.

    8. HSHarry Stebbings20:49

       Which stage was the most common to put a blocker on it?

    9. SWScott Williamson20:53

       Exec team.

    10. HSHarry Stebbings20:55

        (laughs) Do you listen to them?

    11. SWScott Williamson20:58

        Uh. You know, and, and that may not be universally true. Um, but, uh, in my own experience, the exec team's where it gets, gets more difficult because that's where you really need to make cross-company trade-offs. You say... Uh, a good example at SendGrid, we, we stayed pretty true to the mid-market as our target ideal customer profile. We resisted going up to enterprise. That was controversial. Uh, there were... Almost every sales leaders at the company wanted us to invest in more to go up, to do the tippy-top complex shit that, you know, the bigger brands wanted, but we more or less resisted that over the years, and I think that was to our benefit. We kept the product experience really clean, very self-serve first. I think that was the heart of why that company ended up doing well. But, you know, you have a strategy review and they don't see that you're doing the stuff that the top 10 want, and it's complicated.

    12. HSHarry Stebbings21:59

        (laughs) It absolutely is, and then you've also got misaligned incentives in some ways.

    13. SWScott Williamson22:06

        Yeah.

    14. HSHarry Stebbings22:06

        Sales comp is often easier- not easier, but larger if you go after heavy enterprise. Going after a smaller contract is different. I totally see that. Okay. And so you have those different components. Most often, it gets blocked at the exec level. When should founders start doing this? Is that when you're post-100 people? 'Cause there's quite a few layers there. Like, at some point, it's just like one room, one office.

    15. SWScott Williamson22:31

        Right.

    16. HSHarry Stebbings22:31

        When does it become layered?

    17. SWScott Williamson22:32

        Even if you're m- more than 10 people, this can be helpful. Uh, I would say maybe when you're not all in the same room. When you start adding new people at some clip. Because new people just don't have that context, they don't have the tribal knowledge. And when you add more nodes on, the quicker you can get them wrapped around who we're going after, what we're gonna do, what we're not gonna do, what matters most, what business outcomes are we trying to drive, you eliminate a lot of extraneous conversations that can otherwise slow the whole place down. So I think it can be useful very early.

    18. HSHarry Stebbings23:09

        I think it absolutely can when I listen to you there, especially post-10. Question, when do you do six pages versus one page?

    19. SWScott Williamson23:16

        I think a good strat can be as short as two pages. So, there's no need to fill up the six. I think any... I think the reason why Amazon set the six-page limit is because in one meeting on one topic, any more than six pages is just too much. Uh, but make it as short as you can. Uh, the one I did at GitLab for the whole product was probably a couple pages, two, two, maybe three. It wasn't that long. It can be quite concise. That's on the strategy. When I mentioned the one-pager earlier, that was on a particular product concept.

    20. HSHarry Stebbings23:52

        Hmm.

    21. SWScott Williamson23:53

        I called it an opportunity canvas, and this was used early in the process. The owner of it was the product manager. The point of it was to help them think holistically about something they wanted to take on. You don't do this for all projects, you don't do it for iterative improvements, you don't do it for tech debt. But for something that's big that's gonna take weeks or months of engineering time, I think it's very smart to do something like this. And it asks them to go out and talk to 5 to 10 ideal, you know, people in the target user profile.... and interview them about the problem that they have. And then come back and show me an opportunity canvas and it tells me who's the target user, what pain point do they experience, what are the workarounds, what would the upside be to us to do this, what would the first thing you would do to build against this be, what are your alternatives, what are your risks, and what's your KPI? There were a couple other things but it could all fit in one page and if you'd done your homework you can fill it out in 15 minutes. And what that does is it forces the PM to think about a bunch of different angles on an idea. The problem with ideas is, is they can sound very good from one perspective, like "Customer X asked for it." Or, "Wow, this sounds cool," or, "Oh, if we did that we could up-tier them into the next tier." There, there's always some reason why an idea sounds good on the surface. But sometimes when you line these things up it's like, "Ah, shit, our target user that really wants this, we don't actually talk to, we don't market to." Or, "Hmm, there're only three customers that want this and yes, it's cute for them but it's not broad enough." It forces that conversation and it's a good time to either redirect or kill or pause, 'cause you haven't coded anything yet, you haven't wasted the team's time yet so I just spend a lot of time kind of at this opportunity canvas problem validation phase to make sure that the things we are gonna push down the cycle are well-conceived.

14. 26:07 – 28:32

    Managing PM Performance

    1. SWScott Williamson26:07

    2. HSHarry Stebbings26:07

       Tell me, Scott, a- as a product leader you have, uh, hopefully a team that has. ... is full of ideas and does a lot of opportunity canvases. How do you ensure focus and velocity, which is speed in a given direction that's hopefully right, but also not ensure that a team doesn't feel crushed and stifled of innovation and ideas?

    3. SWScott Williamson26:28

       It's ... it's a tricky balance because this sounds a little heavy, right? PMs always have two tracks going, at least that's how we ran it in Syngrid and GitLab. There's a validation track where you're doing your homework on the things you wanna pump into engineering, and then you have a build track. The build track's always moving, you're going sprint to sprint to sprint. Every place I've ever been there's been an enormous backlog for engineering, so it's. In my opinion, if it's well-run, doing a proper validation shouldn't slow down engineering, they have more than enough to do. This is about making sure that the next thing you tee up for them is well-conceived, but to my far earlier point, PMs need to have their time available to be doing this kind of validation work. So it shouldn't slow down engineering, it should speed 'em up because there's less back and forth between PMs and designers and engineers if the project is well-conceived. Where you get a lot of back and forth and slowdown is when you're like, "Are we building for that or that? Who is this for? Who cares about what?" If that shit's unclear, the product development process can get really chaotic. So in my experience it's sped up engineering, but it puts a lot of burden on the PM and the-

    4. HSHarry Stebbings27:46

       How, how do you know if you have a chaotic product development process? I think a lot of founders do, but it may not be obvious. What are the signs that it is a chaotic product development process?

    5. SWScott Williamson27:57

       Tons of back and forth, engineers that don't get it, they're like, "Why are we doing this? I don't understand why this thing is more important than that thing." Um, when you're switching a lot, like, "Oh, well, we're week into the sprint but we got redirected to this thing that's totally different and now I gotta switch." So if there's a lot of context switching, there's a lot of confusion about why, and there's a lot of back and forth between the engineers and whoever asked them to do this thing, it probably isn't a well-conceived backlog

15. 28:32 – 30:33

    Conducting Effective Case Studies

    1. SWScott Williamson28:32

       in the first place.

    2. HSHarry Stebbings28:33

       Okay. We're gonna bring this back-

    3. SWScott Williamson28:36

       (laughs)

    4. HSHarry Stebbings28:36

       ... to also the hiring process, 'cause it's kind of a line but one of the other core elements you said was the case study element. And so kind of thinking about that, how do I do effective case studies in the product interview process?

    5. SWScott Williamson28:47

       I like to pose a non-technical scenario that they haven't worked in before, and actually isn't what we do either, because I don't want them to, A, rely on the jargon that they learned in their last job. And I don't want to also sort of penalize them if we're asking them about an area that I know really well and, "Boy, they should've seen this." Uh, so ask sort of a non-technical, semi-unrelated case to ask them how they would solve a problem.

    6. HSHarry Stebbings29:19

       What would be an example of that, sorry? So if you were at Syngridge, is, is it like, um, you're a PM at Uber and solve this problem? Like, what, what can... Sorry.

    7. SWScott Williamson29:30

       Yeah, yeah. You could. I mean, you can. I'm always sort of borderline embarrassed about this example but I've used it a ton ............................ If you ask product managers in Syngrid or GitLab they probably chuckle about having to have gone through this. I, I, I ask them to pretend they are a product manager at a foods company and they own the milk product line and there's been a problem with the production line, and they're losing X per day and they sort of set up this scenario, and the general manager's asked you to dig in and figure out what to do. So, what do you do? And it's a bizarre problem statement, but you learn a lot from how they handle it. Like, do they start from first principles? Do they have sort of a methodical way of working through a fresh problem? Do they start with the customer or do they just start making shit up? Do they ask good questions to unpack the scenario? These are all signs of someone who thinks systematically and ultimately that's what that case is for, is to test systems' thinking.

16. 30:33 – 33:21

    Common Hiring Mistakes for PMs

    1. HSHarry Stebbings30:34

       Hmm. When it- w- we asked about kind of why does, um, the six pages get called in the process. When you think about, like, candidates going through the, like, PM process, why do they most often fail?

    2. SWScott Williamson30:44

       Uh, when I interview a candidate, I like to... I, I set it up. I say, "Tell me about the product that is the most relevant to what we do here, and I'm gonna ask you a bunch of questions about it." And so I try to go a few levels deep on what they've done.

    3. HSHarry Stebbings31:01

       Does it matter if they haven't done anything similar? And so if I'm joining SendGrid and I used to work at Snap, seemingly uncorrelated-

    4. SWScott Williamson31:09

       Uh-

    5. HSHarry Stebbings31:09

       ... does that matter?

    6. SWScott Williamson31:11

       Not really. I... Look, it can matter. I mean, there, there, there are certain roles where you need a certain level of technical expertise. That's a fact. Let's say I'm hiring for a billing product manager. It... I'd probably want someone who's been around billing before, so you need to make sure that they've had enough domain experience to survive. But mostly what I'm testing for is how you do product and how you think, and that's relatively domain-agnostic. I tend not to hire for domain if I don't have to, and you can test those things from a Snap PM just fine.

    7. HSHarry Stebbings31:50

       Yeah. I totally get you. Sorry.

    8. SWScott Williamson31:52

       Um, so how do they fail? The examples that they give don't indicate to me that they took orders. They didn't use their own judgment from inputs that they got, so either they didn't go out and get good inputs, or B, they didn't or weren't able to turn those into insights. What good PMs can do is take inputs and derive really good insights. And so I'll ask questions like, "Tell me about a time where you were doing discovery with customers and learned something that's surprising that caused you to change course." Or, "Tell me about a time where you were looking at product usage data and found something that was counter to what you believed, and what'd you do about it?" If somebody has spent enough time interviewing and enough time sifting through product usage data, they should have plenty of examples like that. If they haven't and they were just making shit up, that kind of thing turns up. Um, so that, that's one way they fail. The depth of their examples doesn't demonstrate they actually, uh, worked in the way we want them to work. Two, there's think big/think small. Maybe they can't communicate clearly in writing or, or verbally or have trouble iterating to a good answer. And then three, the case study. Uh, a lot of people think very haphazardly about fresh problem 'cause they just... S- they don't have a great framework for

17. 33:21 – 44:55

    Managing Performance & Promotions

    1. SWScott Williamson33:21

       it.

    2. HSHarry Stebbings33:22

       Can I ask, you know, when we think about hiring in a lot of roles, uh, you know, I... W- we have a m- obviously media team here. We're hiring for social media often, is one of the roles we hire for. It's very clear when someone says, "Well, on Instagram, I caused a 38 a- percent uplift in conversion. On TikTok, I caused this percent." Data-centricity tied to their role is a core signal of A, A star candidate early.

    3. SWScott Williamson33:46

       Yep.

    4. HSHarry Stebbings33:46

       Are there... Is that the same for product? And what are the signals that are like, "Ah, Harry's got it from that answer"?

    5. SWScott Williamson33:54

       Yeah, I think someone who, um, can clearly connect the work they were doing to the outcome they were trying to drive, and can describe, like, "Okay, what did I learn from customers that led me to believe that they would take this action if X were there? How did I instrument the product to know whether the intended effect was there or not? And then how did I manage to that and iterate from there?" Like, tell me a story about how you went from early stage to later stage, and what moves did you make along the way? 'Cause it's, it's never about shipping one thing. It's about shipping and learning and shipping and learning, and it's, it's, it's a constant journey, and you have to have good habits all along the way.

    6. HSHarry Stebbings34:42

       Speaking of shipping and learning, we're gonna get to product reviews, but we are always evolving our hiring approach ourselves. Uh, I've made many mistakes hiring. When you think back, what's been your biggest hiring mistakes, and what did you learn from them, and how did it change how you think about hiring?

    7. SWScott Williamson35:00

       Well, I think way back, I, I didn't have nearly as much conviction on, A, what a good PM looked like. I didn't have a rubric in my head like I do now, and I hadn't made the connection on systems thinking and that being super important for PMs. So, I just wasn't interviewing for the right stuff is where the early stage ones came from.

    8. HSHarry Stebbings35:19

       Is that the same for founders today? When you look at the founders that you work with, is that the same as the mistakes that they make when hiring for product teams?

    9. SWScott Williamson35:26

       Yeah, I mean, they don't know... They, most of them haven't been a product manager. They have no idea what this role is about, uh, so they don't know what to look for. They don't know how to grade it, and so they go off of pedigree. "Oh, they were at Google." Or B, "They know the lingo, you know? They talked about validation, so they must be good at it." Um, because, you know, it's like... M- it's natural. I, I get it. Um, I, I sucked at interviewing for this at first too. So, the more that you can do as a founder to get clear on what skills you need out of that PM and be really intentional about testing for it, even if you don't know the function well, you'll be better off.

    10. HSHarry Stebbings36:05

        Say we hire this person. We've done a great job, actually. And we hire this person, and we're excited about them joining. Onboarding is universally done terribly.

    11. SWScott Williamson36:14

        (laughs)

    12. HSHarry Stebbings36:16

        (laughs) How, how do you onboard PMs effectively, Scott?

    13. SWScott Williamson36:21

        Especially in startups where everybody is busy, uh, this is often a disaster. Um, first, especially in early stage scenarios, the founder has to be crystal clear with the incoming product person about what they want to own as the founder and what they want this product person to own. Oftentimes, this is murky.And the PM comes in, or the product leader comes in and the, the founder decides, "Ah, I actually still wanna own prioritization." (laughs) But the product person came in thinking they would own that. So do you wanna own vision? Yes or no? Do you wanna own strategy? Yes or no? Do you wanna own prioritization? Yes or no? Do you wanna own hiring? Yes or no? Be crystal clear about those and communicate that in the hiring process and, and document it when someone comes in so that that's clear. They know what their field they're supposed to play on. And then two, I like to be very prescriptive about what I expect. Okay, in week one, you should meet these people. Here's a link to all the docs you should read. Like in the first two weeks, you should be helping them gain context very fast, like roll out the red carpet. Here's who to meet, here's what to read, here's all the context you need. In weeks three and four, talk to customers, you know, I wanna see 10 customer interviews or whatever. By the end of month one, you should be able to give a demo. Uh, what these deliverables are, company specific, but help them get context, tell them your expectations on what they should own when. Another good example is maybe you're the founder and you still own all the Scrum proceedings. When do I want you to start leading these things? After month one, month two? Like set their expectations and then along the way, you can gauge whether they're gonna be ready on time.

    14. HSHarry Stebbings38:14

        Scott, how fast do you know if someone's bad?

    15. SWScott Williamson38:18

        Well, uh, I think if they're really bad, you know within the first week. If they're maybe good but not good enough, you're gonna know within the first quarter.

    16. HSHarry Stebbings38:30

        Ha- have you ever had someone being really bad? And if so, what did you not see? How did they get through that process?

    17. SWScott Williamson38:36

        When I got better at hiring, there were relatively few of these where it was just, you know, they're, they're bailing on week one. (laughs) It was just-

    18. HSHarry Stebbings38:43

        Yeah.

    19. SWScott Williamson38:43

        ... a total disaster, 'cause we got better for screening, but we did have a fair number that just didn't make a cut at, at month three. You find is A, they don't take ownership or don't want to. Either they don't want to or can't. By month three, you should really see them start leaning in, have a strong point of view, take ownership, have some conviction and priority, and they're just not there for whatever reason. Maybe they didn't have the base skills to form a point of view. Maybe they're a little timid about creating, c- communicating a point of view. Maybe they don't collaborate well. These things can be a little harder to test for and show up in, within the first few months.

    20. HSHarry Stebbings39:24

        Once in those first few months, managing performance, uh, in those first few months, but kind of more broadly, to be fair, I- is so important. How do you think about managing PM performance? We said it earlier, but how do you actually do that, and is there a framework or structure that's effective in doing so?

    21. SWScott Williamson39:41

        I have this thing called a career development framework. I mentioned those four buckets, so validation, build, business, and communication. And then there is a breakdown for PM, senior PM, principal PM, and it tries to outline with as much specificity as possible what behavior and outcome expectations are at each level for each bucket. And I would have conversations with my directs and I would ask any other people leaders to do the same, to have a check-in every two to three months on that. What I would do is very simple. I'd create a new line below their level and I would write down what did I see that was either really good or constructive feedback on each of these four buckets, and then I would also tell them where I think they stood at large against that skillset. Do they need development? Do they meet my expectations? Or do they exceed my expectations? And if you check in on this stuff every couple months, they get nuggets of really actionable feedback. They know where they stand with you, and they have something, they have something or some things to work on over the next two to three months to get better. And then when the review cycle comes up at the end of the year, there's no surprise where they stand. Uh, promotion, firing conversations are all much easier because they know where they stand with you. And it takes some work. I would set prep calls in my calendar. Like, okay, a week before my interview with X, I would have a little half hour prep call, or prep meeting, where I would fill this thing out, gather my thoughts. It takes a little bit of energy to provide good feedback. And then I would have an extra half an hour on top of our normal one-on-one where we would just talk about career shit we wouldn't talk about day-to-day. And that, I found that worked really well if you're consistent.

    22. HSHarry Stebbings41:45

        Okay. Talking about kind of career shit and promotion in particular, what should PMs focus on if they really wanna get promoted as a PM?

    23. SWScott Williamson41:53

        If you have the benefit of something like what I just talked about, then, you know, try to exceed expectations on each of these, each of the areas you're being graded on. In the absence of that, or even preceding that, I think A, you should have the strongest point of view of anybody in the company about the ideal customer for your area. Like if you're the Op- an ops PM at GitLab, you should know what those platform engineers want, how they work, what makes 'em tick, what their problems are.

    24. HSHarry Stebbings42:26

        Is that, is that a way to get promoted, though? If we think about, like, I'm in GitLab. How does having a strong opinion on the ICP help me get noticed by leadership and get a promotion?

    25. SWScott Williamson42:36

        Uh, if you really understand them, then you're gonna tee up the right work which is gonna drive results. Ultimately, you wanna drive results, but how do you get there? I think the building block is having a ton of...... perspective on the target user and what they need to build the right stuff for them. And if you demonstrate that you know the target user, sales is going to trust you, marketing's going to come for you, to you, to make sure that your thing is marketed the right way. Engineering's going to believe you and trust you and not fight you on every decision you make. It just, everything flows from that. So that's the very first thing I would do. And then from there, you're trying to prove business impact. So make sure you have a KPI that leadership cares about that maps to the work that you report on regularly and openly and honestly.

    26. HSHarry Stebbings43:28

        My god, it's a lot of work being a product leader, isn't it?

    27. SWScott Williamson43:30

        (laughs)

    28. HSHarry Stebbings43:30

        (laughs) Yeah, it really is. I'm listening to this like prep call before the meeting I'm like, "Oh, fuck! This sounds awful."

    29. SWScott Williamson43:37

        (laughs)

    30. HSHarry Stebbings43:37

        (laughs) No offense. (laughs) .
18. 44:55 – 48:54

    Product Review Cycle

    1. SWScott Williamson44:55

       KPIs that they were managing to. And the rhythm of that was I would ask them, "Okay, what happened in the numbers? What's going on? What'd you do last month to drive your target metric? And what are you gonna do next month?" It was sort of this constant check-in to make sure that their priorities and actions at least passed a, you know, passed the test that they were reasonably aligned with the target metric they were trying to measure. So that was sort of high level, "How's this whole thing doing?" Then you also have work in progress. So you're the ops PM, and you have this idea that we need a much better incident management feature set. That's where I would get into reviews on this in progress work, and that's where that opportunity canvas then comes in. "Okay, ops PM, show me the canvas for the problem we're solving with incident management." If the concept looks good, then you sort of green light that, and then they move to the next phase, which is building a prototype, usually with design. And then we would go back and review the prototype as a solution. "Okay, PM, you had these 10 customers. They wanted this. Does this design really solve that for 'em?"

    2. HSHarry Stebbings46:13

       Can I just jump in and ask, just so we know, for this product review, who's in the room and who set the agenda? Is it just the people working on it and the leader? Is it the wider product team? Who sets the agenda?

    3. SWScott Williamson46:25

       I think for the opportunity canvas and the solution, let's call it the prototype review, the PM and the designer who are doing the work, the product leader or leaders. For me, it was me, the design leader. We, we had a VP of design at both Synchro and GitLab. The two of us were in there, plus the PM and the designer and anybody else they wanted to invite, and that's sometimes met the engineering manager. Usually a room of four or five. And that's sort, sort of on this conceptual and pre-engineering phase.

    4. HSHarry Stebbings47:00

       Can I just jump in and ask, sorry, I'm too intrigued, you obviously worked at GitLab remote. A lot of people say that w- in terms of product reviews, being remote enables a lot more broad participation because people can obviously be kind of spectators, so to speak, without being-

    5. SWScott Williamson47:14

       Yep.

    6. HSHarry Stebbings47:14

       ... a presence in the room. H- how do you advise remote versus non-remote when it comes to product reviews and wider participation?

    7. SWScott Williamson47:22

       I think you can open it up to more... I, I, I was always of the mind that the more, the merrier, but I wanted to be careful about how many voices were in the room 'cause it... Y- these are usually fairly quick meetings, you know, maybe 30 m- 30 minutes to an hour max. You gotta be quick in getting to the point and getting to the conclusions. At GitLab, we recorded all of them and we posted them, and anybody who wanted to watch them could. So we were very transparent about all these meetings. You could see them all as an in- as an internal employee.

    8. HSHarry Stebbings47:55

       What happens post-product review? Like, how do you ensure that the learnings are codified, shared, and then enacted?

    9. SWScott Williamson48:02

       I think that's where these monthly reviews came in. So let's just say we agreed that they should move on with the project and we liked the concept and we liked the, kind of the design prototype. Then it gets fed into the development cycle and then, as they're talking about their KPI review, they can reflect on what we did last month, what we're gonna do next month. And then you start to see how this thing's getting iterated on as it projects out towards the ultimate customer value. So that's why I separated them out a little bit 'cause the first two are more about making sure this is something we wanna take on and is a good investment, and then the other is more like managing the ongoing priorities

    10. NANarrator48:46

        Ah.

    11. SWScott Williamson48:46

        ... as it relates to building. That make sense?

    12. HSHarry Stebbings48:48

        It does, totally. I, I'm just thinking like when we think about managing those priorities, how do you as a product

19. 48:54 – 49:48

    Codifying & Sharing Learnings

    1. HSHarry Stebbings48:54

       leader determine between resolving left technical debt versus pursuing net new opportunities of revenue generation?

    2. SWScott Williamson49:03

       I think this depends on the stage, broadly speaking.If you're very early, you're probably heavy in new feature build-up. If you're more mature, you've probably got a lot of surface area that already exists and you might wanna allocate a heavier percentage to iterative improvements of things that have already shift and tech debt. At SendGrid, we had a spli- a recommended split, and granted this was when we were sort of 100 million-ish, of 60/30/10, 60 on net new, 30 on iterative improvements, 10 on tech debt. It was totally fungible. Teams could recommend a different split, but in the absence of a better idea, that was our recommendation on how to allocate your efforts.

20. 49:48 – 51:11

    Priorities: Technical Debt vs. Revenue Generation

    1. SWScott Williamson49:49

       If you short iterative improvements or you short tech debt, it will bite you. And so I think having a healthy amount of ongoing improvement to the current experience and a healthy amount of ability for engineers to burn down tech debt produces, uh, reduces the risk of these big pile-ups that sometimes companies get in.

    2. HSHarry Stebbings50:11

       Scott, you've been a product leader for many years now at some of the best. Before we do a quick-fire, just with the theme of reflection, what do you know now that you could tell yourself entering the first product leadership position you took?

    3. SWScott Williamson50:25

       (laughs) Oh my god, there'd be a lot.

    4. HSHarry Stebbings50:27

       You can call yourself the night before that first job as a product leader and say, "Buddy, you should know this."

    5. SWScott Williamson50:35

       I think it would be s- really start with the problem and start with the customer and do a ton of customer discovery. My first PM role was in a place, it was kind of one of these enterprise factories that, that tended to do what large companies asked them to do. And, uh, and I get it, that was where the incentives were aligned, but ultimately I don't think that product was everything it could have been if I'd been more focused on starting with the problem, starting with the

21. 51:11 – 53:39

    Reflection on First Product Leader Position

    1. SWScott Williamson51:11

       customer, so I, I wish I had had that epiphany earlier.

    2. HSHarry Stebbings51:15

       Do you worry that we're going back to that world now with the centralization of budgets back to CFOs, with CFOs being tighter on spend, with bottoms-up being more constrained?

    3. SWScott Williamson51:26

       I think that's, uh, a, a reasonable hypothesis. You know, uh, there are fewer engineers, fewer PMs, fewer designers, people are being asked to do more with less. I would guess the average PM probably has less time to get out of the building, and there's more focus on revenue. And if you're a product manager and you're trying to drive a longer-term vision that might have a payoff in a year or two or three, versus the sales team coming and saying, "Hey, we gotta make the number this quarter, I need this for company X," it's pretty hard to push back on that. And so I can imagine that a lot of PMs are, are facing that and might be shifting more towards doing really tactical short-term stuff.

    4. HSHarry Stebbings52:14

       I wanna move into a quick-fire, Scott, I could talk to you all day. I've loved this. The, the best shows for me are where it's bluntly as granular and actionable as possible, but then I would add one thing which is really quite specific, when it's quite numbered. I don't, uh, people don't know this, but when you number points they instantly become, I think it's 64% more memorable because it structures it in someone's mind.

    5. SWScott Williamson52:37

       Yeah.

    6. HSHarry Stebbings52:38

       Uh, and so this has been fantastic. Uh, I wanna move into a quick-fire. So I'm gonna say a short statement, you give me your immediate thoughts. Does that sound okay?

    7. SWScott Williamson52:45

       Sounds good.

    8. HSHarry Stebbings52:46

       Okay. So tell me, when do we listen to users, customers, versus when do we actually respectfully continue as planned on product roadmap?

    9. SWScott Williamson52:56

       Broadly speaking, listen to customers about their problems and generally ignore their recommendations around solution because they may not... Building exactly what they want may not be the most elegant way to solve the problem, so that- that's generally a rule of thumb.

    10. HSHarry Stebbings53:15

        What's the biggest mistake founders make when hiring product teams?

    11. SWScott Williamson53:19

        I think it's relying on logo and, you know, pedigree versus the actual accomplishments, and I also think there's, uh, in a related fashion, hiring people who don't actually wanna be at the

22. 53:39 – 59:25

    Quick-Fire Round

    1. SWScott Williamson53:39

       stage you are. Early s- if early stage founders try to hire a, an, maybe an early product leader and they hire somebody from maybe a company that's doing 100 million or a billion, make sure they wanna get back into that hands-on, hustle, wear a lot of hats mode, uh, 'cause I see a lot of sort of failed entry 'cause it sounds glamorous to be the first head of but these people actually don't wanna work that way.

    2. HSHarry Stebbings54:07

       My favorite is, like, founding product manager, founding engineer. What the fuck did you find? No, you didn't find shit. The founder founded the company, do you know what I mean? It's like, fuck.

    3. SWScott Williamson54:17

       Yeah, yeah, the, you know, early stage there's a lot of discovery, there's a lot of f- creativity, you're, you're more on the art mode versus science then you have to wanna be there, you, that, that early discovery, ear- taking product from zero or a small number to a bigger number is a much different thought exercise.

    4. HSHarry Stebbings54:37

       What function has the most friction with product and how do you as a leader minimize it?

    5. SWScott Williamson54:43

       It's a tie between engineering and sales depending on the orientation of the company. Some companies are very engineering-led, some are very sales-led. When those are, when the scales are really tipped one way or the other, they end up tending to want to do the priority work, they tend to want PMs to just be order-takers and do what they think. If you're a good PM and you wanna run the right, process the right way, that can create a ton of friction.If they don't really understand why your direction is better than theirs.

    6. HSHarry Stebbings55:21

       Scott, does AI change product teams much?

    7. SWScott Williamson55:25

       It will. It probably has to some degree. Uh, it, it, if nothing else in terms of the projects they're being asked to work on. So A, they're gonna have to understand this domain, they're gonna have to get familiar with LLNs, they're gonna have to learn how to prompt, they're gonna have to learn how to create maybe more of a chat experience versus a typical UI experience. So the, the product, the, the end result for customers is going to change. Two, you'll start to be able to use tools from AI to automate some of this stuff. You know, I mentioned product usage data and customer insights. I could imagine AI will do a nice job of summarizing that for you so you don't have to maybe incur as much brain damage with the input and synthesis and get some help on that. Uh, so PMs will, will have me- more help in synthesizing tons of inputs, and then ultimately I think it might change the role. Like right now, there's a pretty clear division between what PMs do, what designers do, and what engineering engineers do. The PMs decide what to do, designers decide h- how, how it's going to, like what the user experience is and design and engineering builds it, codes it. I can imagine those lines blurring if you get into a world where code assistants can do some prototyping, where code assistants can generate 80% of the code, and then it becomes more about how do you prompt the thing to come up with the right user experience? How do you... Again, I think, I think PM still has a role, because you're still gonna need to decide who we're going after, what problems we're gonna solve, all of that, but the lines may then blur. I can imagine this triple role down the line where they're doing PM design and engineering with the help of AI.

    8. HSHarry Stebbings57:26

       Tell me, what would you most like to change about the world of product?

    9. SWScott Williamson57:28

       It's well-worn advice at this time, but it's the same advice I would have given myself way back when: talk to customers more. You know, I feel like even though that's like the most obvious thing in product, I'm guessing 90% of PMs don't do enough of it and it shows up in the number of failed products and failed projects. And so I, I wish PMs would just start there and then fill in the rest of it.

    10. HSHarry Stebbings57:55

        What recent company product strategy have you been most impressed by?

    11. SWScott Williamson58:00

        Well, at big scale, Amazon's amazing. Uh, I've learned a ton from the way they do things and if you haven't read Working Backwards, I recommend it. For a more recent smaller company example, uh, there's a company called The Browser Company. They're part of-

    12. HSHarry Stebbings58:17

        Yeah, Josh.

    13. SWScott Williamson58:18

        Yeah, yeah.

    14. HSHarry Stebbings58:18

        Yeah.

    15. SWScott Williamson58:19

        Great guy. Very charismatic dude. And they have a browser called Arc, which is a crowded space and a tough, you know, playing with giants there, but I've heard a ton of buzz about them and I've used, I use it myself, I'm on an Arc browser right now. Uh, lots of thoughtful UX touches and they've made it a little more fun to go browse the web and I think they have an ambitious vision of how one might access the internet down the line. Uh, for his, the, for example, they're u- using AI in a clever way, they're making it very easy to intere- interact with chats and petite through their browser. Uh, so they've done a really nice job of trying to create some differentiation through great product and user experience.

    16. HSHarry Stebbings59:06

        I'm looking now actually, I got introduced to him through a mutual friend, uh, he's in Paris now. There we go. Um, Scott, listen, I've loved doing this. This has been so much fun.

    17. SWScott Williamson59:17

        (laughs) Yeah.

    18. HSHarry Stebbings59:17

        Thank you so much for putting up with my meandering questions.

    19. SWScott Williamson59:20

        (laughs)

    20. HSHarry Stebbings59:20

        And you've been amazing.

    21. SWScott Williamson59:22

        Well, my pleasure. It was a lot of fun. Thanks for having me here.

Episode duration: 59:25