A different lens of seeing a product team

What happens when we frame the cross-functional team as a discipline, instead of a collection of individuals from different disciplines?

There are two main problems with this (very popular) illustration.

Let’s start with the less disturbing one: the fact that a real Designer will contribute way beyond “Usability”.

Value risk is usually described as “whether customers will buy your product or users will choose to use it.”

Well, I don’t think you’re actually practicing Design if you’re not deeply concerned with value creation… Most designers, if not all, would agree.

So, I don’t think this model is very helpful. I think it can be dangerous.

But there’s an even bigger problem with this illustration (and way of thinking):

How titles and positions are hindering the potential of true, dynamic and contextual, teamwork.

We get caught up in debates and terminology centered around different disciplines that, together, should form a cross-functional product team.

And by doing that, we forget about the most important thing:

That the cross-functional team should be THE discipline.

Looking into a product team through different lenses

A job position comes attached with a title and is filled by one individual.

This immediately creates an artificial constraint that this person has a set of responsibilities and accountabilities - usually stated in detail, in a job description.

This individual will think of these responsibilities as her main contribution to the team.

So, the mental model is:

My responsibilities (1) — > To support the team (2)

Every time an individual is solely responsible for a certain thing, or when the perception that a certain responsibility falls under one person - we create individual incentives (as opposed to collective) and a whole structure of expectations around that individual.

Individual incentives create silos and fosters competition, instead of collaboration.

Expectations around individuals in a team-based environment can create tension between personal achievements and collective success.

But what if we shift this, and set the team as the starting point?

In other words, what happens when we think:

The team’s jobs to be done (1) — > How can X contribute, right now? (2)

Let me give you an example.

In most companies, the Product Manager is responsible for stakeholder management.

This means communicating on behalf of the team in town hall meetings, writing update documents, and so on.

But why the Product Manager?

Because apart from being on her list of pre-defined responsibilities, this position is typically filled by someone who’s a “great communicator”.

At least that’s the expectation and what’s written in most job outlines.

However, this approach comes with three big flaws:

• There’s no such thing as an all-rounded “great communicator”.

• Every skill/competency or even trait is influenced by context

• This approach doesn’t acknowledge and leverage the total team’s available skillset, preferences, and personalities

Consider this:

Holding a great presentation for 700 people requires preparation and public speaking skills.

Maybe Bob (the PM) is an excellent writer with an outstanding ability to communicate verbally on the spot. But Bob is also introverted, and speaking to a large audience is not only outside of his comfort zone but also a big energy drainer.

On the other hand, Jenny (the team’s Product Designer) loves big crowds and has a passion for public speaking.

So why wouldn’t Jenny naturally take this job to be done, on behalf of the team?

Take another example - this one is real, from a few years ago.

A Tech Lead had been working hard on a complex technical task. She also enjoys writing and frequently blogs about engineering topics for a broader non-tech audience.

Before an important Board meeting, the Chief Product Officer (CPO) requested an update on this challenge.

So, who do you think took on the job of compiling all the necessary information?

The Product Manager…

Why? Because it was his responsibility.

The elephant in the room? The Tech Lead was perfectly suited to write this update for the company’s executives on behalf of the team.

Not only was she better equipped to discuss the topic, she also enjoyed writing about it - usually for non-tech audiences!

Do you see why positions and rigid responsibilities can be so ineffective?

It’s easy to default to the artificial constraints that job positions or titles create.

However, these constraints disappear if we think of the team as the main unit instead, and think:

What are the jobs that the team needs to get done, to achieve the outcomes they have set for themselves collectively? And who’s best suited in the team to do those jobs, at the moment?

When we start doing this, we can truly leverage everyone’s contributions, remove silos, be mindful of different skill sets, personalities, and adapt according to any given context.

It sets the team in the center and celebrates individuality.

Cross-functional teams as the discipline, and the case for individuality

What are the broader jobs to be done that a product team needs to perform?

In other words, what are the larger areas/themes a team must look into, to discover and deliver a product that people love - as part of a profitable business model that works for the company?

