Cross-Functional Collaboration
If Leading Without Authority is the philosophy, this is the daily practice. A PM sits at the center of a team they do not manage, across engineering, design, data, and GTM, and the product only happens when those functions move in sync. Brandon Chu's metaphor fits perfectly: the PM is "the API" every function calls to coordinate. This note is about being a good API: reliable, well-documented, low-latency, and trusted.
#My point of view: you are a connective tissue, not a boss
The PM does not sit above the functions. They sit between them. This is the Product-Design-Engineering Venn made operational: your job lives in the overlaps, and your value is making the whole greater than the parts. Get this right and the team feels like a single organism. Get it wrong and you are a bottleneck everyone learns to route around.
The mindset shift that matters is that you are in service to the team's effectiveness, not its commander. The best collaboration I have seen comes from PMs who ask "what do you need from me to do your best work?" more than they say "here is what I need you to build."
#The functions, and what each needs
Each function has a different contract with the PM. Treating them identically is a rookie error.
| Function | What they own | What they need from the PM |
|---|---|---|
| Engineering | Feasibility, how it's built | A clear problem, stable scope, the honest why behind trade-offs; respect for their estimates |
| Design | Usability, the experience | The user problem (not your solution), early involvement, room to explore (Design Sense and Critique) |
| Data | Truth, measurement | Sharp questions, not "pull me some numbers"; involvement before launch, not after |
| GTM / Marketing / Sales | Commercialization, the market | Enough lead time, a narrative to sell, honest dates (Internal and External Stakeholders) |
This maps to Cagan's ownership split across The Four Big Product Risks: the PM owns value and viability, design owns usability, engineering owns feasibility. Knowing what you do not own is half of collaborating well. The fastest way to lose a designer is to art-direct, and the fastest way to lose an engineer is to dictate architecture.
#Trust is the currency
Everything above runs on trust, and trust has unglamorous mechanics:
- Reliability. You do what you said, when you said. Boring, and the entire foundation.
- Credit and blame. Push credit to the team, absorb blame yourself. This single habit builds more trust than anything else I know.
- The honest why. Never "because the VP said so." Explain the real reasoning (Leading Without Authority).
- Defending the team. Take the heat from stakeholders so your team can focus. Air cover earns loyalty.
This is why I treat collaboration as a character issue as much as a skill one (Character, Competency, and Craft). You can teach someone meeting hygiene. You cannot easily teach the generosity that makes a team trust them.
In a feature team, the PM is reduced to a backlog-administrator handing pre-decided work to engineering. Collaboration collapses into ticket-passing, and the team becomes mercenaries. Real cross-functional collaboration requires an empowered team solving a problem together, not a relay race of handoffs. If your "collaboration" is just routing specs to builders, the org structure is the bug.
#The product trio
The tightest version of this is what Teresa Torres calls the product trio: PM, design, and a tech lead, discovering and deciding together, continuously. I am a believer. When those three share context and make calls jointly (Continuous Discovery), you do not need heavy alignment ceremonies, because the alignment is constant and ambient. The trio is cross-functional collaboration compressed to its highest-bandwidth form.
#How AI is changing it
AI removes coordination overhead: auto-generated standup summaries, status syncing, meeting notes, draft handoff docs (How AI Is Reshaping Product Management). That is real, and it means less time spent relaying information between functions. There is a deeper shift too. As PMs and designers prototype directly with AI, some handoffs collapse entirely, and the trio gets even tighter. What a model does not supply is the trust, the read on what a teammate needs, or the generosity of pushing credit outward. AI lubricates the mechanics of collaboration. It does not supply the relationship.
#Continue Reading
- The Product, Design, and Engineering Venn for the structural picture of where the PM sits.
- The Four Big Product Risks for who owns what, the basis for not stepping on functions.
- Leading Without Authority for the philosophy this note operationalizes.
- Product Teams vs Feature Teams for why team structure determines whether real collaboration is even possible.
- Continuous Discovery for the product trio working together at its tightest.