Subscribe
Share
Share
Embed
What happens when engineers — not product managers — have the final say on what gets built? Raquel Smith is a product executive at PostHog and has lived this model for years. In this episode, she unpacks why product engineering is still the most fun role she's had, how PostHog keeps engineers directly wired to customers with zero gatekeepers, and what it really means to own a feature end to end.
We also get into the uncomfortable parts: how AI is changing the dopamine rush of coding, why collaboration can actually slow you down, and what Raquel worries about most as PostHog scales. Honest, direct, and full of hard-won insights.
---
GUEST
Raquel Smith - Product Executive at PostHog
Raquel took an unconventional path — from a biology/microbiology degree to self-taught engineer, PM, startup founder, and now product executive at one of the most engineer-empowered companies in tech. She's been at PostHog for several years and leads multiple product engineering teams.
Find Raquel:
- PostHog: https://posthog.com
- Email: raquel@[guessthedomain]
---
TIMESTAMPS
01:30 From Biology to Self-Taught Engineer
07:00 The Four Ingredients for Fun at Work
09:00 What Makes PostHog Actually Different
13:00 No Gatekeepers: Engineers Talk Directly to Customers
15:00 End-to-End Ownership and Full-Stack Product Engineering
17:00 Where Engineers End and PMs Begin
20:00 PMs as Context Providers, Not Decision Makers
22:00 Why Collaboration Can Slow You Down
25:00 The Diversity of Perspectives Objection
27:30 Max the Hedgehog and PostHog's Brand
30:00 The PostHog Website Redesign
31:30 Company Meetups
32:00 AI and the Coding Dopamine Rush
37:00 Productivity Gains and New Bottlenecks from AI
41:00 AI Across the Product Development Process
44:00 High Ownership as a Hiring Filter
46:00 Coordinating at Scale Without Bureaucracy
52:00 The Future of Product Engineering
---
KEY TAKEAWAYS
1. Engineers are the final call at PostHog — they decide what to build, when, and how. PMs provide context, not directives.
2. Direct customer contact is non-negotiable. Watching a customer struggle is more motivating than any backlog ticket. No layers between engineers and users.
3. Collaboration has a cost. Single engineers owning features end to end — from API to front end — is faster than consensus-driven teams. Limit who you involve and when.
4. AI changes the feel of coding, not just the speed. It's more like managing a junior dev than writing code yourself — easier to get frustrated when something else does it wrong.
5. DevEx becomes more critical as AI speeds up code output. A 15-minute slowdown that was 6% of a 4-hour PR is 100% of a 15-minute AI-assisted PR.
6. Talent density is the hardest thing to protect at scale. When the org gets complex, it's harder to see who's actually pulling their weight.
---
RESOURCES MENTIONED
- PostHog: https://posthog.com
- "Collaboration Sucks": https://newsletter.posthog.com/p/collaboration-sucks
- Frictionless — book on developer experience in the AI era
- Raquel's article: https://posthog.com/blog/why-product-engineering-is-so-fun
---
CONNECT WITH PRODUCT ENGINEERS
Host: Peppe Silletti
LinkedIn: https://www.linkedin.com/in/peppesilletti/
Website: https://peppesilletti.io
Product Engineers Community:
Website: https://productengineers.com
Newsletter: https://newsletter.productengineers.com
LinkedIn: https://www.linkedin.com/company/product-engineers
---
SUPPORT THE SHOW
If this episode made you rethink how much ownership your engineers actually have, share it with someone who needs to hear it. Drop a comment with your biggest takeaway.
This is a public episode. If you would like to discuss this with other subscribers or get access to bonus episodes, visit
Product Engineers is the podcast about the convergence of product and engineering in the AI era: what's breaking, what's working, and the craft of doing both well.
Didn't want to have a PM telling me where to put the button or how big to make the font. I wanted to make those decisions myself. How does this look at PostHog? What's so different about PostHog?
Engineers are the final call. They decide what to build and when to build and how to build. Have you seen an increase in productivity because of AI? It feels it's sometimes more frustrating.
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" Welcome to What Comes Next, a product engineer podcast.
Today's guest is Raquel Smith, Smith. She's an executive engineering, a product executive from PostHog. So welcome, Raquel. It's great to have you here. Yeah, thank you for having me. Nice.
So let's get started a bit with, with your background story. So you, you have very diverse experience. You actually started with a degree in, in, in biology and microbiology, and then you got into code.
So what happened, like, from that moment to when, until you started working for PostHog? What, what's your story? Uh, yeah, I think, um,
I think if I had had more of a choice or a little bit more maturity, uh, I would have studied computer science in college.
Um, but I think that it's, uh, it ended up being somewhat of a blessing that I didn't, um, because then I was able to find my way on my own, which I think has been really valuable for me learning.
Um, but just the, the short story is that I, uh, found a company that would let me kinda tool around with their website.
Um, and I worked for them as a forum moderator and then web developer, and then kinda grew into some more serious WordPress plugin engineering, and then, um, uh, started building, like, an actual SaaS product with them.
Um, and then did that for a, a little while, decided to try pure product management. Um, and that was fun. I really enjoyed the, like, being able to, to think about the products, but I, I missed coding.
Um, so then I started my own startup and did a large part of the engineering for that, um, and, and really got, I don't know, deeper into engineering than I had been in the past because I was responsible for everything from the infrastructure all the way to, um, not only the, the front-end code and UX, but also, like, how we were, you know, reaching out to potential customers or partners to work with and, um, doing the whole sales cycle as well.
Uh, so that was... Oh, in marketing also. Um, so that was an incredible learning experience. Um, and then when I wrapped that up, um, I didn't want to just be an engineer.
I had been a product manager at a place where engineers, uh, weren't super empowered. Um, and
that I knew that, like, I wanted to code, but I didn't want to have a, a PM telling me where to put the button or how big to make the font. Um, I wanted to make those decisions myself.
So PostHog seemed like a place where I could potentially do that. Um, and, and so that's why I joined and, and I'm still here.
Yeah, so I think it takes a lot of courage to, to do what you did, like going from something that you studied, that was biology and microbiology, to something completely different, and not everyone is kind of,
uh, willing to do, to take that leap, right? So, um, what was really the moment where you realized, like, "I'm done with that and I don't want to do biology, I want to do coding"? Um, I think...
Well, I think I, I knew that, like, I just had more fun. Um, again, you said this podcast was about fun. Um, I just had more fun coding, right? Like, I think the, the first time I ever...
My first line of code I ever wrote, uh, was I had a little WordPress site where I would post recipes and pictures of food. And, uh, and the, like, I wanted to change the header color to orange.
And so I, like, found the style sheet, and then I cha- I found the hex color that I needed to change or the, you know, the CSS property, and I changed the, the hex number to the color that I thought it was gonna be.
And I swore that I was, like, gonna take the site down when I clicked the Save button. Um, but it worked, and it was just this like, "Oh my God, it worked. Like, that's so cool."
I think biology has some similar things, but it's just so much slower.
Um, I'm a fairly fast-paced person, and the fact that I could, like, make a change and see immediately what that change was, um, just was more, much more of a fit for how my brain works and the pace that I like to do things.
I mean, with microbiology, you can have a bunch of experiments going at a time, but like, you know, you, you, uh, plate some microorganisms on a plate, and then you have to wait literally 24 hours, and I just like to see if anything grows, right?
Um, and that just really wasn't, um, wasn't what I wanted. And then the other thing was that I, at my job, a part of my job was, um,
answering questions about our products, um, like technical questions, um, at the, the microbiology place I worked, which is a great company. Um, they're, you know, they're still here doing great.
Um, but I remember I 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.
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.
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.
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.
And, um, it just was much more of a fit for my personality type.
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?
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.
That, that's how I got started, so very similar. [laughs] Yeah. Um- Yeah...
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...
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.
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?
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
why any job can or, you know, may or may not be, um, motivating.
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.
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.
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?
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?
And the more of a black box the company is, the more risky making that decision is going to be. Um,
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.
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,
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
for PostHog, you can actually see that we're, you know, just drastically, wildly open and transparent.
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."
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.
Um, so I think that's really critical.
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.
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,
we, we've had a conversation recently about, uh, fixing little paper cuts that exist across our app.
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."
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."
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,
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?
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-
Really, the, the, the most, the best way to motivate people, your engineers, um, but also motivated people do the best work, right?
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.
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.
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.
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.
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,
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.
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.
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.
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?
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.
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...
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.
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?
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?
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.
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.
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.
Um, and, and that means that there's really only one person ever working on a single feature at a time.
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.
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.
Um, what was the second half of your question? Oh, what- The boundary... what are the boundaries- Yeah... between product managers and product engineers?
Uh, so the, the boundaries, I think it's really important as a company to set up and understand what the boundaries are.
Um, and this is something we're really clear about in our job postings and when we're interviewing product managers.
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.
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.
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.
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.
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.
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.
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
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?
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.
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."
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."
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.
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
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,
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.
But if you don't have that clarity around who owns the decisions, then things, they're gonna get confusing and difficult. Right.
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.
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,
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.
Um, and, and we, we keep them stretched intentionally, but...
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.
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.
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.
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.
So I think maybe on the, on the pricing side, they're not always needing to give all of that context to the engineers.
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.
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]
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.
Um, and, and making good decisions, but I think, uh, it's primarily about speed.
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.
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.
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,
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...
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.
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
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.
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.
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.
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.
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.
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.
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.
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."
And then you can, you know, request for those specific people to give you their thoughts.
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.
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.
So I can imagine someone listening to, to this episode may think, "Okay, but if you work like this, you may be
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."
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,
so it, uh, teams operate more based on feedback after something has happened. So I played volleyball in high school, right? Um,
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.
It's not like the coach is there holding my wrist while I'm going up to hit the ball, you know?
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.
Um, that way I can make a better decision next time without having slowed down the decision that I made this time.
Um, and then on the diversity of perspectives thing, that's assuming that there are only a few decision-makers in the organization.
But in reality, every single person should be owning their one thing, um, and, and be making decisions about that.
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,
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?
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.
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.
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,
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,
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,
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.
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.
She probably doesn't even wanna know how many hedgehogs she's drawn.
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."
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
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.
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.
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.
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.
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.
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?
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.
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.
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]
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.
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.
We're not, like, having wild ragers or anything like that. [laughs] Okay. [laughs] Cool. So, um,
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,
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...
W- what have you been seeing in the, uh, happening regarding this also in, with the engineers at PostHog? Yeah. Um,
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.
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.
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,
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.
Um, and I'd, I'd pick up the problem.
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.
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.
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.
It's outside of me. So I think it actually, it feels at some times more frustrating.
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.
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...
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
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?
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.
It's, there's so much more of this like, "Oh, this thing is stupid. What's going on?" But at the same time,
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.
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...
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.
Um, so management skills are gonna become even more important, which is interesting, I think, um, more than just the coding skills.
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.
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.
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,
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
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...
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.
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.
I think for areas of the code base that are newer and less complex, AI can really speed things up.
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.
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,
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,
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.
I read a book called Frictionless. Um, I don't know that I would...
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
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...
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,
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,
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.
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...
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.
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.
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.
Um, so that's definitely an area that we're looking at improving because, really because it just matters so much more.
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.
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?
So similarly, we've been working on PostHog AI, which is our own agent for analyzing your data, right?
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.
Um, show me how many people clicked this button this week, or what's our retention look like over time for this feature.
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,
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.
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.
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,
so then, so those are two ways that, like, it just makes the, um, the research process so much faster.
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."
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.
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-
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.
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.
[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.
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.
So it sounds like a very fun place to work with, in. And, um, but
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,
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...
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
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.
They're finding the next steps. They're making the decisions about what needs to happen.
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...
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.
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.
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.
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.
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.
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.
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?
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?
Uh, how, how does that get handled? Yeah. You mentioned having senior people.
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.
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.
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.
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
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.
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.
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.
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...
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.
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."
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.
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.
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...
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."
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."
And that just means that there are fewer layers of management, um, in which, like, the communication needs to happen.
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.
Are you optimizing for never having two teams work on the same thing, or are you optimizing for speed? And we've chosen speed.
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?
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,
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...
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?
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
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.
And like I s- everyone knows, it's easier to make fast progress on a greenfield project than it is on something mature.
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.
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.
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?
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.
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.
But it is something that I, I start to think about is like, how do we know...
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.
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?
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.
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
zero to 85% in terms of building something that, like, functionally eng- from an engineering perspective, uh, it's 85% of the way there.
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.
Like say a, say a PM, um, today who isn't an engineer starts code- vibe coding stuff, right?
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.
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.
Um, I think it's gonna be harder for students to learn core engineering, uh, concepts.
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.
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.
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...
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?
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...
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.
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
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...
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.
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...
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.
Um, and so, you know, letting Claude or whatever your agent of choice is vibe that out, like, that's probably totally fine.
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.
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.
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...
It's harder to figure out what are people's actual strengths as opposed to things that AI is just good at, right?
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.
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.
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.
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.
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.
Welcome to the Product Engineer's Podcast. Wow