AI Rollout and Template Sprawl in a 500-Person Product Org
Verdant Robotics is a 500-person robotics company with 8 product teams, 22 page templates, and Notion AI enabled for all members and guests. PMs paste raw customer interview transcripts containing personal data into AI prompts to summarize themes. Legal permits AI use only when personal data is removed. Separately, each team maintains its own PRD template, so the 22 variants use different database properties and rollups break when a PRD moves between teams. New hires take three weeks to find the canonical roadmap. The workspace has 140 teamspaces, many empty or named after former projects, and no template owner. Leadership wants faster AI adoption and a single product operating system, but security is worried about data going into prompts and product is worried about losing local flexibility.
1. Assess the AI risk and prescribe controls that still allow adoption.
Read the worked answer
The risk is not that AI exists; it is that raw customer transcripts with personal data are being placed into prompts without a lawful basis or de-identification step. Legal's condition is clear: remove personal data before AI use. The control therefore has to sit at the workflow level, not only at the tool level.
Restrict Notion AI to the smallest member group that needs it and disable it for guests if the admin setting allows. Publish an AI acceptable-use policy with examples: summarize after removing names, emails, account IDs, and free-text identifiers; use synthetic or aggregated examples for training; do not paste contracts, credentials, or clinical data. Create a de-identification checklist and put it in the interview database template. Have legal review the workflow, not every prompt.
Use workspace settings to confirm who can enable AI and monitor adoption. The judgement is to avoid a blanket ban that drives shadow AI use, while making the prohibited data flows explicit and easy to avoid.
2. Design a template and workspace structure that fixes duplication without killing local flexibility.
Read the worked answer
Consolidate from 140 teamspaces to a small taxonomy: 8 product teamspaces, plus shared Product Ops, Design, Engineering, and Company Wiki spaces. Archive empty or project-named teamspaces after moving surviving content. Create one canonical PRD database with required properties: owner, status, target release, customer segment, and decision log. The 22 templates become database template variants only where the workflow genuinely differs; otherwise they are archived.
Give teams local flexibility through views, filters, and optional sections, not through separate schemas. Use template buttons and database templates so new pages inherit properties. Lock the canonical template page and assign a template owner in Product Ops. Use linked database views on team home pages rather than copies. Put the roadmap in one database and expose team-specific views.
The judgement is that standardization should target the data model and ownership, while views and optional blocks preserve day-to-day flexibility. A single template with no governance will drift again, so name an owner and a review cadence.
3. How should Verdant measure adoption and prevent regression?
Read the worked answer
Measure leading and lagging indicators. Leading: percentage of new PRDs created from the canonical template, percentage of interview records with the de-identification checklist completed, and number of active teamspaces after archive. Lagging: time for a new hire to find the roadmap, number of duplicate templates found in quarterly review, and rollup failures in the PRD database.
Use page analytics where available and database completeness reports. Run a monthly template review with Product Ops and one representative from each product team. Keep an archive teamspace so retired templates are recoverable but not discoverable as current. Add onboarding that requires new hires to create a test PRD from the template.
For AI, audit a sample of prompts and outputs quarterly with legal and security. The goal is not zero local variation; it is that variation does not break reporting, permissions, or compliance.