20Product: Why Most CPOs are Bad | Why You Do Not Need PMs in a World of AI | Why the Design Stage is Dead and How to Use Vibe Coding to Replace It | The Three Roles All Founders End Up Firing on Repeat with Jason James @ Tezi

0:00You are listening to 20 product with me, Harry Stepping. Now, 20 product users show where we dive into the best product minds in Silicon Valley. To unveil how they think about building product teams, managing PMs in a world of AI, how they build the best products and product teams today. Now, we're joined today by one of the best Jason James, co -founder of Tezi, and one of the leading product minds in the Valley, prior to Tezi, Jason was the VP of Product at Instacod, leading up to their IPO. And before that, he was the head of product and design at Thumbtack. But before we dive into the show's day, are you struggling to beat model benchmarks or implement Gen AI in your product?

0:37If so, you need churring. Churring is an AGI infrastructure company backed by incredible investors like Foundation Capital and Westbridge Capital. And they do two things. Number one, they help leading companies in AI labs. Like Salesforce, Anthropic and Meta, enhance their LLMs with advanced reasoning, coding, multi -linguality, multi -modality and more. Number two, they combine human and artificial intelligence expertise to deploy cutting edge AI systems for awesome companies like Rivian and Reddit. Right now, Turing offers a free five minute self -assessment to help you pinpoint your place in the Gen AI journey, get tailored next steps to optimize your model strategy, and then finally learn how Turing can refine and implement your models for better performance.

1:25Take the guesswork out of Gen AI. Visit churring .com, Ford slash 20VC, to start your free assessment today. And once your Gen AI strategy is on point with churring, you have now arrived at your destination. Jason, I am so excited for this dude. I've been looking forward to this one all day, so thank you so much for joining me first. Yeah, really happy to be here, thanks for having me. Now I want to start a little bit before Tazzy, and I want to start with you've been at some of the most incredible organizations from your Instacards to your thumbtacks. If we start breaking them apart, actually, with Instacard, when we think about big lessons learned, what was your biggest product lesson learned from the days at Instacard?

2:07Biggest product lesson learned from Instacard was as much as AB testing and like high velocity optimizations feel like progress. And to some extent they will be when you're out of business of that scale where we're talking like 30 to 40 billion in gross transaction volume. The only thing that really moves the needle is like new capabilities. So we would try and test a lot throughout the customer experience to optimize conversion, make things easier, make search better, the results more relevant. And it would deliver wins, But the sleeper, huge win, was when we launched SNAP -EBT, which is like food stamps, to be able to pay with those on Instacart.

2:57It became a billion dollar business line in less than a year and then grew up to be four billion. So, it changed how we plan and how we think about placing bets from what are the quick When optimizations on the current experience to what do we need to do to unlock the next billion to 5 billion? So if you're an early stage founder, then this means this and building as you are today, how does that change your advice as to how you would advise a founder to allocate team and resources between optimizations and iterations and new capabilities and kind of game changes? So how I translated that into TazeE, where we are seed stage, is if we can launch a new capability and do it at like an A quality level, we can actually set it down for a while and not have to come back and keep working on it for call it a year, which then enables us to be able to go and and add an additional capability.

4:03But when we launch things that are like MVPs that are just kind of like scrappy like beta stuff, we get mired in fixing it and trying to make it work. And it slows down our ability to launch sort of the next big thing that it's going to move the needle on our ability to have a differentiated positioning and to like market ourselves. Does that mean that you don't agree with the kind of test it, ship it, quick and dirty, get customer feedback and sticky type from that. Sort of. So I guess, how do I feel about like MVPs and test and learn? It's when we're building, we'll have varying degrees of clarity as to what the customer needs and wants based on everything else that we've learned from customers over the last year, year and a half at Taze.

4:54and when we have clarity as to what they want, let's just build the thing. Now, where there's ambiguity and we're unsure as to, does this really meet their needs? There's so many steps along the product development journey that we can bring in a customer. And like, whether that's at the design stage, whether that's with a prototype alpha that was vibe -coded to right before launch, we've released to just a few customers. And so I think of it as kind of like one swing and I want to finish this swing, but in between, we will need to involve customers if we lack certainty. Can I ask you, in terms of that MVP stage, how has that changed in the world of AI?

