The Exchanges

Q Okay, I mean, listen, there's, there's so much I want to unpack there, so that's really helpful. I, when I write on my hand, it's good sign. 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?

A 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 valid, I call it validation. So customer interviewing, product usage data, kind of like gathering insights. Two is build, which is how well do you work with engineering? How 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 the 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 execs. 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's how I break it all down.

AI assessment note: “there's four buckets for an individual PM. One is around valid, I call it validation.”

Q Is writing a core skill of PMs? I remember I had Kevin Napaka on from Twilio, uh, and segment, but he said, like, writing is the most important skill. Do you agree? And why so?

A I, I tend to agree, especially at a place like GitLab where it was all remote. We did, PMs did very little synchronous work, and so if you can't rely on sort of verbal agility to get things done, you 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 driving alignment. Uh, there are 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, it's like a two to six pager. I think Kevin might've mentioned this. It's sort of borrowing from Amazon, this concept of, uh, the six pager sort of a longer arc strategy doc. Those are two that I feel like you have to write down.

AI assessment note: “I, I tend to agree, especially at a place like GitLab where it was all remote.”

Q 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?

A 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, it 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 overcomplicate what you ship. So this exercise tested a few things that 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 the written skill because 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 once.

AI assessment note: “We had, uh, what was called the think big, think small was the exercise.”

Q 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?

A 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 a 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, I actually used GitLab for it. We have, uh, 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.

AI assessment note: “We have, uh, we have a merge request feature in GitLab where you can Get comments.”

Q Ok, so decently repeatable product market fit. Now we know when we need to actually do it. Um, I think it's really freaking hard to find these great people, and so I do want to 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?

A 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 the clear the bar for the core competencies of PM, and I can get into what I think those are. An engineering manager interviewing for an hour or so, where are you testing for clearing the bar on the domain and the minimum level of technical knowledge they're going to 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 interview. If you have someone else in the org is very good at interviewing where you get into more like a case question.

AI assessment note: “Five interviews total. First one's a 30 minute recruiter screen”

Q Okay, I mean, listen, there's, there's so much I want to unpack there, so that's really helpful. I, when I write on my hand, it's good sign. 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?

A 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 valid, I call it validation. So customer interviewing, product usage data, kind of like gathering insights. Two is build, which is how well do you work with engineering? How 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 the 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 execs. 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's how I break it all down.

AI assessment note: “how I bucket it is, there's four buckets for an individual PM.”

Q 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?

A 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, it 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 overcomplicate what you ship. So this exercise tested a few things that 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 the written skill because 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 once.

AI assessment note: “We had, uh, what was called the think big, think small was the exercise.”

Q 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?

A 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 a 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, I actually used GitLab for it. We have, uh, 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.

AI assessment note: “Each time I took comments, essentially, I actually used GitLab for it.”

Q 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. How, how do you onboard PMs effectively, Scott?

A 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, oh, I actually, Still want to own prioritization. But the product person came in thinking they would own that. So do you want to own vision? Yes or no. Do you want to own strategy? Yes or no. Do you want to own prioritization? Yes or no. Do you want to 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 contacts very fast. Like roll out the red carpet. Here's who to meet. Here's what to read. Here's all the contacts you need. In weeks three and four, talk to customers. You know, I want to see 10 customer interviews or whatever. By the end of month one, you should be able to give a demo.

AI assessment note: “I like to be very prescriptive about what I expect. Okay, in week one”

Q 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. Um, but I want to 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?

A Well, 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 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 oh three, sort of the nuclear winter of The 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 team, was 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, 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 amazing career in product leadership at Wiley, CAA, SendGrid, Twilio, and GitLab.

AI assessment note: “was finally able to kind of get in the door, get my first PM role”

Q We're going to talk about PM performance. First, I just want to 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?

A Well, I define the role as a hub function between the outside world, the market itself, the customers, the competitive moves, technology changes, and then the company. You 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 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 fives talking to customers and being out in the world. What that means is the work that they T for engineering is oftentimes very ill informed. Maybe based on instinct, or what the sales team told him to do, or what the CEO told him to do, or what customer, the five million dollar 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, ah, 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 busines…

