Why do product and engineering keep getting misaligned even with weekly syncs?

Because decisions don't wait for the sync. Both sides make calls all week (a scope cut here, a technical workaround there), and each one silently changes the plan the other side is working from. A weekly meeting patches the gap for a day; the drift resumes Monday afternoon.

Should product decisions and engineering decisions live in the same log?

Yes, when they constrain each other, which is most of the time. A scope decision changes the architecture that makes sense; a technical constraint changes what the product can promise. Two separate logs recreate the seam you were trying to remove.

What's the fastest signal that product and engineering are out of alignment?

The demo surprise: product sees the build and says 'that's not what we agreed.' Every one of those traces back to a decision made in one room that never reached the other, usually weeks earlier, usually reasonable at the time.

How do we keep product and engineering aligned on decisions?

Alignment isn't a meeting; it's a property of the record. Product and engineering drift apart between sync points because decisions made on one side never reach the other. Keep one shared decision record both sides write to, review changes against it, and treat every unwritten agreement as already lost.

Product and engineering never disagree at the kickoff. The misalignment appears six weeks later, at the demo, and it was manufactured in between, one unshared decision at a time. More meetings won't keep the two aligned. What matters is whether decisions travel.

Why alignment decays

Both sides decide constantly. Product cuts scope in a stakeholder call. Engineering discovers the API can't do what the PRD assumed and picks a workaround. Each call is locally reasonable and quietly rewrites the plan the other side is still working from. Alignment isn't lost in one dramatic moment. It leaks.

Structure makes it worse. Conway observed in 1968 that organizations produce designs that copy their communication structures. The seam between product and engineering (different tools, different meetings, different vocabulary) becomes a seam in the product. Product decisions live in docs and decks; engineering decisions live in PRs and ADRs. Neither side reads the other's medium, so each side's record is, to the other, an unwritten rule.

Syncs don't fix this, because a sync transfers whatever people remember to raise, once a week. Decisions happen daily.

What actually works

One decision record spanning both sides. Not a product wiki and an engineering log: one log, because the decisions constrain each other. "We cut bulk export from v1" belongs next to "we're queuing exports through the job runner," and each entry names its owner. Keep the format to four fields (verdict, reason, rejected alternatives, who agreed) as described in the engineering decision log.

Write decisions where the other side will actually see them. A decision published into a channel the other function never opens is a decision kept secret with extra steps. Distribution is part of the decision, not an afterthought.

Turn the PRD into ratified constraints. Prose gets interpreted; a numbered list of testable constraints gets checked. When engineering signs the list at kickoff, mid-build deviations become visible events ("this violates constraint 4, here's why we need to change it") instead of silent reinterpretations.

Review changes against decisions, not only against code. The demo surprise exists because no step in the pipeline compares the diff to the agreement. Add that step, even manually: does this PR contradict anything we decided? It's the difference between catching drift at review and discovering it in production.

Log the scope changes too. Mid-build changes are fine; unrecorded ones are the poison. A one-line entry (what changed, why, who agreed) keeps the record ahead of reality.

Where Lockstep fits

Lockstep is that shared record, minus the filing. It captures decisions from Slack and Notion where product and engineering already make them (Jira, Confluence, and Google Docs are newer), the owner ratifies each one in a click, and PRs that drift from a ratified decision get flagged with the decision quoted. Both sides, and their AI agents, read from the same log. We're at design-partner stage. See how it works.