Building your team

Having a product mindset means taking whole ownership of a product — and of the value stream behind it, from the customer’s need through to the running software in production. Ownership has implications. It’s predicated on building durable, deep knowledge about your customer, and it implies real changes to how the team is composed and funded.

Durability, and the two kinds of it

Durability unfolds into two aspects: knowledge durability and team durability.

Knowledge durability means building knowledge that grows and deepens over time. The only way that happens is to take full ownership of the whole picture — understanding customer needs and expanding on them, turning those needs into a rich comprehension of how they can and should be met. It can’t be handed to the team through upstream specifications or lists of requirements; that approach loses too much context.

Team durability is the logical extension. Team members must be long-lived on the team. It isn’t 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 domain, what the bank needs, what customers need and the technical knowledge behind fraud prevention.

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.

The five attributes

A team with a product mindset is:

1. Durable — long-lived membership, so knowledge compounds instead of resetting.
2. Cross-disciplined — gone are the days of siloed members living in narrowly focused domains. The team holds business domain expertise, design, architecture, engineering and delivery capacity.
3. Whole — the customer shares the table. Your customer could literally join the team, or the team regularly sits with them. The team isn’t whole without both customer and technology present.
4. Empowered — if the team must wait for an external business event to deliver, it isn’t enabled. If it can’t deploy to production daily, it isn’t empowered. If it isn’t responsible for monitoring and maturing the application once live, it’s neither informed nor accountable.
5. Right-sized — the right skills without external dependencies, while staying as small as possible.

Empowerment 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.

Deep roots in the product and a strong customer relationship mean aligning around outcomes, not feature lists. It’s no longer about “shipping the feature.” The team tests hypotheses quickly, proves what works and kills off features that don’t move the needle — the discipline covered in continuous discovery.

Start with the product trio

Every product team is led by three roles working as one unit — the product trio.

The product manager owns value and viability. This is not a backlog-administration job. The product manager holds the thread from vision to strategy to roadmap, decides what gets built next and answers for the outcome. Customers and evidence inform every one of those decisions — that’s what separates a real product manager from the distant roadmap-translator so many organizations settle for.

The product designer owns usability. User research, prototyping and usability testing, run continuously alongside delivery with the product manager as a partner. Discovery is a habit, not a one-time upfront phase.

The tech lead owns feasibility: technical direction, engineering standards and the technical health of the product. Read “architect” as an enabling role — the tech lead is the accountable technical owner, and likely spends more time mentoring the team than writing code.

The trio leads; it doesn’t replace the team. Around it sit engineers, quality, domain experts and — always — the customer. If one of those three seats is empty, a whole class of decisions has no owner. Fill it before you worry about anything else.

One clarification worth making: the product trio is not the “three amigos.” The trio leads the product. The three amigos — value, implementation and testing — are the three perspectives a specification conversation needs before implementation begins. Different tools for different jobs.

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 and cross-functional — same disciplines around the table — but it’s handed a prioritized list of features to build. Outcomes belong to a stakeholder upstream. The team is judged on output: did you ship what was on the roadmap?

That’s the trap. A feature team can look agile from the outside while operating exactly like a project team: authority for what to build still lives above it. For everything that follows, the distinction that matters is simple — a product team owns the outcome and its value stream end-to-end; a feature team owns a queue.

A project team is further still: pulled together to execute a discrete project, then dissolved. Specialists rotate in and out, taking their knowledge with them. Deep product knowledge never develops, and the customer is usually removed from the team entirely, contributing only through upstream stages.

Right-sizing

Team sizing can be a challenge. Consider the small scale first: a team of only three or four. To be cross-disciplined it needs business domain expertise, design, engineering, quality and delivery — more capabilities than it has people.

My go-to solution is rotation inside the team. Rather than hiring a full-time quality assurance or DevOps specialist, rotate that skill through the team. From one iteration to another, team members take turns fulfilling the role. Each member gains broader skills, and nobody becomes a permanent bottleneck.

On the other hand, what about a team that seems to demand too many people? Teams should be in the 6 to 10 range. If a team grows beyond that, it’s a sign the product itself has become too big — decompose the product and give each piece to a team that can own it whole.

Starting with one person per discipline gives you a template team of around eight roles — the trio at the front, the rest of the capabilities around them:

A role doesn’t necessarily equate to a person. Is the customer sitting with the team every day, or meeting for several hours each week? Will the quality engineer be a dedicated specialist, or a rotating role? Answer those honestly and the roster lands where it should.

The need for specialists

Sometimes you need specialists, and it may not make sense to embed one permanently. That’s fine — but specialists must impart knowledge to the team, not perform magic and vanish. If you need an expert on machine-learning fraud detection, bring them in, and make sure they spend their time conveying knowledge rather than building something the team doesn’t understand.

Two cases resist this: performance testing and security audits. Performance testing at scale demands heavy hardware and specialized skills. Even so, pull those experts into the team — the team is perfectly capable of building a small-scale performance harness, and the product ends up better aligned to performance outcomes. The same holds for security: it belongs in the plan from day one and in feature delivery, so the product passes audits by design rather than getting shunted back for last-minute patching.

Quality assurance isn’t on the specialist list deliberately. All QA and testing work needs to be embedded in the team. If it isn’t, the team won’t own quality, and won’t be invested in meeting customer needs.

Own the whole thing

Strip away the org charts, the rituals and the role titles and one thing separates a product team from everything else: it owns the whole thing — the customer, the problem, the value stream, delivery mechanics, the running software in production. Durability, value discovery and elite delivery follow from that. The process around the team doesn’t create those outcomes. Ownership does.

So hold the mirror up. If your team is handed features against a roadmap someone else built, ships them and moves on, you don’t have a product team — you have a feature team running the same standups. The gap between the two is never really about talent or tooling. It’s about ownership, funding and authority: who decides what to build, who pays for the team and who owns the outcome once it’s live.

If that gap describes your situation, close it deliberately. Pick one team, give it something real to own and defend its ownership like it matters — because it does.

Next steps

• 1.1 Team mobilization — the activity: team matrix, RACI, decision rights, rituals and channels
• Continuous discovery — how the trio keeps deciding what to build
• How product teams outperform — the evidence, if you still need to convince someone