Fullstendig transkripsjon av Why Engineers Should Make the Final Call — Not PMs (PostHog Executive)

was, like, sending an email to my mom or something, and, uh, my boss got mad at me for not, for, like, doing something personal on my work time. 29 00:05:50.120 --> 00:05:58.664 Um, which it's like, I get, but I was also, you know, I was just sending an email to my mom, and- That just wasn't really, that didn't really vibe with me. 30 00:05:58.904 --> 00:06:07.224 Um, I, you know, I'm not the f- the type of person who's like, I, you know, you need to sit in this chair for eight hours and do nothing but work. That's just not how I work. 31 00:06:07.484 --> 00:06:19.054 Um, and not how I saw my career [laughs] going, and I got an opportunity to, to work remotely, and, um, for this company, and, you know, do some small WordPress development for them. 32 00:06:19.104 --> 00:06:23.424 And, um, it just was much more of a fit for my personality type. 33 00:06:23.504 --> 00:06:34.374 So I guess that's, that's the thing that I, I looked for and that really drove me, was like, is this how I see myself moving forward, or is there another opportunity that is gonna fit me better? 34 00:06:34.604 --> 00:06:45.944 Yeah, for me was, um, the MySpace blog. I don't know if you ever used MySpace. At, at the, at the time- Yeah, a long time ago... yeah, like you could, uh, like, uh, customize all the, the themes, and it was great. 35 00:06:46.064 --> 00:06:50.664 That, that's how I got started, so very similar. [laughs] Yeah. Um- Yeah... 36 00:06:50.724 --> 00:07:02.764 so we, we get to 2023, and you are working for PostHog already, and you wrote this article where you say that product engineering, uh, is the most fun role you ever had. And- Mm-hmm... 37 00:07:02.844 --> 00:07:15.024 uh, you, you kind of, uh, say this is because of four specific reasons. So, um, you say, one is challenging problem to solve. You have, uh, support from other highly motivated colleagues. 38 00:07:15.944 --> 00:07:28.804 Three, the autonomy to make important decisions. And four, complete transparency into why your work matters. So is, is this still true in 2026? Did anything change? 39 00:07:31.024 --> 00:07:39.924 No, I don't think anything about those things have changed. I think those are fairly fundamental. And, and not only for product engineering, but I think those things describe 40 00:07:41.624 --> 00:07:48.204 why any job can or, you know, may or may not be, um, motivating. 41 00:07:48.804 --> 00:08:05.703 Uh, I think, you know, you could have a marketing role, and if you can check those boxes, you know, transparency into why your work matters, and challenging problems to solve, and coworkers who are, you know, uh, just as motivated as you are, though that's, that makes for a fun work environment. 42 00:08:06.484 --> 00:08:20.214 I mean, this is something that we can read on a lot of job posting, right? So this is something that people, companies do to sell their, I don't know, their, like work, work with us. This is what we do, right? Yeah. 43 00:08:20.224 --> 00:08:31.264 This

is what you can do with us. But I think, so how, how, how does this look at, at PostHog? So what's, what's so different about PostHog that, uh, in how th- these four principles are delivered? 44 00:08:32.484 --> 00:08:43.544 So, so I will say that whenever you join a new company, there's always the big question, is this company on the inside the way it is represented on the outside? 45 00:08:44.364 --> 00:08:50.964 And the more of a black box the company is, the more risky making that decision is going to be. Um, 46 00:08:52.104 --> 00:09:04.824 a previous job that I worked was definitely told one thing about my role, um, you know, what role I would be doing and what that would look like. And then when I got in there, it ended up not being that way at all. 47 00:09:04.924 --> 00:09:16.404 Um, and, and that's because they're, like I couldn't even use the software, um, before I, I joined the company. I had, I had almost no idea what I was getting myself into. And, um, 48 00:09:17.504 --> 00:09:27.064 and so I think the more open a company is, the more you can trust that what they say the job will be like is actually what it's like. Um, so 49 00:09:28.264 --> 00:09:33.724 for PostHog, you can actually see that we're, you know, just drastically, wildly open and transparent. 50 00:09:33.824 --> 00:09:53.584 Um, and, and you can see in real time the customer, well, one, you can, anybody can sign up and use the product, but, but two, you can see on GitHub, uh, you know, someone filing an issue or commenting on an issue, and then an engineer interacting with that person and asking a question, and then saying, "Here's the PR to fix." 51 00:09:54.064 --> 00:10:10.824 Um, oftentimes the, these types of interactions happen in like a private support, uh, ticket as well, but you can, as a customer, you can see if I file a support ticket, um, and it's something that isn't just like pointing me at the correct documentation or something, if there's an actual technical issue, the engineers are involved. 52 00:10:11.384 --> 00:10:14.684 Um, so I think that's really critical. 53 00:10:14.824 --> 00:10:36.504 It's, it's surprising to me how many people I interview and I ask them what their interaction with customers has been like in the past, which is a common interview question of mine, um, and they've been unfortunately put behind a, a PM or someone's, you know, some sort of customer facing role, and some people are never even allowed to talk to customers. 54 00:10:37.024 --> 00:10:49.604 Um, which is just, I don't know. I, for me, that, that's not like a fit, right? Um, I want to be able to hear why, uh, you know, why a customer's struggling. For instance, um, 55 00:10:50.544 --> 00:10:56.464 we, we've had a conversation recently about, uh, fixing little paper cuts that exist across our app. 56 00:10:57.004 --> 00:11:07.744 Um, and, and some people are saying, "Well, you know, we have a ton of people internally who know what the paper cuts are, so we should just ask people internally what the problems are and fix them." 57 00:11:07.844 --> 00:11:22.764 Um, which it's like, yes, I mean, I think that sounds like a great idea, but at the same time, when you get an engineer in a room with someone and that person shares their screen and says, "This is what I'm trying to do, and this is what I'm trying to achieve, and it's really painful for me to not be able to do this." 58 00:11:22.864 --> 00:11:35.684 Um, one thing is like you can't right now drag a node in a notebook to a different location. You can drag other things, but you can't drag a text node. Um, and, and when you see the customer trying to do that, 59 00:11:36.884 --> 00:11:42.884 it's so much more motivating to be like, "Oh my God, I'm so sorry. I need to go fix that." Like, [laughs] this is, this is a problem, right? 60 00:11:43.004 --> 00:11:57.174 So I think keeping engineers in touch directly with customers is, is just so huge, and so we're very intentional about not putting any, any layers in between engineers and customers because that's- 61 00:11:58.180 --> 00:12:06.860 Really, the, the, the most, the best way to motivate people, your engineers, um, but also motivated people do the best work, right? 62 00:12:07.000 --> 00:12:19.800 So it's, it's really a, you know, it's a win win situation, um, when engineers are happier because they're motivated by directly talking to customers and the business does better because we have really motivated engineers who are doing great work. 63 00:12:21.820 --> 00:12:37.100 And how does that look like in practice? How can engineers, uh, get in touch with users if they want to maybe do an interview or discovery? Yeah. In like, in theory, there are no guardrails. 64 00:12:37.380 --> 00:12:46.820 Um, I mean, there's minor guardrails around like, you know, if this is one of our large managed customers, ask the, ask their, uh, account manager if it's okay for you to reach out right now. 65 00:12:46.960 --> 00:12:58.740 It's possible that they're like in the middle of some sort of important discussion or something and we don't wanna interrupt that flow. Um, so for the big managed accounts then, you know, you should check in first. 66 00:12:59.280 --> 00:13:12.000 Um, but aside from that, there are no guardrails around like can you email a customer to ask for their feedback? Can you ask them to get on a customer interview? Um, 67 00:13:13.060 --> 00:13:24.300 uh, we're, you know, can you send them a, a survey or whatever? Um, so we're, we're very much like, honestly one of our big things is trust over process. 68 00:13:24.380 --> 00:13:35.160 I trust you to make the right call and, and do the right thing in terms of getting this customer's feedback. Um, so in theory, anyone can do it at any time. 69 00:13:35.640 --> 00:13:43.720 I think it does become a little challenging when teams are so busy, they have so many things to do, they have a backlog of feature requests. 70 00:13:43.760 --> 00:13:55.939 And when you

have as many customers or as many users as PostHog does, uh, it feels a little overwhelming to decide who should I reach out to, who are the right customers, you know, who should I be talking to? 71 00:13:56.440 --> 00:14:09.040 Um, so we do have our product managers. Um, they're oftentimes responsible for making sure customer interviews are happening on a consistent basis. Um, we are understaffed on product managers. 72 00:14:09.260 --> 00:14:21.480 Um, if there's any PMs who ever listen to this and, you know, or engineers who wanna do more PM type work, uh, we, you know, you should definitely apply. But, um, but I think that, uh... 73 00:14:22.120 --> 00:14:33.820 So in some teams it doesn't happen as often as it should, but we do try and set it up so that, um, while engineers can do the legwork if they want to, it does happen a little bit more automatically for them. 74 00:14:35.320 --> 00:14:49.140 So going back to the, to the four ingredients for having fun, right? Um, so the first one was challenging problems to solve. And so I know that at PostHog, uh, engineers can work on problems hand to hand, right? 75 00:14:49.180 --> 00:15:03.700 So not sp- not- Yeah... specifically a technical problem, but also a product problem. So, um, how, how does that, that work in practice, and what, what are the, let's say, the, the boundaries with, with product managers? 76 00:15:05.620 --> 00:15:19.940 Yeah. So in terms of working on something end to end, uh, any time a project has to be handed off to someone else, it slows down so much. Uh, because then it gets in a queue, someone else's queue. 77 00:15:20.120 --> 00:15:30.960 You know, they have to prioritize it. It's possible they won't be able to work on it for, you know, a few weeks. Um, so we really value having engineers. 78 00:15:31.140 --> 00:15:49.540 Um, all of our product engineers are very full stack, um, who can do something, you know, write the API, write the backend logic, create the middleware if needed, create the front end if needed, and like make sure the UX is okay, so they can do the entire stack all the way up and down. 79 00:15:49.620 --> 00:15:56.720 Um, and, and that means that there's really only one person ever working on a single feature at a time. 80 00:15:57.260 --> 00:16:14.800 Um, there are some times when, you know, really big projects need to have multiple people on them, but even then, the vast majority of the time, um, we try and, you know, what, what are the vertical slices even within this thing and have one person do one thing all the way from the bottom to the top. 81 00:16:15.340 --> 00:16:24.760 Um, so I... That, that just makes it so that we're not waiting around. Anyone who wants to build a thing can build the whole thing without having to get anyone else involved. 82 00:16:25.480 --> 00:16:31.820 Um, what was the second half of your question? Oh, what- The boundary... what are the boundaries- Yeah... between product managers and product engineers? 83 00:16:32.920 --> 00:16:41.280 Uh, so the, the boundaries, I think it's really important as a company to set up and understand what the boundaries are. 84 00:16:41.560 --> 00:16:46.860 Um, and this is something we're really clear about in our job postings and when we're interviewing product managers. 85 00:16:46.960 --> 00:16:53.120 Um, I think a lot of people come to us because we've been so clear about what is the role of a product manager at PostHog. 86 00:16:53.200 --> 00:17:02.780 Um, uh, most people who come to us don't have any sort of issue with the, the way we've set it up, but the way we've set it up, um, and it goes for, you know, people in sales as well. 87 00:17:02.860 --> 00:17:12.300 I've worked at places where sales wants to be the decision maker on all the product features that are built. Um, but at PostHog, engineers are the final call. 88 00:17:12.820 --> 00:17:23.720 Uh, they decide what to build and when to build, um, and, and how to build also. Um, that doesn't mean that other people's opinions aren't highly valued. 89 00:17:23.820 --> 00:17:37.439 Um, we very much highly value the opinions of product managers and salespeople and marketing folks and, and engineers like are s- you know, really want that feedback and need that in order to make good decisions. 90 00:17:37.660 --> 00:17:44.619 Um, but at the end of the day, the engineers are the ones who write the code and so they are the ones who are deciding what to build when. 91 00:17:44.700 --> 00:17:53.620 Um, so once, once that baseline has been set, um, the role of a product manager at PostHog becomes really clear. The role is to 92 00:17:54.540 --> 00:18:07.300 do a bun- uh, do the research in order to understand, um, you know, what are the things that need to be built first, what does the competitive landscape look like, what are, um, what do our numbers look like, what's our churn, what's our growth rate this month? 93 00:18:08.150 --> 00:18:19.510 So do the research so that they can give all that context to the engineers and have a really deep conversation about these are what the users need, these are, you know, opportunities that we see. 94 00:18:20.090 --> 00:18:26.350 Um, and then at, at that point, it's handed off for the engineers to say, "Okay, this is what I'm going to work on." 95 00:18:26.370 --> 00:18:37.730 And it's not like, um, I don't want to, you know, people to go away thinking that, you know, a PM comes to an engineer and says, "You know, this is a big problem, you know, I, I really think we should fix this." 96 00:18:37.770 --> 00:18:48.850 And the engineer just says, "No, I'm making the decision." You know, that's not, that's not how we work at all. It's, it's very, um, very respectful and, you know, everybody really values everyone's input. 97 00:18:48.930 --> 00:19:02.000 But because there is a clear decision maker, I think it makes it, it work really well. I think if you have, um, if you're a company that has PMs who are the decision makers, um,

