Different types of product manager: A worked example

In my last post I talked about 4 dimensions that determine what kind of product manager an organization needs:

• Number of employees in the organization
• Number of users for your product
• Nature of the product
• Culture of the organization

Different types of organization and product expect/require different types of product management. We all say “product management” but we can mean very different things when we say it, depending on where the organization and product is along these four dimensions.

Here is an example based on a real experience of mine to illustrate this. It was when I was at Rated People, probably about 2010. It shows how the decision-making around the product (i.e. the product management) was informed by these four dimensions.

Rated People is a marketplace where home-owners post jobs they need done. Each job is notified to relevant tradespeople who can then choose to bid for that job or not. The system figures out if a tradesperson is relevant based on the type of work they do (plumbing, carpentry etc) and which areas they work in.

Which areas they work in was originally set by giving a central address and a distance. The system would calculate a circle using the distance as the radius. This was problematic because it didn’t reflect the reality of where people would travel to for work. Famously, London is split into North and South parts by the river Thames. Crossing the river can be time-consuming. People on the north side are more likely to spend more time on the north side of the river and those on the south to stay on the south side more.

We had three different ideas about how to address this problem.

First approach: Pave The Cow Paths. User testing showed that tradespeople generally thought of their work areas based on postcodes. So we could have come up with a solution that would let you enter a list of postcodes somehow, either by clicking on a map or by writing them into a form.

Second approach: Use the latest tech. In 2010 we now had the ability to draw any shape on a map. This seemed quite neat but when we then put it through user testing, our users found it very frustrating to draw the shape they wanted. This feature would have been a complete non-starter for our users.

Third approach: Lateral-thinking application of new tech. This is what we ended up going with. We approximated a circle with an octagon and allowed the user to drag the corners around. This worked well because if you were happy with the auto-generated circular area, the octagon was pretty much good enough for you. If you wanted to change the area then you could pretty well draw any shape you wanted by dragging the corner points. Hat tip to the mighty Oleg Roshka who did all the heavy lifting to make this feature happen.

The Lateral-thinking application of new tech suited us at the time because of where we were against the four dimensions:

• We were a relatively small organization and so could easily get a few key people on a call together to figure out the right solution together
• We had a relatively high number of customers (10’s of thousands) who weren’t particularly tech-savvy
• We wanted this part of the product to be a differentiator compared to the competition (the tradespeople are the paying side of the marketplace)
• The founder liked relatively elegant tech solutions that generalized well

It’s not a case that the other approaches were worse. They would have been more appropriate in different circumstances. The use the latest tech could have worked if our user base was more tech-savvy, for example. Pave the cow paths could have worked but it would have needed a fair amount of fine-tuning after release because different people, in different parts of the country, needed different levels of granularity to define their work areas.

The organization valued and needed this Lateral-thinking application of new tech at the time. That doesn’t suit all products and all organizations.

Here’s an example where pave the cow paths was the right approach. It’s from no less than Facebook and their photos product in 2005:

[E]very development in the Facebook photos product can be linked to that moment in 2005 when the team saw how people were using the photos: “Instead of trying to change people’s behaviour, they codified it.”

https://www.mindtheproduct.com/paving-cow-path-and-other-stories-by-simon-cross/

Facebook started 2005 with 1 million active users and ended with 5 million. This would have meant a lot of engineering challenges around scalability and stability and/or a lot of firefighting to keep the site up and working well. Accel Partners made their $13m investment into Facebook in 2005 which would have meant a lot of hiring. Based on this, some educated guessing about how Facebook would have measured up against the four dimensions:

1. Relatively small organization but going through a lot of hiring and organizational change
2. Very large user base who were young and relatively tech-savvy
3. The product team was up against more established competitors in the photo space, and so had to find a relatively simpler way of getting more activity on Facebook photos
4. The culture was about “moving fast and breaking things”

In this context, it made a lot of sense for the user-facing side of the PM team to get to grips with user behaviour and codify it. If it didn’t work to increase user activity they could pivot to a different idea.

I’m using Facebook as an example because it’s a well-known company that was explicitly following a pave the cow paths philosophy. Please don’t fall victim to survivorship bias and assume that dropping a 2005 Facebook PM into another organization would magically fix things¹.

It’s horses for courses. Different organizations and products expect and need different things from their product managers². We make things harder for ourselves by describing this all under one job title: “product manager” when in reality we mean a lot of different things depending on the context.

With all this said, do you want to see the Rated People feature I was talking about? Of course you do, and you’re in luck because it seems this feature worked well from a user point of view: it’s still there nearly 15 years later.

Here’s an example from DJC Contractors. I’m going to imagine that they live somewhere around the L or the o of London given that they are happy to go further north-west than they are south-east.

Here’s one for Comforooms ltd who are keen on the Western side of London.

On the other hand, Light Electrics, below, works on the Eastern side of London and surrounding areas. They are happy to work in Dartford but apparently don’t want to go to Croydon or as far as Watford. So I’m going to guess they are based relatively close to Chelmsford.

Or getting away from the capital, below are Next Gen Driveways who cover the whole of the South West of England, Swansea, Cardiff and Newport but have explicitly excluded some major local cities/towns (Bristol and Bath).

1. If anything, this Facebook example is a good counterpoint to the prevailing wisdom that you should not be paving cow paths, depending on the context of the organization and the product ↩︎
2. Even in this Facebook example, I’d expect that a PM working on the advertiser side of the business would treat things differently because those are the paying customers. ↩︎

How to figure out what type of product manager an organization needs

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 that¹. 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.

1. 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. ↩︎

The Now/Next/Later Roadmap changed my life

I love ideas that seem so obvious in retrospect. The Now/Next/Later roadmap is one of those: https://www.prodpad.com/blog/how-to-build-a-product-roadmap-everyone-understands/

The traditional roadmap is a group of chevrons or bars set out in quarters one or two years into the future. It says that: In Q1 we will deliver features A and B, in Q2 features C and D etc. Something like the following:

If you can plan this far ahead then, fantastic. But many of us need to be more nimble and to adjust priorities in the face of changing needs and opportunities in the marketplace. For us, this kind of roadmap is too rigid of a way to communicate future product development plans.

Its problems stem from the way it combines prioritisation and timelines into one view. It allows different stakeholders to have very different interpretations of what done looks like for any of these future developments. And it obscures whether we need to do any work now for something that it planned for 3 quarters away.

Now/Next/Later fixes an important part of this by separating out relative priorities from timelines. At Simfoni, implementing Now/Next/Later has helped me have these sorts of conversations:

1. Which of the items in now is genuinely something we should be working on now in support of company OKRs? And is everything in now really well-defined enough for us to be working on it right now?
2. For the stuff that isn’t in now, which pieces should be in next and which pieces should be in later?
3. What requirements/analysis/user testing do we need to do now on items that are in next and later so that we can be ready to build them when the time comes?

I even love the language of Now/Next/Later. Now clearly means something we should be working on right now. The less you have in now the more focussed you can be and the sooner you can get something properly done. Next means we need to get ready for something that we will be working on shortly, so we better firm up exactly what we need to do. And later is altogether more speculative and might need some early stage proof of concept work but it’s not something we should be spending much time discussing at the moment.

How to then apply timelines to the results of the now/next/later work is another topic. But so far I am finding that it helps to make the problem space smaller: we should be able to have pretty firm time-boxed estimates for work in now, and then things will get less precise as we move out into next and later.

All credit to Janna Bastow who invented it, see https://www.prodpad.com/blog/the-birth-of-the-modern-roadmap/ for the history.