5:37You mentioned vibe coding there. Do we skip the design phase entirely and just move to a vibe coding prototyping stage? How has it changed with AI? It's really changed it dramatically, even just in the last year for how we work. our designers now are trying to figure out what vibe designing means, then to some extent, even if they can vibe code. There's some ways in which it works, and so magic pattern has been useful for us to designer can just articulate what they want, what they're trying to do, and then all of us can see a prototype and interact with it and get what the designers trying to put forward, very quickly, very simply.

6:15We haven't quite gotten to the place where the designer can use cursor to like, vibe code at themselves. We've tried just running an environment was too hard. And so maybe someday we can optimize it so that a designer or myself could stand up an environment and do it pretty quickly. But it's enough that, okay, this vibe design thing in magic patterns works for the engineer to vibe code it up themselves. And sometimes it'll be high quality code and sometimes it's gonna require a bunch of work after that. But our standard for what we release is still the same. Like we still want to get to like a quality on anything new, but we can get there faster.

6:57Can I ask, do you think you see then the continued segmentation of roles between design as you said there, who maybe use magic patterns, but still a segmented role, and then end shoe, still a segmented role, but use cursor to be more efficient? Do you think we have to say, or do we see the bundling where all of them come into one product engine design, and we have this kind of uni -superhuman being. So the way I see rules evolving is really towards what I think has been like more natural and organic all along. When I think about early days of tech, it's like engineers. And then they were building and all of a sudden like UX actually mattered because we had like graphical user interfaces.

7:39And some of them could design and some of them like couldn't design, you know, they couldn't imagine it. and make it usable. And so a design as a field, UX design as a field emerged. Then what happens is product emerges because someone needs to understand the business requirements, why we're doing what we're doing, and articulate and prioritize that. But the thing is, some engineers could have always done it. And some designers could have always done it. And so that's how I transition from design into product management is it's not really different. Like design is a set of decisions about a product, and so those decisions can be made by an engineer, they can be made by a designer, they can be made by a product manager.

8:26So I don't see the roles as all that distinct. It's just sometimes you're lacking skills within the team, so then you need somebody to bring those skills. With emerging technologies, perhaps you can have more skills, basically. So an engineer can get to something like solid design wise when it might have been challenging for them in the past. That's great. And same with a designer could perhaps be able to code up something through prompting. And that's amazing. Like for us, my theory was we didn't need PMs until call it 50 people or so. We actually do have some gaps. And so we have PM that's like former senior director at Slack that contributes about 15 hours a week and it really helps fill the gaps on his enterprise experience, clarifying the requirements, prioritizing, because as good as our engineers are and as good as our designers are, it's just helpful support to them.

9:24Do you think early stage companies do need PMs? It's always been held that you know, gather PMs, they're the CEO of the product, but now we're seeing this kind of swing away from PMs. How do you feel about advising an early stage founder on whether they do or don't need a PM? I see PM as, think of it as like a hire of last resort. And so I don't think a company should be allergic to hiring them, but it shouldn't be the default. And why is that creating room for engineers and designers to be leaned in on the business is good for the business. And that having more ownership versus, is, hey, stay in your lane, design the thing, hey, stay in your lane, code the thing.

10:05Leads to deeper employee engagement, helping them think like a founder about all aspects of the business. But if not having PMs is affecting execution, the team is asking for PMs, then that's, I think, the time to introduce one. Does the role of a PM change in a new world of AI where vibe coding is so prominent, where speed of development is so changed? Does the PM role change and does the skills required to be a good PM change? I think where PM spend their time will evolve. And by that, I mean, instead of long PRDs and set of requirements, or even just the idea of CEO of the product, I think is really obnoxious and not helpful.

10:53So a good PM will be filling gaps that a team has. And I think that there will be continual gaps. It is hard when you're in it in the thick of building things to be able to zoom out and say, okay, of the 50 things we might do, what are the like three that we should do, like next cycle? And how do we prioritize against the customers we have versus the customers we want, versus fixing what we have already built versus new capabilities? that requires a building a lot of context. And I think that that continues to be where PM spend a lot of time, but articulating it in some dark, it becomes a one -pager instead of a 20 -pager.

