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.
Do seu primeiro prompt a um resultado entregue — veja como Emma realmente funciona.
Emma parte de uma oportunidade real e validada — não de "tive uma ideia no banho".
Passar para IrisQuem faz o quê, quando, e como sabemos que deu certo? Claro o suficiente para que um engenheiro possa construir isso.
Limite a especificação à menor versão que comprove a hipótese — é aqui que o aumento indevido de escopo é detectado.
Os trade-offs de arquitetura e o tempo de implementação entram na conta antes de a especificação ser fechada — sem surpresas no meio do desenvolvimento.
Passar para BobO PRD vai direto para a fila de build — o mesmo artefato compartilhado por PM, arquitetura e engenharia.
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.
Workflows feitos manualmente são lentos, manuais e dependem de muitas ferramentas. Passe o cursor sobre qualquer card para ver por que cada ganho importa.
Vindo de ChatPRD? Aqui é onde Emma sai na frente.
O ChatPRD gera um PRD polido que fica no Notion para sempre. A especificação da Emma vai direto para o esboço de arquitetura do Bob e para o plano de desenvolvimento do Alex — o documento que você escreve vira o produto em dias, não no próximo trimestre.
A maioria das ferramentas de PRD diz sim para toda ideia de funcionalidade. Emma pergunta "qual é a menor versão que prova que isso funciona?" e escreve a especificação para isso. O aumento de escopo é identificado na especificação, não depois que a engenharia já começou.
Notion AI vive na sua wiki. Emma trabalha ao lado de Iris (research), Bob (architecture), Alex (engineering) e Mike (approvals) — assim, o PRD é revisado pela equipe que vai construí-lo antes que você gaste uma única hora de engenharia.
| Recurso | Atoms Recomendado | ChatPRD |
|---|---|---|
| Saída | Especificação que vira produto | Documento refinado |
| Conectado à engenharia | Passar para Alex | Fica no Notion |
| Disciplina de escopo incorporada | mentalidade v1 | Diz sim para toda ideia |
| Envolve o arquiteto na viabilidade | Antes de a especificação ser definida | Você precisa perguntar separadamente |
| Critérios de aceitação | Por user story | Por user story |
Emma não trabalha sozinho. Veja como as passagens de trabalho acontecem quando você desenvolve com a equipe completa.
O PRD da Emma vai direto para o esboço de arquitetura do Bob. Nada de engenheiros tendo que decifrar depois "o que o PM quis dizer".
Veja como Bob funciona
Emma é responsável pelo o quê e pelo porquê; Alex constrói o como. As especificações viram código sem perdas na passagem.
Veja como Alex funcionaIris valida um nicho; Emma define o escopo do produto que vence nesse nicho.
Veja como Iris funcionaConcrete 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.
Nenhum agente trabalha sozinho. Toque em qualquer colega de equipe para ver como ele cuida da parte dele no seu produto.
Stop writing PRDs no one reads. Let Emma write specs your AI Team builds the same day in Atoms.
