Building a product oriented team
The 5 attributes you need to build a product team — and the 8 reasons they'll consistently outperform project- and feature-focused teams.
This article has been extensively updated to better connect with “receipts.” The prequel, faster, better with a product mindset, introduced a “product mindset.” If you haven’t read it yet, start there. In this article we’ll explore what a product oriented team looks like.
In Product teams really do outperform I built the case that product oriented teams deliver more reliably and faster — and I brought the receipts to prove it. In this article we’ll dive deeper into what it means to build a product team and explore the team’s composition.
Having a product mindset means, more than anything, taking whole ownership of a product — and of the value stream behind it, from the customer’s need all the way through to production. 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.
Owning the product has implications. Owning a product is predicated on building durable and deep knowledge about your customer, their needs and desires and the product itself. It means sticking around after delivery, attending 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 are 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.”
And the payoff isn’t abstract. The research is unambiguous: teams that own their product end-to-end ship faster, recover quicker and deliver more value than teams that merely execute against someone else’s plan. DORA has measured the performance gap across tens of thousands of practitioners. Marty Cagan built the modern product operating model on product teams rather than projects for the same reason. I brought that evidence together in Product teams really do outperform. Put simply, product orientation is one of the highest-leverage productivity moves an organization can make — and most never make it.1
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.
If you’re new, welcome to Customer Obsessed Engineering! I publish about one article each week. Free subscribers can read about half of every article, plus all of my free articles.
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.
Knowledge durability means building knowledge that grows and becomes deeper over time. The only way this happens is to take full ownership of the whole picture. It means understanding customer needs and expanding on them, turning those needs into a rich comprehension of how needs can and should be met. It can’t be handed to the team by upstream specifications or lists of requirements — that approach loses too much context. Product knowledge, customer needs, design requirements, goals, lessons learned — it’s all part of owning the product.
Team durability is the logical extension of knowledge durability. 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. The team must feel permanent. If you’re building a fraud prevention module for a bank it 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.
When it comes to composition teams must be cross-disciplined. Gone are the days of siloed team members that “live” in their narrowly focused domain (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.
A durable, skilled team builds strong, long-lived customer relationships and invites the customer to be part of the team. There are no “upstream” product design specialists handing down requirements. Authority for what to build sits with the team and its product manager — not a distant product owner translating someone else’s roadmap. The customer sits with the team and shares in decision making. Their needs and desires are understood and a richly crafted product emerges from co-working sessions.
Ownership continues beyond deployment and delivery. 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. Watching telemetry to make sure hypotheses about usage, performance and stability are met.
How “project oriented” differs
In contrast, project oriented teams organize around the short-lived, non-durable objectives, leveraging silos of expertise.
This is most evident when looking at team durability and organization. Being organized around the project means the team:
Lacks durability. Team members move from one project to another with relative ease, taking their knowledge with them. They usually don’t develop a strong sense of product ownership.
Won’t develop sustained product knowledge. Team members are usually organized around their discipline. 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. There’s no focus on deep product knowledge. Instead individuals lend strong but transient technical knowledge to the team.
Project oriented teams tend to look like this:
The result: 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 specialized expertise existing in silos there’s constant risk that customer needs are misunderstood, mistranslated or simply never conveyed from one stage to another.
Often the customer is completely removed from the team, committing knowledge only through “upstream stages.” This might be the product owner, or perhaps a UX design team. In both cases, requirements are handed to the technical team to implement after passing through multiple filters. The team merely executes, following the letter of the requirement, without consideration for actual customer needs.
In turn, the technology team also functions as 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.
The feature team: the trap in the middle
Between the product team and the project team sits a third kind that’s easy to miss, because it looks the most like progress. The feature team is durable enough, often cross-functional, and runs all the right ceremonies. But it doesn’t own the problem — it builds features handed down to it. Someone upstream decides what’s worth building, shapes the requirement and passes it along. The team’s job is to deliver, not to discover.
That’s the trap. A feature team can look agile from the outside but operates exactly like a project team: authority for what to build still lives above the team, the customer relationship still belongs to “upstream” and the team merely executes. Most “agile transformations” that stall, stall right here — and most scaling frameworks, SAFe chief among them, install teams from this middle band. The evidence for the product-team alternative is in Product teams really do outperform: bringing the receipts. I take apart the scaling trap in a companion piece on SAFe.
For the rest of this article, the distinction that matters is simple: a product team owns the outcome and its value stream end-to-end; a feature team owns neither.2
This newsletter grows by word of mouth… I’d really, truly appreciate it if you could refer a friend. Your referrals make it worthwhile.
Product team organization
In order to build teams that have a product mindset, we need to support the core principles outlined above. The team must be:
Durable
Cross-disciplined
Whole
Empowered
Right-sized
To create durability, we need to ensure the team consists of long-lived team members (recognizing, of course, that individuals will mature and move on — but the point is, organizationally, the team is permanent and strives for consistency).
Durability carries a budgetary implication people often miss: you have to fund the team, not the project. A team can’t be permanent if its funding evaporates the moment a project ends. Persistent product teams need persistent funding — money that follows the durable team, or the value stream it owns, rather than a fixed scope with an end date. Get the funding model wrong and everything else here stays aspirational.
We also need the team to be self-sufficient, free of external dependencies. They need all the requisite skills to get the job done, having business domain expertise, design, architecture, engineering and delivery capacity.
Creating a “whole team” means sharing the table with the customer. Your customer could literally join the team, or the team regularly sits with the customer. The key point is that the team isn’t whole without both customer and technology at the table. Together, they develop an understanding of the product.
Having deep roots in the product and a strong customer relationship means aligning around outcomes not just feature lists. It’s no longer about “shipping the feature.” The team cares about effecting the customer conversation and metrics that impact business outcomes. They’ll test hypothesis quickly, prove what works and kill off features that don’t move the needle the right way.
To do so, the team must be empowered to deliver. If the team has to wait for some external business event to deliver they are not enabled. If the team cannot actually deploy the application into production daily they are not empowered. If they aren’t responsible for monitoring, observing and maturing the application once it goes live they are neither informed nor accountable.
This is also where elite performance comes from. A team that owns its own deployment ships in small, frequent increments and recovers quickly when something breaks — the behaviors DORA’s decade of research ties to the highest-performing organizations. You can’t buy that with a process; it follows from ownership.3
Our product team is oriented around the product (not the project). Product teams operate quite differently from project teams, as we see in this diagram:
