Guest: Raquel Smith, Product & Engineering Executive at PostHog
I invited Raquel because PostHog has pioneered the product engineer role. I’ve been following them for a long time, and they’re one of the companies that shaped how I think about what product engineering looks like when done right. Raquel wrote an article a few years back about why product engineering is the most fun role she’s ever had. I wanted to know if that was still true.
Her answer, more or less: yes. But it requires a very specific kind of company to make it work.
Raquel’s path to PostHog is not the usual one. She studied biology and microbiology. Then she found a company that let her mess around with their WordPress site.
“The first line of code I ever wrote, I wanted to change the header color to orange. I changed the hex number, and I swore I was going to take the site down when I clicked save. But it worked. And it was just this: oh my God, it worked. That’s so cool.”
Then she tried product management for a while, liked the thinking but missed the coding. Started her own startup, owned everything from infrastructure to sales. Then came a job where engineers weren’t empowered, and she could feel the difference immediately.
“I knew that I wanted to code, but I 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. PostHog seemed like a place where I could do that.”
Engineers Make the Final Call
Most companies say they empower engineers. PostHog actually restructured to make it true.
I asked Raquel to explain how decisions get made between PMs and engineers. Her answer was clean:
“At PostHog, engineers are the final call. They decide what to build, when to build, and how to build. That doesn’t mean other people’s opinions aren’t highly valued — we very much value the opinions of product managers, salespeople, marketing folks. But at the end of the day, the engineers are the ones who write the code. So they’re the ones deciding what to build when.”
This isn’t just a management philosophy. It’s a structural commitment. PMs at PostHog own research, context-gathering, pricing, and launch. They bring a detailed picture of the problem to engineers. Then they step back.
“The role of a PM at PostHog is to do the research — understand what needs to be built first, what the competitive landscape looks like, what the numbers look like. Bring all that context to engineers, have a deep conversation. And then it’s handed off for the engineers to say: this is what I’m going to work on.”
What makes it work, Raquel says, is clarity. If you don’t define who owns the decision, you get confusion. If you do, you get speed.
No Guardrails Between Engineers and Customers
One thing that came up repeatedly: at PostHog, engineers talk directly to customers. No intermediary. No approval chain.
“In theory, there are no guardrails. Can you email a customer to ask for their feedback? Can you ask them to get on a customer interview? We’re very much: trust over process. I trust you to make the right call.”
The only exception: large managed accounts, where you check with the account manager first. Otherwise, go straight to the source.
Raquel mentioned she regularly asks interview candidates about their customer interaction history. The answer surprises her every time.
“A lot of the people I interview have unfortunately been put behind a PM or some sort of customer-facing role. Some are never even allowed to talk to customers. For me, that’s just not a fit.”
She described a moment that stuck with me: watching a customer try to drag a node in a notebook, something they expected to work but didn’t. The engineer in the room immediately felt the urgency. That reaction, she said, doesn’t happen through a ticket.
One Person, All the Way Down
PostHog engineers are full stack by design: one person owns front end, back end, middleware, and UX.
“Any time a project has to be handed off to someone else, it slows down so much. It gets in a queue. Someone else has to prioritize it. It’s possible they won’t be able to work on it for a few weeks. We really value having engineers who can write the API, the backend logic, create the front end, make sure the UX is okay — so they can do the entire stack all the way up and down.”
The tradeoff is obvious: this only works with senior engineers, or at least high-slope ones (engineers who learn fast). PostHog predominantly hires seniors and is honest about it. Junior mentorship isn’t part of the model by design, not an oversight.
Collaboration Sucks
PostHog published an article called “Collaboration Sucks.” I asked Raquel about it.
She didn’t walk it back.
“The worst thing that can happen at a company is that you try so hard to reach consensus with everyone that you never actually do anything. There is no world in which you get 10 people in a room and they’re all going to agree on everything. Not within a short amount of time. We’re a startup. We want to move fast. If we’re wasting half our available time trying to get everyone into agreement, we’re getting half as much done.”
They use an RFC process for bigger decisions: write out the context, the options, the recommendation, then tag only the people whose input actually matters. For day-to-day decisions: someone just has to make the call.
She used a volleyball analogy to explain what feedback looks like once that call is made: the coach doesn’t hold your wrist while you’re hitting the ball. You do the thing. Then you hear how to do it better next time.
AI Makes You a Manager Whether You Want to Be or Not
I asked whether AI had changed the fun of the job. Raquel was honest in a way I didn’t expect.
“It feels, at 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 understand why I screwed that up.”
She described spending a couple of hours this past week building a draggable node feature. The whole workflow is prompting now, less hands-in-the-code and more directing.
“You’re really becoming a manager. Management skills are going to become even more important. There’s still that 20% of coding you have to do yourself because it requires a human brain. But it’s a different type of satisfaction.”
Her concern looks further out: if AI handles the early stages of learning, how do junior engineers become seniors? That’s where you internalize edge cases, failure modes, and system behaviour. If that experience gets skipped, the senior pipeline dries up.
Her counterpoint to herself: people said the same thing about calculators.
I’m not sure the analogy fully holds. But I couldn’t shake it either.
What she’s sitting with as PostHog grows is talent density: whether the clarity of who’s great starts to blur as the org gets bigger and product areas get more complex. She’s already sold on the product engineering model.
“When you start with a really small team and you know everyone, it’s easy to see who’s pulling their weight. But as things diversify — across different product complexity, product maturity, user bases — how do you know that your talent density is staying super strong?”
I don’t know the answer either. But it’s the right question to be sitting with before the org gets too big to course-correct.
CONNECT WITH PRODUCT ENGINEERS
Founder: 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.
