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. A worked example of the extraction is in how do I know engineering built what the PRD said.

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.

Who owns a decision that touches both product and engineering?

One named person, decided before the debate rather than after it. Cross-functional calls are exactly where ownership goes ambiguous: product assumes engineering will push back if it matters, engineering assumes product has the final word on scope, and the call ends up owned by nobody. A role framework like DACI makes the split explicit: one Approver, named Contributors from each side, and a list of people to Inform. A useful default is that product approves what and why (scope, behavior, priority) and engineering approves how (architecture, data model, sequencing), with each side a required contributor on the other's calls.

Whatever the split, the entry records it. "Approved by" is the field that tells someone six weeks later who can change the decision, and who to ask before they work around it. On the engineering side those how decisions are usually written as ADRs; they should live in, or at least link from, the same record as the product calls.

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 (a warning by default; blocking is opt-in). Both sides, and their AI agents, read from the same log. More on the product side of the workflow is on the product teams page. We're at design-partner stage. See how it works.