Building a product oriented team

6 ways teams with a Product Mindset will always outperform project focused teams.

In the first half of this article, faster, better with a product mindset, I introduced a “product mindset.” If you haven’t read it yet, I’d suggest starting there. In this second part we’ll explore what a product oriented team looks like.

In faster, better with a product mindset I introduced a product mindset. In this article we’ll dive deeper into what it means to build a team that is product minded, and we’ll explore the actual composition of a product oriented team.

Having a product mindset means, more than anything, taking whole ownership of a product. We’re talking about creating teams that are synonymous with their product, from inception to delivery and beyond. That last bit, “and beyond,” is key: It means the team doesn’t just toss a finished product over to operations and walk away. Instead, they keep owning it. I’ll talk about exactly what that means in a bit.

There are a few important implications that follow on from owning a product. For example, owning a product is predicated on building durable and deep knowledge about your customer, their needs and desires, and the product design. It also means sticking around after delivery to attend to the “care and feeding” of your product: Is your customer happy with it? Does it achieve what was promised? Could it be improved?

Changes to the team’s composition and ways of working are also implied. This kind of ownership means enabling a team to be self-sufficient. It means empowering them to change direction and interact with the customer before, during, and after delivery. It implies a change to a team’s “ways of working.”

So, let’s dig in and explore. Let’s start by getting clear on what a team with a product mindset looks like, and how it differs from traditional project oriented teams.

The product oriented team

I introduced the idea of “durability” above. This unfolds into two different aspects of the product minded team: Knowledge durability, and team durability:

1. Knowledge durability means the creation of knowledge that is sustained. That knowledge grows and becomes deeper over time. The only way this happens is to take full ownership of the whole picture, and start building that base of knowledge. It means understanding customer needs and expanding on them, turning those needs into a rich comprehension of how needs can and should be met. The knowledge can’t be handed to the team in the form of an upstream specification or list of requirements — that approach loses too much context. The knowledge of the customer, their needs, subsequent design requirements, and how it gets built — that is all intrinsic to owning the product.

2. Team durability is the logical extension of knowledge durability. The team members must be durable and long-lived on the team. It’s not possible to build deep product knowledge if team members are constantly changing. This means that, by-and-large, the team feels permanent. If, for example, you are building a fraud prevention module for a bank, this means each team member truly learns the fraud prevention business domain, what the bank needs, what customers need, and the technical knowledge behind fraud prevention. (Of course some team members change over time, but it mustn’t compromise #1).

This also means that teams must be cross-disciplined. Gone are the days of siloed team members that “live” in their narrowly focused silo, like user experience, programming or quality assurance. In its place is the wholly enabled team that can “get things done.” Which means the team itself must own all of these disciplines. I’ll dive into this more when we talk about team composition.

Ownership at this level also means a deep and enduring relationship with the customer and the product. It means the customer is part of the team. There are no “upstream” product design specialists. The product owner doesn’t meet with the customer and then pass requirements to the team. Instead, the customer sits with the team and builds a relationship. Through this relationship, their needs and desires are understood and a richly crafted product emerges from co-working sessions.

Ownership continues beyond deployment and delivery, too. The team needs to know if the product delights their customer. That means working along with operations to deploy and monitor the application — to observe whether or not it performs as expected. Checking in with the customer to plan and build the next iteration. Creating new ideas that push the product into new areas.

How “project oriented” differs

In contrast, project oriented teams organize around the project, leveraging silos of expertise.

Probably the most significant difference in a project oriented team is durability and organization. Being organized around the project means the team:

1. Lacks durability. Team members move from one project to another with relative ease, taking their knowledge with them. They often don’t develop a strong sense of product ownership.

2. Lacks deep product knowledge. Team members are usually organized around their skill or discipline. For example, a team might need a “fraud specialist” who joins the team, implements a specific solution, and then leaves. Most team members tend to organize around a silo, such as quality assurance, testing, or DevOps. This means they aren’t focused on deep product knowledge, but instead bring a specialist to the table.

Project oriented teams tend to look like this:

Project oriented teams are structured around specialization (not product knowledge)

This combination also means that deep, intrinsic product knowledge never develops in the team. Instead, specific (siloed) segments of the team, such as the product owner, might understand the customer and the product. But few other team members will.

With deep expertise existing in siloes, this exposes plenty of risk that customer needs are misunderstood or simply never conveyed from one stage to another.

Often the customer is completely removed from the team, interacting only with “leadership.” This might be the product owner, or perhaps a UX design team. In both cases, requirements are handed to the technical team to implement. That team will follow the letter of the requirement, without consideration for actual customer needs.

Likewise, the technology team itself is an upstream silo, eventually handing a “finished” product to operations — hopefully, along with instructions for its care and feeding. In the meantime, the project team is dismantled and assigned elsewhere — and nobody is left caring about the product now that it’s in production.

The outcome of all of this: The product is less than it could be. Without a durable team the chance of missing customer expectations is much higher.

Product team organization

In order to build teams that have a product mindset, we need to support the core principles outlined above:

1. Durable

2. Cross-disciplined

3. Whole

4. Empowered

5. Right-sized

If you use the referral button below, you’ll earn free premium access to Customer Obsessed Engineering. Just three referrals will earn a free month!