The Exchanges

Q You've seen many different types of one pages. What is a great one pager, and where do most people go most wrong?

A Yeah, so I think if you're early in the process, um, which is probably where you're writing a one pager, um, the, the important thing to get right Is the problem definition, the why, right? Like what, what are we, what is the core insight that is the reason that we're even talking about this project? Um, and that's usually a user insight or a business insight, um, and or both. Um, and, and then anybody should be able to pick up that one pager and say, okay, I get where we're, I get why we're doing this. And I get the problem and it's, it's totally fine slash expected that the, the solution is probably pretty underexplored in those one pagers. I think people get wrong where the one pager is the solution description, not the problem statement.

AI assessment note: “I think people get wrong where the one pager is the solution description”

Q To what extent are you a gut driven Product leader or a data-driven product leader? If I were to put you in one camp.

A So if you were to put me on a continuum where zero is a hundred percent gut, zero is gut only, um, uh, a hundred is data only. Um, you'd probably put me at like 65, um, with one, with one caveat, which is data is not just in this, you know, Opendoor has this lesson for sure. Um, Not just, uh, you know, quantitative A-B tests, right? Uh, talking to users is data. Like that is real. If you talk to 10 customers and they tell you something, um, that is just as much data as I looked at a 150 data points and, you know, here was the insight. So 65, um, is, is the answer because true gut is just like, I just went with what I thought.

AI assessment note: “you'd probably put me at like 65”

Q to me before, the most important product skill set is simplification. Speaking of product expansion is simplification and finding the kernel of truth. This is a brilliant one is a sea of cacophony. I read this and I was like, my God, it's like Ernst Hemingway has fallen into my email. Um, So can you explain that to me of why a kernel of truth is a sea of cacophony?

A The product job is challenging, right? You have executive pressure. You have your independent thoughts. You have what customers are telling you. You have, uh, maybe scaled customer feedback from your CX team. You have maybe your sales team yelling at you with some other feature requests. It's like kind of, it's the prioritization exercise we talked about. And so you have all of these different pressures. And they often come in, in a variety of different forms, but oftentimes they come in the form of solutions. Hey, we need this feature. Hey, it would be great if the product did this. Hey, we lost a deal because of that, whatever. And I think the core of that product job is say, okay, there's all of this feedback, all of this noise, like what actually matters, what actually matters to, to, to user in the, um, uh, Uber example. For, for a second, there's a ton of things that make that product work or in the early days that made that product work. But at the end of the day, is there a car available? Can it get to me quickly, you know, within, within five minutes at a price that's reasonable. And if you can do that, all the other stuff, all the other product nuances, like kind of fade away. Right. And so that's the simplicity that matters for that product. And so trying to align and say like, okay, how do we prioritize everything that moves in one of those particular dimensions? Um…

AI assessment note: “there's all of this feedback, all of this noise, like what actually matters”

Q Final one before we do a quick fire. You said before about the benefits of staying for longer periods of time at one company for individuals. That is different to how most people operate in the valley. You are incredibly promiscuous as a group, uh, and jump from one AI company to another right now it would seem. Um, why do you believe in the benefits of staying at one?

A So as someone who's biased because I've spent, you know, two, two periods of longer stretches, uh, at companies, I think the reality is, uh, you just become more effective and therefore you can do more, um, more, more, more quickly. You have deeper relationships, you have deeper context on the company, you have deeper context on the customer base, and therefore you can be more effective. So if you're, if you're hopping every 18 months or two years and you assume, you know, It takes six months to ramp. Uh, you know, obviously that's very long to, to ramp to be any effective, but like to, to really deeply understand and gain context, like, and then at some point you're interviewing and thinking about your next thing, like you just don't have that much time to be effective. Obviously if it's the wrong fit, you should, you should move on, but I don't think a goal should be to move on every two years as you know, you can canonically read about, because I think you will just get more effective with time.

