Emma·Product ManagerEmma turns ideas into PRDs your AI Team builds the same day, not specs that sit in a doc for two sprints.
From idea to scoped feature in one chat.
ChatPRD writes a polished doc. Your engineers still have to re-interpret it, split it into tickets, and chase the gaps. Emma writes PRDs Alex reads as the source of truth, no translation layer.
The PRD lives in Notion. The code lives in GitHub. The product lives in production. By sprint 2 they tell three different stories. Emma keeps the PRD in the same workspace as the code so it stays the source of truth.
Solo PRD tools write whatever you ask for. Emma proposes a v1 cut and pushes back on scope drift instead of quietly turning a 2-week feature into a 2-month project.
Từ prompt đầu tiên của bạn đến một kết quả đã được phát hành — đây là cách Emma thực sự hoạt động.
Emma bắt đầu từ một cơ hội có thật, đã được xác thực — không phải kiểu "tôi nảy ra ý tưởng khi đang tắm."
Bàn giao cho IrisAi làm gì, khi nào, và làm sao chúng ta biết nó hiệu quả? Đủ rõ ràng để kỹ sư có thể xây dựng nó.
Giới hạn đặc tả ở phiên bản nhỏ nhất có thể chứng minh giả thuyết — sự phình to phạm vi sẽ được phát hiện ở đây.
Các đánh đổi về kiến trúc và thời gian xây dựng được tính đến trước khi chốt đặc tả — không có bất ngờ giữa chừng khi triển khai.
Bàn giao cho BobPRD đi thẳng vào hàng đợi build — cùng một tài liệu dùng chung cho PM, kiến trúc và kỹ thuật.
Problem, goals, users, scope, out-of-scope, and success metrics in a consistent format every time.
Each story is implementable and testable, not a vague feature wish.
Emma flags ambiguous requirements and proposes a v1 cut instead of writing everything you ask for.
Pulls findings from Iris when available so PRDs are grounded in real insight.
Alex reads the PRD as the source of truth for implementation, no translation layer.
PRDs live in the Editor next to the code, so updates stay visible to the whole team.
Tier the depth from quick internal tool spec to full feature PRD based on what you actually need.
Các quy trình làm thủ công thì chậm, thủ công và phụ thuộc vào nhiều công cụ. Di chuột qua bất kỳ thẻ nào để xem vì sao từng lợi ích lại quan trọng.
Bạn chuyển từ ChatPRD sang? Đây là điểm mà Emma vượt lên.
ChatPRD tạo ra một PRD chỉn chu, được lưu lại mãi trong Notion. Bản đặc tả của Emma đi thẳng vào phác thảo kiến trúc của Bob và kế hoạch xây dựng của Alex — tài liệu bạn viết sẽ trở thành sản phẩm chỉ trong vài ngày, không phải đến quý sau.
Hầu hết các công cụ PRD đều nói có với mọi ý tưởng tính năng. Emma hỏi: "phiên bản nhỏ nhất chứng minh điều này hoạt động là gì?" rồi viết đặc tả cho phiên bản đó. Scope creep được chặn ngay trong bản đặc tả, chứ không phải sau khi engineering đã bắt đầu.
Notion AI hoạt động ngay trong wiki của bạn. Emma làm việc cùng Iris (research), Bob (architecture), Alex (engineering) và Mike (approvals) — vì vậy PRD được chính đội ngũ sẽ xây dựng nó rà soát trước cả khi bạn tốn dù chỉ một giờ kỹ thuật.
| Tính năng | Atoms Được đề xuất | ChatPRD |
|---|---|---|
| Đầu ra | Đặc tả dùng để xây dựng | Tài liệu đã được trau chuốt |
| Được kết nối với bộ phận kỹ thuật | Bàn giao cho Alex | Nằm trong Notion |
| Kỷ luật phạm vi được tích hợp sẵn | tư duy v1 | Nói có với mọi ý tưởng |
| Mời kiến trúc sư tham gia đánh giá tính khả thi | Trước khi đặc tả được chốt | Bạn phải hỏi riêng từng phần |
| Tiêu chí chấp nhận | Theo từng user story | Theo từng user story |
Emma không làm việc một mình. Đây là cách các bước bàn giao diễn ra khi bạn xây dựng cùng toàn bộ đội ngũ.
PRD của Emma đi thẳng vào bản phác thảo kiến trúc của Bob. Không còn cảnh kỹ sư phải giải mã sau này "PM muốn nói gì".
Xem cách Bob hoạt động
Emma chịu trách nhiệm cho cái gì và tại sao; Alex xây dựng cách thực hiện. Đặc tả được chuyển thành mã mà không mất mát qua khâu bàn giao.
Xem cách Alex hoạt độngIris xác thực một thị trường ngách; Emma xác định phạm vi sản phẩm có thể chiến thắng trong thị trường ngách đó.
Xem cách Iris hoạt độngConcrete product artifacts Emma produces that feed straight into engineering.
Full PRD for one feature with problem, scope, user stories, and acceptance criteria.
Define what ships in v1 and what waits, so you launch something useful instead of nothing perfect.
User stories with clear acceptance criteria your engineers can build and test against.
Cut a feature into shippable slices so each sprint produces something you can demo.
Lightweight PRDs for internal tools that need clear scope but not customer-facing rigor.
Define what done means before launch so nothing critical gets missed at release.
@Emma write a PRD for a referral program for our SaaS. Pull Iris's audience research, define problem, scope, out-of-scope, and v1 metrics, then write user stories with acceptance criteria Alex can build against.
@Emma I want to launch a freelancer time-tracking SaaS in 4 weeks. Ask me the right clarifying questions, then propose a v1 scope that ships something useful, with a clear list of what waits for v2.
@Emma the current notifications PRD has 14 user stories and we have one engineer-week. Cut it to 3 stories that deliver the core value, flag what we lose, and rewrite the doc.
@Emma we launch the invoicing module next Thursday. Write the launch checklist covering acceptance criteria, David's tracking spec, Sarah's landing page status, and Adrian's campaign readiness.
Không agent nào làm việc một mình. Chạm vào bất kỳ đồng đội nào để xem họ xử lý phần việc của mình trong sản phẩm của bạn như thế nào.
Stop writing PRDs no one reads. Let Emma write specs your AI Team builds the same day in Atoms.
