Day one with a new client. 8 am sprint planning meeting.

I expected the usual: the product manager walks through objectives, engineering discusses capacity and priorities, and the team commits to the sprint.

Instead, the product person started screen-sharing Jira and writing requirements live while talking. The designer was creating mockups in real-time. Engineers were trying to figure out the technical approach on the spot.

This wasn't a planning meeting. It was the start of an 8-hour Zoom session that happened every single day.

This blog post was originally a newsletter that was sent last Friday.

Want to get it directly? Head over to https://fieldway.org/newsletter to subscribe.

I took notes and observed. Afterwards, I asked the product person about the features they were building and why. I kept asking why, digging deeper.

They didn't have clear answers for most of it. Either executives had told them to build something, or it just seemed like a good idea but hadn't been validated.

There was no time for thinking. No time for design. Just constant live collaboration.

The defect rate was through the roof. They missed every sprint commitment.

A Consistent Pattern

I've seen variations of this story at multiple companies now: smart teams trapped in what they think is "collaboration" but is actually just chaos.

You know the saying: a camel is a horse designed by committee.

That's exactly what happens when product tries to think collectively in real-time. Design can't apply creativity because they're reacting in real-time. Engineering can't focus because there's no clarity on what they're actually building.

Everyone's drowning together, and somehow that feels collaborative.

These weren't incompetent people. Product, Design, and Engineering had all gotten trapped in a pattern.

The truth was that weren't actually collaborating; they were spreading responsibility for decisions across the entire team.

There's a fear underneath all this. The fear of making the wrong call alone. The fear that if something goes wrong, it's your fault.

So you pull everyone into every decision. More people in the room means the risk is distributed, right?

Except spreading responsibility doesn't reduce risk. It just creates worse outcomes.

Because product has a unique job that only product can do: thinking deeply about users and their problems, understanding the business context, and defining what to prioritize.

You can't do that job in an 8-hour Zoom meeting with everyone watching.

When product doesn't own their responsibility for deep thinking and prioritization, engineering and design are left trying to figure it out live. Nobody can get into flow. Nobody can apply their expertise effectively.

The team in this story wasn't lacking process. They were lacking the space for product to do actual product work.

What Changed Over 90 Days

Once I understood the pattern, I could help them see it too.

We started by stepping back. I helped the product team think deeply about their why - who their ideal customer was, what problems those customers actually faced, and which of those problems deserved priority.

We cleaned up the backlog. We sorted and prioritized based on user needs, not executive whims or unvalidated assumptions.

Two weeks later, sprint planning went from an all-day exercise to a 2-hour meeting. There was pre-work. Requirements were documented. Design had time to think. Engineering could focus on viability and technical approach without figuring out the problem space live.

Three months later, meeting time was down 80%. The team was hitting sprint commitments consistently. They achieved 3x productivity improvements.

Not because we had some magical new process, but because product finally had space to do their job.

The Framework I've Learned Works

Product must own deep understanding of user problems and business context. That's the job.

Product should absolutely get input from engineering on technical viability, from design on user experience, and from stakeholders on business constraints.

But bringing everyone into the thinking phase doesn't make the thinking better. It prevents the thinking from happening at all.

Here's what I've learned works consistently:

Product takes time to research, think, write, and sketch. Days, not hours. You need to talk to users. You need to understand their problems. You need to prioritize based on real data and insight.

Then you bring that understanding to design. You align on the problem and initial approaches together.

Then you bring in engineering early for viability assessment. You want their input on what's possible within your stack and architecture.

But you don't do the initial problem definition and prioritization work live with everyone watching. That's where product's unique expertise matters most.

The team I worked with had confused "involve engineering and design early" with "do all the thinking together synchronously."

One creates collaboration. The other creates chaos.

Give Yourself Permission for Thinking Time

If you're spending 8 hours a day on Zoom with your team, you're not doing product work. You're coordinating, but you're not leading.

You need time to think deeply. Not 30 minutes between meetings. Days.

I know that sounds impossible when you're already drowning. But here's what I've seen work:

Build a cadence for your sprints where engineering is executing while you're doing product work. You'll intersect frequently. You're working together. But you're not in constant real-time collaboration.

Time-box your research and thinking, but make it substantial. Block two days to talk to users and synthesize what you learned. Block a full day to prioritize the backlog based on that insight.

Set boundaries around this thinking time. You can't help engineering be successful if you haven't done the work to understand what success actually means for your users.

Your job isn't to be available to engineering every moment. Your job is to make sure engineering is building the right things for the right reasons.

That requires thinking time. Give yourself permission to protect it.

This Week

Look at your calendar. How much time did you spend this week in synchronous meetings with engineering and design?

Now ask: how much time did you spend actually thinking about your users and their problems?

If the first number is significantly larger than the second, you might be trapped in the collaboration illusion.

Here's what to do about it: Pick one day next sprint—just one—and block it for product work. No meetings. Tell your team you're doing user research or backlog analysis. Use that day to think deeply about one priority problem.

You don't have to fix everything at once. Start with one day of protected thinking time.

Cheers,

Matthew

P.S. The team in this story wasn't unique. I've seen this pattern at companies across industries. The good news is it's fixable once you recognize what's actually happening. The hard part is giving yourself permission to step back and think when everything feels urgent.