Working on a product is difficult. The large difficulties when it comes to solving any such effort are fairly straightforward to identify. What is the product? What does it do? Who does it serve? etc…

However, one thing that often doesn’t get considered explicitly is how a product team comes together to solve these problems. Not taking into account the different concerns of a product team and how it works can cause tensions, create inefficiency, and stall out an otherwise highly capable team.

I want to talk about those concerns and a basis for which to keep a team moving forward.

Before difficulties come concerns

A product team has several different concerns going on at the same time. These concerns have to be balanced with care.

The major concerns of product teams are Product, Design, and Engineering.

Product
Product establishes the “why”. Though referred to as Product (capital P), Product does not represent the product itself. Instead, as a role, Product represents the users’ needs FROM the product.

Product establishes the external need that goes into the product.
Fail response: doesn’t connect because Product didn’t establish the right need.

Design
Design establishes the “how” from the products’ perspective. Design takes the needs of users (often from Product) and expresses them into solutions which fit the product. As a role, Design represents the needs of the brand (look and feel).

Design establishes the internal idea which will solve the need.
Fail response: doesn’t feel right because design didn’t design it right.

Engineering
Engineering is the “how” brought to life. Engineering takes the considerations established by Product and Design and formalizes a solution to make it real. As a role, Engineering represents the product itself.

Engineering establishes the external solution to be presented to the user.
Fail response: doesn’t work/exist because engineering didn’t build it right.

To be clear, just because concerns fall in one bucket or another does not mean no one else can be concerned with them. That is, just like a firefighter is expected to fight fires, they aren’t the only ones that can stop a fire or act if a fire is happening.

Let’s TOCC about it

Great teams usually are composed of multi faceted and very passionate individuals. This means folks know their stuff and are there because they care about the work and/or product. This combination leads to lots of strong opinions.

Given that Product, Design, and Engineering have differing concerns, you can also see how they all depend on each other.

In a product team, you have to be able to move fast. However, how can you move when you are mired in a situation where X different people have X different ideas of how a thing should be? How do you avoid bikeshedding?

Trust. Orchestration. Communication. Compromise.

Trust is a necessity in any team. While a general trust exists in most teams, in product teams there needs to be a high level of trust.

As stated above, the level of talent on these teams is extraordinarily high. As such, there needs to be a high degree of trust in each other when a lot of these folks are used to being the most talented person in the room. Folks need to trust that others on the team are equally diligent/exacting/dedicated/effective.

Further, this trust needs to extend to other facets of the team. That is, Engineering trusts in Product/Design, Design trusts in Product/Engineering, and Product trusts Design/Engineering.

Without this type of trust, you end up with statements like: [to Engineering] X shouldn’t be that hard, or [to Product] just make a decision it’s not hard, or [to Design] just make it look pretty.

Orchestration is required in order to keep the pieces moving. Again, we’re dealing with different concerns trying to come together. Adding to the complexity, each of those concerns tends to carry different individuals driving their own opinions and expectations.

Without orchestration, what could be a nice harmonious workflow turns into chaos.

Teams are sitting idly by waiting for other teams which leads to tension. Folks are rushed into making half baked decisions which betrays trust. Compromises are made due to a lack of options as opposed to having too many.

So orchestration means timing, but it also means alignment. Orchestration means ensuring folks are on the same page. That is, if X is working on something, they communicate that openly so that Y doesn’t inadvertently work on the same thing. It can also avoid Z creating more work for X by accidentally shifting the expectations/base/goal.

Communication is vital as we all know. There isn’t much need to hash this one as it’s fairly evident throughout, suffice to say, erring on the side of over communication should be highly promoted.

Compromise is seen as a bit of a dirty word. Normally, you don’t want to compromise on anything you do. Normally, a compromise is a less than ideal choice.

Here, compromise is more about choosing to move forward.

As mentioned previously, given the nature of the teams we’re talking about, there will always be strong opinions. There will be a diversity of opinions, and IDEALLY, there will be an environment for folks to share, discuss, and potentially debate those opinions.

It should be self evident that folks will not always agree.

Compromise here isn’t about compromising a solution or a choice, it’s about the people involved being willing to compromise on a path forward. That is, give up their position for the sake of moving forward.

As we all know, even the most well thought out plans and ideas just fail to work sometimes. It happens now and again that only after executing do we realize a solution just doesn’t work as expected.

Compromise is about taking that idea in earnest and being open to the possibility that there may be another way.

Here’s a TL;DR example:

Trust you’re all coming from a place of passion and are looking to do the best for the product.
Communicate your position.
Be willing to compromise for a solution.
Orchestrate a means to move forward. (i.e. we’ll do X and see how it goes then maybe try Y).

Product Sum

Building a product is hard. Bringing together a highly talented team of folks with differing concerns and driving a concerted effort is even harder.

It takes explicit work to ensure the different concerns of the product are met. It also requires everyone to be committed to keeping the process moving forward.

In the end, everyone is looking to create a product which wows users. With a little bit of explicit direction and understanding, everyone on the team can come together to add to a wonderful product.