Working in multidisciplinary squads has become the default model for most modern organizations. Engineering, Data, Design, and Product—these are our four pillars. But too often, collaboration becomes chaos. There are many things that people working with technology learn from books, but the reality can be pretty different.
>> The PM doesn’t own the squad. The PM owns the product strategy.
The myth of the squad owner
Modern tech teams are built around multidisciplinary squads. The idea is simple: bring different skills and perspectives together to build better products, faster.
But in real life things get a little bit different: roles get blurry, people overstep and collaboration becomes friction, This is precisely why the idea of a squad owner can be attractive; after all, if collaboration can get messy, you need someone to organise that mess
But the Product Manager is not the “owner” of the squad. That responsibility is shared — and structured. The PM plays a crucial role, but not the only one. This is especially considering that we (and as “we” I am part of it as well, since I've been working as Product Manager for the past 10 years) cannot necessarily code and also decide what is the best UX for a given product.
Before we talk about collaboration, we need to define what each seat actually owns.
Engineering owns the “how”
PMs connect strategy to user pain and define the problem to solve. But once the solution is framed, engineering decides how to build it.
It’s crucial that product managers get that engineering isn’t a service provided to the product team, but a crucial pillar in bringing the business strategy to life.
Yet, too many PMs still behave like backseat developers, without understanding that it’s not leadership. They’re attempts, often fruitless , at control and even micromanagement, which do not guarantee quality delivery.
Of course, great PMs ask smart questions. Sometimes engineering defaults to the path they know best and it may not be the best path overall. So it’s our job as PMs to challenge those assumptions, understand trade-offs, and push for scalable solutions.
But, it’s the engineers who write, review, and ship the code. And that requires a culture of collaboration inside engineering itself and, more than that, it requires trust.
Peer code reviews, pairing across seniority levels, and approval workflows are not just bureaucracy. Even in the era of AI,where operational processes are being optimized through a variety of tools, engineers play a crucial role in ensuring that what we design has a minimum set of features to our users.
Authors like Martin Fowler and Kent Beck have argued for years that strong communication within engineering teams is what drives both speed and quality. One tip here for you, as the PM, is to bring engineers to the game, sharing with them the why behind what the company wants to build.
Data: No decisions without it
I don’t know about you, but I’ve been part of many different company realities. A lot of them love to say they don’t make a single decision without checking twice, when in fact, many of those decisions are made purely empirically. The reality is no PM should make decisions without data.
I once worked at a company where the data was so clean and accessible that PMs could pull their own queries. Learning SQL changed my speed, my confidence, and my impact.
But let’s be real, many companies don’t have that level of infrastructure. And that’s why a tight partnership with data analysts is non-negotiable.
When a stakeholder says, “every customer is complaining about this,” data is what separates fact from fiction:
- How many users is that actually?
- What’s the usage pattern?
- What’s the revenue impact?
- Is this problem seasonal or structural?
And once you decide where to go, data drives the rollout strategy: A/B testing, control groups, success metrics, sample sizes, regional pilots — none of this happens in a PM’s head alone.
This is a function often overlooked in product literature. Fortunately, authors like Jake VanderPlas and Hadley Wickham have highlighted how collaboration between product and data transforms decision-making.
In an ideal world, every squad has a dedicated Data Analyst. In reality, you’re lucky to get on their roadmap. Meanwhile, Data Scientists and Engineers often sit under technical leadership, focusing on advanced or AI-driven work.
If the organization wants to grow in product maturity, it needs to invest in data, in order to build the structure that allows a truly data-driven culture to move from the PPT to the team’s day-to-day reality.
Design is not a service desk
If your designers are treated like “the people who make screens,” you’re missing out on much that professionals could deliver, and in turn they’re developing far below their potential.
I’ve worked in two different kinds of environments: one where design was focused solely on UX, and another where designers co-led the product conception alongside the PM. And I have to tell you, the second one was years ahead of the first, not to mention employees were a lot more satisfied at feeling part of something bigger.
Authors like Don Norman and Steve Krug have long stressed that exceptional user experiences emerge when designers, engineers, and product leaders collaborate early. Design isn’t a production line. It’s a partner in discovery. In mature companies, designers are often the ones who surface the problem in the first place.
Designers lead the exploration of:
- What should the product be?
- How does it impact the problem?
- How will users actually experience it?
Collaboration isn’t “everyone does everything”
Now that we have talked about the roles in a squad its time to talk about how they can interact in order to to increase the team’s overall productivity, ownership, and also happiness at work.
Marty Cagan, in Inspired: How to Create Tech Products Customers Love, says it clearly: great products come from strong partnerships between PMs, Designers, and Engineers. Shared vision, user understanding, and collective prioritization. I can say, without fear of being wrong, that this is the success formula, but I would be lying if I said it’s the easiest thing to do in the everyday running of a company.
Still, by this point, I hope I’ve made clear the difference between true collaboration and the shared confusion of ” “everyone owns (and does!) everything”.
Squads thrive when responsibilities are clearly defined and respected: Engineering leads the “how”; Product leads the “why”; Design shapes the “what” and, last but not least, DS anchors decisions in truth.
Communication is the glue of accountability
True collaboration doesn’t happen only in Slack threads or endless standups. It happens through structured, intentional communication. I’ve been working remotely for years, and I truly believe in this model. However, there’s no denying that this requires better and more organized governance to facilitate accountability.; Otherwise product teams can risk being seen as taking too long, and always saying no.
Engineers need the space to present technical trade-offs and progress. PMs need to clearly articulate vision and strategic context. Designers need to bring insights into the room early. Data needs to ground everything with evidence.
A simple RACI matrix can save your squad from weeks of ambiguity.
For example, in a discovery process:
- Responsible: Design
- Accountable: Product & Design
- Consulted: Data & Engineering
- Informed: Stakeholders & Leadership
Beyond knowing who is responsible for what, it’s essential to have clear agreements among everyone involved at each stage about how evolutions will be documented and presented. Don’t be naive in thinking you don’t need to provide visibility into what’s being done— you (definitely!) do!
Discovery should be a day to day routine, not just an occasional process
Teresa Torres, in Continuous Discovery Habits, reminds us that discovery isn’t something you schedule quarterly. It's a continuous practice that needs to be worked into your daily collaboration framework
When discovery is part of your squad’s operating system, it looks like this:
- Designers lead problem framing and user research.
- PMs tie discoveries to strategic outcomes.
- Data validates (or kills) hypotheses.
- Engineers bring feasibility into the room early.
When you get it right
When your four pillars — Product, Engineering, Data, and Design — are respected and aligned, this is what happens:
- Faster delivery. Decisions are clearer. Escalations are rare.
- Higher quality. Blind spots shrink. Solutions improve.
- Happier teams. People feel trusted and empowered.
- Better outcomes. Because clarity beats control.
But I need you to understand that this doesn’t happen overnight. It takes intention, communication,, respectful conflicts, and leadership maturity.
PMs need to accept that, although many books and articles over the years have described us as the CEO of the squad and the product, our real work is to deeply understand the product and its priorities, looking where the business wants to go, bringing the right people into the right roles, and sharing responsibilities.
How to do that? By empowering engineers to own technical excellence, designers to shape the problem, and the data analysts to anchor reality and give in sight into the real results achieved.
Final thought: Distribute power, not chaos
No one in a modern squad succeeds alone.
The PM doesn't win by controlling everything. They win by building a system where the right people own the right steps of the entire process.
So the next time someone calls you the “owner of the squad,” smile and correct them:
” I own the product strategy, but we own the squad together”
That’s how great products are built: not by heroes, but by empowered, structured, aligned teams without avoiding communication and (eventual) conflicts.
