Build A One Page Product Leveling Guide

How to turn a sprawling competency matrix into a one-page system people can actually use

Hi there! It’s Adam again. As a reminder, I started this newsletter to provide a no-bullshit, guided approach to solving some of the hardest problems for people and companies. That includes Growth, Product, and company building. Something on your mind you want advice on? Reply and let me know.

I also have a fun and educational podcast about the intersection of company-building and fatherhood. It’s called Startup Dad and you can check it out here.

---

The majority of product leveling guides solve the right problem using the wrong format.

People need to know where they stand. Managers need a shared language for feedback and promotion. Leaders need consistency across teams. Nobody wants a promotion process driven by vibes, recency bias, or whoever has the loudest manager in calibration or the thickest promo packet (iykyk).

So companies build a leveling guide; typically driven by HR and based on Radford (expert rope maker anyone?). Then that guide slowly becomes a junk drawer and the system falls apart.

Every behavior gets added. Every edge case gets a bullet. Strategy, execution, communication, product sense, influence, data, experimentation, mentorship, and now AI. The list grows until the guide can support almost any conclusion if you squint at the right paragraph. It’s no longer useful. And the junk drawer approach can actually become harmful.

The purpose of a leveling guide isn’t to capture everything that matters. It’s to create shared expectations that improve decisions and continuously raise the bar at every subsequent level.

In this newsletter you’ll learn:

• Why artifact-heavy leveling guides reward work theater instead of outcomes

• Why promotion is often focused on a single moment instead of a sustained pattern

• Why seniority means creating leverage through decisions, mentorship, and AI fluency

• How to compress the a leveling guide into a one-page management system people can actually use

I recently worked through a before-and-after that put a very bright spotlight on the junk drawer problem at Mozilla. We hadn’t updated our Product Management IC leveling guide in ~7 years. The original guide covered six levels across more than 20 rows of expectations: scope, planning, execution, ownership, adaptability, risk, communication, influence, knowledge, craft, and more. Most of the individual statements were reasonable, but they encompassed a lot of “work theater” and focused on tasks rather than real outcomes. Together, they were too dense and too confusing to become effective operating language.

The final version fits on one page. It kept the six levels, added a 7th and compressed the job into a level summary and five dimensions. Mentorship became part of the definition of seniority. AI fluency became a cross-level expectation.

The result was just as rigorous, simpler and more opinionated about what matters.

It required a shift away from PM-shaped activity (the aforementioned “work theater”) and toward increasing impact. The question moves from whether someone performs the visible rituals of product management to:

What changes because this person is in the seat?

Now, I know what you’re thinking: Adam, our company does this just fine. It’s super clear and everyone knows exactly where they stand…

I’m sure you do.

A useful guide shows how a PM creates better outcomes with increasing scope, ambiguity, judgment, and influence. It distinguishes a great moment (“even a broken clock is right twice a day”) from a sustained track record. And it makes clear that seniority is a different kind of contribution; not merely more work.

Here’s what changed.

Start with outcomes

There’s a version of product management that looks great in a leveling document and mediocre in the real world. That is, unfortunately, the version most companies use.

The roadmap is tidy. The update is crisp. The meetings happen (dear GOD do the meetings happen). Decisions are documented. Stakeholders feel included. The PM is fluent in all the rituals of product work. They hold the leading role in the work theater production.

And yet… the product doesn’t move.

That’s the trap with tactical leveling systems. Observable behaviors are easy to describe and defend. You can point to the strategy document, the launch plan, or the stakeholder update. The system feels objective because the evidence is visible.

But those artifacts are tools. They aren’t the outcome. And as my pal Ravi Mehta likes to say: this is a tool, not a rule.

A strong PM improves the odds that the team works on the right problem, makes better tradeoffs, and produces something the customer and business care about. Sometimes that requires a great strategy document. Sometimes it requires killing a project before anyone writes one. Sometimes it requires a hand drawn sketch on a cocktail napkin with a pale blue highlighter.

If the guide doesn’t make that distinction, people optimize for visible work. They create more documents, meetings, and process. They learn to sound senior without creating more leverage. And with AI they learn to crank out an infinite supply of work slop, because it’s easy.

That’s how a leveling guide accidentally teaches the wrong job.

Run outcomes through every dimension

Many guides include one dimension called Product Impact or Product Ownership. That’s where the outcome language lives. Everything else is a checklist of behaviors.

