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

Bonfire of the Best Practices

As we get stuck into 2024 I am wondering how many of the product and engineering best practices that we’ve seen develop over the past 10-15 years will turn out to be ZIRPs (“zero interest rate phenomenon”).

Probably quite a few. Two reasons I can see:

First reason is pretty obvious. When money was cheap the objective was to raise as much investment as possible and use that money to build an aggressive roadmap fast. When time is of the essence and cost isn’t a big deal, the first reaction of most managers is going to be to hire people to do more stuff. Not surprising that many companies over-hired – e.g. see https://qz.com/from-overhiring-to-optionality-what-we-can-learn-from-1850267076 and https://stripe.com/gb/newsroom/news/ceo-patrick-collisons-email-to-stripe-employees

Burning loads of VC cash to hire loads of people to build more stuff brings its own set of challenges. The processes and best practices that evolve will work well with these sorts of challenges.  When there is less investment money floating around you need to be leaner and more intentional in where you spend your time. The processes that work best in a leaner environment won’t necessarily be the same as those that worked in the sorts of VC-backed outfits we’ve seen over the last decade.

It’s a common trope that you shouldn’t just pick a process that worked in a company whose brand you admire and expect it to work in your company. What I’m saying here is a bit stronger than that. I’m saying that any product or engineering advice coming out of the VC-backed cash-burning-machine era might need to be chucked in the bin in these leaner times.

It’s not just that a bigger company’s processes might not work for where your company is right now. The sorts of processes that worked in a ZIRP era business model might just not make sense in a leaner era.

Here comes the second reason that makes it even more important for you to question ZIRP-era process advice.

As a company gets bigger, the people who have the time and inclination to write about processes get further and further removed from the reality on the ground. Even in @simfoni it’s difficult for me to know what an individual product iteration really involves for the people doing the work. If you’re reading a blog post by a tech leader of a company with 200  or 1,000 engineers, how confident should you be that the blog reflects reality? Or does it reflect what the writer thinks is happening, or how they would like things to be happening?

A great example of this is the Spotify Model. The Spotify model is (was?) an organizational structure that inspired a lot of imitators until it turned out that even Spotify didn’t use the Spotify model: https://www.agility11.com/blog/2020/6/22/spotify-doesnt-use-the-spotify-model  It was as much a leadership aspiration as it was a statement of reality.

To sum up, I see 2 things combining here:

1. Processes developed in ZIRP-era VC-backed company might fundamentally not work in leaner times
2. The processes as described in blog posts and analyst reports maybe never even existed in real life

So a 2024 resolution for myself, and a call to arms for anyone reading is to “question all the blog posts”. Even more than you normally would.

Except for this one, of course. This one is bang on the money 😀

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.