Business, Design, and Engineering.

This know-how and skills must exist in the team.

However, instead of framing that collaboration through the lenses of different positions (e.g. Product Manager, Design Lead, Tech Lead), we describe the broader themes - agnostic of specific titles and also the number of people.

This may seem like a subtle little change in framing. But let me unpack why it’s important.

First, we all know that when it comes to Business, the Product Manager should be the one bringing that particular skill to the table.

Undoubtedly, there are quite a lot of jobs related to this theme (see the left part of the picture)

But if the Product Designer in that team happens to be particularly skilled in, for example, Business Design - then they’ll naturally work very closely in this matter too. They should! (see the right part of the picture)

Arguably, who knows, that designer is even better equipped to address some of the viability risks that the team must be mindful of.

In that case, embrace the fluidity of skills in the team - and get rid of position-specific expectations.

As long as the team has the skill set, you’re good!

Second, I love the concept of a Product Trio.

But one pitfall has been the marginalization of several other people involved in providing crucial contributions to address some of these risks (e.g. a user researcher who’s part of the team, working hard to help de-risk value and usability - but who’s not the “Lead Designer” and therefore part of the “trio”). When we have these lenses on, that changes.

Third, some jobs to be done inevitably require more specific skills and knowledge than others.

For example, a Product Manager may enjoy some aspects of Design - but that doesn’t make her a strong Designer…

To quote Christina Wodke:

“We all design, but we are not all designers. We all cook, but we are not all chefs. We all take photographs, we are not all photographers. (…) To design well, you must study a number of topics, all worthy of a lifetime of practice, from graphic design to ergonomics. It is human to design, but it is a profession to be a designer.”

In these cases, specific backgrounds will matter.

But on the other hand, there are many other jobs a team must do that should remain flexible when it comes to who performs them.

Last year, after speaking at La Product Conf in Madrid, a Product Manager asked me backstage:

“I’d love to spend more time doing discovery - thanks for the talk! But I spend so much time with backlog management. For example, I’m the only one writing all the user stories… could this be done by one of the engineers?”

My answer:

“You shouldn’t even be spending your time writing user stories… But if this is an expectation of your job in your organization that you cannot change just yet, then yes - distribute that load through the team as much as possible!”

These types of banal jobs to be done shouldn’t have to be performed by one single person - just because it’s an expectation that comes with a certain title…

Instead, reflect on this:

What are the jobs to be done that can be shared, switched, or rotated?

• Do you have one person repeatedly handling a trivial task on behalf of the team (e.g. facilitating a retrospective meeting)? Rotate.

• Two people are very skilled in the same thing or love doing it? Share it.

• One person hates doing X and is usually the one doing it - and another one enjoys it? Switch.

Tip: most “jobs” should be shared.

The way forward

I urge all of us to think of a cross-functional product team as an actual discipline.

Forget about Product, Engineering, and Design as disciplines - just to name a few. Let’s start talking about cross-functional teams as the unit, instead. 

Let’s focus on the whole team’s jobs to be done first, instead of the positions/disciplines/titles that are responsible for X, Y, and Z - regardless of context.

Let’s acknowledge the fact that competency is contextual, that some personalities thrive in certain environments, and that human beings are way more adaptable and malleable than what’s pre-defined in a job description.

Let’s expand our knowledge of the relationships between different backgrounds and types of work, rather than obsessing with discipline-specific siloed jargon discussions.

Let’s think more about the team’s outcomes and how every individual can support, in her or his unique way - and leverage her or his expertise.

If we look at it through those lenses, everything becomes less territorial (even though it really shouldn’t be in the first place). Expectations are clearer. And the industry will evolve towards deeper collaboration and bringing the best of all worlds, instead of trying to claim spaces and continuously repackaging old ideas to better fit their own audiences. 

.

.

Hey there! 👋 Afonso here. Thanks for reading! I’m still testing this idea, not fully mature in my mind yet. Did it resonate with you?

Send over your thoughts (DM me or comment here/Linkedin) - would love to hear people’s opinions on this perspective