Couple of things come to mind here.
Shaper Technical Ability
A lot of product development workflows don’t necessary require product managers, product owners, etc. to have much technical ability. My opinion is that Shape Up is slightly different. In order to be able to properly constrain and write a good pitch, the shaper should have at least some level of understanding of product architecture. This helps greatly with setting boundaries and uncovering rabbit holes early on in the shaping process. At the very least, identifying new vs. existing patterns, design components, etc. can help the shaper understand when in the process a senior developer needs to be involved.
Discussing vs. Investigating
A discussion around the technical details of a new project doesn’t necessarily remove someone’s focus as long as they’re allowed to do so asynchronously, and given the responsibility to decide for themselves whether something can be a discussion or if it truly needs further investigation. In many cases, further investigation can be avoided by properly defining out of bounds and rabbit holes.
My thought is that one of the key details of Shape Up that isn’t really discussed by RJS and that enables team focus on a single project is having CTO level or Principal (senior-most) Engineers that have the room to do deep technical work out of cycle. In Basecamp’s case I think those would be people like DHH and at least Jeremy (guessing). In our case, the VP of Engineering/Product and Director of Engineering don’t have in-cycle commitments which should give them availability to help on technical details in shaping.
I also talk about Shape Up and Product Development in general on Twitter