https://richard.northover.info/writing/digital-product-person

Being a "Digital Product Person"

OK, I admit it: I struggle to say what I do for a living.

To most normal human beings, the job titles I've had for the last quarter of my life don't mean a lot. Although in the past "science journalist" and even "web developer" resulted in reassuring nods of understanding, the last decade or so of "product manager" has basically drawn a slightly uncomfortable blank. Only people who already know have a vague idea what it means.

Lots of modern job titles are pretty opaque. They either stick around because they sound good, like "technical architect", or they just never get updated, like "project manager". Either way, they don't make useful answers to the question "what do you do?" because most people aren't in the same specialist work area. Even people in the niche next-door will only know very roughly.

Over the last 7 or 8 months, I've been gradually trying to rebuild my own answer to that question, having left my job and become a freelancer. It suddenly becomes quite important to be able to say what you do under these circumstances, and not just because you have to write a decent bio on LinkedIn. If nobody knows exactly what you do, then how are you going to get paid to do it?

I guess this is why so many people end up having to fudge their descriptions in so many ways. "Working on the border of technology and design" or "with experience in P Q and R".

To make matters worse, although on paper I've been employed as a "product manager" for the last decade or so, I've never really seen myself as one. According to what the general definition of a "product" is, I've never actually managed a product.

There are millions of blog posts and articles on this subject, mostly being read by product managers trying to work out what on Earth they're meant to be doing for a living. The consensus has always been that being a Product Manager is a bit like being a translator, sitting in the middle of the Venn diagram of the types of people involved in making technology things. They help these different disciplines - broadly "technical", "design" and "the business" (the people who worry about making money at some point) but also legal people, marketing people, project management people - to go in the same direction by translating between the languages they speak, carefully working out which bits need translating and editing while they're at it. It's like being an opinionated Rosetta Stone.

All the disciplines have their own areas of expertise and focus on problems that overlap in various combinations, but in the end they're working on a thing, and that thing is mostly referred to as a "product". The Product Manager's job is to work out what the it should actually be: what problems there are in a particular area, who has those problems and why, how to work out whether the ideas behind the product are successful, and so on.

But not all products are equal. Some are destinations you deliberately go to, with names and purposes and marketing budgets. Something like BBC Sounds or Gmail is like this, and they'll have Product Managers looking after them and steering their development. That's the kind of thing most people think of as a product.

On the other hand, the BBC Account or Google Account systems aren't a destination you deliberately visit, they're more like the door you go through to get to one. Things like this often get called "services", with someone called a "Service Owner" responsible for them.

Strangely, some see products and services the other way round. "Products deliver outputs, services deliver outcomes" is a great article on the NHS Digital blog, and it makes a convincing argument that the word "service" is really the big and important one. For example, the website you used to book your COVID vaccine is a product, and the broader interconnected machinery - which includes the website, but also the booking system that the website talks to and plenty of other things - is a service, delivering the end-to-end result that you end up actually getting your vaccination.

The outcome, the ultimate reason for any of the constituent parts existing, is the thing that everyone needs to keep in mind so that the people booking their vaccination don't fall between the cracks. This is something that could happen if the constituent parts forget what they're constituent parts of. Product managers are working on the parts, while service designers have a view of the whole.

I think what I'm revealing here, if anything, is that what I really do is overthink things. But I think I'm in pretty good company on this: like lots of other Product people I've met, what I do could be called purposeful overthinking.

This isn't just about defining words, it's about the different ways the words get used, what the concepts mean, and what they tell us about what we're doing and why.

I think it's useful to spend time swimming around in the area you work in, overthinking it, and seeing what happens.