AI assessment note: “you just become more effective and therefore you can do more”

Q It doesn't harm it. Does it have to benefit it? A lot of people say if you're going to do a second product, it has to benefit the first. I don't think it,

A Has to benefit the first, but it has to take advantage of some competitive advantage that your company has, right? And so if you think about sort of a, a classic two by two matrix, um, where you have, you know, your customer set and your, uh, uh, competitive advantages, um, as a company, your core product is your existing customers with your existing product, uh, and competitive advantages. Uh, if you have a new customer set and a new set of Competitive advantages or capabilities. That's probably just a new company. And so you're either playing in, do we take our core capabilities and attach to a new customer set? Or do we take a new customer set and attach to our core capabilities? And I think you can play in either one of those, but in, in, in both cases, it doesn't have to make the core product better, but it does have to make the core experience for your customers better. And it does have to make the business obviously better.

AI assessment note: “it doesn't have to make the core product better”

Q You've seen many different types of one pages. What is a great one pager, and where do most people go most wrong?

A Yeah, so I think if you're early in the process, um, which is probably where you're writing a one pager, um, the, the important thing to get right Is the problem definition, the why, right? Like what, what are we, what is the core insight that is the reason that we're even talking about this project? Um, and that's usually a user insight or a business insight, um, and or both. Um, and, and then anybody should be able to pick up that one pager and say, okay, I get where we're, I get why we're doing this. And I get the problem and it's, it's totally fine slash expected that the, the solution is probably pretty underexplored in those one pagers. I think people get wrong where the one pager is the solution description, not the problem statement.

AI assessment note: “people get wrong where the one pager is the solution description, not the problem statement.”

Q one. You said there are kind of about good, good PMs being able to balance between the kind of needs of the business, but also the needs of the user. The role of the PM itself is changing so much. It would seem, especially in a world of AI. Can you talk to me about how the PM role changes in a pre versus a post AI world most significantly?

A The tools and means and mechanisms, I think, Will change, right? And so your, your primary tool or artifact of like writing a PRD versus building a quick demo may change as AI makes it easier and cheaper and, and, um, to, to, to build. And I think we will see that we'll see a collapsing or converging of the end product design triad. I think they will never be the same, but I think everything will be pulled in tighter. So I think all of that will change. I think what won't change is actually the core of the PM job, which is. You gotta go talk to users. You gotta go figure out what people want. You gotta go build it. And you gotta go build it in a way that makes sense for the business, right? And I think trying to actually figure out the creative part of like, okay, I've got some customers telling me this. I've got some customers telling me that. I've got my CX team telling me this. I've got my user interviews telling me this. I've got my data telling me that. What do I actually like build? What do I do? How do I make a good decision that That works. And how do I do it with velocity? How do I know type one from type two decisions? Like those core components, I actually don't think change in a pre or post AI world. I think what changes is your ability to communicate those ideas, your, your, your ability to do more upfront, your ability to do better user research because you can sh…

AI assessment note: “writing a PRD versus building a quick demo may change as AI makes it easier”

Q I'm series A style. So I've got investors and they want me to go from two million to eight million in a year. But I'm mindful that I've got growing technical debt. Do I focus on new product expansion and just let the technical debt ride it out? Or do I solve technical debt at the kind of, um, at the cost of maybe lower growth and lower new products?

A So I think when you're Early-ish stage like that, um, at, you know, seed series A doing two million, um, trying to get to eight million. Like you have to earn the right to exist in the future and paying down tech debt doesn't pay the bills. And so I, I think at that stage, it's probably a little bit early to start paying down technical debt. Now it, it, it a little bit depends. Are you in like a land grab? Uber was in a land grab for many, many years, right? It had to be first. It had to get riders. It had to get drivers, right? And so there's a very much a land grab competitive dynamic. That pushes a, you know, a certain philosophy and velocity. I think most early stage companies tend to be that where, um, you have to figure out if the thing that you're building in that two million ARR you may not know yet actually has value and people want it and people will pay for it. And so I think, um, early stage slowing down to, to, to pay down that debt is oftentimes a bit challenging.

