A deep dive into Product Management leveling at Oscar

“The only thing worse than leveling is not leveling.”

Our Chief Strategy and Policy Officer, Joel Klein, said this at a leadership meeting once where we were discussing the struggle that is leveling — and it is really so true.

I firmly believe that as a company grows, it becomes critically important to give your employees visibility into where they stand, what they need to focus on improving, what’s coming next for them, and what the company is doing and why. In other words, people need clarity and context, both about their own roles and how they fit into the bigger picture.

Seems so simple, right? If only!

A critical part of providing this clarity and context is a comprehensive and easy-to-understand leveling framework. This allows your employees to understand what the expectations are of the level they’re in currently, what they need to demonstrate to be eligible for the next level, and what their potential career progression might look like over time. It provides clarity about the current expectations of them, as well as context about the longer term path and how they are expected to grow.

The product team at Oscar recently rolled out new and improved leveling frameworks for both product management and product design, and these rollouts were so successful that we wanted to share our process and strategy around this with all of you out there that could benefit from it.

The problem

First off, like many startups, we operated for a good few years without any leveling frameworks in place (and we probably waited too long to focus on them). And when we did finally draft our v1, we found that, while we had invested a lot of time and thought into it, it was lacking in a few key ways:

• It was too hard to quickly distill the main differences in expectations between levels. This was partially because the framing document contained lots and lots of text (never a good thing!) and also because the descriptions themselves were a bit too vague and open to interpretation.

Here’s a snippet from our v1 for product management — as you can see, the prose-based layout makes it too difficult to figure out the difference from one level to the next.

• It didn’t include more management-focused levels above Senior Product Manager/Designer, mainly because at the time we crafted it we didn’t have too many people in high-level roles such as director or VP.
• A long tail of other problems such as lack of IC (individual contributor) career path option above a certain level, misuse of the title Technical Product Manager, and so on.

We relied on our v1 for over a year (which was too long), finally deciding to invest in revamping the framework to coincide with our annual performance review process, so that we’d be able to deliver clear performance reviews anchored against improved and consistent criteria.

The process

We decided to tackle product management first (design would come next). After defining the problems we wanted to solve for, we started by doing lots and lots of research about how others handle this. Here are a few resources that ended up being particularly instrumental in helping us craft our solution:

• Sachin Rekhi shared a presentation about product leveling at other tech companies that helped us gut check our levels and titles to make sure they were on par with how others are doing them, and also inspired us regarding the key dimensions of advancement from one level to the next.
• Brent Tworetzy’s post was particularly helpful in guiding us towards the format we ended up using, as we loved the idea of using grids that make it super easy to discern what is expected at each level.

We also talked to a lot of people — from our team about their experiences at prior companies, from Oscar’s other departments, and from outside of Oscar too to learn how other companies do it. This was an important part of the research process as we learned about many different approaches and were able to pick pieces from those that best applied to our situation.

Once we had aligned on our ideal format, we started working on defining the categories and attributes we wanted to include. This was really hard and was where we spent the bulk of our time.

First off, while you can get ideas from others out there, it’s really important to tailor your leveling criteria to your company and its unique culture and environment. For example, at Oscar, given how tightly tech and the business have to operate together, it’s particularly important for product managers to have very strong collaboration and communication skills.

And second, in order to make sure you have the right balance of criteria for each level AND that each criteria is clear and not too open to different interpretations by different people, you have to go through many iterations of wordsmithing to get this right. Many.

The result

We ended up with 5 categories of competencies: strategic thinking, analytical and technical skills, problem solving and user understanding, collaboration and communication, and leadership.

Here is a visual we showed the team to illustrate how we expect these competencies to strengthen over time as someone progresses through levels. As you can see, it helps illustrate what the primary areas of focus are for each level and where the main changes are from level to level.

And for each of the categories, we added 7-8 more specific criteria and showed at what level each was expected. After a ton of time and work put in by several leads on the team (special shout out to Jesse Horowitz), here’s the final result:

A few critical additions

But that’s not all. We realized while doing this that there are a few more pieces that are essential to ensuring the rollout of this goes well:

1) An overarching summary of what external changes you should expect to see as someone’s skills progress and they either get closer to the next level or get promoted. Here’s what we came up with:

As someone progresses through levels, their area of ownership will grow in scope and they will become more independent in managing their area.

Spectrum: P1s start off with specific features or small projects and require help both with prioritization and with specification creation and execution, whereas P5s will be managing a large area (i.e. mapped to another internal department) that includes multiple tech teams and be able to do so without much help beyond guidance on overall company prioritization.

2) Some principles to get ahead of the inevitable questions about edge cases and variations in scenarios that cause this to not always be 100% black and white. Here’s what we came up with:

• A promotion is the recognition that you’ve already been operating at the next level for at least 3-6 months. Note: this is true across our entire company.
• In order to be considered to be “operating at the next level”, you should be demonstrating at least 80% of the expected competencies for that level. For any criteria where you are not quite there yet, the expectation is that you be at par with your current level (no clear gaps or fatal flaws!).
• There are certain core characteristics that must be demonstrated to be at the next level in order for you to be promoted (for example, communication and collaboration), because without them, you will not be able to succeed in that role.
• You may exceed expectations for your level on some competencies but still not be ready for the next level on the whole.

In sum

When we rolled this out, the overwhelming feedback we got was that this was pretty simple, straightforward and clear. In fact, we didn’t get much feedback at all, which I think means it was a success!

Just like in product development, taking something very complicated and distilling it into something simple and clear takes a lot of work. But luckily at Oscar, we’re used to it (because as you probably know, health insurance = insanely complicated!), and we know it’s worth the effort.

We hope this is helpful to any of you out there who are struggling with leveling at your own company. It’s not one size fits all, but the more content we all share with each other, the easier it will be for future product leaders to pull the pieces that are relevant to them and put the right structure in place to enable their team to thrive.

P.S. Product Design leveling details coming soon!