Product Engineer Competency Map

This map answers one question from two directions: what does a product engineer at each level actually do at each stage of the journey?

From above (delegation). A lead uses it to decide how much to hand off to whom, and where to stay close. Find the engineer’s level, read across the row, and you know what you can delegate at each touchpoint and what still needs your eyes.
From below (growth). An engineer uses it to see what they’re expected to own now, and what the next level looks like in concrete behavior, not vibes.

It sits on top of two docs and does not repeat them. Engineering Levels defines what each level is (how much ambiguity you can absorb before you need direction); treat that as the single source for the level definitions. Product Engineer Track defines the mindset (ship, watch, adjust; small PRs behind flags, instrumented and watched; mitigate before investigate). This map applies both across the journey, stage by stage.

Every cell describes an observable behavior: something you could watch someone do, not an adjective you’d argue about.

The Map

Levels run Intern → Junior → Mid → Senior. The spine is the same at every level: the type of work doesn’t change, only how much clarity you need coming in and how much you produce going out.

Touchpoint	Intern	Junior	Mid	Senior
Quarterly Planning	Sits in to see how bets get made; does not size.	Gives a rough size signal on a familiar candidate when asked; says so when unsure.	Sizes non-trivial candidates on request; names the Define-and-testing effort, not just the build.	Challenges scope and sequencing; flags which bets carry the most technical uncertainty so they run first.
Story Mapping	Reads the board to see where their work sits; updates the status of stories they own.	Keeps their stories current; acts as DRI on a small initiative with support.	Owns an initiative end to end as DRI; posts its weekly update; keeps its releases honest.	Shapes the backbone and the initiative breakdown; catches when a board should split or an initiative is spanning two journeys.
Discover	Pulls a specific metric or log when asked; reports what they see.	Surfaces patterns from usage data and error rates; needs the problem framed for them.	Turns a symptom into a clear problem statement and checks it against the data before calling it done.	Finds the problem worth solving from vague direction; rules out non-tech fixes early.
Define	Contributes in the session; follows the definition doc, does not write the engineer section.	Writes the engineer section with review; sees the solution once the problem is clear.	Owns the engineer section and gives the green light; argues build/buy/open-source and boring technology.	Co-leads the session; finds the elegant solution from first principles; sets performance expectations up front.
Build	Drives AI on tasks with explicit acceptance criteria; asks when the output looks off.	Drives AI on a scoped story; reviews output against the doc; escalates when scope shifts.	Drives AI on complex work; ships small PRs behind flags, instrumented; keeps the project’s `CLAUDE.md` current.	Directs implementation and reviews others’ output for correctness and maintainability; unblocks the team.
Launch	Executes assigned release steps; does not own the rollout.	Follows the release plan reliably; confirms the feature is live.	Owns a feature’s rollout behind a flag; confirms the instrumentation reports before calling it done.	Owns the release end to end; mitigates before investigating when a number moves; anticipates risk before it surfaces.
Learn	Reflects on their own work in the session.	Writes the knowledge artifact for the area they built.	Reviews what was built for maintainability and performance; names regressions honestly.	Connects the miss or the win to how the team builds next; turns a learning into a process change.

The five middle rows (Discover through Learn) sharpen the Engineering Levels matrix toward product-engineer craft (instrumentation, flags, AI-driving, the knowledge artifact). The two outer rows (Quarterly Planning, Story Mapping) are where a PE participates in shaping the work, not just delivering it.

What You Can Delegate at Each Level

Read this as the manager’s side of the map. The rule underneath it: delegate one rung past what’s comfortable, then close the gap with review.

Intern. Hand off well-scoped tasks with acceptance criteria spelled out. Stay close on anything ambiguous, and check the output against the definition doc yourself.
Junior. Hand off a scoped story end to end, including its Build and its release. Stay close when scope shifts or the problem needs reframing; those are the moments they’ll come back to you.
Mid. Hand off a whole initiative, from problem statement to launch, with them as DRI. They size, define, build, and ship without supervision. Your job becomes direction and review, not steering.
Senior. Hand off ambiguous direction, not problems. They find the problem, shape the solution, and raise the bar for the engineers around them. Delegate the things you would otherwise keep for yourself.

If you can’t yet delegate at the level someone is supposed to be, that gap is the coaching agenda.

Reading Your Own Column

Read this as the engineer’s side of the map. Your level is defined by what you can take in: how much ambiguity you can absorb before you need the problem clarified. Moving up is always the same move, applied earlier in the journey.

Intern → Junior. Stop needing acceptance criteria spelled out. Take a scoped task and bring it to completion without being told each step.
Junior → Mid. Take a reported symptom and produce the problem statement yourself, then own the definition doc through to a green light.
Mid → Senior. Stop waiting for the problem. Find and frame it from vague direction, and start shaping how the work runs, not just your own output.
Senior and beyond. The shift is from individual execution to raising the whole team’s ceiling. That conversation happens with leadership.

For the full progression narrative behind each move, see Engineering Levels.