AI assessment note: “it's probably a little bit early to start paying down technical debt”

Q your new product change, your product update, your redesign is shit versus Users are just not used to the transition or the change. I remember the iPhone losing its home button. Me and all of the people around me were like, this is a terrible swipe up. Now it's preposterous to think of that. How do you think about whether it's a bad decision or it's just user preferences changing?

A The iPhone one is particularly challenging because it's hardware. Um, and so hardware is hard. Um, uh, in software though, you know, I think you, you tend to have the ability To give people time. I think what, what you need to do is be a little bit more rigorous in how you think about, um, your metrics and your definition of success where, you know, the classic, okay, we're going to make a change. We're going to roll it out until we get stats. And then we're going to pick the winner and then that'll move forward. Like that may lead you in the wrong direction here, right? Because it may be, yeah, you have a novelty effect and, and the numbers decrease, or frankly, the novelty effect and the numbers increase. But it's temporary. And so if you think there's the risk of that change being just sort of like a, um, a change to, to, to customer's behavior, you may just set up your experiment differently and you say, okay, We're going to look at all the data, but we're not going to make a decision in the first two weeks. We have to have the, the fortitude, the guts, the, the, the gumption to say, we might see patterns in the behavior where behavior is slowly changing over time. And so we actually need to evaluate this experiment on month, you know, or week five through eight data, not week one through four data.

AI assessment note: “evaluate this experiment on month, you know, or week five through eight data”

Q What is the best work product? Again, I'm a founder, you're helping me. How do I test them?

A The best best is people you've worked with before, because that's a heck of a lot better than a one hour interview. Um, but I think, you know, I, I think it can either be show me a previous work product that you've worked on or some type of consistent case study of like, Hey, here's a somewhat depending on the, the, the role, uh, the seniority of the role, here's a somewhat ambiguous problem. Let's talk about how you would handle it or put together a doc or a deck or whatever on how you would handle it. And I think the, the, um, Important part here is it can't be so narrowly scoped because the tactics of the job you can learn, how to run a sprint, how to do prioritization, like that, that stuff you can learn. That's not what the test is. The test is the clarity of thought and, um, Uh, getting to that outcome.

AI assessment note: “show me a previous work product that you've worked on or some type of case study”

Q To what extent are you a gut driven Product leader or a data-driven product leader? If I were to put you in one camp.

A So if you were to put me on a continuum where zero is a hundred percent gut, zero is gut only, um, uh, a hundred is data only. Um, you'd probably put me at like 65, um, with one, with one caveat, which is data is not just in this, you know, Opendoor has this lesson for sure. Um, Not just, uh, you know, quantitative A-B tests, right? Uh, talking to users is data. Like that is real. If you talk to 10 customers and they tell you something, um, that is just as much data as I looked at a 150 data points and, you know, here was the insight. So 65, um, is, is the answer because true gut is just like, I just went with what I thought.

AI assessment note: “you'd probably put me at like 65”

Q You said about being biased there, because I said, which is your favorite. How do you think about managing momentum as a product leader? It's very difficult to do well.

A One of the things that I try to think about is, You might be unnatural if you feel like the team needs a momentum boost. That might be the team is newly formed. That might be you're coming off an extended break. Obviously some, some people, uh, take, take a break around the holidays. That could be you just had a difficult business outcome. Um, that could be a, a reduction in force or something like that. And so you're like, okay, we need to inject and infuse some positive energy and momentum here. Let's maybe unnaturally ship something that, yeah, maybe it's a little bit lower impact, but it's higher confidence, lower effort. So we can prioritize speed, And confidence of impact, so the team gets a little bit of, uh, um, Excitement moving forward and that compounds. And so you may have a slight unnatural prioritization that says, okay, we just came back from the holidays. Everyone's pumped about their plans. Yes. We just thought about the next year, but like let's ship something that matters in the next week.