11:41Can I ask you if we said that about kind of Instacart and the importance of building new capabilities over iterations and optimizations. If we discuss ThumbTank, another incredible company, when we think about lessons learned there, What was the biggest product lesson from Thumbtack? For me, the biggest product lesson from Thumbtack is you should just do the common sense things and whether you have the data to support them or not and chasing the data to support why we should do something can actually just be distraction and the delay. And so the unpack that what I mean is I recall so much time we spent Heming and Haing in 2016 through 2018 about whether we'd be native first.

12:29Like how important app usage was versus web usage and we knew it was correlated to retention but we didn't know if it was causal to retention and to do sort of analysis and study to determine the causality of something takes quite a long time. When at the end of the day we could have just said, listen, the long -term secular trend is everything's moving towards mobile. More usage, whether they desktop and mobile is better. So yeah, let's just go all in and we'll see what happens. So I guess it helped me see the value of even in like late -stage companies of conviction, based bets that are based on like sensible secular long -term trends or, you know, otherwise.

13:17Do you think you should have a decision -making structure where people are able to make decisions fast versus seek consensus and debate? Oh, yeah. I hate consensus building. I think it leads to slow execution and often worse outcomes that it lacks anyone's conviction because it ends up being watered down that this is the right thing. So I'd rather have someone feel empowered to make the call, test, learn, and like either be right or wrong, but like get to an answer quickly so that they can move on to the next thing. What's the biggest non -consensus product decision you made that didn't work? And what did you learn from it?

14:03I think the biggest non -consensus product decision that I made that didn't work is how we built TACI, like the V1. We took a breath first approach. The consensus view is, you know, start narrow, point solution, land and expand. It's the wedge. That sort of thing. What we set out to build is the equivalent of a full life cycle recruiter. And so that necessitated a ton of surface area across the entire recruiting journey from opening an offer all the way up and opening a role all the way up to the point where you're ready to extend an offer That was the like product scope. So very broad What was right about that is it's a very differentiated positioning and has helped us get a ton of meetings And customer interest because companies are tired of point solutions and they don't want to integrate another one What we've struggled with is it's a lot of surface area and it's hard to get, you know, 12 things to a sufficient quality level.

15:13The thing that I learned from it is you can't do an MVP for a breadth -first approach. And I think Ben, the CEO at equals, has a post on this where it's basically MVP versus full build. and so they have a spreadsheet product and you had to take like a full build approach. We took an MVP approach to a full build breath product when really we should have delayed going to market by another six months to get it all to like a higher quality level. How do you know whether something's full build or MVP a bull? What's that difference between the two? For us, it's about the thesis that we're trying to test.

15:59In order to be able to validate or invalidate the hypothesis that we have, it requires certain things to be true. If we'd only built an AI sourcing tool, let's say, where you can create a list and email candidates and stuff like that, much of the market is today, that would lead us to be selling to recruiters. And it would then be about efficiency of the human recruiting team with an AI enabled tool. That wasn't thesis that we were trying to test. What we're trying to test is can AI be a labor capacity addition or augmentation for a company? And so that needs to be like the breath of a human sort of role.

16:50And so for us that necessitated like building more. I always think about the road to the start line and what is required to get feature parity in a product. And how difficult is that? We often sit with like messaging products. Whereas you're messaging products is quite difficult to even just get to parity with any of the leading messaging providers. And then you're only equal. And that's not that compelling. You mentioned that like, hey, if we'd only focused on sourcing or only focused on an initial course segment or wedge, when we spoke before, you said something that I really liked. You said, most hiring managers hire poorly.

17:26And I totally agree, dude, I've interviewed, you know, a thousand of the best founders of the last decade, literally. And 50 % is the strike rate on like good hiring, okay? So what are the most common ways that people screw it up? I think the most common way that I see hiring managers screw up hiring is like over delegation which then is compounded by the fact that they have like muddy thinking. They don't know what they want and they haven't taken the time to like really suss that out. So then you think you're hiring a recruiter and it's the recruiter's job to hire for you, but the recruiter doesn't really get what you want because you don't know what you want.

