Product Engineer - What I've Noticed
I've been working as a Product Engineer (PE from here on) at my company for the past few months. The role has been to pick one feature and carry it all the way through on my own — from defining the spec to development and release.
This post is a fairly unpolished dump of what I've felt while doing that work. It isn't a methodology or a proposal for how to work more efficiently. I think the PE role is still being defined, still taking shape. If you come away thinking "so there's a PE out there who sees it this way," that's enough for me.
1. Starting with the Smallest Task
At the point where I switched into the PE role, I only understood what a PM does in the abstract. I read a few books about product management from the library and got a rough sense of it, but actually doing it was a different story.
I talked it over with the PM team beforehand and we agreed I'd start with the smallest unit of work available. Looking back, that was the right call. Early on, getting comfortable with the role mattered more than the size of what I shipped. I spent hours, then days, writing a single spec document, and none of that was wasted.
The hard part was not getting impatient. When I was only writing code, I had something visible to show at the end of each day. During my first few weeks as a PE, I barely wrote any code at all. That time went into getting a feel for the new PM role and for how I wanted to work as a PE going forward.
2. How Should I Be Thinking About This Work?
At first I approached it as stacking the PM role on top of what I already did (backend, frontend). Early in a project I'd be in PM mode defining the spec, and once the spec doc and design were locked, I'd flip into developer mode and write code. I'd been a full-stack engineer all along, so this felt natural. I figured all I had to learn was how to do the PM part.
I had a reason for keeping the two modes strictly separate. I worried that wanting to write code faster, wanting to ship the product faster, would push me into compromising the spec or the design. Once a product spec is settled, the code gets built on top of it. If the code or the system structure started pushing back on the spec, I thought the spec would come out worse for it.
That approach didn't hold up. You simply cannot lock down a spec doc and a design completely and then move to the next stage. Spec work and design work often ran into the middle of the project, and every time they did, I bounced between the two modes. The context switching cost was real, but the bigger problem was how draining it was.
So I changed how I thought about it: there's a single role called Product Engineer, and I'm the one filling it. This might sound like semantics, but for me it made a real difference. There's a team, I'm part of it, and I work as the lead directing the other members. Those members aren't real people, but inside the workflow I've built I manage them, hand them work, and review what they produce as if they were.
And carrying things from the first stage to the last in a single breath turned out to be less exhausting than chopping the work into separate stages.
The reason a single breath matters is the size of the context you have to hold. Documents, code, the release schedule, product quality — all of it lives in your head, and you have to push through before it goes fuzzy. Think about whether you can recall the details of a feature you shipped six months ago. That's why I think a large project running longer than six months is too much for one PE to handle.
As for the compromises I worried about at the start, I no longer see them as automatically bad. I won't make a compromise that shakes the foundation of the spec, but I came to accept small spec changes that make the release smoother and faster as a practical choice. I couldn't always draw that line cleanly.
3. What Was Outside the Process
The PM team would share the rough direction of a feature and why it was needed. I'd pick one and see it through from start to finish.
Back then, this was the entire process in my head.
PM team → Spec writing → PM team review → Spec + design finalized → Development → QA → Release
Outside that flow sat the Voice of Customer, the history of past support tickets, and especially feedback from the Sales and CS teams. I skipped those steps, or went through them as a formality.
This is the mistake that stings the most. Maybe because I've spent so long working as an engineer, my eyes were locked on the pipeline in those arrows. The pipeline is visible and leaves an artifact at every stage. Feedback from Sales and CS doesn't work that way — if you don't go after it deliberately, it just slips past. A product nobody uses means nothing.
4. Reading Is 99, Writing Is 1
Working as a PE, I felt the ratio of reading to writing flip hard. If I exaggerate a little, reading is 99 and writing is 1. This is probably similar for developers too: the amount of code you have to read outgrows the amount you write.
There were two kinds of reading. One was the existing product's code and docs — reading to understand context. The other was reviewing the docs and code the AI produced. The second kind took over more and more of my time.
I didn't read every document end to end. But I read the core early-stage docs myself, start to finish. If there's even a small inconsistency in an upstream document, an LLM widens the gap from the original intent as it moves downstream. So the earlier the document, the more times I read it — two, three passes.
Lately I've been running into a problem where the writing LLMs produce is hard to read. It's not just me; other people describe the same experience. I've installed a few plugins to make the output more readable and cut down on reading time and fatigue.
5. Roll Back Instead of Patching
This follows from the previous section. If a wrong sentence or concept makes it into an early document, the LLM keeps referring back to it through the entire process of building and releasing the product. For example, if the early doc carries even a slightly wrong idea about why this feature exists, the detailed execution plan written later often ends up off-target.
An LLM is software with infinite possibilities open in every direction, all 360 degrees of it. I think the human's job is to narrow that down to the very small range that actually reaches the goal. If the aim is off at the early stage and the angle is wrong, the gap by the final stage is enormous.
So when I felt a document drifting off course while I was writing it, I chose to roll back and start over. That was faster than patching pieces in the middle.
I treated source code the same way — always ready to roll back. Code did get a slightly different approach, though. I'd build it as fast as I could to the point where it satisfied the functional requirements and the feature actually ran, then improve it gradually through code review. That might just be because my background is development, not PM.
Even after seeing the code work, if the result was badly off or implemented wrong in a way that no amount of cleanup would fix, I rolled back and rebuilt it. The important part is reflecting what I didn't like in the design document first. Otherwise you get the same result all over again.
6. I Don't Edit Docs or Code Myself
This is the part of how I work that changed the most.
At each stage of the PDLC, I tried not to be the one directly doing the work. There's one of me as the PE, and separate agents handling each stage. The BMad setup I use has a PM agent for spec documents (John) and a developer agent for implementation (Amelia). They look like people's names, but they're agent names.
Agents don't write every document. I write the very earliest ones myself. intent.md, for instance, is a short document introducing the feature and explaining why it's needed. Since it's the starting point for the whole build, I write it from beginning to end. Sometimes I'll draft it and hand off the rest.
But for the documents produced after that, I don't think it's a good idea for me to go in and edit pieces by hand. The reason is the variety and volume of them. Say I find a passage that describes concept A incorrectly and fix it. Tracking down every other document connected to that concept, reading them, and fixing them all is a lot to ask of a person. Fix one spot and the documents fall out of sync with each other, and that inconsistency shows up plainly at the next stage.
So when I find something wrong, I tell the AI about it and have it find and fix every similar passage across all the documents. Claude and Codex these days combine several tools internally, so they locate and correct things well even across a lot of material. The result is better than what I'd get by hand.
The same goes for source code.
In section 4 I said reading is 99 and writing is 1. This is why the ratio ended up that way. Reading and judging is my share; writing and fixing is the agents'.
7. Workflow
When I started in the PE role, my early goal wasn't to finish a particular feature but to build a workflow.
The premise is this. Everything you produce other than source code exists, in the end, to get source code written. So what mattered was making the spec docs and the intermediate documents easy for the AI to write code from. A spec doc has to be readable by both people and AI, but some intermediate documents don't need a human reader at all. Once you draw that distinction, it's clear where your time should go.
In my case I built and maintained the combination BMad(Spec) + BMad(Custom module) + Ralph loop as my workflow.
- BMad's spec module has an agent ask questions in a fixed order and organize the answers into a document. You don't start from a blank page, and it keeps you from skipping decisions you absolutely have to make. BMad itself forces you through the fundamentals of building a product.
- BMad's custom module acts as a bridge between BMad's output documents and the Ralph loop. It takes the BMad artifacts (ux-design-specification.md, architecture.md, prd.md, epics.md) and produces a file called prd.json.
- The Ralph loop runs during development. Based on prd.json, it works through every Epic and Story in order. Each Story gets its own separate session, so there's little risk of hitting the session token limit. It also tracks progress per Story, so a new session still knows internally where the work stands.
I'm not saying this combination is the right answer. There are far too many techniques out there for writing specs with AI and for building source code with it. The point is to pick a few and turn them into one flow that runs from the first step to the last without breaking. Wherever it breaks, a person has to patch the gap by hand, and that's the moment the single breath I mentioned earlier falls apart.
You can also manage the workflow itself as source code. I kept mine in a separate internal repository called dev-hub. Pull down just dev-hub locally, start claude or codex, and you can get going straight from a command.
That's the record of the past few months. The way I work is still changing, so I expect I'll find things I want to rewrite when I come back to this post in a few months.
I mentioned it briefly above, but the Ralph loop approach seems to come up less often lately. I think that's because Claude and Codex have gotten genuinely good at carrying one large task from start to finish on their own.
Maybe the most important part of working as a PE is that process itself: constantly experimenting with the newest tools and methods, taking them on, and improving from there.