and then you try and make 98 00:19:02.930 --> 00:19:15.210 product engineers m- give them, give them more decision making capacity, um, you either have to say, "Okay, in this, in this thing we're gonna try it where product engineers are the decision makers and, and PMs, uh, 99 00:19:16.270 --> 00:19:22.730 not need to... And PMs not need to not be able to be the final call," or you have to like change the whole org. 100 00:19:22.790 --> 00:19:29.590 But if you don't have that clarity around who owns the decisions, then things, they're gonna get confusing and difficult. Right. 101 00:19:30.090 --> 00:19:44.230 So can we say that at PostHog, um, product managers are like m- managing the bigger context, so the bigger picture, and they act like a- Yes... like a compass, right? For the org, everyone in the company. Yeah. 102 00:19:44.730 --> 00:19:58.270 And then the engineers kind of own a slice of that context, so they can work on a specific problem end to end, and then ask for help when needed. Is it like that? Yeah. Um, 103 00:20:01.270 --> 00:20:15.090 I wouldn't necessarily say engineers own a slice of the context. Uh, we... Uh, and maybe, maybe it is. So, so a PM at PostHog usually has a number of teams under them. Um, usually three is like a happy spot. 104 00:20:15.630 --> 00:20:20.050 Um, and, and we, we keep them stretched intentionally, but... 105 00:20:20.090 --> 00:20:33.530 So, so maybe in that light, like if a, if a PM at PostHog has three teams, then they give one third of their context to the, you know, the feature flags team, and then the feature flags team owns that slice. 106 00:20:33.590 --> 00:20:45.950 So y- I think that could be true. It's not true that the PM has all the context about feature flags and then just doles out the little bits that the engineers can handle. That's not it at all. 107 00:20:46.470 --> 00:20:59.230 The, the PM is responsible for gathering that context, um, and, and bringing it all to the engineers. Um, the PMs also, uh, own pricing at PostHog, which is incredibly important. 108 00:20:59.590 --> 00:21:10.010 Um, and that's usually, uh, an area that the PMs own completely, pricing and launch, um, that, you know, the engineers aren't really involved in those types of decisions. 109 00:21:10.070 --> 00:21:15.130 So I think maybe on the, on the pricing side, they're not always needing to give all of that context to the engineers. 110 00:21:15.190 --> 00:21:24.390 Although with the, um, with the relationships that our PMs usually have with them, that, that context is given. They're, you know, they're asking for feedback from the engineers, et cetera. 111 00:21:24.810 --> 00:21:37.050 So r- regarding like asking feedback and collaboration between product engineers, I read one of the lat- latest articles from the newsletter that said like, "Collaboration sucks." It was very [laughs] 112 00:21:37.070 --> 00:21:49.610 it was very strong, strong, uh, opinion there, and I see it, I think it triggered a lot of people for sure. But you know, maybe- Yeah... could you get a bit more into that? Yeah. That's about speed really. 113 00:21:49.730 --> 00:21:54.890 Um, and, and making good decisions, but I think, uh, it's primarily about speed. 114 00:21:55.230 --> 00:22:04.170 The worst thing that can happen at a company is that you just try so hard to reach consensus with everyone that you never actually do anything. 115 00:22:04.710 --> 00:22:17.750 Um, there is no world in which you get 10 people into a room and they're all going to agree on everything. Um, at least not within a short amount of time. Uh, and we're a startup. We want to move fast. 116 00:22:17.810 --> 00:22:32.550 We need to move fast. And if we are wasting, you know, half of our available time on trying to get everyone into agreement, then we're getting half as much done. So, so really, uh, 117 00:22:35.290 --> 00:22:42.700 the, the reason that we try and limit collaboration a little bit is the, is the same thing. Like, uh, it's, I guess, it... you... 118 00:22:42.810 --> 00:22:57.490 it can be seen in the fact that we try and have a single engineer who can do all the back end code changes and all the front end code changes, because when you have to get multiple people involved, it just slows everything down, um, whether it's because of a handoff or differences of opinion. 119 00:22:57.530 --> 00:23:07.650 When you can get a single engineer who takes the thing, does it all, and ships it, and then they can hear feedback from customers and iterate from there, then, um, then that works really well. Um, so 120 00:23:08.790 --> 00:23:24.950 we, it's not that we don't actively look for opinions from others. It's that you really shouldn't try and get opinions from everyone. Um, and, and to not insert yourself, um, where you don't need to be. 121 00:23:25.050 --> 00:23:39.430 So for instance, um, w- we were dealing with a, a, a people issue, um, on, on the, at the exec level. Um, and for some reason, someone had tagged me into the thread, so I was aware of it and getting notifications for it. 122 00:23:39.450 --> 00:23:48.029 And then they'd say something and then I'd respond. Um, but then Tim ended up being like, "Raquel, I appreciate you being here, but you don't need to be here right now." And I was like, "Oh, you're totally right. 123 00:23:48.070 --> 00:23:58.590 Like, I'm wasting my time," right? "I'm not being that helpful here. You don't need my opinions." Um, so I, you know, turned off reply notifications for that thread so that I stopped getting notified about it. 124 00:23:59.190 --> 00:24:11.830 Um, and, and I think that, like being aware of what you, when, when you need people involved, who you need involved, and who you don't need involved is really important as an organization. 125 00:24:12.330 --> 00:24:22.146 So we have an RFC process, for instance, um, where a request for comments is an RFC. And That's where you write out everything, you lay all the context out. 126 00:24:22.346