18:14And so I think the best hires will come from like super active involvement by the hiring manager that they are in it and very hands on, but most hiring managers think that they've outsourced it and they are hands off and it doesn't go well. Don't laugh, what's the best way to know what you want? I know that sounds super meta, but say we're hiring an engineer, what is the right way to know what we want? Should we write out all the daily tasks? Should we write out the values, the skills? How do I know? For me at least, how I figure it out is I start from the outcomes that I'm trying to achieve. So what would actual like success be for this person?

18:57If they did the job for 30, 60, 90 days, like how would I actually be happy with them? What's true about our culture, that they just need to have a level of grit, drive, ownership, that sort of thing? And so I try to articulate that and make chat GPT or our max TAZ agent, output it as a JD, post it. And I just really need to start talking to people. For me, I learned through talking to the first 20, 30 candidates to get a feel for at least some pattern matching across them of what is an excellent answer sound like versus, you know, not so good. But initially, I can't tell the difference. So I have to just talk to a ton of people.

19:42And I also look for help from other people that have hired for the role. And so, hey, who do you know who's good at this? And at least I can talk to that person even if they're not on the market about what I should be looking for. So they don't know what they want is number one. Any other ways where people seriously make mistakes on hiring in that core first process. Yeah, and I've gotten this wrong. So I get sort of why it happens. But a lot of people hire for a resume. And I've found some of the worst tires that I've made, some of the worst tires I've witnessed are based on incredible resumes.

20:21And I think why people get that wrong is you mistake that this person was in a seat at a certain time. And in many ways, it was an elevator going up and they were on the elevator. But what we failed to understand was like, what did they do? Like, what did they actually do to change the trajectory, did they contribute or just were they at the right place at the right time. I find that right place right time can get you really far in terms of getting big roles and stuff like that, but you get found out after a year, a year and a half. And so those are often execs that turn over quickly and it's unfortunate.

21:06I'm an early stage founder and you're my friend helping me. That's a person with a stellar resume who looks great. How do I determine if the stellar resume is justified and great we should hire them versus they're on the elevator going up? What questions depict that? How do I unpack that? I've learned a lot about interviewing from a poorver founder CEO of Instacart. He spent like seven hours with me over like the course of maybe four weeks when recruiting for the VP of Design role he was trying to fill. And much of it was just my questions for him. Like I probably had a hundred questions for him.

21:44His like one question for me was like he maybe had three questions, but like the one that stuck with me was just like what did you do? And like I'd say some things and then he's like no, but like what did you really do? The more that you kind of like keep pushing at that question. What you'll hear is either like platitudes or like depth and specificity, and then you can take that and triangulate it, like back channel with like other folks and like their orbit. Hey, so how instrumental was this person to this outcome? And you'll hopefully get some real talk based on that. If they did big things, that's incredible.

22:26Then they have great resume and they contributed, but sometimes you can't find it. Do you think fundamentally it is so competitive, say, that if you're an early stage company, you will never have a great person who has contributed with a great resume, want to join your company? Do you have to find diamonds in the rough? Because it's so hard so early that no one who's been there and done it wants to go back. If I think about the founders and experience sort of veteran, like myself and my co -founder, where we're like 40 plus, we've been in the industry for one or two decades. Yeah, we can pull those folks.

23:03But when I think about, okay, new grad or drop out, I don't think they actually need it. I think you just need people that are going to be like very competent and very driven and very ambitious and like hardworking and stuff like that. And that'll get you plenty far to where you've earned the right, I guess, to be able to get some remarkable people to come work for you. But I don't think it's essential to get off the ground. You mentioned the 15 hours a week that the person from Slack, the pot takes him with you. How do you advise founders on pot time, advises in that respect, which you see more and more of?

23:42As a founder, I find that everyone wants to give me advice and get paid for it. And for the most part, I don't need it. There's a few key areas where advice has been useful as it pertains to fundraising or go to market because that's like it hasn't been a strength or part of my background or my co -founders background. But by and large, I find advice to be like cheap. I can get it for free if I want. So like, I don't know why I would pay for.

