Welcome to the Product Engineer Handbook. Just like our public company handbook, we made this to share how we work, how we think, and ultimately help engineers prepare for the future. Why? Let's start with something obvious.

Software product development is changing. It's faster, less predictable. One industrious engineer with a little help from their friends Claude, Codex, and Copilot (lol, only joking, obv not Copilot!) can ship in a week what used to take whole teams of engineers months.

In this reality, teams and individuals that embrace a broader definition of what constitutes "developer work" will outperform those that cling to old assumptions and norms, and do so while working within smaller, more efficient teams.

We think those teams will be led by product engineers. Unlike a traditionally defined full stack engineer, a product engineer's job goes beyond shipping code. It's about engineering every aspect of the product and what makes it successful.

Product engineers talk to users. They decide what to build. They own pricing, revenue, and user experience. They support customers directly. They're accountable primarily to their users and paying customers. They own product decisions.

The Product Engineer Handbook is about helping developers embrace this new reality. The good news? You can wake up tomorrow and decide to be one. You don't need anyone's permission, least of all ours. All you need is an open mind, a love of building, and the desire to learn.

Reading this handbook will help you understand how to adapt your thinking, the behaviors you should adopt, and the skills you should develop to become a successful product engineer.

Just like our company handbook, where we publicly document our strategy and how we work, the Product Engineer Handbook is a living document. One we will grow, fine-tune, and iterate like any other software product. Consider this version a minimum lovable product.

If you enjoy it, you should sign up to our newsletter, Product for Engineers, so you don't miss out on new chapters.

Got a request for something we should add to the handbook? Leave a comment on this page, or in our community.

In the most general terms, a product engineer is a software developer who:

• Builds products for real users
• Writes full stack code
• Cares deeply about solving the "hair on fire" problems of their users

For us this means product engineers need to be:

• Directly responsible for improving the product and building new features.
• Opinionated on the roadmap and future of the product.
• Able to make design decisions to create great user experiences independently.
• Supporting users directly – all our product engineers also do support.
• More willing to build a product from scratch for users when needed.
• Less loyal to features they’ve added in the past.
• Aware of how their product and work fits into the company's strategy.
• Primarily motivated by the impact of their work and outcomes.

We're not alone in thinking this way. incident.io sums up product engineers as developers who:

"Care more about outcomes and impact than the exact implementation, or the tools used to solve the problem."

Jean-Michel Lemieux, former VP of Engineering at Shopify, defines them as:

"Engineers who have a thirst for using technologies to leapfrog human/user problems. Those with empathy to reach for magical experiences."

Lee Robinson, VP of Developer Education at Cursor, says product engineers "work backwards from the desired product experience" to the technologies that enable it:

"They consider the frontend, backend, design, and everything in between to create a great user experience. They don't need to understand every part deeply, a common misconception of "fullstack". Instead, they have a broad understanding of the available tools and deep experience applying those tools to build products."

Gergely Orosz, The Pragmatic Engineer, describes what he calls product-minded engineers as:

"Developers with lots of interest in the product itself. They want to understand why decisions are made, how people use the product, and love to be involved in making product decisions. They're someone who would likely make a good product manager if they ever decide to give up the joy of engineering."

In sum, a product engineer is someone who cares more about the outcomes and impact of their code on users than the implementation. Their goal is creating a great product for users. A product that solves real problems and, ultimately, sparks joy.

Developers used to spend years learning the specifics of a language’s syntax, the architecture of components, and understanding how code turns into a running application. This was core to creating value in software.

Today, the value of these skills is being driven down: anyone can pay $20 for a machine that spits out code that works well enough. In a world where anyone can have enormous piles of mostly-working code, code is not enough on its own to create an advantage.

But here’s the good news: it never was.

AI can't build your business. You can't plug a large language model into your AWS account and expect it to print money.

Code that works isn’t just code that compiles or passes tests, it’s code that creates results. Results for customers who depend on it. Results for the business that maintains it. Code that keeps the lights on gives you more leverage to reach your goals.

Developers who understand and embrace a broader definition of their role, who obsess over the impact of their work on real users, are more valuable to the teams and products they work on. They're more likely to find satisfaction in their work.

Embracing the product engineer mindset requires a complete reset of how organizations behave. It requires smaller teams, more autonomy, and transparency. It requires minimal process, time to build, trust and feedback. It requires a culture that gives everyone permission to be ambitious.

For individuals, being a product engineer is just plain fun. When you truly understand and engage with the impact of your work on real users, every line of code you write is more meaningful.

For companies, embracing product engineers and the culture they need to flourish, unlocks the kind of speed and agency that allows small companies to out flank larger incumbents. To spark joy in users and build products they truly love. It's a competitive advantage.

In our experience, nothing is more motivating than working with other talented product engineers. The speed, scale, and ambition of problems you can tackle when product engineers work together is on a different level.

As Ant Wilson, CTO and co-founder of Supabase, notes:

"When you find all of the above traits in a single person, your definition of the word ‘feasible’ changes dramatically. At the start of every product cycle, we ask the question “what is the most ambitious thing we can hope to achieve in the next 3 months?”, and the team never fails to push the boundary on what we previously considered reasonable."

And, as one of our colleagues, Danilo Campos, shared in Slack:

"We are surrounded by optimists. By people who want things to work, and believe in their bones things CAN work. An astonishing amount is possible when talented people BELIEVE it’s possible. It’s so much fun to do the things you’re good at when everyone is happy you’re good at them."

Next chapter: Traits of product engineers.