From Engineer to PM: How Thinking in Systems Makes You Write Better User Stories

What engineering gives you

When you've spent time doing impact analysis before code releases — asking "what else breaks if we change this?" — you build a mental model of how systems behave under change. You learn that nothing changes in isolation. A field added to a database table, a new step in a workflow, a changed API response — each one has downstream effects that aren't visible from the surface.

That instinct is exactly what makes a PM more useful in a requirements conversation.

Most user stories fail not because the acceptance criteria are vague — though they often are — but because the person writing them hasn't thought through the system state changes the feature implies. They've described the happy path without asking what the system needs to know, remember, or communicate at each transition.

The state machine test

Here's a habit I picked up from my engineering days that I now apply to almost every feature: think of the feature as a state machine. What states can a record, workflow, or document be in? What events trigger transitions between states? What should happen if a transition fails mid-way?

For a digital signature flow, for example:

What engineers actually need from a PM

Early in my product career, I wrote user stories that were basically feature descriptions in "As a user, I want..." clothing. They satisfied the format without doing the work.

What changed was learning to separate three things that often get conflated:

1. The user intent — what they're actually trying to accomplish

2. The system behavior — what needs to happen technically to support that intent

3. The failure modes — what to do when the happy path doesn't play out

Engineers don't need you to design the implementation. But they do need you to have thought through the second and third categories before writing the acceptance criteria. When a PM says "it depends" or "we'll figure that out in the sprint," they're handing the decision to someone who may not have the user context to make it well.

The other side of the bridge

I should say: the engineer-to-PM transition also taught me what I can't do. I can't replace the judgment of a senior engineer who has lived with the system for two years. I can't let my technical instincts override user research that contradicts my assumptions. And I can't mistake "I understand how this works" for "I understand what users need."

Systems thinking is a tool, not a worldview. The best product work I've done has been when I brought the technical lens *into* discovery — asking the right questions earlier, not substituting my answers for the user's.

That, more than anything, is what the engineering years gave me: a vocabulary for asking better questions on both sides of the room.