My recent experiences interviewing Product Manager candidates have shown me how being a PM means different things to different people. So to better understand what a candidate has done and is looking for in their next job, I ask them the following question:
“Where do you enjoy working the most; feature, project, product, or business level of a company?”
There’s no single correct answer, but the candidate’s response usually tells me a lot about how they view themselves and how they can be most impactful.
Feature
Feature PMs are people who work primarily with engineering teams to implement functionality via a feature within an existing product. They spend most of their time triaging customer requirements they’ve gathered from sales teams, customer support tickets, and ideally interactions with customers and feeding them into the development process.
A feature PM’s scope is deep, but not wide. Usually, larger companies employ lots of feature PMs to ensure all some kind of consistency for all features they ship. A good example might be for a technical product like Windows which speaks the very complex SMB file protocol, a feature PM might own a specific type of operation (multi-channel reads, write leasing, etc.) of that protocol and report to a PM lead who is responsible for the entire protocol.
A less technical example might be how Facebook employs roughly 20 PMs on their Messenger product, all organized in a hierarchy with the VP of Messenger at the top. At the lowest level, feature PMs are responsible for ensuring Messenger endpoints are all equally accessible and compliant with accessibility regulations. These people will have to become experts in their area of the product, and over time will choose to seek broader scope, or become an expert in more complex subject matter.
From what I’ve observed, most feature PMs have a technical background and are great at exploring complex architectural implementation decisions. Since much of what they do is coordinate complex technical projects between teams while making sure the user’s needs are taken into account at every step of development, feature PMs develop skills communicating technical complexities to their stakeholders.
Given their depth, feature PMs are a great addition to product teams looking to add specific strengths to their roster. If there’s a rapidly growing area of the product which needs someone to have a deep technical understanding of the problem space (e.g. protocols, sync, or data consistency), a feature PM can be a critical addition to the team.
It’s worth mentioning that I’ve interviewed a few feature PMs looking to own a product or work on projects across teams. Usually they’re coming from a large company, and the biggest challenges they have during their interview are:
- The tendency to introduce complexity into a decision and leave it unresolved
- Uneasiness thinking about product decisions from a business- or investor-centric perspective
- Lack of scrappiness and track record of individually producing work vs. coordinating or documenting completed work
However, even if you need the candidate to be able to work at a higher level, it’s important not to dismiss a feature PM right off the bat. There are plenty of smart and talented people working as feature PMs who would thrive given the chance. It might be tricky finding the right one, but the risk can be worth the reward.
Project
Candidates applying for a PM job coming from a consulting background typically answer a lot of questions with examples from various projects they were assigned at their firm. I usually think of these candidates as people most comfortable working at a project level of complexity even if they don’t answer my question that way.
These folks have lots of experience quickly learning a new product or market, and have a mandate to complete a single well defined task within a finite amount of time. In a large company, PMs who enjoy working at the project level might move around from department to department solving similar problems.
For example, before GDPR took effect in Europe, Microsoft deployed a teams of PMs, lawyers, and engineers to work with it’s various business units to ensure GDPR compliance. These people became experts in GDPR as they spent months dropping into teams and executing a plan to bring them into compliance.
When I’m interviewing someone who’s worked at the project level of an organization, especially when they come from a consulting background, I’m interviewing them to see if they can act like an owner. Yes, it’s a bad stereotype consultants don’t care about their clients, but at some level it’s hard to be 100% emotionally invested in something if you’re moving from project to project every few months.
Most of the time, the candidate demonstrates they’re very capable of acting as an owner. In fact, many candidates with consulting backgrounds are looking to make a change specifically because they want more ownership, so they’re almost always a great fit.
Often times, consultants acting as project PMs are great generalists. Given their breadth of experience, they can be dropped into any part of the company, assess a situation, and make or execute on a recommendation.
Product
Unless you’re a founder at a very early stage company, it’s almost impossible to own an entire product end-to-end. However, at most later stage companies there’s a need for a product manager to be involved and take ownership of the entire product development cycle end-to-end.
That means being responsible for the initial customer discovery, defining technical requirements, iterating with engineers and designers to ship the product, and finally defining and executing a go-to-market strategy and being accountable for it’s success or failure.
Most PMs, myself included, grow into this role over time or come into it from a previous startup or leadership experience. Working at a product level requires being able to go up and down in complexity as you oscillate between talking to customers and engineers, and the ability to quickly absorb and synthesize data in ways which resonate to all your stakeholders across your organization. For people who are intellectually curious, this can be an ideal job if they’re willing to put up with lots of context switching.
The most frustrating aspect of working at the product level can be how many stakeholders you have. The company will look to you as a leader, but you’ll need to convince your boss, their peers, as well as your peers in product/sales/marketing/finance to execute on your plans. The amount of social capital you’ll have to build up to effectively do this can seem draining, and for some (including myself) it might seem like this part of the job gets in the way of creating something awesome.
It’s important not to fall for the myth of the lone genius, and to remember creative processes are also collaborative ones most of the time. Developing strong relationships in your organization is a critical part of the job, and as those relationships grow stronger, so does your ability to create.
One thing to watch out for when interviewing, however, is for PMs who would rather spend time building social capital and be everyone’s friend than make hard product decisions. A PM anti-pattern exists where relationships with internal stakeholders are prioritized over doing the hard right thing for the customer.
Unfortunately, this is trait is almost impossible to detect during an interview.
Business
Most of the time, the people who work at a “business” level are in some sort of leadership position in their organization. I’m not that high on the totem pole to be interviewing people for leadership positions, so I have yet to hear a candidate answer with this response.
However, in my mind, all candidates need to demonstrate the ability to align customer and business needs. Can they weigh the pros and cons of a decision based on some framework which takes into account business realities as well as supporting data? Or do they make decisions by over indexing on a single noisy customer’s feedback? Even worse, do they let their own personal feelings about the product drive product development?
Product Management is a strange and evolving discipline. These “levels” all overlap and PMs need to operate at each one of them simultaneously to be successful. Yet, I’ve found this framework useful in assessing how candidates might be most impactful, and I hope you might too.
Big thanks to Dan Golant, Viraj Sinha, and Austin Louden for reviewing this and making me sound better than I am.
Top comments (2)
Nice work, thanks!
great overview!