Product management is hosting a party, not playing chess

I think that "hosting a party" is a bad analogy, because it implies that a lack of inclusion is a bad thing. People who aren't invited presumably feel bad, and the person who is responsible for the invites is judged for who they include/don't include. Parties are about being social and having a good time. Customer-facing product meetings are about trying to understand and potentially solve a customer problem. The dynamics in play are quite different, and recognizing this is important.

As a developer, I was regularly on customer-facing calls, and I think that having devs on calls is often really important. As a developer, I was also pulled into many calls that were a huge waste of my time.

A big part of being effective as a PM involved knowing when to pull people in, and who, often based on who the customer is and the nature of the problem they had. If this call is the result of an escalation from some huge customer, it's really critical to bring someone in who will calm them, not agitate them. If the call is just an exploration of potential roadmap items, getting more devs into the room can be beneficial.

To whatever extent there's a time to "party", it's also entirely appropriate to play chess and be strategic when necessary. That means that some devs are involved less than others at times, for the same reason that a top wide receiver gets the ball more than 2nd stringers.

(Editing to say: On 2nd thought, "2nd stringers" isn't a great analogy either. I'd say it's more about positional players. Each person on the team has a unique skillset. People are strong in some areas and weaker in others. Some are hired specifically because of one skillset vs. another. That's not an indictment of the person, but just the reality of the makeup of a team at any given time. Asking a fullback to run a deep route doesn't make sense. Asking your best-in-the-world database guy who tends to have no patience for customers and rubs them the wrong way doesn't make sense. But do cultivate these skillsets and provide opportunities for growth).

That doesn't mean the 2nd stringers shouldn't get more reps, or that they can't learn the skills. I've worked with devs who wanted to be better with customers and asked for that opportunity, and I was always eager to give them that opportunity. But not everyone wants this, some people prove not to be capable of this, and that's fine.

I think the author's point that some product people are inappropriately dismissive is a fair one. I've worked with PMs who had a terrible relationship with their devs, and who were fairly criticized for their protectionism. But the solution to this isn't to start throwing parties. As with most things in life, reality is a bit more complex, and the answer far more nuanced.

Bottom line:

- Some devs are great with customers

- Some devs are awful with customers

- Some devs want and can learn how to be better with customers

- Some customer calls need devs involved

- Some (many) customer calls would be a complete waste of the dev team's time

- Understanding who's who and what's needed for a given circumstance is the key

This has to be the most common fallacious line of thought that I see in discussions about roles and experiences at work.

Whether something has a lot of value is, well, irrelevant. There are just too many different things that provide a lot of value to the team. The problem is that things that provide value come with a cost and sometimes with harsh tradeoffs.

If you decide that everybody on your engineering team must interact with customers, then maybe you get the value—but you also drive away some valuable team members who don’t like customer-facing roles. Your team becomes more homogeneous and you lose some diversity of thought. Most teams need a combination of viewpoints to succeed—we don’t just need to develop our customer focus, but also our focus on tech, on operations, on finance, on personnel, etc.

Another way I see this fallacious reasoning pop up is when people say that managers should be engineers or have an engineering background… because managers are better managers if they have an engineering background. All other factors being equal, this is true! But a lot of similar things are true, like how engineers would be better engineers if the had management backgrounds. We must accept some level of specialization because specialization is good for the team. Specialization doesn’t just mean that people have additional skills, it also means that people are missing skills.

if product management is hosting a party, it is usually a party of people that speak about 10 different languages, and everyone needs to get along in the next 15 minutes or else.

generally, some developers can be exposed to some clients sometimes. but not all developers to all clients all the time.