Product Manager in the Middle - In the Brain of the Storm

🧠 Brainstorm Rooms: How We Made Discovery Truly Cross-Functional

Inês Pinheiro-Kumar returns with another chapter of The Product Manager in the Middle—this time stepping into the stormy world of cross-functional discovery.

If you’ve ever felt stuck between blockers and misaligned visions, this one’s for you. Inês shares how she turned chaotic collaboration into a powerful, repeatable practice—bringing Product, Design, and Engineering into true alignment from day one.

---

Most teams talk about the perfect synergy between Product, Design, and Engineering.

Few actually build with it.

Reading Marty Cagan’s Inspired and his take on the synergy between Product, Engineering, and Design made me realize just how rare this trifecta actually plays out in the real world. But I kept wondering—how could I foster this kind of collaboration consistently inside a large organization?

I found an answer. You might, too… if you keep reading.

⚠️ In the Eye of the Inefficient Storm - The Illusion Of Collaboration

As many of us have heard—or read—the perfect product trifecta comes from the combined perspective of the Product Manager, Engineering, and Design. As Cagan notes, the strongest initiatives come from these three collaborating from day one, taking part in shaping both the problem and the solution.

But in practice? That’s rarely the case.

What I experienced instead were broken and clunky collaboration attempts.

1. Product defines the direction.

2. Design interprets and builds wireframes.

3. Engineering jumps in to say if it’s feasible or not… after the PRD is already written.

Sometimes it works. But more often than not, promising ideas hit friction, dilute, or never reach their full potential.

I struggled with this too when I first started.

It was considered normal for the Product Manager and Designer to partner during discovery — if there was enough capacity, and if you were lucky enough to have a designer assigned to you in the first place. But once that phase ended, Design typically stepped back, only to return later to produce wireframes based on the PRD or to validate specific flows.

Engineering, on the other hand, usually entered the conversation even later, when the PRD was already written. Their involvement was often limited to suggesting technical approaches or, in the worst cases, flagging that the proposed solution wasn’t feasible at all.

By then, the window for real collaboration had already closed.

🚨 It was inefficient. And frustrating.

What baffled me was that no one else seemed all that bothered by it. People just accepted it as part of the job. But I’m not one to conform to a broken system.

⛈️ When the Solution Generates Problems

I learned the hard way that in the world of Agile, there wasn’t a clear artifact where this collaboration could naturally happen. I tried to hack it into existing meetings -sprint planning and backlog refinement—because they were the only moments when the whole team was together.

Unsurprisingly, it didn’t work.

Refinements are meant to break down defined ideas into tasks. Sprint planning is about execution, not exploration. Bringing raw, early-stage problems into these forums only led to bloated meetings and team fatigue.

So, I had to go back to the drawing board.

Then, during a regular workday, one of my engineers mentioned they’d be unavailable for a bit—they had to join a “war room” to solve a major incident. And suddenly, something clicked.

That was it.

A war room, but for ideas. A recurring space for deep, early collaboration—not just reactive firefighting.

At our next standup, I pitched the idea: "Would you be up for giving this a try?" The first few rounds weren’t perfect, but the change in team dynamics was instant. We leveled up. And more importantly, we started building together.

🌪️ Raising up a Storm

The concept was simple: everyone in one room. No stakeholders. No external distractions. Just the team—engineers, designer, product operations, and me.

Alongside my Engineering Manager, we brought problems to the table. Not specs. Not tasks. Problems.

Our goal? Get raw, unbiased solutions from all angles. Think hackathon—but without the pressure to ship. We weren’t building, just thinking. Together.

What we got back were solutions that no single role could’ve dreamed up on their own. Engineering shut down anything unfeasible or too big. Design guarded the user experience and flows. POPs ensured rollout and go-to-market realities stayed in view.

My job as PM was to make sure we were solving the right problem and reaching the right outcome.

There were times when the structure became a problem - we went too deeply into the details and components of the solution. One time, in the middle of a tangent-heavy session, an engineer stood up in frustration and said, "Isn’t this just another backlog refinement at this point?"

He was right. We had drifted.

My EM and I went back to the drawing board, and tried to properly structure this very promising new artifact - tackling the core issues, focus and time spent debating.

Below you can find a breakdown of the core structure of the meeting (and a nice template will be available for you to try this out with your team at the end of the article for Product Voyagers Subscribers!)

Here’s how we made it work.

Before the Session:

• The entire team adds problems (as Miro cards or JIRA tickets) to a shared board.

• If there are too many, the team votes on which to tackle first based on their impact.

During the Session

• The artifact runs 60–90 minutes, depending on topic volume and availability.

• Each topic gets 10 minutes max. First 2 minutes for context.

• An elected moderator keeps the discussion focused and prevents rabbit holes or discussion loops.

• After the 10 minutes are up, the team decides if a good starting point to develop the initiative has been reached.

  • If there are unclear points, the relevant team member is assigned to bring more information in the following session, and we move on.

• In the last 10 minutes, the team wraps up and reviews the outcome of each discussion that happened.

After the Session

• If an initiative is clear, it enters the usual product development flow with all the brainstorming outcomes.

• If not, it goes back into the queue for future sessions with a summary of already discussed ideas and questions.

• And if something turns out not to be worth the effort? We drop it…with confidence.

☀️ The Light After the Storm

After implementing Brainstorming Sessions, they’ve become a natural and anticipated part of our team rhythm. They’ve brought stronger, more thoughtful initiatives to life. But more than that, they’ve given everyone a deeper sense of contribution and ownership - truly improving our teamwork.

Like any Agile artifact, this isn’t a one-size-fits-all. You’ll need to adapt it to your team’s size, cadence, and org setup. But at its core, it’s about making space for truly cross-functional thinking.

That’s what gets you the magic—the kind of magic that’s promised in books, but hard-won in reality.

I share with you the screenshot of our Miro template (with the actual template shared via email to our subscribers) - this can be replicated in FigJam, Atlassian tools, or whatever whiteboard software you use - I’d dare to say, even the old school approach of sticky notes and a surface to write on is all you really need!

If you give it a try, do share with us how it went - we are always happy to hear feedback on the resources we share with our community.

---

This is a open edition of The Product Voyagers. To unlock full playbooks, tools, templates and expert takes — go Prime and get everything in your inbox.