AI assessment note: “they've changed in that they've given team PMs more time to be customer facing.”

Q What would be an example of that? Sorry. So if you were at Sandgrid, just, is it like, um, you're a PM at Uber, and Solve this problem.

A Yeah, you could. I mean, you can, I'm always sort of borderline embarrassed about this example, but I've used it a ton of talent. If you ask product managers in SendGrid or GitLab, they probably chuckle about having to have gone through this. I, I, I asked 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 it sort of set up this scenario. And the general managers 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 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.

AI assessment note: “I asked them to pretend they are a product manager at a foods company”

Q Once in those first few months, managing performance in those first few months, but kind of more broadly, to be fair, 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?

A I have this thing called a career development framework. I mentioned those four buckets. So validation, build, Business and communication. And then there's a breakdown for PM, senior PM, principal PM. And it tried 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 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 skill set. 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…

AI assessment note: “I have this thing called a career development framework. I mentioned those four buckets.”

Q I mean, god, yeah. You've spoken before also about, like, iterating and learning. I think one common feature of any product team or leadership role especially as well, though, is the product review cycle. Quite hard to know how to do a product review. Well, if you've never done one before, how do you do product reviews? Well, and what's been some big lessons in what works?

A If you're early, you might be able to combine all of this, but I tend to separate reviews that are about work in progress from reviews about the product or product area as a whole. As an example, this opportunity, let's say you're a product manager in the ops area of GitLab. I used to have a monthly KPI review with each area. So we had a dev monthly KPI review and sec monthly KPI review and ops monthly KPI review. This was more about the area as a whole. Each area had a target KPI or numerous 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 going to do next month? With sort of this constant check in to make sure that their priorities and actions At least past, uh, you know, past 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 have 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 your views on this in progress work. And that's where that opportunity canvas then comes in. Okay, OpsPM, show me the canvas for the problem we're solving with incident management. If the concept looks good, then you sort of gre…

AI assessment note: “I tend to separate reviews that are about work in progress from reviews about the product”

Q 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. How, how do you onboard PMs effectively, Scott?

A 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, oh, I actually, Still want to own prioritization. But the product person came in thinking they would own that. So do you want to own vision? Yes or no. Do you want to own strategy? Yes or no. Do you want to own prioritization? Yes or no. Do you want to 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 contacts very fast. Like roll out the red carpet. Here's who to meet. Here's what to read. Here's all the contacts you need. In weeks three and four, talk to customers. You know, I want to see 10 customer interviews or whatever. By the end of month one, you should be able to give a demo.

AI assessment note: “be crystal clear with the incoming product person about what they want to own”

Q Once in those first few months, managing performance in those first few months, but kind of more broadly, to be fair, 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?

A I have this thing called a career development framework. I mentioned those four buckets. So validation, build, Business and communication. And then there's a breakdown for PM, senior PM, principal PM. And it tried 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 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 skill set. 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…

AI assessment note: “I have this thing called a career development framework. I mentioned those four buckets.”

Q I think it absolutely can. When I listened to you there, especially post 10, Question. When do you do six pages versus one page?

A I think a good strap 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 pages 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. 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 going to 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 five 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, Candice. And it tells me, here'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 agains…

AI assessment note: “That's on the strategy. When I mentioned the one pager earlier, that was on a particular product concept.”

Q What would be an example of that? Sorry. So if you were at Sandgrid, just, is it like, um, you're a PM at Uber, and Solve this problem.

A Yeah, you could. I mean, you can, I'm always sort of borderline embarrassed about this example, but I've used it a ton of talent. If you ask product managers in SendGrid or GitLab, they probably chuckle about having to have gone through this. I, I, I asked 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 it sort of set up this scenario. And the general managers 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 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.

AI assessment note: “I asked them to pretend they are a product manager at a foods company”

Q I mean, god, yeah. You've spoken before also about, like, iterating and learning. I think one common feature of any product team or leadership role especially as well, though, is the product review cycle. Quite hard to know how to do a product review. Well, if you've never done one before, how do you do product reviews? Well, and what's been some big lessons in what works?