AI assessment note: “let's maybe unnaturally ship something that, yeah, maybe it's a little bit lower impact”

Q to me before, the most important product skill set is simplification. Speaking of product expansion is simplification and finding the kernel of truth. This is a brilliant one is a sea of cacophony. I read this and I was like, my God, it's like Ernst Hemingway has fallen into my email. Um, So can you explain that to me of why a kernel of truth is a sea of cacophony?

A The product job is challenging, right? You have executive pressure. You have your independent thoughts. You have what customers are telling you. You have, uh, maybe scaled customer feedback from your CX team. You have maybe your sales team yelling at you with some other feature requests. It's like kind of, it's the prioritization exercise we talked about. And so you have all of these different pressures. And they often come in, in a variety of different forms, but oftentimes they come in the form of solutions. Hey, we need this feature. Hey, it would be great if the product did this. Hey, we lost a deal because of that, whatever. And I think the core of that product job is say, okay, there's all of this feedback, all of this noise, like what actually matters, what actually matters to, to, to user in the, um, uh, Uber example. For, for a second, there's a ton of things that make that product work or in the early days that made that product work. But at the end of the day, is there a car available? Can it get to me quickly, you know, within, within five minutes at a price that's reasonable. And if you can do that, all the other stuff, all the other product nuances, like kind of fade away. Right. And so that's the simplicity that matters for that product. And so trying to align and say like, okay, how do we prioritize everything that moves in one of those particular dimensions? Um…

AI assessment note: “there's all of this feedback, all of this noise, like what actually matters”

Q your new product change, your product update, your redesign is shit versus Users are just not used to the transition or the change. I remember the iPhone losing its home button. Me and all of the people around me were like, this is a terrible swipe up. Now it's preposterous to think of that. How do you think about whether it's a bad decision or it's just user preferences changing?

A The iPhone one is particularly challenging because it's hardware. Um, and so hardware is hard. Um, uh, in software though, you know, I think you, you tend to have the ability To give people time. I think what, what you need to do is be a little bit more rigorous in how you think about, um, your metrics and your definition of success where, you know, the classic, okay, we're going to make a change. We're going to roll it out until we get stats. And then we're going to pick the winner and then that'll move forward. Like that may lead you in the wrong direction here, right? Because it may be, yeah, you have a novelty effect and, and the numbers decrease, or frankly, the novelty effect and the numbers increase. But it's temporary. And so if you think there's the risk of that change being just sort of like a, um, a change to, to, to customer's behavior, you may just set up your experiment differently and you say, okay, We're going to look at all the data, but we're not going to make a decision in the first two weeks. We have to have the, the fortitude, the guts, the, the, the gumption to say, we might see patterns in the behavior where behavior is slowly changing over time. And so we actually need to evaluate this experiment on month, you know, or week five through eight data, not week one through four data.

AI assessment note: “evaluate this experiment on month, you know, or week five through eight data”

Q How do you know the PM type that you need? You look across the team and go, oh, we're missing a consultant, a former consultant, analytical brain who wants to be CEO of the product.

A In a pithy way, someone that, uh, opened door where we're closely with, um, had this phrase, which is you hire your strategy. Right. And so the person you pick to play that role will dictate how that person defines, you know, the success of, of that product. And so I think you need to have a perspective on that when you're hiring. So for example, if you look around and there are two dimensions, there's what is the, um, sort of team as in maybe the product, uh, that they're working on that team need, i.e. Hey, this is a backend infrastructure thing where the key to success is the algorithm that we put forth. Therefore, the PM that we need to have and needs to be able to deeply understand whatever the case is, you know, optimization or have a more mathy background. So there's that sort of type of team fit that I think is most important. Then the second is like your product team, your functional product team, and you can say, okay, our functional product team has like a lot of people that fit this type of mold. We need somebody who's going to push us in the direction of being sort of that, like crazy out there tinkerer, always trying the new, you know, newest tech tool. And they're going to ingest that energy into our product team because we are also So I think both of those are important.

