I was at an event a while ago, listening to a full-time product person giving a presentation about how the private sector organisation they worked for delivered great products. It was a fantastic presentation from a talented product person. I learned a lot and I’d go and work for their organisation tomorrow, despite my long-standing addiction to the public sector.

But. There was one line in the middle of the presentation that bothered me and I played with it like a piece of food stuck between my teeth for the rest of the day, getting more and more irritated.

The line that bothered me was an assertion that the product person in the team should take up the slack of any other roles in the team that needed filling.

There was some context given around the fact that these other non-product roles were less than full-time, or less than permanent roles. Despite that, the inference was clear: any gaps in the team should be plugged by the product person.

Are we putting product down?

Product is a relatively new discipline and we’re often not clear enough about what it involves. My concern at what I’d heard that day caused me to gather together several niggles under the same heading. I’m not going to talk at length about these, but I would like to highlight two trends that could cause problems for product people, and suggest some possible fixes.

1. Role descriptions

The first trend is that I’ve seen descriptions of product roles that start with – or highlight – the ability to step into other roles as a key requirement. This isn’t necessarily entirely wrong. I agree that you need flexibility in multidisciplinary teams, and that it is important for product people to have a range of skills and an understanding of the other roles they’re working with. There is a limit, though.

If a delivery manager or software engineer job advert started the description of their role with “it’s important that the postholder knows a lot about other roles and can fill in for them from time to time”, what would we think? Or if a user researcher or performance analyst said “but I also help the team out by doing a different role”, would our responses be at all different to when this is included in a product job role description? If we’re not sure about our answers to these questions, then we’re at risk of downgrading the importance of a product role.

2. Core product skills

The other trend I’ve become aware of is that, as product people, we’re not good at discussing core product skills. To unpack this a little, by “core”, I mean skills that are critical to our success: user stories, planning, prioritisation, vision, negotiation, discovery, roadmaps, etc.

By “discussing”, I mean what gets covered in the various product community meetings, threads and chats that I’ve been involved in. My experience is that the core areas I’ve outlined above are discussed less often than other topics: roles/career pathways, assessments, hiring, training, interaction with other roles on a multidisciplinary team, skills used by other roles etc.

It’s possible that this is just me being grumpy and everyone else is happy with their core product skills and wants to learn a bit more about other stuff. And that’s fine. What wouldn’t be good is if we, as a product community, allow our lack of confidence to dilute our focus on core skills.

That wouldn’t be good because focusing on other areas will lead to confusion about product roles. Worse, any failure to discuss important topics will inevitably create problems in articulating our product roles and developing our skills.

How to avoid putting product down

If this is a problem, then how do we avoid it? Here are three approaches that I think will improve things.

1. Be the glue

The biggest compliment I’ve ever been paid as a product person is to have someone else describe me as “the glue” in the team. Product is the crossroads where so many conversations and clarifications in a multidisciplinary team take place. Product people should always be serving as part of what makes the team more than a collection of individuals.

Being the glue sometimes means being able to step into a gap to clarify, unblock or assist delivery. It doesn’t mean enabling a long-term gap or area of team disfunctionality to be ignored. Stepping in to do some user research so that your user researcher can run multiple sessions: that’s good; doing all the user research because you don’t have a user researcher, that’s going to cause problems.

In the long-term doing multiple jobs badly to the detriment of your role harms your team more than it helps it.

2. Be clear

If we don’t understand our role as product people, then we can’t expect other people to. Product is a role, a profession and a craft and it has an equal right to exist as any other role within a multidisciplinary team.

Being confident about this doesn’t mean being unhelpful or aggressive; it means being able to talk to people about what we do, how we do it and why we do it. (“People” here includes immediate team members and also senior managers, stakeholders, and others, and “talk” doesn’t have to be verbal: blog posts can often be a useful way of communicating with people who are geographically distant.)

If we’ve waited to explain what we do, how we do it, and why we do it until there’s a debate about our role, then we’ve waited too long.

3. Understand the difference between core and secondary skills

Because product people need to work with such a varying range of other roles, it’s tempting to conflate the skills we need and the skills that are useful. Yes, those user research / UX / development / infrastructure / architecture / testing / prototyping skills / deep understanding of the history of the product you’re involved with are useful. But they won’t make or break your ability to do your job as a product person, in the same way as an inability to prioritise or communicate vision will.

(The other difference between core and secondary skills is that primary skills are always helpful but secondary skills can sometimes be a hindrance. A development background can be useful but it can make it difficult to keep the stories that you write from venturing too far into solution space, for example.)

Header Image: Product by Nick Youngson CC BY-SA 3.0 Alpha Stock Images

Meta-title-footnote: As a Raymond Carver fan I’m more than happy to contribute to “What we talk about when we talk about X” becoming the 21st century version of “It is a truth universally acknowledged”.