The (software) product manager job role is far from standardized. It can mean very different things in different organizations. Check how your organization maps across four dimensions to figure out what kind of product manager it needs. And to determine if it’s the right place for you as a PM.
I used to think of product management as a linear progression. Starting from the very first days of a startup, where a founder is driving the whole product vision, to a professionalised, product-led approach.
Something like the pioneer/settler/town planner model, (with some further useful discussion on it here)
Or along the lines of this model from Gartner:
To be fair, the Pioneers/Settlers/Town Planners and the Gartner models aren’t necessarily straightforward maturity models. But they do a good job of articulating different approaches to product management.
What they don’t tell you is where on the model you should be.
I used to think it was just down to the scale of your organization. A smaller one would be more pioneering or instinct-driven, while a larger one would need to become more product-led, or risk becoming a dead-end feature factory.
It turns out that it’s more nuanced than that1. Here are four dimensions that will help clarify what an organization needs when they say product manager:
- Number of employees in the organization
- Number of users
- Nature of the product
- Culture of the organization
There will often be correlation between these, but not always.
Number of employees in the organization
As the organization gets larger, Metcalfe’s law becomes more of a challenge: The more people you have, the number of potential touchpoints goes up exponentially.
A smaller organization is more about individuals. The stakeholder management aspect product role is more about your relationships with specific (probably highly-opinionated) individuals.
As the organization scales the stakeholder management piece becomes much more about aligning multiple stakeholders, handling cross-functional teams and removing organizational obstacles.
Number of users
A product with 10 users is going to feel very different to one with 100 which, in turn will feel very different to one with 1000 or 10,000 etc.
At 10 users, the person running product can intimately know what everyone needs, perhaps better than the users themselves. At 100, one person can still have an overview of all the users but you can start thinking about ideal customer profiles and all that good stuff. If you’re in the 10’s of thousands then user research, customer testing and user segmentation take on a whole new meaning.
Nature of the product
Let’s simplify for a moment and call the (software) product we’re creating a website. Even in this simplified scenario it’s clear that not all websites are created equal.
Assume you’re an airline. You need a website so that people can find your flights, book them, get their loyalty points, get customer support, handle changes and other problems, etc. But the website is not your product. Your product is flying people from one place to another.
Similar story if you’re a hotel or a retailer where the software product is an enabler, it’s not your real product.
Very different story if you’re selling a SaaS product. In this case your web app is your product. Similar if you’re a marketplace: for sure you need the buyers and the sellers on there but your web app is far more central to your product than in the airline or hotel or retailer example.
If you are selling your web app then the nature of the product role is more technical than if you’re not selling your web app. By “more technical” I mean that understanding the art of the possible is a much more important part of the product role than in a similar scale organization where the website because you are likely to be trying to differentiate your product from your competitors more.
Culture of the organization
Imagine an organization that wants to move fast and break things.
Now imagine an organization working in a highly-regulated environment that has a much longer time-horizon.
These will need to take a very different approach to their product management. The move fast and break things culture will prioritise getting things out to users fast. The organization with a longer time-horizon will prioritize more planning, iteration, experimentation and validation before something goes live.
This is not to say that the organization with the longer time-horizon is necessarily going to be more sleepy than the “move fast and break things” one. You can still do experiments at pace even if you’re not delivering working products live. In my experience I’ve seen some products where the users value stability and so would prefer things to know about new features weeks ahead of time, and others where users would jump on a new thing if it can be released in the next few days.
Putting it all together
Here are a few examples based on places I’ve seen.
Company A: <100 employees (more personal than cross-team); >25,000 customers (lots of user testing, user research); B2B2C marketplace (relatively technical understanding needed); Engineering-heavy culture (needed to be relatively nerdy)
Company B: >5,000 employees (lots of cross-functional alignment needed); < 10 customers (new product, so needed to differentiate); B2B SaaS product (relatively technical understanding needed); culture valued slow and steady planning with a long time horizon
Company C: <100 employees; >100 customers; Services company – tech was mainly an internal tool (so didn’t need too much technical know-how); very commercial-focussed culture focussed on building features to help win new clients
Each of these companies had very different needs in their product managers. Not to say one is better and one is worse. Just that, for example, if a Company A or B PM found themselves in Company C they might feel like they were in a feature factory. Conversely, a Company A or C PM would feel stifled in Company B.
- Credit to an inspiring conversation with Andy Richardson, among others, at a London CTOs unconference session about the pros and cons of the CPTO title, followed up by some discussions with the ever-challenging Chirag Shah. ↩︎
Be good, work hard, get lucky 