AI assessment note: “there are two dimensions, there's what is the sort of team... need”

Q Final one before we do a quick fire. You said before about the benefits of staying for longer periods of time at one company for individuals. That is different to how most people operate in the valley. You are incredibly promiscuous as a group, uh, and jump from one AI company to another right now it would seem. Um, why do you believe in the benefits of staying at one?

A So as someone who's biased because I've spent, you know, two, two periods of longer stretches, uh, at companies, I think the reality is, uh, you just become more effective and therefore you can do more, um, more, more, more quickly. You have deeper relationships, you have deeper context on the company, you have deeper context on the customer base, and therefore you can be more effective. So if you're, if you're hopping every 18 months or two years and you assume, you know, It takes six months to ramp. Uh, you know, obviously that's very long to, to ramp to be any effective, but like to, to really deeply understand and gain context, like, and then at some point you're interviewing and thinking about your next thing, like you just don't have that much time to be effective. Obviously if it's the wrong fit, you should, you should move on, but I don't think a goal should be to move on every two years as you know, you can canonically read about, because I think you will just get more effective with time.

AI assessment note: “you just become more effective and therefore you can do more”

Q one. You said there are kind of about good, good PMs being able to balance between the kind of needs of the business, but also the needs of the user. The role of the PM itself is changing so much. It would seem, especially in a world of AI. Can you talk to me about how the PM role changes in a pre versus a post AI world most significantly?

A The tools and means and mechanisms, I think, Will change, right? And so your, your primary tool or artifact of like writing a PRD versus building a quick demo may change as AI makes it easier and cheaper and, and, um, to, to, to build. And I think we will see that we'll see a collapsing or converging of the end product design triad. I think they will never be the same, but I think everything will be pulled in tighter. So I think all of that will change. I think what won't change is actually the core of the PM job, which is. You gotta go talk to users. You gotta go figure out what people want. You gotta go build it. And you gotta go build it in a way that makes sense for the business, right? And I think trying to actually figure out the creative part of like, okay, I've got some customers telling me this. I've got some customers telling me that. I've got my CX team telling me this. I've got my user interviews telling me this. I've got my data telling me that. What do I actually like build? What do I do? How do I make a good decision that That works. And how do I do it with velocity? How do I know type one from type two decisions? Like those core components, I actually don't think change in a pre or post AI world. I think what changes is your ability to communicate those ideas, your, your, your ability to do more upfront, your ability to do better user research because you can sh…

AI assessment note: “writing a PRD versus building a quick demo may change as AI makes it easier”

Q How does the product development process change in the world of AI? I heard from many people that have worked with you that you're like the master of the actual process of product development. How does that change in the world of AI?

A Um, that's super kind of people to say. I don't know if I would consider myself a master. If you go back 20 years ago, it's like Pretty waterfall-y. And I think we've, we've as a, as an industry moved away from that, but you still have sort of like the PM owns this artifact of the initial PRD or, or, or one pager and design owns the, the, the, the Figma file or the design prototype and engineering owns the actual implementation and the code. And I think that creates a process in and of itself, right? Where like the PM is sort of at the top of the funnel and developing the idea. Then the designer comes in, you work with the designer and then Um, and it sort of moves down funnel. And I think AI completely collapses that cycle and accelerates a lot of the upfront up funnel work where, where again, you can just do, you can build a prototype and you can show that to customers and like the PM and the designer might just work collaboratively to say like, let's just build a prototype. Let's skip the documents stage and let's just, uh, uh, do that instead of sort of, um, maybe talking as a first step and then showing some flat files and then maybe building one or two prototypes It's to, to sort of refine your hypotheses, and so I think, um, the development process just accelerates a bunch.