--> 00:24:31.086 Th- this is the decision we're making, this, this is the context involved, these are the potential solutions, this is my recommendation and here's why. Um, and then you tag certain people in. 127 00:24:31.126 --> 00:24:38.586 You say, "I think I need your opinion because you know about this one thing. I think I need this other opinion, person's opinion because they know about this other thing." 128 00:24:38.966 --> 00:24:44.286 And then you can, you know, request for those specific people to give you their thoughts. 129 00:24:44.706 --> 00:24:55.406 But the worst thing is when, you know, you have a decision that needs to be made that isn't really all that important, and then 10 people come in with their own opinions, and then it just slows down. 130 00:24:55.486 --> 00:25:08.366 And so I think that was Charles's, Collaboration Sucks was Charles's honestly very great take on, like, how to think about why and when you're getting people involved, because a lot of the time, you know, someone just needs to make a decision. 131 00:25:09.206 --> 00:25:15.566 So I can imagine someone listening to, to this episode may think, "Okay, but if you work like this, you may be 132 00:25:16.486 --> 00:25:26.126 losing in terms of, like, diversity of perspective, like if you don't have like, you, you don't really act as a team. You're like, have, what, one person does it, is doing everything." 133 00:25:26.156 --> 00:25:39.316 So maybe the, do you think this could be like a cons of working like, uh, in this way? Uh, what would, what would you say to, to, to these people thinking like this? No. Um, when you, when you talk about a team, um, 134 00:25:41.486 --> 00:25:49.206 so it, uh, teams operate more based on feedback after something has happened. So I played volleyball in high school, right? Um, 135 00:25:50.226 --> 00:26:00.525 I would go up to hit the ball, and if I hit it out of bounds or something, the coach comes over and says, "Hey, you hit that ball out of bounds. You should, you know, change the angle of your wrist," or whatever. 136 00:26:01.026 --> 00:26:05.636 It's not like the coach is there holding my wrist while I'm going up to hit the ball, you know? 137 00:26:05.636 --> 00:26:13.726 Like, there's, so I do the thing, and then I get feedback about how it could've been better, and that is hyper valuable, and that is what we want to optimize for. 138 00:26:13.926 --> 00:26:18.806 Um, that way I can make a better decision next time without having slowed down the decision that I made this time. 139 00:26:19.526 --> 00:26:27.406 Um, and then on the diversity of perspectives thing, that's assuming that there are only a few decision-makers in the organization. 140 00:26:28.286 --> 00:26:36.246 But in reality, every single person should be owning their one thing, um, and, and be making decisions about that. 141 00:26:36.306 --> 00:26:48.226 So maybe, you know, you aren't making a decision over here about this thing, um, but you're making a

decision over there about that thing, and we will get the diversity of perspectives and opinions. And I mean, I'm a, 142 00:26:49.206 --> 00:27:01.406 I'm classically someone who throws my opinion in on things. Um, and so, [laughs] you know, it's not that we're like, "Nobody can come share their opinions about this marketing launch we're gonna do," right? 143 00:27:01.426 --> 00:27:14.426 But, um, it's more about, like, the, the urge to find consensus versus hearing opinions and then the decision-maker knowing I can, I should listen to this or I shouldn't, and I'm just gonna say, "Hey, thanks for your opinion. 144 00:27:14.626 --> 00:27:28.126 See you later. I'm not gonna listen to it right now," um, you know, for, for whatever reasons. Um, so yeah, I think those aren't sup- like, the especially diversity of opinions isn't super valid as a valid downside. 145 00:27:28.366 --> 00:27:44.446 Okay. So, um, back, back to the fun stuff. So what's, what's with the, with the hedgehog? Like, why is the hedgehog the, the mascot of PostHog? Why is the hedgehog the mascot of PostHog? Um, 146 00:27:45.966 --> 00:27:58.346 I don't really know. Max predated me at the company. Max is the hedgehog's name. Um, we, our AI bot was called Max for a little bit, but now it's just PostHog AI, but the hedgehog is still named Max. Um, 147 00:27:59.666 --> 00:28:12.306 and I think the hedgehog exists, Tim and James didn't want, like, a boring SaaS company. Um, and so one of the first hires that they made was Lottie, who's our illustrator, and, 148 00:28:13.686 --> 00:28:19.946 uh, this is again, like, what happens when you just kind of give people free rein to, to do what they think is cool and important. 149 00:28:20.546 --> 00:28:32.586 And so Lottie has drawn, I don't know, she should count the number of hedgehogs that she's drawn in her, uh, probably coming up on six years here at PostHog. Um, it's, it's [laughs] probably insane. 150 00:28:32.626 --> 00:28:35.346 She probably doesn't even wanna know how many hedgehogs she's drawn. 151 00:28:35.386 --> 00:28:45.086 But, uh, but yeah, it just, I think, came about because they hired her and said, "Do this, do this thing, and we don't wanna be a nor- normal, boring SaaS company." 152 00:28:45.686 --> 00:28:56.446 Um, and so Max definitely has taken on a life of his own, and, um, is a really important beloved part of our brand. Um, I think 153 00:28:57.406 --> 00:29:07.066 if any, if anyone is thinking about starting a company and asking themselves whether or not they ha- they should have a mascot, um, I'd say the answer is absolutely yes, you should have a mascot. 154 00:29:07.106 --> 00:29:22.206 It's, it's such a fun way for us to express ourselves, um, just with a s- silly little hedgehog mascot. [laughs] Yeah. And also, the, the, the website, like, I think, uh, there's, there was a complete redesign. 155 00:29:22.266 --> 00:29:29.276 It was, it was kind of fun to see it, like, looks like an operative system. Yeah. So the, the- Yeah... it's, it's good to be on there. 156 00:29:29.276 --> 00:29:40.586 That was pretty wild, and again, that, that's a result of, uh, someone having a vision. That someone being Corey, uh, our, our designer. Um, he had a vision for the website. 157 00:29:40.686 --> 00:29:54.906 Uh, honestly, one of the, the, where it came from is PostHog has so many products, and it's really hard to make something simple with all the information that we need to be able to give about it. 158 00:29:55.686 --> 00:30:08.086 Um, and so Corey was thinking like, "Well, what's something that has basically infinite possibility and flexibility, but that still has, like, good information hierarchy?" And he thought about an OS, right? 159 00:30:08.246 --> 00:30:20.866 Like y- your, your macOS or your Windows OS. And so he designed it around that, and just was able to push forward and do this, like, wild, crazy project. 160 00:30:20.966 --> 00:30:29.722 I think it took him and Eli over six months to build, and, um, it wasn't- Perfect on, on launch, but that's not really what we're optimizing for. 161 00:30:30.302 --> 00:30:42.142 Um, we're optimizing for doing really cool things, and I think a lot of people on the internet said it was, like, the coolest website that has been launched, I don't know, maybe since MySpace profiles were [laughs] 162 00:30:42.662 --> 00:30:56.482 able to be customized. Yeah, pretty cool. And I, I really don't want to, don't want to ask you how fun are your, like, company meetups. I, I... Let's not get into that. [laughs] Oh, they're so fun. We have so much fun. 163 00:30:56.582 --> 00:31:08.622 I just, uh, got back from a call or from a meetup in San Francisco with our data stack team, and yeah, definitely have lots of fun. Yeah. But it's, like, wholesome fun. Uh, PostHog's a very wholesome company. 164 00:31:08.762 --> 00:31:16.502 We're not, like, having wild ragers or anything like that. [laughs] Okay. [laughs] Cool. So, um, 165 00:31:17.922 --> 00:31:30.602 in, in, in a, in a, in your article, uh, you write that, uh, part of the formula of, you know, having fun as an engineer is also this kind of, uh, dopamine rush you get, um, 166 00:31:31.522 --> 00:31:44.882 uh, with coding, like pro- solving problems and, you know, that, that's what we really like to do as engineers. But now, uh, with AI, this kind of fun can kind of be threatened, right? Um, so how... 167 00:31:45.392 --> 00:31:54.522 W- what have you been seeing in the, uh, happening regarding this also in, with the engineers at PostHog? Yeah. Um, 168 00:31:55.962 --> 00:32:08.002 that, that's actually an interesting question in terms of how AI, like, makes the job of an engineer more or less fun. I think Dylan, uh, Martin wrote about this recently. 169 00:32:08.102 --> 00:32:17.842 I can send you the link later, uh, to his website. But he, he was saying that his role still is just as fun, but it's very different today than it was three years ago when I wrote that article.

