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.
De votre premier prompt à un résultat livré — voici comment Emma fonctionne réellement.
Emma part d’une opportunité réelle et validée — pas de « j’ai eu une idée sous la douche ».
Transférer à IrisQui fait quoi, quand, et comment savons-nous que cela a fonctionné ? Assez clair pour qu'un ingénieur puisse le construire.
Limitez la spécification à la plus petite version qui valide l’hypothèse — c’est ici que les dérives de périmètre sont détectées.
Les compromis d’architecture et le temps de développement sont pris en compte avant que la spécification ne soit figée — pas de surprise en cours de build.
Transférer à BobLe PRD va directement dans la file de build — le même artefact partagé par les PM, l’architecture et l’ingénierie.
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.
Les workflows conçus manuellement sont lents, manuels et très dépendants des outils. Survolez une carte pour voir pourquoi chaque gain compte.
Vous venez de ChatPRD ? Voici où Emma prend l’avantage.
ChatPRD génère un PRD soigné qui reste dans Notion pour toujours. La spec d’Emma passe directement dans l’esquisse d’architecture de Bob et le plan de développement d’Alex — le document que vous rédigez devient le produit en quelques jours, pas au trimestre prochain.
La plupart des outils PRD disent oui à chaque idée de fonctionnalité. Emma demande : "quelle est la plus petite version qui prouve que ça marche ?" puis rédige la spec pour cela. Le scope creep est stoppé dans la spec, pas une fois que l'ingénierie a déjà commencé.
Notion AI vit dans votre wiki. Emma travaille aux côtés de Iris (research), Bob (architecture), Alex (engineering) et Mike (approvals) — ainsi, le PRD est relu par l’équipe qui va le construire avant même que vous n’ayez dépensé une seule heure d’ingénierie.
| Fonctionnalité | Atoms Recommandé | ChatPRD |
|---|---|---|
| Résultat | Une spécification qui se concrétise | Document peaufiné |
| Connecté à l’ingénierie | Transférer à Alex | Vit dans Notion |
| Discipline du périmètre intégrée | état d’esprit v1 | Dit oui à chaque idée |
| Implique l’architecte dans l’évaluation de la faisabilité | Avant le verrouillage des spécifications | Vous devez demander séparément |
| Critères d’acceptation | Par user story | Par user story |
Emma ne travaille pas seul. Voici comment se font les relais quand vous construisez avec l’équipe complète.
Le PRD d’Emma va directement dans l’esquisse d’architecture de Bob. Pas de « qu’est-ce que le PM voulait dire ? » à décoder plus tard par les ingénieurs.
Voir comment Bob fonctionne
Emma porte le quoi et le pourquoi ; Alex construit le comment. Les specs se traduisent en code sans perte lors du handoff.
Voir comment Alex fonctionneIris valide une niche ; Emma définit le périmètre du produit qui l’emporte sur cette niche.
Voir comment Iris fonctionneConcrete 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.
Aucun agent ne travaille seul. Touchez n’importe quel coéquipier pour voir comment il gère sa partie de votre produit.
Stop writing PRDs no one reads. Let Emma write specs your AI Team builds the same day in Atoms.