AI assessment note: “AI completely collapses that cycle and accelerates a lot of the upfront up funnel work”

Q I'm series A style. So I've got investors and they want me to go from two million to eight million in a year. But I'm mindful that I've got growing technical debt. Do I focus on new product expansion and just let the technical debt ride it out? Or do I solve technical debt at the kind of, um, at the cost of maybe lower growth and lower new products?

A So I think when you're Early-ish stage like that, um, at, you know, seed series A doing two million, um, trying to get to eight million. Like you have to earn the right to exist in the future and paying down tech debt doesn't pay the bills. And so I, I think at that stage, it's probably a little bit early to start paying down technical debt. Now it, it, it a little bit depends. Are you in like a land grab? Uber was in a land grab for many, many years, right? It had to be first. It had to get riders. It had to get drivers, right? And so there's a very much a land grab competitive dynamic. That pushes a, you know, a certain philosophy and velocity. I think most early stage companies tend to be that where, um, you have to figure out if the thing that you're building in that two million ARR you may not know yet actually has value and people want it and people will pay for it. And so I think, um, early stage slowing down to, to, to pay down that debt is oftentimes a bit challenging.

AI assessment note: “at that stage, it's probably a little bit early to start paying down technical debt.”

Q It doesn't harm it. Does it have to benefit it? A lot of people say if you're going to do a second product, it has to benefit the first. I don't think it,

A Has to benefit the first, but it has to take advantage of some competitive advantage that your company has, right? And so if you think about sort of a, a classic two by two matrix, um, where you have, you know, your customer set and your, uh, uh, competitive advantages, um, as a company, your core product is your existing customers with your existing product, uh, and competitive advantages. Uh, if you have a new customer set and a new set of Competitive advantages or capabilities. That's probably just a new company. And so you're either playing in, do we take our core capabilities and attach to a new customer set? Or do we take a new customer set and attach to our core capabilities? And I think you can play in either one of those, but in, in, in both cases, it doesn't have to make the core product better, but it does have to make the core experience for your customers better. And it does have to make the business obviously better.

AI assessment note: “it doesn't have to make the core product better, but it does have to make”

Q Can I ask you, when it comes to hiring for product teams, I do want to discuss this because you said about hiring for true product teams, and I thought that was just interesting. What do you mean when you say true product teams versus just good PMs?

A Earlier in my career, I was like, okay, if you, you know, find someone who's smart and, and hardworking and can do that distillation, And there's a good PM. You can give them any problem and they'll figure it out, right? And I think for some generalist problems and generalist people, that's true, but not all PMs are created equal, right? There are PMs who grew up as designers and then became a PM or engineers or have a technical background or data background or a business background or an ops background, right? And like, I think it's a, we can be more nuanced in thinking and saying, what is this, this team Need. And therefore is this PM the right PM fit for the team? So it's sort of the same way you have founder market fit, right? You have like PM team fit.

AI assessment note: “what is this, this team Need. And therefore is this PM the right PM fit”

Q When you look back on your hiring decisions, When they've gone wrong, what did you not see that you should have seen?

A So I believe that, um, poor hiring decisions are, uh, almost, are never just the person, never just the responsibility of the person being hired, the, the, the new person who it didn't work out with. It's almost always, uh, the company or the hiring person's fault, right? And so I think if in, in that context, um, What I've seen most effectively is either that person wasn't set up for success. And so they didn't have enough clear direction, um, or definition of success or clear outcomes. They had the wrong skillset to sort of what we were just talking about. Hey, their interest is on the design side, but what the team really needed was like a more engineering technical leader. Cause that's, that's some of the challenges that the team was facing. Um, or, uh, and this is sort of a corollary to the first one. The ambiguity of the role and the ambiguity of the challenge was above that person's ability to distill the, that ambiguity and find what really matters.

AI assessment note: “either that person wasn't set up for success... They had the wrong skillset”

