Squads without handoffs

Teamwork has always been a mix of things: arguing an idea into shape, catching what someone else missed, a shared picture slowly forming. But a big part of it was handoffs, and not only between product and engineering. Customer success passed what they heard to product, product passed the spec to design and engineering, then the finished thing went to marketing, and from marketing to sales. Inside product and engineering we were already looping fairly often. The long, slow handoffs sat at the edges, and each one lost a little intent and a lot of time. That is the part agents are starting to absorb, and what remains is a smaller team, close enough to hold the whole problem at once.

It has also changed how I think about the work. I find myself thinking in loops now. The old lifecycle had them too, we just never called them out: something came in from customers, something changed, someone checked whether it worked. Building workflows around AI forces you to name them. You have to find each loop, define it, and write it down before an agent can run it again and again.

Inside the team, the roles are blurring. Product people ship code, engineers shape the product, designers land their own changes. When anyone can make working software, a title tells you less and less about what someone will bring. And who cares? As long as everyone adds value through what they are good at, it is still a team game. What matters more is what we used to treat as secondary: what you are strong at, where you are weak, and how well the team decides together. When building a feature is easy, the hard part is agreeing on which ones to ship and how they fit into a shared vision.

Most of the talk about the ideal product team still comes down to a ratio, and it is pulling in both directions. Some teams shrink to a pair, one person who explores and one who makes it hold. Others go the opposite way, one product person spread across dozens of engineers, or no product manager at all. A lot depends on what you are building, but for consumer products or traditional SaaS, I would argue the pair gets the most out of the people involved.

I would just drop the labels. Naming the two roles is still the old habit of sorting people by function, and the line between them moves from one person to the next. In my case the pull is toward the early part, where an idea goes from nothing to something real enough to argue with. The person I want next to me is good at the part I am not: what breaks at real volume, what a design gets wrong for the user nobody pictured. They might be an engineer, a designer, or another product manager. Their eye catches what mine misses, and that is the whole point of the pair.

So the useful questions about a team change. Less about which roles you need and in what ratio, more about which loops matter, who is best placed to own them, and what is still missing. And for each person: what are you best at, and what are you willing to learn?