A If you're early, you might be able to combine all of this, but I tend to separate reviews that are about work in progress from reviews about the product or product area as a whole. As an example, this opportunity, let's say you're a product manager in the ops area of GitLab. I used to have a monthly KPI review with each area. So we had a dev monthly KPI review and sec monthly KPI review and ops monthly KPI review. This was more about the area as a whole. Each area had a target KPI or numerous 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 going to do next month? With sort of this constant check in to make sure that their priorities and actions At least past, uh, you know, past 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 have 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 your views on this in progress work. And that's where that opportunity canvas then comes in. Okay, OpsPM, show me the canvas for the problem we're solving with incident management. If the concept looks good, then you sort of gre…

AI assessment note: “I tend to separate reviews that are about work in progress from reviews about”

Q 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?

A I think that's, uh, 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 got to 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 facing that and might be shifting more towards doing really tactical short-term stuff.

AI assessment note: “I think that's, uh, a reasonable hypothesis.”

Q 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 and on the show that came out on Monday. What do you think?

A I think it depends on What, where you want to end up. If you want to 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 want to be a CPO, a VP, if you want to really connect the dots between the product as a function and 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, there may be a faster path to a really cool PM job.

AI assessment note: “I think it depends on What, where you want to end up.”

Q 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.

A 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 going to need to start adding nodes onto your PM machine. You're going to need to break up the product experience. You're going to need, be able to bring on individual PMs and designers and engineering managers to own pieces of it. And when you get to maybe, maybe when it's still three PMs, there's still not a big need for big structure 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 going to get this huge variance in performance. And so that's, that's generally how I think about that, that transmission.

AI assessment note: “Basically, it's when you've found repeatable product market fit.”

Q Is that the same for product? And what are the signals that are like, ah, Harry's got it from that answer?

A Yeah, I think someone who, um, can clearly connect the work they were doing to the outcome they were trying to drive, um, 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 add 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? Because 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.

AI assessment note: “Yeah, I think someone who, um, can clearly connect the work”

Q 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.

A Yeah. I mean, they don't know that 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 it must be good at it. Um, because you know, it's like, it's natural. I get it. Um, 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.

AI assessment note: “Yeah. I mean, they don't know that most of them haven't been a product manager.”

Q 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?

A If you really understand them, Then you're going to tee up the right work, which is going to drive results. Ultimately you want to 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 are going to trust you. Marketing is going to come for you to you to make sure that your thing is marketed the right way. Engineering is 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.

AI assessment note: “make sure you have a KPI that leadership cares about”

Q 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 and on the show that came out on Monday. What do you think?

A I think it depends on What, where you want to end up. If you want to 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 want to be a CPO, a VP, if you want to really connect the dots between the product as a function and 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, there may be a faster path to a really cool PM job.

AI assessment note: “I think it depends on What, where you want to end up.”

Q Is that the same for product? And what are the signals that are like, ah, Harry's got it from that answer?

A Yeah, I think someone who, um, can clearly connect the work they were doing to the outcome they were trying to drive, um, 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 add 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? Because 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.

AI assessment note: “clearly connect the work they were doing to the outcome they were trying to drive”

Q 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?

A I think that's, uh, 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 got to 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 facing that and might be shifting more towards doing really tactical short-term stuff.

AI assessment note: “I think that's, uh, a reasonable hypothesis.”

Q 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.

A 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 going to need to start adding nodes onto your PM machine. You're going to need to break up the product experience. You're going to need, be able to bring on individual PMs and designers and engineering managers to own pieces of it. And when you get to maybe, maybe when it's still three PMs, there's still not a big need for big structure 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 going to get this huge variance in performance. And so that's, that's generally how I think about that, that transmission.

AI assessment note: “Basically, it's when you've found repeatable product market fit.”

Q We're going to talk about PM performance. First, I just want to 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?

A Well, I define the role as a hub function between the outside world, the market itself, the customers, the competitive moves, technology changes, and then the company. You 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 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 fives talking to customers and being out in the world. What that means is the work that they T for engineering is oftentimes very ill informed. Maybe based on instinct, or what the sales team told him to do, or what the CEO told him to do, or what customer, the five million dollar 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, ah, 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 busines…

AI assessment note: “I define the role as a hub function between the outside world”