Q What is the best work product? Again, I'm a founder, you're helping me. How do I test them?

A The best best is people you've worked with before, because that's a heck of a lot better than a one hour interview. Um, but I think, you know, I, I think it can either be show me a previous work product that you've worked on or some type of consistent case study of like, Hey, here's a somewhat depending on the, the, the role, uh, the seniority of the role, here's a somewhat ambiguous problem. Let's talk about how you would handle it or put together a doc or a deck or whatever on how you would handle it. And I think the, the, um, Important part here is it can't be so narrowly scoped because the tactics of the job you can learn, how to run a sprint, how to do prioritization, like that, that stuff you can learn. That's not what the test is. The test is the clarity of thought and, um, Uh, getting to that outcome.

AI assessment note: “it can either be show me a previous work product that you've worked on”

Q How does the product development process change in the world of AI? I heard from many people that have worked with you that you're like the master of the actual process of product development. How does that change in the world of AI?

A Um, that's super kind of people to say. I don't know if I would consider myself a master. If you go back 20 years ago, it's like Pretty waterfall-y. And I think we've, we've as a, as an industry moved away from that, but you still have sort of like the PM owns this artifact of the initial PRD or, or, or one pager and design owns the, the, the, the Figma file or the design prototype and engineering owns the actual implementation and the code. And I think that creates a process in and of itself, right? Where like the PM is sort of at the top of the funnel and developing the idea. Then the designer comes in, you work with the designer and then Um, and it sort of moves down funnel. And I think AI completely collapses that cycle and accelerates a lot of the upfront up funnel work where, where again, you can just do, you can build a prototype and you can show that to customers and like the PM and the designer might just work collaboratively to say like, let's just build a prototype. Let's skip the documents stage and let's just, uh, uh, do that instead of sort of, um, maybe talking as a first step and then showing some flat files and then maybe building one or two prototypes It's to, to sort of refine your hypotheses, and so I think, um, the development process just accelerates a bunch.

AI assessment note: “AI completely collapses that cycle and accelerates a lot of the upfront up funnel work”

Q How do you know the PM type that you need? You look across the team and go, oh, we're missing a consultant, a former consultant, analytical brain who wants to be CEO of the product.

A In a pithy way, someone that, uh, opened door where we're closely with, um, had this phrase, which is you hire your strategy. Right. And so the person you pick to play that role will dictate how that person defines, you know, the success of, of that product. And so I think you need to have a perspective on that when you're hiring. So for example, if you look around and there are two dimensions, there's what is the, um, sort of team as in maybe the product, uh, that they're working on that team need, i.e. Hey, this is a backend infrastructure thing where the key to success is the algorithm that we put forth. Therefore, the PM that we need to have and needs to be able to deeply understand whatever the case is, you know, optimization or have a more mathy background. So there's that sort of type of team fit that I think is most important. Then the second is like your product team, your functional product team, and you can say, okay, our functional product team has like a lot of people that fit this type of mold. We need somebody who's going to push us in the direction of being sort of that, like crazy out there tinkerer, always trying the new, you know, newest tech tool. And they're going to ingest that energy into our product team because we are also So I think both of those are important.

AI assessment note: “you hire your strategy. Right. And so the person you pick to play that role”

Q Can I ask you, when it comes to hiring for product teams, I do want to discuss this because you said about hiring for true product teams, and I thought that was just interesting. What do you mean when you say true product teams versus just good PMs?

A Earlier in my career, I was like, okay, if you, you know, find someone who's smart and, and hardworking and can do that distillation, And there's a good PM. You can give them any problem and they'll figure it out, right? And I think for some generalist problems and generalist people, that's true, but not all PMs are created equal, right? There are PMs who grew up as designers and then became a PM or engineers or have a technical background or data background or a business background or an ops background, right? And like, I think it's a, we can be more nuanced in thinking and saying, what is this, this team Need. And therefore is this PM the right PM fit for the team? So it's sort of the same way you have founder market fit, right? You have like PM team fit.

