APEX Framework Implementation
Initiative: APEX Framework Implementation
The Bet
We believe that by providing Product Managers with AI-assisted Git-based workflows through Cursor IDE, we can: - Reduce the time from initiative to approved PRD by 50% - Increase PRD quality and completeness - Eliminate document sprawl across tools (Confluence, Google Docs, etc.) - Enable auto-generation of JIRA Epics and Stories from approved PRDs
Background
The current product development process suffers from: - Document sprawl across Confluence, Google Docs, and emails - No single source of truth for product specifications - Manual translation of PRDs to JIRA tickets - Lack of traceability from feature to original initiative - No systematic experiment-driven validation
Pilot Projects
| Project | Domain | Description | Status |
|---|---|---|---|
| Project Searchlight | Analytics | Lighthouse data integration, alerts | Selected for greenfield stack |
| Demand360 | Forecasting | Demand analytics dashboard | Data model changes needed |
| Tour Operator | Apps | B2B partner portal | Active development |
Key Decisions
Repository Architecture (2026-02-11)
Decision: Domain-centered product repositories with initiatives as directories.
Rationale: Customer-facing product surfaces (Pricing, Forecasting, Reporting) provide natural boundaries. Each initiative is a directory containing all related artifacts.
Branching Strategy (2026-02-11)
Decision: Start without PR workflow for simplicity. Use branch-per-initiative when collaboration needed.
Rationale: Reduce friction for PM adoption. Git handles merging well when work is in separate directories. Add PR workflow later if conflicts arise.
Technology Stack (2026-02-11)
| Component | Choice | Rationale |
|---|---|---|
| Frontend Platform | Vercel | Fast deployment, composable stack |
| Authentication | Clerk | Plug-and-play auth with SSO support |
| Editing | Cursor | AI-assisted, developer-friendly |
| Knowledge Work | Obsidian | Local-first, Git-compatible |
| Backend | Existing APIs | GraphQL via monolith initially |
PRD Auto-Generation (2026-02-11)
Decision: PRDs are auto-generated from initiative context (meetings, discovery, experiments).
Rationale: Reduces manual work, ensures consistency, provides input for engineering AI agents.
Success Metrics
| Metric | Baseline | Target | Measurement |
|---|---|---|---|
| PM Git adoption | 0% | 100% | Active commits |
| Time: Initiative to PRD | Unknown | -50% | Git timestamps |
| PRD completeness | ~60% | >90% | Automated validation |
| Document sprawl | High | Zero | Confluence audit |
Timeline
| Phase | Dates | Focus |
|---|---|---|
| Phase 1 | Feb 11-18 | POC with Cursor skills, test with Searchlight |
| Phase 2 | Feb 19-28 | Pilot with 2-3 PMs on selected projects |
| Phase 3 | Mar 1-15 | Iterate based on feedback, add JIRA integration |
| Phase 4 | Mar 16-31 | Full rollout, training, documentation |
Related Documents
- Process Proposal - Full process definition
- Tooling Proposal - Tool taxonomy and workflows