Product Engineering Progression Framework
How to grow as a product engineer. Levels based on demonstrated impact, not tenure.
TL;DR
The Levels:
- L1 - Execute assigned tasks. Understand problems before coding. Ship small PRs daily.
- L2 - Own features end-to-end. Find gaps in requirements. Measure outcomes, not output.
- L3 - Define problems for your team. Make tech decisions that serve business needs. Multiply team effectiveness.
- L4 - Set technical direction across teams. Shape product strategy through technical insight.
Progression Principles:
- Impact over tenure - demonstrate capability, not years
- Breadth over depth - work across the stack
- Business outcomes over technical perfection - solve the problem, don't over-engineer
- Visibility matters - make your impact seen through communication and collaboration
L1 — Product Engineer I
Scope: Individual tasks and small features within a defined problem space.
Problem Solving
| Expectation | Bad Example | Good Example |
|---|---|---|
| Understand the problem before coding | Start building a "caching layer" immediately when asked | Ask: "What's slow? For whom? How do we measure success?" |
| Ask clarifying questions | Assume you understand the ticket | "This says 'improve search' — are we targeting speed, relevance, or both?" |
| Break work into 1-2 day chunks | Create a branch, disappear for a week | "I'll do the API endpoint today, the frontend tomorrow, tests day after" |
How to know you're doing this well:
- Your PRs merge within 24-48 hours of starting
- You rarely get "that's not what I meant" feedback
- Your manager doesn't need to check in to know your status
Technical Execution
| Expectation | Bad Example | Good Example |
|---|---|---|
| PRs are 50-200 lines, focused | 800-line PR touching 15 files | One PR per concern: refactor, add interface, implement logic |
| PRs explain the "why" | "Added user validation" | "Added email validation — support reported 12 signups last week with invalid emails causing downstream failures" |
| Use structured logging | console.log('user ' + userId + ' failed') | logger.info('payment_failed', { userId, amount, error: err.code, traceId }) |
How to know you're doing this well:
- Reviewers approve without asking "why did you do this?"
- You can find your own bugs in production using logs
- Your PRs get approved same-day
Product Thinking
| Expectation | Bad Example | Good Example |
|---|---|---|
| Know what problem you're solving | "I'm building the notifications feature" | "I'm reducing churn by alerting users before their trial expires — we lose 23% of trials who forget" |
| Understand who's affected | "Users want this" | "Enterprise admins managing 50+ seats need bulk actions — they're doing 50 clicks per onboarding" |
Collaboration
| Expectation | Bad Example | Good Example |
|---|---|---|
| Daily status updates | Radio silence, then "done" on Friday | "Finished API endpoint, starting frontend. Blocked on Figma specs for empty state." |
| Flag blockers within 30 minutes | Struggle silently for 4 hours | "Stuck 30min on auth flow. Tried X, Y, Z. Getting error ABC. Anyone seen this?" |
| Review PRs within 24 hours | PRs sit unreviewed for 3 days | Same-day reviews with specific, actionable feedback |
Ownership
| Expectation | Bad Example | Good Example |
|---|---|---|
| Follow PRs through deployment | Merge and move on | Merge, monitor error rates for 15 minutes, verify in prod, update ticket |
| Participate in incidents | "That's not my code" | Join the call, help investigate, document what you learn |
L2 — Product Engineer II
Scope: Complete features and small projects. Beginning to influence problem definition.
Problem Solving
| Expectation | Bad Example | Good Example |
|---|---|---|
| Identify edge cases before building | Build happy path, discover edge cases in QA | "What happens if the user has no payment method? If they're mid-checkout when their session expires?" |
| Question assumptions | Accept "we need real-time updates" at face value | "Who needs real-time? How fresh is fresh enough? SSE handles 90% of cases without WebSocket complexity." |
| Propose solutions with trade-offs | "We should use Redis" | "Option A: Redis ($50/mo, 10ms latency). Option B: DB caching (free, 50ms). Given our 100 RPM, I recommend B." |
How to know you're doing this well:
- QA rarely finds issues you didn't anticipate
- You push back on requirements and the push-back is appreciated
- You're asked "what do you think?" not just "can you build this?"
Technical Execution
| Expectation | Bad Example | Good Example |
|---|---|---|
| Work across the stack as needed | "I'm a backend engineer" | Fix the React bug blocking your API work instead of waiting for frontend help |
| Balance tech debt with business needs | "We need to refactor before adding features" | "This feature ships with current code. I'll log a ticket to refactor if we add more integrations." |
| Comprehensive observability | Logs only | Logs + metrics (request latency p50/p95) + traces with correlation IDs |
Product Thinking
| Expectation | Bad Example | Good Example |
|---|---|---|
| Suggest improvements based on data | "Users probably want X" | "Amplitude shows 40% drop-off at step 3. Adding progress indicator could help — Instagram saw 15% improvement." |
| Measure outcomes, not output | "I shipped 5 features this quarter" | "The features I shipped reduced support tickets by 30% (from 50/week to 35/week)" |
Collaboration
| Expectation | Bad Example | Good Example |
|---|---|---|
| Proactively communicate risks | "Deadline is Friday, we'll see" | "At current pace, 60% chance we hit Friday. Biggest risk is payment integration. Want to cut scope or extend?" |
| Help onboard new engineers | Point to docs and walk away | Pair for first PR, introduce codebase patterns, check in daily for first week |
| Work effectively with stakeholders | "Product said to build it this way" | "I talked to Sarah in Support — she needs X, Y but not Z. I suggested simplifying to just X, she agreed." |
Ownership
| Expectation | Bad Example | Good Example |
|---|---|---|
| Own features end-to-end | "I built it, PM decides if it's working" | Track adoption (20% of users tried it), gather feedback, propose improvements |
| Write blameless postmortems | "John deployed broken code" | "Deploy at 3pm caused outage. Root cause: missing DB migration. Fix: add migration check to CI." |
| Take initiative within your domain | Wait for tickets | "I noticed slow queries in dashboard. Added indexes. Load time: 3.2s → 400ms." |
L3 — Senior Product Engineer
Scope: Complex projects and systems. Defines problems and solutions for the team.
Problem Solving
| Expectation | Bad Example | Good Example |
|---|---|---|
| Identify problems before they're assigned | Wait for PM to create tickets | "Our error rate spikes every Monday 9am. I dug in — it's the weekly report job. Proposing we move it to 6am." |
| Navigate ambiguity | "Requirements are unclear, can't start" | "I'll build a prototype of approach A, get feedback in 2 days, then commit to direction" |
| Consider second-order effects | "Adding caching will speed things up" | "Caching speeds reads but adds invalidation complexity. For this use case, optimizing the query is simpler." |
How to know you're doing this well:
- You bring problems and solutions to planning, not just estimates
- Junior engineers seek your opinion on architecture
- Your technical proposals get approved without major revisions
Technical Execution
| Expectation | Bad Example | Good Example |
|---|---|---|
| Tech choices serve business needs | "Kubernetes is industry standard" | "For 3 services and 10K users, DigitalOcean App Platform. Kubernetes when we hit 20 services." |
| Appropriate complexity only | Build abstraction for one use case | Three similar implementations is fine. Abstract when fourth appears and pattern is clear. |
| Champion symptom-based alerting | Alert on "DB CPU > 80%" | Alert on "error rate > 1% for 5 min" — users feel symptoms, not CPU. |
| Mentor others | "Read the docs" | Code review that explains the why: "Use useMemo here because this calculation runs on every render (see React profiler)" |
Product Thinking
| Expectation | Bad Example | Good Example |
|---|---|---|
| Partner with PM/stakeholders to define what to build | Build what's specified | "The spec says 'improve checkout'. I interviewed 5 churned users — real issue is surprise shipping costs. Let's show costs earlier." |
| Prioritize impact over perfection | Spend 2 weeks perfecting edge cases | Ship 80% solution in 3 days. Monitor. Edge cases affect 2% of users — fix those next sprint if needed. |
| Connect tech decisions to business outcomes | "We need to refactor the auth system" | "Auth refactor enables SSO. SSO is blocker for 3 enterprise deals worth $150K ARR." |
Collaboration
| Expectation | Bad Example | Good Example |
|---|---|---|
| Multiply team effectiveness | Do all the hard work yourself | Write design doc. Create spike tickets. Enable 3 engineers to work in parallel. |
| Build relationships across the org | Know only your team | Coffee with Sales to understand customer pain points. Lunch with Support to hear common issues. |
| Drive alignment on tech direction | Endless debate in Slack | Write RFC, collect feedback async, schedule 30-min decision meeting, document outcome. |
Ownership
| Expectation | Bad Example | Good Example |
|---|---|---|
| Own outcomes, not deliverables | "Feature is shipped" | "Feature shipped. Adoption at 15% (target: 30%). Hypothesis: discoverability. Testing banner this week." |
| Accountable for system reliability | "Ops handles production" | You own error budget. When checkout errors hit 0.5%, you investigate before being asked. |
| Lead incident response | Wait for someone else to take charge | "I'm taking point. Alice, check DB. Bob, check recent deploys. I'll update status page every 15 min." |
L4 — Staff Product Engineer
Scope: Organization-wide technical strategy. Solves problems that span multiple teams.
Problem Solving
| Expectation | Bad Example | Good Example |
|---|---|---|
| Identify high-leverage problems others haven't seen | Work on assigned projects | "We have 6 teams building their own auth. Centralized auth service saves each team 2 weeks/quarter." |
| Create clarity from org ambiguity | "Leadership hasn't decided on platform strategy" | Write the platform strategy proposal. Circulate. Get buy-in. Present to leadership. |
| Balance short-term and long-term | "We need to stop and rewrite everything" | "Ship this feature with current arch. Parallel track: I'll prototype new arch. Migrate team-by-team over 6 months." |
Technical Execution
| Expectation | Bad Example | Good Example |
|---|---|---|
| Set direction that enables business strategy | "Here's our tech roadmap" | "Business wants to enter EU. Tech implications: GDPR compliance, EU data residency, latency. Here's the 6-month plan." |
| Improve engineering velocity across teams | Optimize your own team | "Flaky tests cost us 2 hours/dev/week across 30 devs. I'm fixing test infrastructure. Expected savings: 60 dev-hours/week." |
| Establish patterns that scale | "My team does it this way" | "Here's the API design guide. Here's the template repo. Here's the service bootstrap script. New services: 2 weeks → 2 days." |
Product Thinking
| Expectation | Bad Example | Good Example |
|---|---|---|
| Shape product strategy through tech insight | Wait for product to define roadmap | "With our new ML pipeline, we can offer personalization that competitors can't. Here's the product opportunity." |
| Identify tech-enabled business opportunities | "Tech is a cost center" | "If we expose our pricing engine as an API, partners can integrate. Potential: new revenue stream, $500K/year." |
| Trusted advisor to leadership | Leadership asks engineering questions elsewhere | CEO asks you directly: "Can we do X by Q3?" You give honest, actionable answer. |
Collaboration
| Expectation | Bad Example | Good Example |
|---|---|---|
| Influence without authority | Tell other teams what to do | "Team X owns this decision. I've shared data and recommendations. I'll support whatever they choose." |
| Build engineering culture | "Culture is HR's job" | Host monthly tech talks. Mentor senior engineers. Write blog posts. Recognize good work publicly. |
| Create forums for technical decisions | Decisions made ad-hoc in Slack | Establish Architecture Review Board. Monthly roadmap syncs. RFC process with clear approvers. |
Ownership
| Expectation | Bad Example | Good Example |
|---|---|---|
| Accountable for org-wide engineering outcomes | "My team's metrics are good" | You care about eng-wide velocity, reliability, developer experience. You own metrics like: deploy frequency, MTTR, developer NPS. |
| Drive initiatives that improve how the org works | Focus only on features | "Our deploy process takes 45 min. I sponsored a project to get it to 10 min. Result: 20% more deploys/week." |
| Represent engineering in company decisions | Engineering is "consulted" | You're in the room for strategic decisions. "If we acquire X, integration is 6 months and requires Y and Z." |
How to Use This Framework
For Self-Assessment
Rate yourself honestly on each dimension at your current level:
| Rating | Meaning |
|---|---|
| Consistently exceeds | You do this better than most at your level, most of the time |
| Meets | You do this reliably |
| Developing | You do this sometimes, or with support |
| Gap | You rarely do this |
Focus on gaps first. Exceeding in one area doesn't compensate for gaps in others.
For Growth Conversations
- Pick 1-2 dimensions where you're ready to stretch
- Identify specific opportunities to practice next-level behaviors
- Ask for feedback after 2-4 weeks
- Adjust and repeat
Don't try to grow everywhere at once. Depth in few areas beats shallow progress in many.
For Promotion Decisions
Promotion = you're already consistently operating at next level, not a reward for potential.
Evidence required:
- 3+ months of sustained next-level performance
- Feedback from peers and cross-functional partners
- Concrete impact examples for each dimension
Common Mistakes
| Mistake | Fix |
|---|---|
| Focusing on years of experience | Track demonstrated impact instead |
| Trying to level up everywhere at once | Pick 1-2 dimensions, go deep |
| Waiting to be given senior work | Take initiative. The work proves the level. |
| Measuring output (PRs, tickets) | Measure outcomes (user impact, business metrics) |
| "I'm a backend engineer" | Product engineers work across the stack as needed |
| Over-engineering for technical elegance | Ship the simplest solution that solves the business problem |
| Silent work | Make impact visible through communication, docs, and collaboration |
| Assuming the spec is correct | Question requirements. Dig into the real problem. |
Related:
- Engineering Onboarding - How we work day-to-day
- Engineering Fundamentals - Technical concepts to master
- Career Levels Overview - Company-wide leveling framework