Product–Engineering Sync

Purpose: Keep product and engineering aligned on roadmap, constraints, and upcoming work

How to run this meeting

The PM and EM should co-facilitate this meeting — not take turns presenting at each other. The goal is a shared understanding of what's being built, why it's being built, and what's in the way. If only one side is driving the conversation, you'll miss half the context. Rotate who opens each section and actively invite the other side to poke holes.

Surface technical constraints before commitments are made, not after. The most damaging pattern in product-engineering relationships is a product manager promising a customer a date before talking to engineering. Use this meeting as the formal checkpoint: every item that's moving from "upcoming" to "in progress" should have had an engineering feasibility conversation first. If it hasn't, that's the first thing to discuss.

Use this meeting to prevent surprises, not just share status. "In progress" items are table stakes — what you really need to discuss are the things that are about to become problems. If a technical constraint is going to delay a feature, or a product requirement shift is going to invalidate engineering work, this is the room to say it. Build a culture where raising concerns early is rewarded, not penalized.

Before the meeting

• PM updates roadmap status for all in-progress and upcoming items
• EM reviews the upcoming work list and flags any items that need scoping or feasibility discussion
• Both sides surface risks or blockers that weren't visible at the last meeting
• Any pending product decisions that affect engineering (scope changes, reprioritization) are documented before the meeting
• Architecture or technical design docs for upcoming work are linked in the agenda

Meeting Details

• Date:
• Facilitator:
• Attendees:
• Duration: 45 minutes (weekly recommended)

---

Roadmap Status

Current state of in-progress work. One line per item — flag anything that's off track.

---

Upcoming Work

Items moving into development in the next 1-2 sprints. This is the section to pressure-test before commitments are made.

Notification preferences (sprint starting March 24) Product intent: Let users control frequency and channel for each notification type. Current assumption is that this is a settings-level change with no backend complexity.

Engineering flag: There's a dependency on the notification service refactor that's currently in progress. If the refactor isn't complete by March 21, this feature will need to wait or be scoped differently. @darius to confirm timeline by EOW.

Salesforce integration (sprint starting April 7) Product intent: Sync Stoa action items to Salesforce Tasks. Bidirectional sync is a stretch goal — core requirement is one-way push from Stoa.

Engineering needs: API credentials and sandbox access from the Salesforce team. @marcus to coordinate with sales ops.

---

Technical Constraints

Engineering realities that product should factor into planning. Raise these before they become blockers.

• Database migration scheduled for April 3–4: The planned Postgres upgrade will require a 4-hour maintenance window. Any features that need to ship that week should target April 2 or April 7.
• Mobile SDK version dependency: The iOS push notification changes required for notification preferences require iOS 16+. Approximately 8% of our users are on older versions. Product should decide: graceful degradation or minimum version bump?
• Rate limiting on third-party AI provider: Current contract allows 10K summary requests/day. At current growth rate, we'll hit the limit in approximately 6 weeks. Needs a contract renegotiation or architectural change before it becomes a production incident.

---

Risks

Things that could derail committed work or create surprises downstream.

---

Decisions

Decisions made or needed. Capture the "who decided" and "why" — this is the institutional memory that prevents relitigating the same debates.

• Decided: Salesforce integration will prioritize one-way sync (Stoa → Salesforce) for v1. Bidirectional sync moves to v2 scope. Rationale: Reduces engineering complexity by ~40%; meets the needs of all 4 pipeline deals that require it.
• Pending: Mobile minimum version requirement for notification preferences. @rosa to check what % of enterprise users are on iOS <16 — may change the calculus.

---

Action Items

Follow-up

Notes are shared with both the full PM team and the engineering team leads within 2 hours. Any decisions that affect sprint planning should be communicated to the broader engineering team before the next sprint kickoff. Risks that have no clear owner after this meeting should be escalated — an unowned risk is a future surprise.