170 00:32:18.502 --> 00:32:30.582 Um, and then this week I was actually doing some coding, and the, the whole workflow is very different. Um, it's more obviously prompting than it is actually hand-writing code. Um, 171 00:32:31.682 --> 00:32:46.422 and if I think about, like, what it used to be back then versus what it is now, um, so I used to pick up a problem, say it was a, a part of the code base I hadn't worked in at all, 'cause that's the type of problem that I was working on this past week. 172 00:32:47.022 --> 00:32:49.542 Um, and I'd, I'd pick up the problem. 173 00:32:49.602 --> 00:33:03.162 I'd have to wade through the files to find what I'm looking for, kind of, you know, ef- eventually find my way to a file that I think is what I want to be changing, and then actually think about how to make these changes myself. 174 00:33:03.302 --> 00:33:14.522 Um, I... Ob- it wouldn't work the fr- the first time. Almost never does. Um, and so then there's lots of, like, trying different things and, you know, wondering what I'm missing, wading through functions. 175 00:33:14.582 --> 00:33:31.002 And, um, it's, it's very... Like, I, I personally was so involved in the coding that I was doing. Whereas now someone else is doing that coding. Um, and someone is the AI, right? But it's like it's not me. 176 00:33:31.062 --> 00:33:40.982 It's outside of me. So I think it actually, it feels at some times more frustrating. 177 00:33:40.992 --> 00:33:47.602 It's easier to be frustrated when you see someone else doing something wrong and you're like, "No, that's not what I told you to do," versus stumbling through it yourself. 178 00:33:47.662 --> 00:34:00.222 You're like, "Oh yeah, I, I understand why I screwed that up," right? So I think it can be more frustrating to have something else do something wrong. Um, I remember, uh, I was trying to, like... 179 00:34:00.882 --> 00:34:13.222 I, I was building some little draggable nodes in our notebooks, uh, v- for the, you know, uh... You can move a header, right? Um, and drag it around instead of copy and... or copy-paste. Um, and 180 00:34:14.362 --> 00:34:24.822 I said these, "This icon isn't lining up next to any of the headers or the paragraphs. Like, make it line up." And then it did something, like, totally off the wall. And I was like, "What the hell is going on? 181 00:34:24.882 --> 00:34:36.422 All you needed to do was, like, adjust the CSS a little bit for the paragraph tag in this, you know, H2 so that the icon was at the correct height." But it... So it's just like, I don't know. 182 00:34:36.542 --> 00:34:41.712 It's, there's so much more of this like, "Oh, this thing is stupid. What's going on?" But at the same time, 183 00:34:42.861 --> 00:34:55.142 you can manage a lot of these processes at once and still feel proud of the work that you did because you know that at the end of the day, like, I had to tell this thing to not do the stupid thing and actually hand-write the code myself so that it was doing the correct thing. 184 00:34:55.242 --> 00:35:10.622 Um, so there is still that pride in the work. Um, and, and it can be faster, but you have to be so much more on top of it than, than you would normally expect, um, because you're... 185 00:35:10.662 --> 00:35:20.392 Well, I guess maybe not than you would normally expect. You have to be... You're really becoming a, a manager. You have to be a manager for these AI systems. 186 00:35:20.542 --> 00:35:29.062 Um, so management skills are gonna become even more important, which is interesting, I think, um, more than just the coding skills. 187 00:35:30.362 --> 00:35:45.222 But you still, it's, there's still that, like, I don't know, 20% of coding that you have to do yourself because it requires a human brain at this point. Um, I think maybe we'll get beyond that. Um, I don't know. 188 00:35:45.722 --> 00:35:52.702 Like, the pace of change is, is incredibly fast. But, but yeah, there is still the pride in the work because of the work that you're doing. 189 00:35:53.052 --> 00:36:02.501 And then once, I mean, say we get to a point where it's all just management, um, I'm primarily just a manage- like, in management at PostHog right now. Um, and, 190 00:36:03.682 --> 00:36:16.922 and yeah, I don't get the dopamine rush of coding and shipping the features. Um, but I get to be really proud of the things that my team have done. Um, so I don't know. I think, I think it's a different type of 191 00:36:18.702 --> 00:36:35.848 satisfaction, I guess. I'm a big user of Claude and, like, Opus 4., 4.5. It's kind of amazing of what it can do. So like, I generate 90% of my code nowadays with- Like that. Uh- Yeah... 192 00:36:35.848 --> 00:36:44.338 I mean, of course I'm, they're reviewing every- everything. But I, I ca- I can see that I can do three times more in the same amount of time. 193 00:36:45.278 --> 00:37:00.518 Have you, ha- have you, have you seen an increase in, in, like, in productivity in, in the teams you're, you're managing because of, um, AI helping producing more code? And if, like, y- if you've seen new bottlenecks. 194 00:37:01.138 --> 00:37:10.298 I think for areas of the code base that are newer and less complex, AI can really speed things up. 195 00:37:10.358 --> 00:37:25.828 You can, you know, you can basically create a whole new product in a very short amount of time, as long as you're [chuckles] not working in, like, hyper-complex areas of the code base, um, bugs that are really hard to track down. 196 00:37:26.508 --> 00:37:37.918 Uh, so for, like, product analytics, some of the stuff that we have to track down is so deep in there that prompting AI just isn't going to help. Um, you have to, 197 00:37:39.318 --> 00:37:52.838 you have to know so much about where this thing might be happening. Um, maybe some prom- prompting helps, but, but a lot of that i- isn't s- sped up a ton. But in terms of, like, creating UIs and, uh, you know, 198 00:37:54.978 --> 00:38:07.698 bringing new

