I had a great conversation about collaboration with a Product Lead this week, and I’ve been thinking about it quite a bit since. Product Management roles vary so much between companies and how you work with teams is often a direct reflection of how that specific company views the PM role.

I’ve learned, mostly the hard way, that good collaboration doesn’t come from more meetings, bigger docs, or louder opinions. It comes from a simple rhythm that’s easy to repeat when things get messy: Align early. Build closely. Learn continuously. That’s the whole model. It isn’t fancy, but when I’m asked to define my collaboration style, that is the root of it.

Phase 1: Align Early

Before anything gets built, I slow things down on purpose. I want shared understanding before shared output. That means discovery conversations focused on framing the problem clearly: why we’re doing this, why now, who it’s for, and how we’ll know if it worked.

I bring design and engineering in as early as possible. We need to surface UX patterns, technical constraints, and real tradeoffs upfront—not halfway through a sprint when emotions are high and timelines are tight. I usually lean on lightweight PRDs, RFCs, and early prototypes here. I don’t love documents for the sake of documents; I use them because ambiguity is expensive. Unclear alignment always shows up later. Always.

Phase 2: Build Closely

Then we build. Closely.

Recently, for me, this doesn’t start with a ticket for engineering. It starts with agent-driven prototyping. I like getting out of Figma and into a live, usable demo in a sandbox as quickly as possible. Staying hands-on with both Design and Engineering ensures these high-fidelity demos actually align with what we can deliver in a final release.

Throughout execution, I stay in engaged in the staging or pre-production environments. I’m testing flows end-to-end and validating acceptance criteria by actually using the product, not just reading tickets and nodding along. When I give feedback, I explain the why behind it. I’ve found that video recordings where I can poke through DevTools to show exactly what happened are always well-received by engineers. Engineers aren’t big fans of long descriptions of an issue and nice visible context helps a lot here.

No matter where we are in the development cycle I always make space for engineers to push back. Some of the best product decisions I’ve been part of came from an engineer saying, “There’s a simpler way to do this,” and being taken seriously. That trust matters to me. Even if we can’t make the change now, we can plan for it for a fast-follow or future improvement.

Phase 3: Learn Continuously

After launch, I switch modes. Now it’s about learning. I look at adoption, usage, and feedback from Customer Success and Sales to see if we actually solved the problem.

• Did this change behavior?
• Did it remove friction?
• Did anyone actually care?

Sometimes the answer is uncomfortable. That isn’t a failure; it’s an opportunity. When I say I “switch modes,” I mean I take a full step back from personal feelings and listen to the feedback objectively. I want to deliver value, not just say “we launched.”

How this looks across the org

Context helps, so here is how this philosophy manifests across different teams:

• With Design: I don’t come to the table asking for “Cards” or other UI. I’m sharing customer problems and what success looks like. We align on UX goals and patterns before sketching. I want to avoid introducing UI that feels foreign unless there’s a strong strategic reason.
• With Engineering: Discovery is about shared understanding, not just handing over solutions. I respect technical ownership. Engineers own the “how,” I own the clarity of the “what.”
• With Customer Success: I treat their feedback as a standing input, not an occasional check-in. This team hears things no dashboard will ever show you.
• With Sales: I look for signal, not noise. I’ll shadow calls to help with positioning, but I’m careful to separate real market demand from loud, one-off anecdotes.
• With Leadership: I align early on strategy and constraints. I prefer prototypes and narratives over dense slide decks. I present tradeoffs and options, not just “the answer.”

The Goal

There are still plenty of frameworks I pull from when formality requires it: Outcome-driven thinking, JTBD, Dual-track discovery. I don’t follow any of them perfectly, and I don’t think you’re supposed to.

What I care about is this: collaboration isn’t just how work gets done. It’s how day-to-day execution connects to strategy. When that loop is tight, teams move faster without cutting corners. When it’s not, you feel it immediately.