AI assessment note: “what is this team need and therefore is this PM the right PM fit”

Q When you look back on your hiring decisions, When they've gone wrong, what did you not see that you should have seen?

A So I believe that, um, poor hiring decisions are, uh, almost, are never just the person, never just the responsibility of the person being hired, the, the, the new person who it didn't work out with. It's almost always, uh, the company or the hiring person's fault, right? And so I think if in, in that context, um, What I've seen most effectively is either that person wasn't set up for success. And so they didn't have enough clear direction, um, or definition of success or clear outcomes. They had the wrong skillset to sort of what we were just talking about. Hey, their interest is on the design side, but what the team really needed was like a more engineering technical leader. Cause that's, that's some of the challenges that the team was facing. Um, or, uh, and this is sort of a corollary to the first one. The ambiguity of the role and the ambiguity of the challenge was above that person's ability to distill the, that ambiguity and find what really matters.

AI assessment note: “What I've seen most effectively is either that person wasn't set up for success.”

Q Who is the one to set that OKR of that is what you need to focus on? Is that the CEO? Is that the CPO? Is that the head of product?

A That level where you're talking about that needs to come tops down. Um, and say, this is the, the success metric for the company. And then that cascades to the rest of the org. So for example, in the Uber case, just to extend, you know, trips may just be the metric, right? Like that's the, okay, that, that, that, that matters. Um, but I'm doing Uber pool, right? And so like, okay, I can see that as a, as a product leader for my area, right? Which is not the whole company, obviously for my area and say, okay, how do I ladder to that? Right. And so what ladder, what matters to me Is okay. In this case, it's easy. Uber pool trip count, right? But I can match my OKRs and everyone else can ladder their OKRs to the top level. And so OKRs to me are like cascading trees, right? Where, however, wherever you are in the organization, like it should be layering up to the one or two above that.

AI assessment note: “needs to come tops down. Um, and say, this is the, the success metric”

Q What was the worst product decision you made at Uber and how did that impact your mindset going forward?

A Uh, back in the early days of UberPool, um, uh, the way you accessed the product was a sort of this, um, subset of UberX. So it wasn't all on the slider as it is today. Um, it was sort of, you go to UberX and then above it, you see this little, um, toggle where you can pick UberPool or you can pick UberX and you, um, Uh, see some differences around the price or the time that you would get there. And, um, uh, for a little bit, uh, the default was Uber pool. And I think that was a poor product decision. Um, because, uh, uh, even if you had chosen Uber X on your last ride, it defaulted back to Uber pool. And so the UI wasn't clear enough what was happening. And so people were accidentally choosing, Uber pool. You know, they thought they were getting an UberX. That's maybe what they were accustomed to or whatever. Um, and then someone else would show up in the car. Um, and they'd be like, oh no.

AI assessment note: “the default was Uber pool. And I think that was a poor product decision.”

Q What was the worst product decision you made at Uber and how did that impact your mindset going forward?

A Uh, back in the early days of UberPool, um, uh, the way you accessed the product was a sort of this, um, subset of UberX. So it wasn't all on the slider as it is today. Um, it was sort of, you go to UberX and then above it, you see this little, um, toggle where you can pick UberPool or you can pick UberX and you, um, Uh, see some differences around the price or the time that you would get there. And, um, uh, for a little bit, uh, the default was Uber pool. And I think that was a poor product decision. Um, because, uh, uh, even if you had chosen Uber X on your last ride, it defaulted back to Uber pool. And so the UI wasn't clear enough what was happening. And so people were accidentally choosing, Uber pool. You know, they thought they were getting an UberX. That's maybe what they were accustomed to or whatever. Um, and then someone else would show up in the car. Um, and they'd be like, oh no.

AI assessment note: “I think that was a poor product decision.”