features to life, um, you know, I spent a couple hours this week and made a whole new variable scene to manage all your SQL variables, and, uh, it, that, that is definitely faster. 199 00:38:09.008 --> 00:38:14.458 I read a book called Frictionless. Um, I don't know that I would... 200 00:38:14.498 --> 00:38:26.258 The, the first chapter of the book I felt like was useful in, um, kind of explaining why DevX is actually so much more important in the era of AI, and it's, their hypothesis is that 201 00:38:27.638 --> 00:38:49.548 y- because code is made faster, um, if you used to have a 15-minute slowdown on a PR that took four hours, then, you know, a, a DevX slowdown, meaning it takes 15 extra minutes to, like, deal with test failures or getting your stack up and running or, or whatever it is, um, that, that only represents, like, 6% of... 202 00:38:49.808 --> 00:38:59.978 I forget what the actual number is, 4% or 6%. Um, 6% of the time that that actual PR took in order to write. But now if it takes 15 minutes to write a PR with AI, 203 00:39:01.198 --> 00:39:15.507 um, 15 minutes of the engineer's time, and then there's a 15-minute DevX slowdown, um, that's 100% of the time that that PR took is now also taken up by DevX issues. Um, so, so their, uh, 204 00:39:16.818 --> 00:39:29.638 hypothesis was that, like, DevX is gonna become more and more and more important, uh, as AI becomes more of the, the, the thing writing the code. I don't wanna say the person writing the code. 205 00:39:30.138 --> 00:39:40.858 Um, but, but so we, uh, we are prioritizing DevX. I think we, we have a higher-up right now for, uh, someone to work on DevX at PostHog to make sure that... 206 00:39:40.878 --> 00:39:51.438 And it's not about, like, creating a great dev e- dev environment for agents. I mean, that is part of it, but also for the people who are having to manage the agents and manage getting their PRs through. 207 00:39:52.078 --> 00:40:01.178 What does that actually look like, and how do we keep them moving fast and not slow them down? Um, so I wouldn't say our DevX... I think our DevX is actually quite good. 208 00:40:01.818 --> 00:40:12.198 Um, if you, like, if you look at all the companies, you know, where's the median and where's PostHog, um, I think our DevX is actually quite good. Is it amazing? Is it standout? I wouldn't say we're there yet. 209 00:40:12.318 --> 00:40:19.638 Um, so that's definitely an area that we're looking at improving because, really because it just matters so much more. 210 00:40:19.738 --> 00:40:31.978 One, as our workforce grows, the more engineers we hire, [chuckles] the more painful and the more time these issues, um, cost us. But, um, but because really AI just speeds up the, the workflow. 211 00:40:33.498 --> 00:40:44.078 And, and what about, um, the impact of AI, uh, on, on the product development process as a whole? Do you see any, any, any improvements there thanks to AI? 212 00:40:44.498 --> 00:40:51.577 So similarly, we've

been working on PostHog AI, which is our own agent for analyzing your data, right? 213 00:40:51.707 --> 00:41:00.538 And it's been kind of slowly, but then suddenly you look at it and it's like, "Oh, this actually works really well," so now we use PostHog AI for a lot of our data analysis. 214 00:41:01.018 --> 00:41:06.138 Um, show me how many people clicked this button this week, or what's our retention look like over time for this feature. 215 00:41:06.598 --> 00:41:17.318 Um, those are things you could oftentimes do in our UI with the buttons or write your own SQL queries. Now PostHog AI can do a lot of that for you. We are gonna be releasing a, 216 00:41:18.508 --> 00:41:26.458 um, and I'm talking about our products because we use our products so much, but we're gonna... for our product development process. But we're gonna be releasing, like, a, a deep research mode. 217 00:41:26.538 --> 00:41:37.418 Um, and our product managers have already started using that to create their, what we call growth reviews, which is, like, a monthly review, detailed review of all of our metrics for a certain product. 218 00:41:37.518 --> 00:41:49.258 Um, and so I know Anna, one of our PMs, has already started using that to draft out her growth reviews and, and gather a lot of the metrics and do a lot of the analysis that can be done within our data. Um, 219 00:41:50.218 --> 00:41:57.438 so then, so those are two ways that, like, it just makes the, um, the research process so much faster. 220 00:41:58.118 --> 00:42:10.538 Um, and then in terms of prototyping, we have some engineers who will just head over to Lovable and say, "Build me a prototype that looks like PostHog or whatever that does, that has these features, X, Y, Z." 221 00:42:11.318 --> 00:42:24.388 I think a lot of people here don't do that because it's almost just as easy to prompt Claude Code and, like, have it generate, uh, the feature or, like, what the, uh, a mock-up, a prototype of the feature could look like, even if it's not actually plumbed in. 222 00:42:25.078 --> 00:42:38.738 Um, so we see that a little bit less than I think, um, other companies might see it. Um, but, but I don't know, it's, it's something that, you know, we do definitely have people doing. Um, and then- 223 00:42:40.686 --> 00:42:52.346 I'm not sure how much the marketing and sales teams are using AI. I know they do demos all the time of tools they've built for ChatGPT or Cloud Code or to make their lives easier or whatever. 224 00:42:52.586 --> 00:43:04.746 Um, so it's definitely, it's very pervasive. We're a very AI-forward company. Um, we're, you know, we're all, all about it. Uh, as long as the, um, security protocols are followed. 225 00:43:04.866 --> 00:43:16.146 [laughs] Um, so, you know, don't share anything you shouldn't be sharing, and make sure, you know, you're being smart about it. But, but we, we think there's a ton of opportunity to use AI to make us better. 226 00:43:16.186 --> 00:43:28.746 So it's, it's really all throughout our, our, like, product research and development and even sales and marketing processes. So the... All, all this sounds, sounds very fun. 227 00:43:28.826 --> 00:43:33.686 So it sounds like a very fun place to work with, in. And, um, but 228 00:43:34.606 --> 00:43:47.206 I think also one, one important thing is that growth engineers at PostHog have a lot of ownership and autonomy, and they take responsibility for, for the outcome, right? So, um, how, how, how do, 229 00:43:48.826 --> 00:44:06.206 how do they, um, deal with, with this weight of, of, uh, being responsible for the outcome? I think we... So we, in our hiring processes, we look for people who are high ownership. Uh, I don't think that someone... 230 00:44:06.426 --> 00:44:21.946 Like, someone wouldn't be happy at PostHog if they weren't a high ownership person. Um, it just, that's not how we work. Um, in fact, that's one of the things that we ask, you know, a, a team lead when we 231 00:44:22.946 --> 00:44:34.726 bring a new person onto the team, um, during their probation period is, does this person, are they a driver? Do they own their work? And that means they have the thing that they need to do. They're pushing it forward. 232 00:44:34.766 --> 00:44:38.646 They're finding the next steps. They're making the decisions about what needs to happen. 233 00:44:38.726 --> 00:44:48.026 Um, ultimately, those types of people are okay with the ownership after the fact, after it's shipped, and saying, "Oh, that didn't go very well," right? Um, I... 234 00:44:48.066 --> 00:44:56.526 You know, sometimes there's a disconnect there, but a lot of the time people who have ownership before launch also have ownership after launch. 235 00:44:57.086 --> 00:45:08.766 So really we optimize for people who are just kind of naturally that way, and it doesn't bother them. Um, we also are... We don't blame people for things going poorly. 236 00:45:08.866 --> 00:45:19.166 Um, the, you know, if you ship something and it, it flops, it's, you know, it's not like you get in trouble. But we do expect that you are learning from that and making adjustments. 237 00:45:19.246 --> 00:45:30.666 So if something flops, we would expect that you don't do it the same way the next time. Um, or that you say, "Oh, I did these things poorly, and here's what I learned," right? So that's what's most important. 238 00:45:30.846 --> 00:45:39.866 Um, everybody fails. I have done things poorly in the past. I have failed. Um, so it's not like we're expecting people to be perfect. 239 00:45:39.886 --> 00:45:50.406 But we do expect that everybody is failing forward and being really honest with themselves about what could have gone better, what went right, what didn't go right, and what can I learn for next time. 240 00:45:51.916 --> 00:46:02.166 And I can imagine someone from, from the audience can, can be thinking, um, if everyone has this kind of autonomy and is so senior and they have this kind of s-

