Most product-versus-engineering fights get blamed on personalities. They live at the seams.
Product owns the what. Engineering owns the how. That part is usually clear. The trouble starts at the two places where work has to cross between them: the seam where product hands a story to engineering to build, and the seam where engineering hands it back, which is to say, ships it. On most teams each of those crossings runs on one side's say-so alone. Product decides a thing is ready and pushes it into the queue. Engineering decides a thing is done and calls it shipped. Nobody on the other side gets a vote, the board slowly stops meaning anything, and everyone blames the other team's attitude for what is really a structural problem.
The fix is a shape you already know. You have probably walked through one at a butterfly exhibit: you step through the first door, it closes behind you, and only then does the second door open. It keeps the butterflies from escaping, and it gives the staff a chance to make sure nothing harmful comes in with you. A healthy board has two of these, one at each seam. Nothing crosses until both doors have opened, in order.
Split the board
The backlog belongs to product, outright, to order however and whenever they want. In Progress belongs to engineering, outright, once the prework is real. Each side owns its end without apology. The airlocks sit on the two hand-offs between them.
The entry airlock · On Deck
A story reaches the shared On Deck column only when two doors open. Product's door is priority: it is the true next thing, and it is shovel-ready, spec'd, contextualized, no open questions, something a developer could pick up right now and start. Engineering's door is readiness: the acceptance criteria are clear, the work is understood, and it is right-sized, a few days and rarely more than a week. This is the door most teams skip. Any PM can get their top feature to the top of the backlog. Almost none can get it ready. Priority is the easy half. Ready is the hard one, and without a forcing function it quietly never happens.
Pull in strict priority order
Once work is on deck, the team always takes the next highest item. No cherry-picking, no reaching for the piece you happen to enjoy. Bugs, features, and tech debt all live in one agreed order. Brutal shared ownership of every item beats specialization, because a thing that is started is worth more than a thing that is admired. (A small operational grace: the backlog itself only needs approximate order, because product re-picks at the On Deck gate. Save strict one-to-n for On Deck, where it earns its keep.)
Hold the quarter
Reserve about 25% of the board for engineering-health work, and watch that number together, out loud, every grooming session, correcting it when it drifts. The capacity is reserved, but the prioritization stays shared. Engineering still has to convince product that a given piece of health work is worth doing, and those items compete in the same single priority order as everything else. The trick was never the number. It was that two people watched it on purpose. A number two people watch beats a policy nobody enforces.
The exit airlock · In Review to Ship
When a developer calls a story done, it does not go to done. It goes to In Review. That is engineering's door: the definition of done, coded, unit-tested, test plan executed, bugs fixed, could ship today. Then comes product's door: the acceptance test. The PM tries to use the thing, naively, the way a customer would, usually live so the whole team watches it work or watches it break. Only when it does what it promised does the second door open and the story ships. Nothing reaches done on a developer's word alone.
What it bought
We built Azure DevTest Labs on this board. It worked when we were tiny: me, two engineers, and a PM running the acceptance test right after standup. It worked just as well when we grew past thirty people running a service that managed about 5% of all Azure VMs. By then the acceptance test had become a reverse demo day: the PMs would pick up whatever was In Review and demo it against the user story, so “show it, don't say it” was built into the last gate. The auto-shutdown feature that came off that board still runs across Azure today.
The same operating model carried four people and thirty-plus without a rewrite. It scaled because it was never about heroics or a particular cast of characters. It was about who could move work across a line, and making sure the answer was always “not one side alone.”
Not just clarity. Shared clarity.