The Product Engineer Subscribe
FIELD NOTES · WORKING PROFILEv0.5 · OPEN FOR DISCUSSION

The Product Engineer Mental Model

What does a Product Engineer actually do?

I read 15 public sources: definitions, first-person accounts, hiring posts and how teams say they work. I kept 74 short excerpts, word for word, and asked one question of each: what practice is this?

No job postings here, and no sources where the title only renames the usual software engineering job. Every excerpt links to its source.

01 · THE VOICES

15 sources, five kinds of voice.

Eight of them use the title Product Engineer. The rest describe the same work without the title: how a team expects its engineers to work, or what a founder is hiring for. Each source keeps its kind.

    02 · WHERE THE DECISION STARTS

    From the user to the decision.

    Most voices start in the same place: who the user is, the problem they want solved, and their journey to solve it. The decision comes out of that.

      03 · THE PRACTICES

      Eleven practices, not types of person.

      Grouping the excerpts gave me practices, in the order a decision travels from the user and back. Each source covers between two and seven of them, in combinations that don't repeat. So these are things people do in different proportions, not archetypes.

        04 · OWNERSHIP END TO END

        One person, the whole path.

        Ownership end to end is not one more practice. It is the same engineer carrying a piece of work along the path: the user's problem, the decision, the build, and what happens after shipping. Each row is a source; a lit step means it describes that part of the path.

        Where the voices say it outright

        05 · COMPARE

        Who says what.

        Rows are practices, columns are sources. A lit cell means that source has at least one excerpt for that practice.

        Hover or focus a lit cell to read what that source says.

        06 · ONLY NOW, THE DISCIPLINES

        Which knowledge does each practice draw on?

        I start from practices and only then ask which discipline knows how to do them. User/Design here means user-centered and service design, not interface work.

        07 · TENSIONS

        Where the voices disagree.

        08 · THE DEFINITION

        Where the practices meet.

        THE PRODUCT ENGINEER · MY DEFINITION · v0.5

        A Product Engineer is a software engineer who takes part in understanding real users' problems, deciding what is worth building, and turning those decisions into usable solutions. They bring technology, design and product judgment together, carry the solution along the whole path — from the user's problem to the decision, the build and what they learn after shipping — within their scope and with the help they need, working with other disciplines.

        Working definition v0.5, mine, built from the sources above. Not a universal definition.

        Still open

        • The problem is the thinnest practice: voices talk about getting close to users far more than about stating their problem.
        • How much handoff still fits?
        • How close to users is close enough?

        How I read the sources

        15 public sources, reopened on 18 and 19 October 2026 (Osmani and Cherny from captures of 23 September). From each, I kept the activities it attributes to engineers, as verbatim excerpts of at most 25 words. I set aside 7 sources I had read first because they don't show an engineer doing the work: they speak for the PM or the team as a whole, give company-level advice or principles, or are historical. Everyone already knows what a software engineer does; this page is about what goes beyond it. An AI assistant working with me grouped the excerpts into practices and tagged the disciplines each draws on. Counts show where these voices repeat; they don't measure the market. Ashby, incident.io, Intercom, PostHog and Antonio Alegria each appear twice; from Ashby's company-wide principles I kept only the one worked example about an engineer.

        Practices, how many excerpts back each one, and from which sources
        PracticeExcerptsSourcesWho says it
        Get close to who the user is65Andy Vandervell, Eric Roby, Michael Matloka, PostHog, Ryan Ashcraft
        Understand the problem they want solved33Antonio Alegria, Des Traynor
        Follow their journey to solve it76Addy Osmani, Antonio Alegria, Des Traynor, Eric Roby, Ian Carey, PostHog
        Decide what's worth building1310Abhik Pramanik, Addy Osmani, Andy Vandervell, Antonio Alegria, Benjamin Encz, Des Traynor, Edd Sowden, Eric Roby, Michael Matloka, PostHog
        Prototype and ship small65Addy Osmani, Benjamin Encz, Boris Cherny, Des Traynor, Eric Roby
        Build end to end66Antonio Alegria, Boris Cherny, Edd Sowden, Michael Matloka, PostHog
        Simplify and let go44Boris Cherny, Des Traynor, Eric Roby, PostHog
        Learn after shipping129Andy Vandervell, Boris Cherny, Des Traynor, Edd Sowden, Eric Roby, Ian Carey, Macey Baker, PostHog, Ryan Ashcraft
        Keep the system healthy44Abhik Pramanik, Boris Cherny, Edd Sowden, Macey Baker
        Work across disciplines76Abhik Pramanik, Andy Vandervell, Antonio Alegria, Boris Cherny, Eric Roby, Ryan Ashcraft
        Room to work64Andy Vandervell, Antonio Alegria, Edd Sowden, Macey Baker