entrepreneurial spirit, right? 241 00:46:03.046 --> 00:46:13.406 Um, then how do you actually coordinate anything, and how do you make sure that people, people aren't building duplicate features or maybe they are not being consistent with the rest of the product? 242 00:46:14.086 --> 00:46:20.766 Uh, how, how does that get handled? Yeah. You mentioned having senior people. 243 00:46:21.086 --> 00:46:36.845 Um, and I think that's honestly something to be very aware of is that the way we are set up, we are not set up to help people learn how to be good engineers. Um, we... That doesn't mean we only hire seniors. 244 00:46:36.886 --> 00:46:47.736 We do predominantly hire seniors. Um, every now and then we will bring someone in who has less experience because they, we think that their relevant experience is really strong. 245 00:46:48.286 --> 00:46:57.346 Um, and they, uh, we, we say high slope, so they're gonna learn really quickly, and they will be learning. They will be teaching themselves. 246 00:46:57.386 --> 00:47:04.696 They're not waiting around waiting for someone to mentor them necessarily, right? Um, it's a downside. I mean, I would love to be able to 247 00:47:05.786 --> 00:47:14.246 mentor more junior engineers, but just at, at the stage of company that we are and the way that we're set up, um, it's, it's not really something we can offer. 248 00:47:14.346 --> 00:47:23.206 Um, I don't wanna discourage more younger people from applying, but, um, or, you know, fewer years of experience. Doesn't matter how old you are. 249 00:47:23.306 --> 00:47:29.645 Um, but the, the critical thing is, like, you know, you can move fast and you can make decisions and you can learn really fast. 250 00:47:30.146 --> 00:47:40.946 Um, and oftentimes being senior means that you can just make great decisions faster because you've seen them before. And then in terms of, like, people being... 251 00:47:41.086 --> 00:47:51.246 Making sure that we're working on the right things, we really leave that with the people who are doing it. Uh, we don't, we don't optimize for never duplicating work. 252 00:47:51.926 --> 00:48:00.886 Um, every now and then we will have multiple people working on the same thing, and at some point we catch it, and we say, "Whoops," you know? "Maybe we, [laughs] maybe we should have talked a little bit more." 253 00:48:00.906 --> 00:48:13.526 But I think that is better than requiring that everybody have, like, approval processes that take 15 sign-offs before it can happen. Um, because that's just super slow. 254 00:48:13.606 --> 00:48:28.366 And so I guess one way that we, we do try and manage this a little bit is that, uh, we keep all management layers super stretched thin at PostHog, which means that, um, at one point I had, like, 13 or 14 teams under me. 255 00:48:28.486 --> 00:48:37.506 Um, and I would attend their stand-up, or not their stand-ups, their sprint plannings, and, um, and just kind of listen at a high level, what are these people working on? Um, and then I would... 256 00:48:37.546 --> 00:48:47.474 You know, the hope is that- Within those 14 teams, one of them I might hear, or two of them I might hear are working on a similar thing and I'm like, "Hey, you two should go talk to each other." 257 00:48:47.594 --> 00:48:56.814 Or maybe, um, one of the other execs is, who's watching over a bunch of other teams, um, says, "Oh yeah, our team's gonna work on this." And I say, "Oh, I heard about that too." 258 00:48:56.974 --> 00:49:03.694 And that just means that there are fewer layers of management, um, in which, like, the communication needs to happen. 259 00:49:04.554 --> 00:49:14.973 So, so yeah, we, I think keeping management stretched thin across a lot of the company is really helpful for that. But then also making a choice as to what you're optimizing for. 260 00:49:15.004 --> 00:49:20.504 Are you optimizing for never having two teams work on the same thing, or are you optimizing for speed? And we've chosen speed. 261 00:49:22.594 --> 00:49:37.464 So as, as an executive, what do you think are going to be the hardest, hardest things to protect as PostHog grows, maybe out of the startup, uh, stage, and, uh, in terms of working in this fun way? 262 00:49:39.214 --> 00:49:55.034 I think, uh, what worries me most is the dilution of talent. Um, we, when you start with a really small team and you know everyone and you know all the work that every single person is doing, 263 00:49:56.114 --> 00:50:06.034 they, it's, it's easy to see who's really pulling their weight and who's not. But when, uh, when we're so diversified across... 264 00:50:06.074 --> 00:50:23.014 Not diversified in like people sense, but across the, the different things that we work on, um, it's, it's hard to know, like, is this just a really challenging area for someone to work on, or is it that this, like, function isn't wor- like this part of the org isn't really working that well right now? 265 00:50:23.114 --> 00:50:32.414 Um, those, those are things that I'm not really even sure how to answer right now. And, and we're trying to figure that out. Um, because 266 00:50:34.134 --> 00:50:42.754 the, there's, there's so much variety in terms of, and so much variability in terms of, like, product complexity and product maturity and user base. 267 00:50:42.814 --> 00:50:48.213 And like I s- everyone knows, it's easier to make fast progress on a greenfield project than it is on something mature. 268 00:50:48.254 --> 00:51:03.894 But how much is that impacting and how much should that impact the, um, the rate that people move at? Which for us, you know, speed has a definite correlation with talent. Um, it's not one-to-one. 269 00:51:03.934 --> 00:51:10.254 There are other things that go into talent as well, like making great decisions and being a great communicator. Um, but, but speed is a big part of it. 270 00:51:11.054 --> 00:51:22.014 Um, so yeah, I, I think that's, that's something that worries me, is that

