PRD Template for EdTech Products
A product requirements template built for education technology product managers. Covers learning outcome measurement, accessibility compliance, LMS integration, student data privacy, and the unique challenge of building products that actually teach.
Why edtech PRDs need a learning-first approach
EdTech product management sits at the intersection of technology, pedagogy, and institutional procurement. A product that is technically excellent but pedagogically unsound will not improve learning outcomes. A product that improves outcomes but fails accessibility standards cannot be sold to institutions. And a product that passes every compliance check but frustrates instructors will not be adopted.
The core challenge is measurement. Unlike e-commerce where conversion is a clear metric, edtech success requires proving that learners actually learned something — not just that they clicked through content. This means PRDs need to specify learning outcome metrics alongside engagement metrics, define assessment validity criteria, and include pedagogical review milestones that most product templates skip entirely.
This template addresses these challenges with edtech-specific guidance in every section. It includes dedicated sections for accessibility compliance (WCAG, Section 508, VPAT), student data privacy (FERPA, COPPA), and LMS interoperability standards (LTI, SCORM, xAPI) that are non-negotiable for institutional sales. Whether you are building a learning platform, assessment tool, or classroom management system, this template provides the structure your pedagogical, compliance, and engineering teams need.
The complete edtech PRD template
Ten sections tailored for education technology products with learning outcome focus, accessibility requirements, and institutional compliance guidance.
Problem Statement
Define the learning problem your product addresses. Distinguish between learner engagement gaps, instructor workflow inefficiencies, and institutional adoption barriers. Quantify the problem using learning outcome data, completion rates, or time-to-proficiency metrics.
Example: "Online course completion rates average 15% across our platform, with 60% of drop-offs occurring in the first two modules. Exit surveys indicate that 43% of learners who drop out cite 'lack of immediate feedback on practice exercises' as a primary reason. Instructors report spending 8 hours per week grading assignments that could be auto-assessed, time they would prefer to spend on 1:1 student support. Comparable platforms with adaptive feedback see 35% completion rates."
Tips
- Separate learner-facing problems from instructor-facing and admin-facing problems
- Use learning outcome data, not just engagement metrics — completion is not the same as comprehension
- Reference pedagogical research when available to support the problem framing
- Identify which learning modalities are underserved: self-paced, instructor-led, cohort-based
Goals and Objectives
Set goals that measure learning effectiveness alongside product adoption. EdTech products must demonstrate educational value, not just engagement. Include learning outcome targets, instructor efficiency gains, and institutional adoption metrics.
Example: "Primary: Increase course completion rate from 15% to 30% within 90 days of launching adaptive feedback. Learning outcome: Learners who complete the course achieve a minimum 80% score on the post-course assessment (baseline: 72% for current completers). Instructor efficiency: Reduce average grading time per assignment from 12 minutes to 2 minutes. Adoption: 60% of active instructors enable adaptive feedback within 60 days of availability."
Tips
- Include learning outcome metrics, not just completion and engagement rates
- Set both learner-facing and instructor-facing success criteria
- Define institutional adoption targets separately from individual user adoption
- Include accessibility compliance as a hard gate, not a secondary goal
User Stories
EdTech products serve multiple distinct user types: learners, instructors, administrators, and sometimes parents. Write stories for each persona with acceptance criteria that reflect pedagogical goals, not just functional behavior.
Example: "As a learner working through a coding exercise, I want immediate feedback on my submitted code so that I can understand my mistakes and correct them before moving to the next concept. Acceptance criteria: feedback appears within 5 seconds of submission; feedback identifies the specific error and explains why it is incorrect; feedback suggests a hint rather than revealing the answer; learner can resubmit up to 3 times with progressive hints; after 3 attempts, a worked solution is shown with step-by-step explanation."
Tips
- Write stories for all user types: learner, instructor, course admin, institutional admin, parent
- Include stories for accessibility: screen reader users, keyboard-only navigation, captions for video
- Cover offline and low-bandwidth scenarios — many learners have unreliable internet
- Address content authoring stories separately from content consumption stories
Functional Requirements
EdTech functional requirements should cover content delivery, assessment, progress tracking, feedback mechanisms, and collaboration features. Include learning-specific requirements like spaced repetition algorithms, adaptive difficulty, and content sequencing rules.
Example: "FR-1: Auto-grading engine must support multiple question types: multiple choice, fill-in-the-blank, code execution (Python, JavaScript, SQL), and short answer with rubric-based AI scoring. FR-2: Adaptive feedback must reference the specific learning objective the learner is struggling with and link to relevant course material. FR-3: Progress dashboard must show completion percentage, time spent, assessment scores, and predicted time to course completion. FR-4: Content must support SCORM 2004 4th Edition and xAPI (Experience API) for LMS interoperability."
Tips
- Specify supported content types and assessment formats with exact behavior for each
- Define adaptive learning rules: how difficulty adjusts, what triggers adaptation, learner control
- Include LMS interoperability standards: SCORM, xAPI, LTI (specify versions)
- Address content versioning: what happens to learner progress when course content is updated
Accessibility and Compliance
EdTech products must meet accessibility standards (WCAG 2.1 AA minimum, Section 508 for US institutional sales) and student data privacy regulations (FERPA, COPPA for K-12). These are not optional — they are legal requirements for institutional adoption.
Example: "ACC-1: All content must meet WCAG 2.1 AA standards. Video content requires closed captions with 99% accuracy and audio descriptions for visual content. ACC-2: All interactive elements must be keyboard-navigable with visible focus indicators. ACC-3: FERPA compliance: student education records accessible only to authorized parties; parental consent mechanism for users under 18. ACC-4: COPPA compliance for K-12 products: no behavioral advertising, parental verifiable consent before data collection from users under 13. ACC-5: VPAT (Voluntary Product Accessibility Template) documentation maintained and updated with each release."
Tips
- WCAG 2.1 AA is the minimum — many institutions now require WCAG 2.2 or AAA for specific criteria
- FERPA applies to any product used by a school receiving federal funding (essentially all US schools)
- COPPA applies if your product is directed at children under 13 or you have knowledge of child users
- Maintain a VPAT — institutional procurement teams will request it before purchasing
Success Metrics
EdTech metrics should measure learning effectiveness, not just platform engagement. Time on platform is not a positive metric if learners are not progressing. Define metrics that distinguish between productive learning time and unproductive struggle.
Example: "Learning effectiveness: Post-assessment score improvement (pre vs post). Baseline: 15-point average improvement. Target: 22-point average improvement with adaptive feedback. Engagement: Weekly active learning sessions per enrolled learner. Baseline: 1.8. Target: 2.5. Completion: Course completion rate. Baseline: 15%. Target: 30%. Satisfaction: Learner NPS. Baseline: 32. Target: 50. Instructor adoption: Percentage of instructors using auto-grading. Target: 70% within 90 days."
Tips
- Measure learning outcomes (assessment scores, skill demonstrations) not just engagement (time on site)
- Track completion rate by cohort, not just overall — cohort-based courses behave differently from self-paced
- Include instructor satisfaction and efficiency metrics alongside learner metrics
- Define leading indicators: early module completion rates predict overall course completion
Timeline and Milestones
EdTech timelines must account for content creation, pedagogical review, accessibility testing, and institutional procurement cycles. School and university purchasing follows academic calendars with specific procurement windows.
Example: "Phase 1 (Weeks 1-4): Auto-grading engine for multiple choice and code exercises. Milestone: Engine passes accuracy benchmark on test dataset. Phase 2 (Weeks 5-8): Adaptive feedback generation with learning objective linking. Milestone: Pedagogical review by learning design team completed. Phase 3 (Weeks 9-10): Accessibility audit and VPAT update. Milestone: WCAG 2.1 AA compliance verified by third-party auditor. Phase 4 (Weeks 11-14): Pilot with 5 instructors and 200 learners. Milestone: Completion rate improvement validated. Phase 5 (Week 15): GA release. Note: Institutional sales targeting Fall semester must have signed contracts by June."
Tips
- Academic procurement cycles are rigid — products must be ready months before semester start
- Include pedagogical review as an explicit milestone, not an informal check
- Plan for accessibility audits early — remediation can take weeks
- Content creation timelines are often longer than engineering timelines — plan accordingly
Risks and Mitigations
EdTech risks include pedagogical ineffectiveness, accessibility failures that block institutional sales, data privacy violations, and the challenge of changing established teaching behaviors.
Example: "Risk: AI-generated feedback provides incorrect guidance that reinforces learner misconceptions. Likelihood: Medium. Impact: High (educational harm). Mitigation: All AI feedback reviewed against answer rubrics; confidence threshold below 80% triggers human review queue; instructors can flag and correct AI feedback. Risk: Product fails accessibility audit, blocking university procurement. Likelihood: Medium. Impact: High. Mitigation: Engage accessibility consultant during design phase; automated WCAG testing in CI/CD; manual audit at Phase 3."
Tips
- Address pedagogical risk: what if your product teaches incorrectly or reinforces bad habits?
- Plan for instructor resistance to new technology — adoption requires change management
- Include data breach response specific to student records (FERPA requires notification)
- Address content accuracy risks: outdated material, cultural bias, language accessibility
Integrations and Interoperability
EdTech products must integrate with Learning Management Systems, Student Information Systems, and identity providers used by educational institutions. Interoperability standards are not optional for institutional sales.
Example: "Integration 1: LMS integration via LTI 1.3 (Learning Tools Interoperability). Supported platforms: Canvas, Blackboard, Moodle, D2L Brightspace. Grade passback via LTI Assignment and Grade Services. Integration 2: Single Sign-On via SAML 2.0 and OpenID Connect for institutional identity providers. Integration 3: SIS integration for roster sync via OneRoster 1.2 API. Integration 4: xAPI Learning Record Store for detailed learning analytics export."
Tips
- LTI 1.3 is the current standard — LTI 1.1 is deprecated but still required by some institutions
- Support both SAML 2.0 and OIDC for SSO — different institutions use different IdPs
- OneRoster integration is increasingly required for K-12 institutional sales
- Test integrations with the actual LMS instances institutions use, not just sandbox environments
Open Questions
Document unresolved decisions about pedagogical approach, content strategy, pricing model, and institutional vs direct-to-consumer positioning.
Example: "Q1: Should adaptive difficulty allow learners to manually override the AI recommendation and choose their own difficulty level? Pedagogical argument for both approaches. Decision owner: Head of Learning Design. Needed by: Week 2. Q2: How do we handle learner progress when an instructor updates course content mid-semester? Options: grandfather existing learners, migrate progress, or require restart. Decision owner: Product. Needed by: Week 3. Q3: Should auto-graded assessments count toward final grades, or only be used for formative feedback? Institutional policies vary. Decision owner: Customer Success + Legal. Needed by: Before pilot."
Tips
- Flag pedagogical questions separately — they require input from learning design, not just product
- Identify questions that institutional customers will need to answer per their own policies
- Include content licensing questions if using third-party educational material
- Address data ownership: who owns learner data when an institution churns?
Related templates
PRD Template
The universal PRD template with all ten core sections for any product team.
View template →PRD for Gaming Products
Gamification, engagement loops, and player progression systems for interactive products.
View template →PRD for Media Products
Content delivery, recommendation engines, and creator tools for media platforms.
View template →Frequently asked questions
Generate an edtech PRD from your actual data
Connect your tools, describe the feature, and get a PRD with learning outcome requirements, accessibility specs, and traced sources. Free to start.
Free to start. No credit card required.