Feature Kickoff

Purpose: Give the full team shared context on a feature before work begins

How to run this meeting

The goal of a feature kickoff is not to hand engineers a spec — it's to make sure everyone understands the problem deeply enough to make good decisions without constant PM involvement. Walk through the "why" before the "what." Engineers who internalize user intent will catch edge cases, make better tradeoffs, and push back productively when implementation reveals hidden complexity.

Capture open questions in real time, in the doc, as they come up. Don't let them get lost in side conversations. Every open question should have an owner and a deadline before the meeting ends. It's normal to leave a kickoff with 5–10 open questions; that's a sign the team is thinking critically, not a sign the feature is under-specified.

Walk through edge cases explicitly, even if they feel unlikely. What happens if the user has no data yet? What if they're on a free plan? What if the API call fails? Discussing these in the kickoff is ten times cheaper than discovering them in QA. Timebox the session at 60–90 minutes and schedule a follow-up if major questions remain unresolved.

Before the meeting

• Write and circulate the feature brief or one-pager at least 48 hours before the meeting
• Include links to relevant customer evidence, design mockups, and prior art
• Confirm that design has a working prototype or high-fidelity mockups ready to walk through
• Identify the engineering DRI and any cross-functional dependencies (data, platform, security)
• Pre-read all open questions you're aware of so the group can focus on new ones

Meeting Details

• Date:
• Facilitator:
• Attendees:
• Duration: 60–90 minutes

---

Feature Overview

Summarize the feature in 2–3 sentences: what it does, who it's for, and why we're building it now. Link to the full brief.

Scheduled Reports lets workspace admins automatically send a snapshot of key metrics to a defined list of recipients on a recurring schedule (daily, weekly, or monthly). It targets operations leads who currently export CSVs manually every week and email them to stakeholders. We're building it now because it's blocking 3 enterprise expansions and was the top requested feature in the Q3 survey. → Full brief

---

Goals

List the specific, measurable outcomes this feature is expected to drive. Tie these to OKRs or metrics dashboards where possible.

• Reduce manual CSV export + email workflows for ops leads (target: 50% reduction in export-related support tickets)
• Unblock 3 enterprise expansion deals totaling $180K ARR
• Increase weekly active usage of the Reports section by 20% within 60 days of launch
• Non-goal: Real-time alerting or threshold-based notifications (separate initiative)

---

User Stories

Write stories in the format: "As a [role], I want to [action] so that [benefit]." Flag the must-haves vs. nice-to-haves.

Must-have

• As an admin, I want to schedule a report to be sent every Monday at 9am so that my team starts the week with current data without me doing anything
• As an admin, I want to specify recipients by email so that people without Acme accounts can receive reports
• As a recipient, I want to receive a clear, readable email with embedded metrics so that I don't need to log in to get value

Nice-to-have

• As an admin, I want to preview what the report email will look like before saving the schedule
• As an admin, I want to pause a schedule without deleting it so that I can resume it after a product launch freeze

---

Technical Considerations

Surface known technical constraints, dependencies, and implementation risks. Engineers should add to this section during the meeting.

• Report generation will use the existing async job queue (Sidekiq); need to confirm max job TTL supports monthly cadence
• Email delivery via SendGrid — confirm we have template slots available under current plan
• Scheduled jobs need to respect workspace timezone settings, which are stored inconsistently (some as IANA strings, some as UTC offsets) — @backend to investigate before scoping
• Data volume: largest workspace has 2.1M rows; report generation at that scale needs a benchmark before we commit to a delivery time SLA
• Dependency: Email preferences (unsubscribe) feature must ship first or simultaneously

---

Design Constraints

Document the guardrails the design must work within — platform limits, brand standards, accessibility requirements, existing patterns to follow.

• Must work in email clients that don't render CSS (Outlook, some Gmail configurations) — use table-based layout
• Report email must be accessible: alt text on all charts, sufficient color contrast, screen-reader-friendly structure
• Scheduling UI should follow the existing modal pattern (see Figma component library → Modals → Scheduled Actions)
• Mobile: the scheduling setup flow is desktop-only for V1; email output must be mobile-readable

---

Open Questions

Capture every unresolved question here in real time. Each must have an owner and a deadline.

---

Action Items

Follow-up

Post the finalized notes in the team's shared channel and link them from the feature tracking issue. All open questions should be resolved before engineering begins scoping. Schedule a technical design review if backend complexity warrants it. The PM is the DRI for resolving open questions on deadline.