The structure quietly implies that outcomes are one part of the job. They aren’t. Outcomes should run through the entire system:

• Strategy and product sense: Can this person turn insight into choices that improve the odds of a meaningful outcome?

• Execution: Can they move important work through ambiguity without letting the hard parts stall the team?

• Problem solving and judgment: Can they make tough and correct calls when the data is incomplete, the tradeoffs are real, and reasonable people disagree?

• Stakeholder influence: Can they get the right people aligned around decisions that change the outcome?

• Ownership: Is the area meaningfully better because they owned it?

• Team leverage: Do the people and systems around them get better because they’re there?

Now the guide reads like a map of increasing impact rather than a Rube Goldberg machine of product building.

The PM should be able to read the next level and understand the kind of impact they need to create. They should not conclude that they need to write better documents and attend more stakeholder meetings (though if those will drive the outcome then go nuts).

Treat promotion as a pattern

Promotion systems often overvalue the big moment. In fact, most systems do.

Someone ships an important launch, rescues a troubled project, or handles a high-visibility executive request. These moments matter. They show what someone can do under pressure.

They aren’t a promotion case by themselves.

The higher the level, the more the system should ask for a demonstrated pattern of outcomes over time. Not perfection. Not a long inventory of activity. A pattern.

At earlier levels, you’re often evaluating capability: can this person own defined work, operate with growing independence, and deliver a meaningful result?

At senior levels, you’re evaluating durability: can they keep producing outcomes when the problem is ambiguous? Can they make good decisions without an obvious answer? Can they create leverage beyond their own project? And most importantly: can they do it more than once?

The guide should make this rule explicit:

One great launch is good evidence but a sustained pattern makes a great case.

That protects the company from promoting on one shiny episode. It also gives the employee a more honest picture of what the next level requires.

Make seniority a shift in kind

Too many leveling systems treat seniority as a volume knob.

One level owns a project. The next owns a bigger project. Then a portfolio, more stakeholders, more visibility, and—inevitably—a scarier calendar.

That’s a workload escalation plan not a leveling model.

At some point, the contribution has to change in kind:

• A mid-level PM can own a defined area and deliver meaningful outcomes.

• A senior PM can operate through more ambiguity, connect the work to a broader strategy, and produce outcomes repeatedly.

• A principal PM may reframe the domain itself: Which bets should we make? How should the portfolio change? What problem are we actually solving? What future are we underestimating?

More scope may follow but it isn’t the definition and across our industry it’s the thing that has led to the rise of scope-chasers. Gotta fatten that promo packet!

The real shift is leverage: better framing, better judgment under ambiguity, better decisions across groups, better bets, better outcomes through other people, and better taste about what not to do.

If the guide can’t distinguish “bigger” from “different,” people will keep doing the old job at a louder volume and everyone will act surprised when it doesn’t work.

Reward decisions, not comfort

This may be my favorite change I made. Product Management a popularity contest so let’s stop treating it like one in our leveling guides.

“Stakeholder management” can hide a lot of nonsense.

At earlier levels, it often means keeping people informed, navigating dependencies, and preventing surprises. Useful, but not the senior bar.

At higher levels, the job is to help the organization make hard decisions that produce better outcomes.

Consensus is lovely when it happens. I’m pro-consensus in the same way I’m pro-sunny weather: great when available, bad as a dependency. Just ask people in Seattle.

Senior product work involves reasonable people who disagree for reasonable reasons. Sales wants one thing. Engineering sees a different risk. Design is worried about the experience. Support knows where the bodies are buried. Leadership wants speed. The data is suggestive but not decisive. Everything comes with a caveat.

The guide should reward the PM who can turn that mess into a decision—not by steamrolling, but by clarifying the tradeoff, naming the cost, making a recommendation, and helping the group move. And when they move it should (again) be toward a measurable outcome.

That’s a more useful standard than “good stakeholder management.”

Make mentorship part of seniority

I think this may be my second favorite change.

There’s a point in a PM career where individual output is no longer enough. That doesn’t mean everyone becomes a manager. It means senior ICs must multiply the people and systems around them. You do that by sending the ladder down (or sideways or sometimes upwards) to make the entire organization better.

The guide should ask:

Who got better because they worked with this person?

