PRD Template for Developer Tools

Example: "Backend teams spend an average of 4.5 hours per week writing and maintaining API documentation. Documentation drifts from actual API behavior within 2 weeks of any endpoint change, causing an average of 3.2 integration issues per sprint that take 45 minutes each to debug. Frontend engineers report that 67% of API integration bugs stem from documentation inaccuracies, not actual API problems."

Example: "Primary: Reduce time from 'API endpoint changed' to 'documentation updated and accurate' from 2 weeks to under 5 minutes (automated from code). Developer experience: Time-to-first-successful-API-call for a new developer using our docs should be under 10 minutes. Adoption: 80% of engineering teams using auto-generated docs within 60 days of rollout. Quality: Documentation accuracy (docs matching actual API behavior) must exceed 99% at all times."

Example: "As a backend engineer adding a new API endpoint, I want the documentation to auto-generate from my code annotations so that I never manually write or update API docs. Acceptance criteria: documentation generated from OpenAPI/Swagger annotations in code; preview available in PR before merge; changes auto-deployed on merge to main; breaking changes flagged with migration guide prompt; generated docs include request/response examples, error codes, and authentication requirements."

Example: "FR-1: CLI must support JSON, YAML, and table output formats via --output flag; default is table for interactive terminals and JSON for piped output. FR-2: All API endpoints must return consistent error responses: {error: {code: string, message: string, details?: object}} with appropriate HTTP status codes. FR-3: SDK must support async/await patterns in all supported languages (TypeScript, Python, Go); callback patterns are not supported. FR-4: Configuration file must support YAML and TOML formats; environment variable overrides follow the pattern TOOLNAME_SECTION_KEY. FR-5: All API operations must be idempotent; retrying a failed request must not produce duplicate side effects."

Example: "DX-1: API versioning via URL path prefix (/v1/, /v2/); major version changes require 12-month deprecation notice; deprecated endpoints return Sunset header. DX-2: Rate limiting: 1,000 requests/minute for authenticated users; rate limit headers (X-RateLimit-Limit, X-RateLimit-Remaining, X-RateLimit-Reset) on every response. DX-3: Error messages must include: what went wrong, why it went wrong, and how to fix it. Example: 'Invalid API key format. API keys must be 32 characters starting with 'sk_'. Generate a new key at dashboard.example.com/keys.' DX-4: Interactive API documentation (Swagger UI or Redocly) with runnable examples and sandbox environment."

Example: "Onboarding: Time-to-first-API-call. Target: under 10 minutes for 80% of new users. Adoption: Weekly active developers. Target: 500 within 3 months. Depth: Average API calls per active developer per week. Target: 200+. Satisfaction: Developer NPS. Target: 50+. Documentation: Percentage of support questions answerable from docs (measured by support team tagging). Target: 80%. Retention: 30-day developer retention rate. Target: 60%."

Example: "Phase 1 (Weeks 1-4): Core API with 5 essential endpoints, authentication, and rate limiting. Milestone: API passing all contract tests. Phase 2 (Weeks 5-6): SDK for TypeScript and Python with full type definitions. Milestone: SDKs passing integration tests. Phase 3 (Weeks 7-8): Documentation site with interactive examples and quickstart guide. Milestone: 3 developers from outside the team complete quickstart in under 15 minutes. Phase 4 (Weeks 9-10): CLI tool with core operations. Milestone: CLI feature parity with API. Phase 5 (Weeks 11-14): Beta program with 50 developers. Milestone: Developer NPS above 40."

Example: "Risk: Initial API design has ergonomic issues discovered only after developers start building against it. Likelihood: High. Impact: High (breaking changes erode trust). Mitigation: Run design review with 5 external developers before public launch; commit to 12-month deprecation cycle for any breaking changes; version API from day one. Risk: Open-source alternative gains traction and eliminates willingness to pay. Likelihood: Medium. Impact: High. Mitigation: Focus on managed service value (reliability, support, compliance) rather than pure functionality; contribute to open-source ecosystem to build goodwill."

Example: "Integration 1: GitHub — PR comments with API diff, breaking change detection, and documentation preview. Integration 2: CI/CD — GitHub Actions, GitLab CI, and Jenkins plugins for automated testing against API contract. Integration 3: IDE — VS Code and JetBrains extensions with autocomplete, inline documentation, and error highlighting. Integration 4: Package managers — npm, PyPI, and Go modules with semantic versioning. Integration 5: Monitoring — Datadog and Grafana dashboards for API usage and error rate tracking."

Example: "Q1: Should we offer a free tier with rate limits or a time-limited free trial? Free tier drives adoption but creates support burden from non-paying users. Decision owner: CEO. Needed by: Week 2. Q2: Should SDKs be auto-generated from OpenAPI spec or hand-written? Auto-generated is faster to maintain but often produces non-idiomatic code. Decision owner: Developer Experience lead. Needed by: Week 3. Q3: Should we open-source the core library and charge for the managed service? Open-source builds trust but may reduce willingness to pay. Decision owner: CTO. Needed by: Week 4."