Free AI PRD generator

Team invites during setup Problem: Office managers set up new scheduling accounts but often never add their team: 38% of new accounts have no second user after 14 days. Accounts with 2+ users are the ones that convert to paid. Goals: - More new accounts get a second user in their first 14 days - Invite teammates without leaving setup Success metrics: Share of new accounts with no second user at day 14: baseline 38%, target 25% (proposed). Non-goals: - Bulk import from HR or payroll systems - Changes to roles and permissions Users and use cases: Primary user: an office manager setting up an account. Use cases: invite teammates during setup; skip and invite later; get a reminder if they forgot. Requirements: 1. [P0] Setup includes an invite step after account creation where the user can enter one or more email addresses. 2. [P0] The invite step can be skipped, and skipping never blocks finishing setup. 3. [P0] Each invited address receives an invitation email with a join link. 4. [P0] If no second user has been invited by day 3 after sign-up, the account owner receives one reminder email. 5. [P1] The reminder email links directly to the invite screen. 6. [P2] The invite step shows how many teammates have joined (proposed). User flow: 1. User creates the account. 2. Invite step: enter emails or skip. 3. Invitees get an email and join. 4. Day 3: if no one has been invited, the owner gets a reminder. Edge cases: - Invalid email address: show an inline error; valid addresses still send. - Invitee already has an account: [decide] - Owner invited someone who hasn't joined by day 3: no reminder, because an invite was sent. Open questions: - Should the day-3 reminder go out if an invite was sent but not accepted? - Is there a limit on invites per account during setup? Risks and dependencies: - Email deliverability for invites and reminders (proposed) - Tracking needed to measure the day-14 metric (proposed)

Partial payments and deposits on invoices Problem: Freelancers using the invoicing app want to collect part of an invoice upfront, such as a 50% deposit, and today they can't. [evidence: how many requests, from which customers] Goals: - Let senders request and collect part of an invoice's total - Keep the remaining balance clear to both sides Success metrics: Share of invoices using partial payments: [baseline] 0, [target]. Support requests about deposits: [baseline], fewer after launch (proposed). Non-goals: - Payment plans with automatic installments - Changes to taxes or accounting exports (proposed; confirm) Users and use cases: Primary user: a freelancer sending an invoice. Use cases: request a 50% deposit before starting work; client pays the deposit, then the balance later. Requirements: 1. [P0] The sender can set an amount or percentage due now on an invoice (proposed). 2. [P0] The invoice shows amount paid and balance remaining after each payment (proposed). 3. [P1] The sender is notified when a partial payment arrives (proposed). 4. [P1] The sender can request the remaining balance with one action (proposed). User flow: 1. Sender creates an invoice and sets a deposit. 2. Client pays the deposit. 3. Invoice shows as partly paid. 4. Sender requests the balance; client pays it. Edge cases: - Client pays more than the deposit: [decide] - Invoice edited after a partial payment: [decide] - Refund of a deposit: [decide] Open questions: - Can clients choose the amount, or only the sender? (product) - How do partial payments appear in accounting exports? (finance, engineering) - Does the payment provider support partial captures on one invoice? (engineering) Risks and dependencies: - Payment provider support for partial payments (proposed) - Accounting export format changes (proposed)

CSV export for all reports Problem: Ops managers want to take report data into spreadsheets and can't. There were 14 support tickets asking for export last month. Goals: - Export any report to CSV with the filters shown on screen - Handle large reports (up to 200,000 rows) reliably Success metrics: Export-related support tickets: baseline 14 per month, target near 0 (proposed). Share of weekly active accounts using export: [baseline], [target]. Non-goals: - Excel (.xlsx) or PDF export - Scheduled or emailed exports Users and use cases: Primary user: an ops manager. Use cases: export a filtered report to share with finance; pull a large report into a spreadsheet for analysis. Requirements: 1. [P0] Every report has an Export CSV action. 2. [P0] The export contains exactly the rows and columns matching the filters on screen. 3. [P0] Exports up to 200,000 rows complete without timing out. 4. [P0] Large exports run in the background and notify the user when ready (proposed threshold: [rows]). 5. [P0] The CSV uses UTF-8 and quotes fields containing commas or line breaks. 6. [P1] Dates and numbers export in a consistent, spreadsheet-readable format (proposed). 7. [P1] The file name includes the report name and export date (proposed). 8. [P2] Users see their recent exports for 7 days (proposed). User flow: 1. User applies filters to a report. 2. User selects Export CSV. 3. Small export: file downloads. Large export: user is told it's being prepared. 4. User downloads the file when notified. Edge cases: - Report with no rows: export a header-only file. - Filters changed while a background export runs: the export uses the filters at request time. - User lacks access to some columns: those columns are excluded. - Export over 200,000 rows: [decide] - Text fields beginning with = or +: escape them so spreadsheets don't run them as formulas (proposed). Open questions: - Row threshold for background exports (engineering) - Should exports be logged for audit? (security) Risks and dependencies: - Database load from large exports (proposed) - Notification system for background exports (proposed) Launch plan: - Release to all accounts, starting with the 14 customers who asked (proposed). - Tell support and publish a help article. - Measure export tickets and usage for 30 days.