The Great Maze: Breaking down the Individual Contributor Track
Chapter 1: Breaking down the Individual Contributor Track
How does one become a “Master Product Manager?” Consciously focusing on practicing and developing your craft. This is probably the track that is least understood and least fleshed out, save by a few companies, and many of those companies admit that they haven’t really gotten it right yet. In short, this track is what product managers follow when they don’t want to stop building product directly, but want to feel that they are still progressing, challenging themselves, and being acknowledged for hard fought mastery of skills and domain knowledge that brings value to an organization.
What does an IC track look like?
In practice, it’s a competency framework that includes a matrix of skills with definitions that of what each skill looks like at each level. The most common structure I’e seen is roughly IC 1- IC 7 levels , and have a title that match up with each level, like junior PM, PM, Senior PM, Lead PM, Group PM, and Principle PM. Ideally, each level also has a corresponding salary band, a practice which indicates a transparent culture and equitable salary practices, (both good things for gender equity.)
Facebook has a clear individual contributor track framework, although I have no idea how well it’s been implemented, but from what I know of it, it feels well-constructed. Generally companies that do have a clear IC progression track are of that size and maturity. Modern, but well into stable enterprise development practices. Someone I just spoke to at Spotify admitted that they recently developed an IC track framework but are still figuring out what that looks like in practice.” I’ve developed a few competency frameworks for organizations that I’ve worked for and seen a few others for orgs that I didn’t work for, but consulted or trained at.
Companies who have a developed IC track indicate an attention to employee satisfaction and well-being. Rolling out a developed competency framework and defined levels takes a lot of time, then then takes a lot of effort to implement and train managers and employees on how to approach using the framework for progression and development. Generally, it’s a green flag for me that a company has though through and values what it means to be an IC.
Suggestion: When you are interviewing at a company a great question to ask is if they have a competency framework for the PM role and/or if the company has clear development tracks.
What an IC means can vary from company to company, and that’s sort of the point, it helps define success in that specific context, so you don’t have to guess or wonder. Generally, a key tentpole of this track is gaining enough mastery on the “full stack” of PM skills. PMs at the highest level are not only able to execute it in many different scenarios and problem contexts with confidence, but are also able to train, mentor and champion these practices and processes with other PMs and stakeholders.
An IC 7 product manager would hypothetically be assigned super complex, wooly project with full autonomy and trust of the organization. They would make recommendations on strategy, priority and scope, and the org would (theoretically) follow their plan. They would be viewed as a leader by other functions and would have the influence and authority to influence and structure processes and practice both within product and without it. There would be a strong mentorship component and they might work with junior PMs on the same project, stewarding and mentoring their work towards a delivery deadline.
This track is suited for folks who are very interested in deeply understand how to think about product practice, is exceptionally well versed in full-stack PM skills, has played a pivotal role in customer understanding and solution validation, and has invested significant time in understanding the domain market and competitor landscape. Even if one has a lot of experience, it takes some time for a PM to grow in the highest level of IC if they are a full-time perm position.
I think an IC 7 is an exceptionally difficult role to play in-house because the role are responsible for delivering within situations of immense complexity, but usually have no control over the organization structure, practices or culture, other than the culture that you are able to create around yourself and your teams. It is possible for two senior PMs to have widely different experiences, for better or for worse, at the same company. Often this success or failure has to do unconscious bias, sometimes it has to do with general mismanagement, or perhaps whether a PM came up in the environment or if they were hired in after working at other companies. It’s hard to say what contributes to success or failure. I’ve seen great PMs not resonate with an organization, it doesn’t mean they aren’t great. It means that there are a lot of factors that make a senior PM a fit within a company.
Other Options
If you want to be a senior PM who is still responsible for building stuff, but don’t want to work for a big enterprise company there are other options. The point here is not to quest for the perfect job at the perfect company. Spoiler alert: that doesn’t exist. You are working out what works best for YOU.
You could join a start-up as their first PM hire. In my experience most start-ups try to cut corners by making their first product hire a junior PM. This tends to be a mistake because founders at this stage need someone who can educate them on product development, and go toe to toe with them on product roadmap discussions. This is also a very tough role, and requires someone who is ok with chaos, has strong opinions loosely held, and is capable of relinquishing certain battles in order to better win the war. The best case scenario for this type of role is that the person would come in early, and potentially be given co-founder status. The other difficulty is that this role would be responsible for delivering early on, but in most cases have to quickly move into management and leadership as the org grew.
You could also join an agency as a consultant PM. I worked for Pivotal Labs for three years, and many Pivotal alumni go on to found their own agencies because they like working that way. This is a circumstance that will most likely let you focus on building and delivering work. You are typically protecting from having to sell the work. The projects are focused, and scoped, and there is usually a clear(ish) deadline or milestones for what you have to deliver. It’s a great structure for getting really good at executing and delivering quickly. I loved my time at Pivotal Labs, but I also recognize that most agencies aren’t run that way. Most consultants don’t have any say in scope that is contracted or the deadlines decided. If your agency isn’t great at selling or standing up for good process, you might not be allowed to do research or conduct D+Fs.
The final option if you are a really experienced PM that wants to find the most interesting work possible, is to be freelance contractor. This is a really attractive option for a few reasons; 1) you get to scope the work and create a really clear proposal for the work that you’ll do, 2) you have a lot of flexibility in your work schedule, 3) generally the day rate for a PM with 10–15years of experience range from $850–1200 a day, depending on what they are doing. There are downsides too to freelancing, but if you are so inclined freelancing is an option I’ve seen a lot of amazing senior PM take.
Having spent 5 years in leadership roles, I made a conscious decision to head back into freelance contracting as a PM consultant because I really missed just building stuff. I’ve enjoyed it because I’ve been able to combine discovery and framing with enablement, some mentorship, and org coaching, even some executive coaching, while drawing clear boundaries around myself and what i’m there to do. I can focus on what is going to help the work, rather than try to navigate the politics of messy scale-up leadership. I’m not saying that I won’t ever take a leadership role again, but this time of focusing on building and doing has helped me re-discover what I love about product management and software development.
I hope that sticking with an IC role becomes more common place, and that more organizations elevate and value that progression. I’ve seen so many great PMs head blindly into management positions because that’s the only option given to them to progress. This often forces folks who are ill-suited for managerial roles into roles that burn them out, while leaving company without strong voices that have the capacity to steward practice and drive forward great product experiences or innovative solutions.
Up Next — Chapter 2: Management Track