24:18What bed advising companies since leaving Slack. I got connected to him through my wife who was an engineer at Slack and worked with him. And my pitch to him was, I wouldn't you like to get in the game a little bit. And instead of just, you know, give advice, like, can we do some work together? And it's a nice change of pace. It's hard to find like a way to contribute when you don't want to sign on full time to, you know, do a 15, in 20 -hour a week, like PM job. And it's been remarkable, actually. So I've worked with like 100 PMs, probably over the course of my career. I like his 15 to 20 hours, more than most of their like 50 to 60 hours.

25:02What makes it so successful in a way that founders can learn from? I put a real premium on getting to the right answer quickly. And it's hard to find those people. but when you find them that they can take in the context, they understand the problem, and they're going to solve it in a way that is simple, clear, and quick. I will hang onto those folks for the rest of my career, and I have. So I don't know how to always get there. I don't know it on the front end. I only know it through doing, but I do like working with part -timers or fractional people because I get to try it before I buy it. And then sometimes it's like, oh, this really, really works.

25:49And so we found that like three or four times already in the last year with some part -timers. So I would advise founders try it a lot. If you can get the people to do some work like embedded team members, but you just don't have to have them full time, which also then creates more flexibility about how we manage cost and burn and stuff like that. You've said something brilliant before, which is about founders tend to fire the same three roles over and over. It was a bit of a clear fire. What are the roles that they tend to fire over and over? And can you unpack that statement for me? Yeah. I've seen this movie, you know, many companies over the last 15 years.

26:31The three roles that I see that get fired over and over are CPO, CMO and head of talent. They typically have like one and a half to two year stints and then they like move on to their next thing, you know, sort of like quietly and discreetly. So most folks don't understand that they were fired, but when you're in the senior leadership team, you do, why does that happen? I think it's very similar to the same deal of like any mishigher. it's muddy thinking. And it's like founders vaguely know what they want. They want the product to work. They want the business to grow. They want to make good hires.

27:16But the level of clarity and vision of like, okay, here's the product. I have a crisp product vision for where we're headed. I have a crisp workplace vision for who we are and what our culture is. I have a crisp vision for growth. That, I believe, belongs with the founder. And until they arrive in a place of clarity for themselves, they're not going to get it through somebody else. You mentioned CPO first there. CPO is this kind of hailed role. If you would advise me as a founder, when is the right time to start thinking about hiring CPO? I'm going to assume most founders are product people. I think that that tends to be true.

27:57I honestly think you don't need a CPO until maybe like as a founder you're starting to think about transitioning into the chairman role. Do you think most CPO is a shit? Yes. Yeah, absolutely. Yeah. How do you know how do you know if a CPO is shit? Like I interview a lot of CPO's. How do I know if that's shit? If they say alignment a lot, like what are the buzzwords? The only thing that matters with a CPO is whether they have the trust of the CEO. And so if they have the trust of the CEO, then they can stick around and they'll likely sort of be successful. And if they don't, they're going to continually butt heads and it's just not gonna work out and the role will turn over every year and a half, two years.

28:48In those situations, the CEO should just do the job because they need to learn through doing and in doing the job in thinking harder about the problem, they are the only ones that really have a shot, I think, at cracking it. And I guess how does the CPO establish trust? I think it comes from results. So they say a thing, they were right, it delivered the results. And so being consistently write a lot, builds trust and clarity. It's not hand -wavy, it's not platitudes, it is like a clear, a crisp articulation of what we should do, why we should do it. And at the end of that process, we will have either validated or invalidated.

29:33But what I find is when a CPO can make a whole career out of being hand -wavy, it's like kind of like a magician where there's like a misdirection in slight of hand to say like, Hey, we're going to do this and we're going to do that. And when you don't put numbers to it, when you don't put dates to it, there's just a complete lack of accountability or the accountability moves down. And it's always a director's fault or some VP's fault. And so those types of things obscure what really is the CPO's to own. I often find the wheat CPO's oscillate a lot around process implementation. and it makes it sound really scientific and structured in a way that they know what they're doing, but in a way just adds a level of bureaucracy.