The scenario
Your team wants to add real-time notifications to your web app. In a traditional workflow, this would mean a meeting, someone volunteering to write tickets, a week of back-and-forth, and eventually some loosely-scoped issues that developers have to interpret.
With Lisa, here's how it actually goes.
Step 1: Start a discovery session (5 minutes)
Open Lisa and say:
"I want to add real-time notifications to our app. Users should get notified about issue updates, new comments, and when they're assigned to tasks."
Lisa starts a discovery session. She asks:
- "I see you're using PostgreSQL and Next.js. Should we use WebSockets, SSE, or a polling approach?"
- "Should notifications persist in the database or be ephemeral?"
- "What channels do you need — in-app, email, or both?"
You answer conversationally. Lisa builds context.
Step 2: Lisa generates the plan (2 minutes)
Lisa produces:
A PRD
Complete product requirements document with:
- Goals and non-goals
- User stories (5 stories covering different notification types)
- Acceptance criteria for each story
- Technical considerations based on your actual codebase
An architecture document
- System design using pg_notify + WebSocket
- Data model for notifications table
- API contract for notification endpoints
- Integration points with your existing event system
Step 3: Lisa creates the work (3 minutes)
From the plan, Lisa generates:
A milestone: "Real-time Notifications v1"
Due date based on scope estimate.
8 structured issues
Each issue has:
| Issue | Dependencies | Acceptance Criteria |
|---|---|---|
| Database schema for notifications | None | Migration runs, table created |
| Notification service (pg_notify) | Schema | Events trigger notifications |
| WebSocket endpoint | Service | Connections handle 1000+ clients |
| Client-side WebSocket hook | Endpoint | Real-time updates in UI |
| Notification bell component | Hook | Badge shows unread count |
| Email notification channel | Service | Emails sent within 60 seconds |
| Notification preferences | Schema | Users can toggle per-type |
| E2E tests | All above | All scenarios pass |
Each issue includes verification hints:
## Verification
- Run: `SELECT * FROM notifications WHERE user_id = ?`
- Check WebSocket message arrives within 5 seconds
- Verify unread badge updates without page refreshStep 4: Sync to your tools (1 minute)
Push the issues to Linear or GitHub with one click. Status, priority, labels, and descriptions all sync bidirectionally.
Step 5: Ship
Developers pick up issues with full context. No "what does this ticket mean?" conversations. No missing acceptance criteria. No lost context about why the WebSocket approach was chosen over SSE.
Total time: ~15 minutes
From "I want notifications" to 8 fully-scoped issues with a PRD, architecture doc, milestone, and dependencies. Ready for developers to start work.
Try it yourself
Sign in to Lisa and run your own discovery session. Connect your repos, start a conversation, and see how it changes the way you think about project decisions.