For the past few months, Product Engineer has been the term I use to introduce myself professionally. It's a new role that has been gaining ground since 2025, popularized on the American startup side by PostHog, and more broadly driven by the arrival of AI in the daily life of product teams.
The idea is simple: a single profile thinks, designs and codes a product, from framing to production. Where just a few years ago it took a multidisciplinary team (Product Manager, Designer, Developer at minimum) to deliver a substantial web project, a Product Engineer can now handle it alone.
Here's what the role actually covers: where it comes from, how I practice it day-to-day, and when to call on this profile rather than a classic team.
Where the Term Comes From
The term "Product Engineer" appeared on the American startup side several years ago, at companies like Stripe, Linear, or PostHog. It refers to a developer who takes on the product as much as they code: they talk to users, they arbitrate design choices, they push feature ideas rather than wait for a spec.
So it's not a brand-new role, but it's gaining popularity now because AI tools have removed the bottlenecks that made this profile hard to sustain.
On the code side, the successive arrival of Cursor, Claude Code, Lovable, and Codex makes it possible to ship in a few days what would have taken several weeks before. On the design side, AI-assisted Figma and new tools like MagicPath make a solo founder capable of delivering a presentable interface. On the product side, ChatGPT and Claude structure a brief, a roadmap, or a spec in minutes.
You obviously still need skills in each domain, product, design, and dev, to steer the AIs effectively and make them produce quality work. But one person's working capacity is dramatically amplified by AI. This brings a change in what team structure is now possible. A single profile can now cover three roles by leaning on AI.
Product Engineer, Product Manager, Designer: Three Roles, a Shifting Boundary
The historical framework is still useful for situating the Product Engineer.
- The Product Manager sets the strategy, prioritizes topics, aligns teams, measures business impact. They think the "why" and the "what".
- The Product Designer designs the experience, the interface, the system. They think the "how the user experiences it".
- The Software Engineer executes, codes, deploys. They think the "how it holds up in production".
The Product Engineer covers all three on a focused scope: one product, one major feature, one MVP. They carry the "why", the "how the user experiences it", and the "how it holds up in production" on the same topic, leaning on AI as an amplifier for each layer.
This versatility doesn't replace the other roles, it adds to them. A PM keeps driving a multi-year product vision, a Designer keeps a coherent design system alive at scale, a Software Engineer holds critical infrastructure in production. The Product Engineer, for their part, takes on a topic end-to-end and ships it.
That's what makes them useful at every stage. A solo founder uses one to go from idea to SaaS in a few weeks. A product team brings one in to prototype before kicking off the dev pipeline. A scale-up entrusts one with a specific initiative (an AI layer, an MCP server, a new user flow), without having to grow the team or mobilize three profiles in parallel.
What changes with AI isn't that the other roles shrink. It's that a fourth role is being added.
What a Product Engineer Is Not
That said, this profile shouldn't be confused with other roles:
- It's not a full-stack dev with a cool title. A full-stack dev writes code from a spec. A Product Engineer writes the spec, then the code, then iterates on usage.
- It's not a Product Manager who vibe codes. A PM won't arbitrate an architecture choice and won't run an optimization refactor.
What I Actually Do, in a Day
A typical Product Engineer day alternates between roles and tasks.
In the morning, I might work on a product spec. Not a 10-page PRD, but a structured note in Markdown format, with the problem, the users, the scope, and the known trade-offs. Codex or Claude help me clarify what I want, and I arbitrate the strategic and structural choices.
In the afternoon, I move to code. One end-to-end feature: Vue components, Supabase functions, SQL modeling. Cursor or Codex write most of the code. I direct, I review, I test, I refactor, I improve. The core skill isn't "knowing how to do everything", it's knowing how to orchestrate the AI to do each layer well enough, while keeping an eye on the quality and coherence of the result.
At the end of the day, I step out of the code. SEO work with Claude Cowork, a LinkedIn post or a tweet on X: content and distribution.
A few times a week, I look at the stats and user behavior: PostHog sessions, completion rates on a flow, logs of MCP calls. It's that work that helps me figure out what to code next.
Across all of this, I arbitrate scope, deadline, and technical debt alone. No prioritization meetings, no handoffs between design and dev.
Four Projects That Illustrate My Product Engineer Role
Here's what I've shipped myself as a Product Engineer over the last 18 months.
Begonia.pro, my Local SEO SaaS. A complete SaaS, launched solo. I thought through the positioning, designed the screens, coded the frontend and backend (Nuxt + Supabase), plugged in Stripe, shipped to production.
Fude.md, a Markdown reader with polished design. A desktop application (Nuxt + Electron + Convex) for comfortably reading your Markdown files, with sync. I handled the product design, the visual design, the app code and its backend architecture, and the addition of an MCP server that opens Fude to AI agents.
A web crawler coded in 3 days. To feed Begonia.pro with SEO data, I needed a robust crawler that could read local business websites. In 3 days, I had a functional crawler with AI as a dev assistant. Before AI, the same project would have taken me 2 to 3 weeks.
SIZR, a macOS app vibe-coded with Codex. A utility app to precisely resize your windows. I had never coded in Swift or for macOS. With Codex, the application was created and functional in under an hour.
When to Bring in a Product Engineer
Four situations where this format makes sense in practice.
- You're a non-technical founder and you want an MVP fast. A PE handles conception, design, and code in parallel, without going through a design agency → dev studio → freelance ops chain. You save coordination time as much as money.
- Your product team wants to prototype before kicking off the dev pipeline. Rather than mobilizing 3 devs on a POC that will be thrown away, a PE delivers a presentable prototype in a few days. The team validates or buries the idea before the main roadmap is touched.
- You're a scale-up that wants to integrate an AI layer without growing the team. A PE comes in as reinforcement, takes on the AI feature end-to-end (design, code, integration with the rest of the product), and leaves. No hiring, no heavy onboarding.
- You have a SaaS and you want to open it up to AI agents. Plugging an MCP server into your SaaS is a good example: it's a new standardized tool designed for AI agents, and a PE who's already built one will handle it much faster than a team discovering it.
The Limits of the Role
The Product Engineer role also has its limits.
A PE doesn't replace a team of 10 on a mature product. The bandwidth of a single brain hits a ceiling fast. At the scale of an existing product with tens of thousands of users, multiple integrations, strong security constraints, and several roadmaps in parallel, a single PE is undersized.
Specialization stays useful on a lot of topics. The security of a product that handles payments demands dedicated expertise. The infrastructure of a platform serving millions of requests per day isn't a PE topic. Neither is the design system of a company with multiple product lines.
A PE is also single-scope: they take on one product or one feature at a time. Asking a PE to hold 4 topics in parallel just doesn't work.
The Product Engineer is a role particularly suited to taking on one product, or to carrying a specific initiative within a larger organization. Not to run a whole company roadmap.
Why This Format Will Spread
AI and models keep improving. Every month, the tools gain capability, and versatility becomes more accessible to profiles who didn't have the time or the inclination to cultivate it.
What will likely emerge in the coming years is a product team structure organized around small "Product Engineer + specialists" pods: a PE who carries a scope, surrounded by specialized profiles (security, data, design system) consulted depending on the topic. Rather than large teams where each role takes its turn.
The shape of product work is changing.
What About You?
How is your product team organizing itself in the face of AI? Does the Product Engineer format have a place in your projects, or do you prefer to keep a classic multidisciplinary team?
📌 If you have an MVP to ship, an existing product to connect to AI, or simply a product topic to dig into, discover my Product Engineering services.