In the final model, mentorship isn’t buried in a separate competency. It appears in the level summaries themselves. A developing PM learns the craft. A mid-level PM begins mentoring junior teammates. A senior PM strengthens peers as well as junior PMs. At the highest levels, developing senior talent and future product leaders is part of the job.

That placement matters because it says team leverage isn’t optional extra credit for senior ICs. It’s part of what seniority means.

Treat AI fluency as cross-cutting craft

As I wrote in my last newsletter on AI Fluency - AI belongs in a modern product guide, but adding another matrix row would repeat the original mistake.

The standard shouldn’t be who tried the most tools or generated the most output. That’s how you get a 47-page PRD nobody reads and a team wondering whether productivity is just work slop with better margins.

Ask instead: Are you and your team better because of AI?

Does it improve the quality, speed, or effectiveness of the work without making the work sloppier? Can the PM use it to explore data, synthesize customer signal, pressure-test strategy, or prepare for a hard decision? Do they verify the output? Do they know where it creates leverage and where it creates risk?

The final guide handles this with a short statement that applies to every level. AI fluency is becoming part of product craft, not a standalone career track. In much the same way you don’t have “Computer PMs” or “Spreadsheet PMs” the notion of an AI PM was a fine moment in time but we need to move past it. In this guide we name the expectation, then evaluate it through the same standards as everything else: judgment, quality, leverage, and outcomes.

Here’s the exact language:

AI fluency is an expected part of modern Product Management practice. Effective Product Managers use AI to improve the quality, speed, and effectiveness of their work while applying sound judgment, thoughtful verification, and an understanding of where AI can provide leverage. As AI continues to evolve, PMs are expected to develop and apply AI-enabled ways of working as part of their ongoing professional growth and craft.

Force the guide onto one page

I forced a single, annoying constraint to make the guide more memorable and it worked great:

Make the core guide fit on one page.

Not because one page is magical. Because the constraint forces choices and because no one wants to scroll through multiple pages.

If everything matters equally, the guide isn’t a guide anymore. It’s a landfill with headings.

The final version used five dimensions:

1. Product ownership and impact

2. Product strategy and sense

3. Execution and delivery

4. Problem solving and judgment

5. Stakeholder influence and alignment

Mentorship lives in the level summaries and AI fluency sits above the matrix as an expectation across the craft. Those choices prevent them from becoming two more columns to remember.

You can argue with the five dimensions. You should. I did. That’s part of the work.

But keeping the guide small enough means a manager can easily use it in a one-on-one and a PM can explain the next level without a translator. Each cell should answer one question:

What does stronger impact look like at this level?

Put tactical skills, examples, and edge cases in supporting material. Especially examples. The one-page guide is the operating system and everything else is reference material.

And remember: if the simple version doesn’t work, the detailed version won’t save you.

Want this guide? Reply to the email that sent you this newsletter and ask. I’ll send it.

Roll it out as a management system

A simple guide can still fail if it arrives as a lengthy policy memo.

People experience leveling changes as possible threats to status, compensation, fairness, and future opportunity. Answer those concerns directly. Explain what changes, what doesn’t, and which tradeoffs led to the decision. Don’t pretend the model is perfect.

Every leveling system is the best of a set of mediocre options. Your goal should be the version that creates the most clarity with the fewest harmful side effects.

Then put the guide where decisions happen. Use it in goal-setting, feedback, one-on-ones, performance conversations, and promotion calibration. Give managers language and examples. Make the levels easy to understand.

If the guide only appears during promotion season, you don’t have a management system.

Wrapping it up: time for the real test

The true test of a leveling guide is whether people can use it.

Can a PM explain what the next level requires?

Can a manager give sharper feedback because of it?

Can a calibration group distinguish one great moment from a sustained pattern?

Can senior PMs see that the next level requires different leverage, not simply more work?

Can the organization reward outcomes rather than PM-shaped work theater?

A one-page guide will be imperfect. Good. Long guides are imperfect too. They just hide it better because no one will take the time to read the damn thing.

The goal is a shared language that improves decisions.

• Outcomes over artifacts.

• Patterns over moments.

• Leverage over volume.

If people can remember those three distinctions—and use them when it matters—you have a a solid start for your leveling guide.

Want to see our single-page leveling guide? Reply to the email that delivered this newsletter and ask. I’ll send it.

Thanks for reading; see you next time.

-Adam