because things get a lot muddier as you grow, how do you know that your talent density is staying super strong? 271 00:51:22.154 --> 00:51:33.554 I think PostHog in general has a very high talent density. Um, I would choose, you know, many, many, many of my coworkers here to, to work on a project with me. 272 00:51:33.674 --> 00:51:41.874 Um, whereas before I didn't even know what talent density looked like before I joined PostHog, I think. Um, and it's just wild how much we have here. 273 00:51:41.954 --> 00:51:45.714 But it is something that I, I start to think about is like, how do we know... 274 00:51:45.774 --> 00:51:56.714 As the, as we get bigger, the waters get less clear, and, and how do we know that we're keeping up the same talent density, I guess, 'cause I think that's super important. Makes sense. Yeah. 275 00:51:56.874 --> 00:52:07.394 Um, okay, so b- before wrapping up, I'd like to ask you if you, how do you predict the, the role of product engineers is going to evolve, like, in the next five years? 276 00:52:08.114 --> 00:52:17.994 Do you think it's gonna stay, like, a bit niche, or maybe it's gonna, more companies are going to adopt it? I think it'll be interesting. Um, I think a lot of people are going to start calling them product engineers. 277 00:52:18.134 --> 00:52:27.114 One of the actual concerns that I have, which I think I'm not alone in this concern, um, but I, I think there's gonna be a lot of people who can go from 278 00:52:28.094 --> 00:52:38.194 zero to 85% in terms of building something that, like, functionally eng- from an engineering perspective, uh, it's 85% of the way there. 279 00:52:38.834 --> 00:52:46.374 But, and so I think a lot of those people will end up calling themselves product engineers. Um, they'll have a strong emphasis on the product part of it. 280 00:52:46.414 --> 00:52:52.794 Like say a, say a PM, um, today who isn't an engineer starts code- vibe coding stuff, right? 281 00:52:52.934 --> 00:53:07.874 They might call themselves a product engineer at that point because they're actually building product, but they're probably gonna be lacking, like, that, that critical last 15%, um, that really makes it a solidly engineered, stable, reliable product. 282 00:53:08.734 --> 00:53:23.214 Um, especially when it comes to, like, growing that in the future. Um, and, and I think that, that problem, I actually worry about that problem in about, maybe not in 5 years, maybe in about 10 to 15 years. 283 00:53:23.474 --> 00:53:29.634 Um, I think it's gonna be harder for students to learn core engineering, uh, concepts. 284 00:53:29.894 --> 00:53:42.334 Um, and so how are we, if, if no one's going through the junior stages of engineering, how do you grow a senior engineer, right, who knows all the edge cases and how these things interact? And I do- I don't know. 285 00:53:42.544 --> 00:53:47.514 I, I think it'll be really interesting. At the same time, the optimist in me says, like, people said the same thing about calculators. 286 00:53:47.894 --> 00:53:55.054 How are people going to understand the math if they just type in the buttons and it gives them the answer, right? And it's like, well, a lot of the time you don't... 287 00:53:55.094 --> 00:54:06.214 I mean, you should understand the concepts, which we still teach in, in school. Um, but I, you know, I, I don't need to hand write out a derivative, you know, every time because I can, you know? 288 00:54:06.294 --> 00:54:15.574 The, the calculator can do it for me. So I don't, I don't really know. I can't predict how that will look, but it is a slight concern that I have, is that we're gonna actually... 289 00:54:15.603 --> 00:54:22.914 I think the role of a senior engineer is gonna become way more valuable. Um, but it's gonna be way harder for people to get there. 290 00:54:23.434 --> 00:54:35.154 I don't think our, like our, our systems are gonna be set up for fostering people to grow into senior engineers. Um, so then product engineering I think will be the mix of people who 291 00:54:36.114 --> 00:54:47.498 are able to, to build products more easily, but still have that, like, core engineering skill set and they can get that last 85%. Um, and- And, uh, you know, we'll... 292 00:54:47.698 --> 00:54:59.318 I think, I think it might actually enable people to be more, um, more product engineers. Like, I think it might actually enable that more people call themselves product engineers. 293 00:54:59.398 --> 00:55:09.658 There are a lot of people who, um, you know, don't... aren't that great with design, don't really feel that comfortable making a front end. But if they can vibe code it together, um, I don't wanna... 294 00:55:09.998 --> 00:55:19.928 You know, front end is my favorite part of the tech stack, but at the same time, it's one of the most flexible, and, like, you don't need it to be as robust as your back end. 295 00:55:20.398 --> 00:55:26.828 Um, and so, you know, letting Claude or whatever your agent of choice is vibe that out, like, that's probably totally fine. 296 00:55:27.238 --> 00:55:38.738 So I imagine we'll find more people being able to pick up the, the front end of the tech stack, um, when, you know, maybe previously they wouldn't have called themselves a product engineer before because of that. 297 00:55:39.178 --> 00:55:51.258 At the same time, I think the best, um, the best product engineers are people who really care about UX, and therefore have kind of found themselves on the front end anyway because that's where they can really impact UX. 298 00:55:51.878 --> 00:56:00.318 Um, so I don't know. I, I think it'll be really interesting. Um, I think it'll be... One thing we've found actually in all of our hiring is it's a little bit harder to find... 299 00:56:02.458 --> 00:56:10.818 It's harder to figure out what are people's actual strengths as opposed to things that AI is just good at, right? 300 00:56:11.018 --> 00:56:24.298 AI can throw together a decent UI really quick, um, but does that mean the person's actually a good product person? That's... It's, it's definitely harder to suss out in, in interviewing. Yep. 301 00:56:24.438 --> 00:56:38.718 It's all about critical thinking, right? Like- Yeah. And, yeah. Yeah. Okay. Um, right. So we're good. At the end of the, this episode, and thank you very much for, for joining the, the podcast. 302 00:56:38.798 --> 00:56:47.578 Um, if anyone has, uh, any questions for you, where they can contact you, where they can find you, where, where are you most active nowadays? Yeah. 303 00:56:47.678 --> 00:56:57.918 Uh, Raquel@, and then I won't say the rest of it, but, uh, people can email me. Um- Find it... and yeah. I, I think that's the best way for people to get in touch. 304 00:56:57.958 --> 00:57:14.478 I also have my own website, but there's, like, nothing there, so. Okay. Okay. Thanks again, Raquel. Cool. Yeah. Thank you, Pepe. We don't wait for space. We build it, we own it, we ship what comes next. 305 00:57:14.558 --> 00:57:20.778 Welcome to the Product Engineer's Podcast. Wow