Feature Discovery

Product managers migrating a large sales/advisors org from a legacy system to a new platform need to systematically identify which features are critical to migrate, which can be improved during the move, and which can be safely cut. The legacy system lacks proper documentation and no single person knows the entire feature set, making it difficult to capture all existing capabilities and make confident scope decisions across business, tech, and design teams.

1. User provides rough feature concept. 2. AI agent restates understanding for confirmation. 3. Agent runs codebase exploration (find patterns, constraints, dependencies) and external research (similar products, libraries, best practices). 4. Map open questions on functionality, UX/UI, and business rules by priority. 5. For feature parity initiatives, explicitly validate that no legacy features are silently deferred. 6. Identify natural release phases based on dependency chains and incremental value. 7. Propose UX/UI directions with clear context and phase tags. 8. Compile discovery document with research findings, questions, proposals, and decision log. 9. On request, generate stakeholder review CSV for meetings. 10. Build functional prototype with mock data on throwaway branch for UX evaluation. 11. Ingest stakeholder meeting notes to iteratively resolve decisions and update scope.

Surfaces unknowns and dependencies upfront before specification, preventing late-stage scope rework and feature parity misses. Enables teams to validate UX/UI with working prototypes and make informed phase decomposition decisions.

Discovery document template at .pm/templates/discovery-document.md. Prototype conventions: use existing shadcn/Radix components, follow cx-advisor-portal async server component pattern, mock data uses factory functions at src/constants/mocks/. Phase tagging applied to all questions, proposals, and assumptions. Stakeholder CSV format: three sections (In Scope, Out of Scope FYI, Questions to Decide) with columns for What, Why It Exists Today, Need It?, and Decision/Notes. No Jira references in CSV. Meeting notes stored at .pm/meetings/YYYY-MM-DD-{topic}.md with bidirectional links to discovery docs.

Investigation requires multiple iterations across three sources: scraped legacy codebase, outdated documentation (Jira and Confluence), and live system behavior. Cross-validation is essential because documentation often lags implementation and some documented features were never actually built or are no longer used. Stakeholder/user confirmation is required to validate findings, as code may contain abandoned features or undocumented behavior. The trickiest challenge is filtering noise to extract critical business input quickly, making confident scope-cut decisions, and moving efficiently into formal epic/feature definition — all while keeping the discovery phase from becoming a bottleneck. A CSV template (columns: What, Context, Need It?, Decision / Notes, Meeting notes) structures stakeholder conversations and drives decisions in sync or async formats. Conversations start as concise Slack messages to business partners, then are imported back into the discovery doc and CSV for synthesis. This creates a tight feedback loop between discovery research, stakeholder validation, and scope decisions. Critical clarity needed on every feature: what it does, who uses it, and its classification (must-have for parity, nice-to-have for later, or replace with better alternative targeting the same user need).