Product Requirements Document Example for an Early-Years EdTech Product

Summary

We will build a schools tier whose first release does three things and nothing more: let an educator assign existing Nimbletots activities to a class or group, show class-level progress in one dashboard, and generate an EYFS-aligned progress summary that staff can share with parents. This is the smallest surface that delivers the value the pilot validated, namely a median of about 2.5 hours per week saved on planning and progress tracking, self-reported across 40 educators ^[1].

Everything in this document is scoped so that the safeguarding and data-protection reviews can pass before general availability. Because the product is used by and reports on children, the EYFS statutory framework ^[2] and the ICO's Age-Appropriate Design Code ^[3] are treated as requirements, not aspirations. Anything that cannot meet them in v1 is explicitly out of scope below.

Why this works — Answer-first: the reader learns the exact scope and the two non-negotiable constraints before any detail. As the PRD's opening, it states what is being built and the outcome it must achieve, grounding the value claim in cited internal evidence.

Purpose and Context

This PRD exists to convert a validated pilot into a buildable v1 that the safeguarding and data-protection reviews can approve. It is the single specification the engineering and learning-design squads build against, and the document the Data Protection Officer and safeguarding lead sign off against.

The opportunity is a B2B extension of a consumer product. Nimbletots already reaches roughly 180,000 family accounts, but settings in the pilot asked for a way to use the same activities with a whole class and to evidence progress against the EYFS — a job the consumer app was never built for. The 8-week pilot closed with 9 of 12 settings saying they would pay to continue ^[1], so the commercial question is settled enough to build; what is not yet settled is the exact shape of the first release, which is what this document fixes.

The decisions this PRD informs are: what the squads build over the four-month window, what the reviewers gate against, and what is deliberately deferred. It does not decide pricing, procurement or go-to-market — those sit in the Business Case and are out of scope here. Where the Summary states what is being built, this section states why now and for whom the specification is being written.

Why this works — Distinguishing purpose (why now, who it serves, what it decides) from the Summary (what and the outcome) stops the two opening sections repeating each other, and names the reviewers so the build knows exactly whose sign-off it is written to earn.

Goals and Success Measures

The feature succeeds if educators can plan and evidence learning faster without new safeguarding or privacy risk. We will judge v1 against three measures, each tied to a pilot baseline.

First, adoption: at least 80% of educators in an onboarded setting create a class and assign at least one activity within their first fortnight (pilot educator weekly-active reached 83%) ^[1]. Second, retained value: settings self-report time saved at or above the pilot median of about 2.5 hours per week. Third, reporting use: at least half of active classes generate an EYFS progress summary at least once per half-term. These are leading indicators of the retention signal we saw in the pilot, where 9 of 12 settings said they would pay to continue ^[1].

The guardrails matter as much as the targets: zero confirmed child-data incidents and no accessibility regression on educator screens are release-level conditions, not metrics we optimise towards. How each measure is instrumented is specified in Analytics and Tracking Requirements below.

Why this works — Good PRDs state measurable success up front, anchor targets to real baselines rather than round numbers, and name the guardrails that a target must never be bought at the expense of — so the team can tell later whether v1 achieved the outcome honestly.

Users and Use Cases

Educators' core job is to evidence each child's development against the EYFS areas of learning without losing contact time with the children themselves. The statutory framework is explicit that assessment should not involve long breaks from interaction with children, nor require excessive paperwork ^[2] — yet planning and progress-tracking remain a recognised workload pressure across the sector's roughly 46,600 Early Years Register settings in England ^[6]. The pilot quantified this for our users: educators self-reported a median of about 2.5 hours per week returned to teaching once planning and progress-tracking moved into Nimbletots ^[1]. v1 is designed around that single job — evidence learning faster, with less paperwork, and no new safeguarding or privacy risk.

There are two educator roles. A setting administrator manages the organisation, adds or removes staff, and controls which classes exist. An educator manages their own classes, assigns activities, and produces reports. Children do not have independent logins in the schools tier; they are represented by minimal records (first name or initials, year group, and a setting-issued identifier) and access activities through an educator-supervised device.

The primary use cases in scope for v1 are: set up a class and its roster; assign activities to a class or a group within it; check at a glance who has and has not engaged; and produce an EYFS-aligned summary to share with a parent at a review point. Parent-initiated use, cross-setting reporting and local-authority submission are recognised jobs but are not v1 use cases (see Scope and Non-Goals).

Why this works — The one research-grounded section: it opens with the users' real job-to-be-done, evidenced against the statutory framework and the sector's scale, then narrows to the specific roles, data model and use cases v1 serves — so the requirements that follow are anchored in a verifiable user need, not an assumed one.

Scope and Non-Goals

In scope for v1: organisation and class setup, activity assignment to a class or group, a class-progress dashboard, and the EYFS progress report. The child-facing activities themselves are unchanged from the consumer app. Consumer family accounts, billing, and procurement are outside this spec.

To protect the four-month build and keep the compliance surface small, v1 deliberately excludes:

• statutory EYFS Profile submission to a local authority;
• two-way integration with school management information systems;
• native single sign-on with local-authority identity providers;
• in-app parent accounts within the schools tier;
• child-to-child interaction of any kind;
• offline mode;
• free-text observational notes on children.

Each of these is a credible later addition, but none is needed to deliver the validated time-saving, and several would materially expand the data-protection and safeguarding review. They are recorded here so their absence reads as a choice, not an oversight.

Why this works — Pairing the in-scope surface with an explicit, reasoned non-goals list is one of the most valuable parts of a PRD: it prevents mid-build negotiation and shows reviewers the compliance surface was deliberately contained.

Requirements and Behaviour

R1 Class and roster management. A setting administrator can create classes and add children as minimal records; an educator can be assigned to one or more classes. No free-text notes about a child are supported in v1.

R2 Activity assignment. An educator can assign one or more existing activities to a whole class or to a named group within it, optionally with a start and end date. Assignments map to Nimbletots' existing maths, English and science strands, including phonics, so they align with early-literacy evidence on phonics and phonemic awareness ^[4].

R3 Class-progress dashboard. An educator sees, per class, which activities were completed, aggregate progress by learning strand, and children who have not yet started an assignment. Data refreshes at least every 15 minutes.

R4 EYFS-aligned progress report. An educator can generate a per-child or per-group summary that maps observed activity to the relevant EYFS areas of learning ^[2], exportable as PDF and shareable with a parent through a setting-controlled link.

R5 Access and roster changes. Access to a class is granted and revoked by the setting administrator; when an educator or child is removed, their access or record is handled per the retention rules in Non-Functional Requirements. No child record is visible to anyone outside the setting.

Why this works — Requirements are numbered, testable, and each ties to the feature's purpose, with the expected behaviour spelled out. Constraining out free-text child notes is a deliberate design decision that reduces safeguarding risk.

User Flows

Four flows carry the whole of v1. Each is described by its steps and the outcome it must reach.

Flow 1 — Setting onboarding and roster setup (administrator).

1. Administrator accepts the invitation and confirms the setting as data controller.
2. Administrator creates one or more classes and adds children as minimal records.
3. Administrator assigns educators to classes.

Outcome: a class exists with a roster and at least one educator, and no free-text child data was entered anywhere in the flow.

Flow 2 — Assign activities (educator).

1. Educator opens a class and selects a whole class or a named group.
2. Educator picks one or more activities and, optionally, a start and end date.
3. Educator confirms; each child's supervised device then shows only that assignment.

Outcome: the right children receive the right activities, and the assignment appears on the dashboard.

Flow 3 — Monitor class progress (educator).

1. Educator opens the class dashboard.
2. Educator reads completion and per-strand progress, and identifies children who have not started.

Outcome: the educator can act on who needs support, with data no older than 15 minutes.

Flow 4 — Generate and share an EYFS report (educator).

1. Educator selects a child or group and a period.
2. System maps observed activity to the relevant EYFS areas of learning ^[2] and produces a summary.
3. Educator exports a tagged PDF or creates a setting-controlled parent link.

Outcome: a parent receives a read-only summary at a review point, and no other child's data is exposed.

Why this works — Laying out the four journeys as ordered steps with an explicit outcome each makes the flows independently testable and shows the squads exactly where the privacy constraints (minimal records, single-assignment device view, setting-controlled links) bite inside real usage.

Edge Cases and Exceptions

The register below fixes the behaviour for the states most likely to break the four flows. Handling that is not specified here defaults to failing safe: deny access and surface a clear educator-facing message rather than expose or guess.

Why this works — A concrete edge-case register with a fail-safe default turns the risky boundaries of a child-facing product into testable rows, and each row is written so QA can assert the safe behaviour rather than infer it.

Non-Functional Requirements

Safeguarding. The tier must meet the safeguarding and welfare expectations of the EYFS statutory framework ^[2]. There is no child-to-child communication, no public profiles, and no child-visible free text. Access to a child's record is limited to staff at that setting.

Data protection for children. Each setting is the data controller and Nimbletots the processor, under a data-processing agreement. The design must conform to the ICO Children's Code, including data minimisation, high-privacy defaults, and the best-interests-of-the-child principle ^[3]. A Data Protection Impact Assessment is a release gate, and child records carry a defined retention period after a setting leaves.

Accessibility. All educator-facing screens must meet WCAG 2.2 Level AA ^[5].

Performance and availability. Dashboard views load within two seconds at the 95th percentile for a class of 30, and the service targets 99.5% monthly availability during UK term-time hours.

Why this works — For a child-facing schools product these are first-class requirements, not footnotes. Naming the controller/processor split and making the DPIA a gate turns compliance into something engineering can build against.

Analytics and Tracking Requirements

Analytics in the schools tier is deliberately minimal and privacy-preserving: events are keyed to the setting and educator, never to an identifiable child, in line with the Children's Code data-minimisation principle ^[3]. No event carries a child's name; where a child must be referenced, only the setting-issued identifier is used. The purpose is to instrument the three success measures and their guardrails — nothing more is collected in v1.

Reporting needs. A weekly internal view tracks the three success measures against their pilot baselines by cohort of onboarded settings; the two guardrail events are alerted in real time to the on-call and DPO. No child-level analytics dashboard exists, by design.

Why this works — Specifying events, their properties and the metric each feeds — in a table, with an explicit no-child-PII rule — makes measurement buildable and shows reviewers that instrumentation itself honours data minimisation rather than quietly widening the data collected.

Dependencies and Constraints

The DPIA and a signed data-processing agreement template must be ready before general availability. The EYFS framework was updated with effect from September 2026 ^[2], so the report's area-of-learning mapping must be reviewed against the current version before launch, owned by Dr. Amara Okoro. Market sizing for prioritisation assumes the 46,600 providers on the Early Years Register in England as the addressable base ^[6]. The tier also depends on the existing consumer activity content and its progress-capture pipeline, which is owned by the platform squad and is treated as a fixed input to v1.

Why this works — Surfacing the dependencies and external constraints with named owners keeps the PRD honest and prevents launch-blocking surprises during the build.

Open Questions

Should group assignment support cross-class groups in v1 or only within a class? What is the minimum viable retention window that satisfies both settings and the Children's Code ^[3]? These are flagged for resolution before the assignment and reporting stories are locked; each is assigned an owner and a closing date in Recommended Next Steps below.

Why this works — Recording the unresolved decisions explicitly, and flagging when each must be closed, keeps the PRD honest rather than papering over unknowns that would otherwise surface mid-build.

Acceptance Criteria

A1. A setting administrator can create a class of 30 children and assign an educator in under five minutes, with no field accepting free-text child data.

A2. An educator assigns a phonics activity to a group of six children; each child's device shows only that assignment, and the dashboard reflects completion within 15 minutes.

A3. The class dashboard correctly lists children who have not started an assignment, verified against seeded test data.

A4. An EYFS progress report generates for a child, maps activity to the correct areas of learning, and exports as an accessible, tagged PDF.

A5. A parent link opens a read-only summary, expires when revoked by the setting, and exposes no other child's data.

A6. An automated audit confirms all educator screens pass WCAG 2.2 AA checks ^[5] and the DPIA sign-off is recorded before release.

A7. Each edge case in the register above has a passing test asserting the safe behaviour, including the shared-device and setting-offboarding cases.

Why this works — Acceptance criteria are specific and independently verifiable, including the privacy and accessibility gates and the edge-case register, so "done" is unambiguous for QA and reviewers.

Recommended Next Steps

Before any story is estimated, five things must be done:

1. Wireframe the four user flows and review them with three pilot settings for comprehension — owner Priya Nair, before sprint 1.
2. Complete the DPIA and finalise the data-processing agreement template, including the retention window — owner DPO with Léa Dubois, gates general availability.
3. Re-map the EYFS areas of learning to the September 2026 framework ^[2] and validate the report output with a practitioner — owner Dr. Amara Okoro, before the reporting story is locked.
4. Agree the accessibility test plan covering WCAG 2.2 AA ^[5] and PDF tagging — owner Engineering, before sprint 1.
5. Close the two open questions (cross-class groups; retention window) — owners Priya Nair and the DPO respectively, both by the end of sprint 1.

Only step 2's DPIA is a hard release gate; the others are pre-build design and validation that de-risk the estimate.

Why this works — Turning the open work into a short, owned, sequenced checklist — and naming which single item is a release gate — tells the team exactly what must happen before build without re-litigating the whole document.

Ownership and Review

This PRD is owned by Priya Nair (Product Manager), who holds the pen and final say on scope. Contributors are Dr. Amara Okoro (EYFS mapping and pedagogy), Léa Dubois (engineering feasibility and data-processing design) and Sam Whitfield (commercial context, out of scope here); Tom Fisher (CEO) is the accountable executive for the schools initiative. The Data Protection Officer holds decision rights on the compliance gates defined above and can block release independently of Product.

Source evidence lives with the pilot: the schools pilot dataset and the Product Validation Report hold the baselines this document commits to ^[1]. External standards cited here (EYFS, Children's Code, WCAG, Ofsted) are linked in Sources so any reader can check them.

Review rhythm: this document is reviewed at the start of each sprint during the build and re-baselined at every release gate. It must be revisited — not merely amended — if any of these events occur: the EYFS statutory framework changes again ^[2], the ICO issues new Children's Code guidance ^[3], or the pilot assumptions in this document do not hold once real settings are onboarded.

Why this works — Stating ownership, decision rights (including the DPO's independent block), where the evidence lives, and the specific events that trigger a revisit is what keeps a PRD a living contract rather than a one-time artefact — and it carries the cross-cutting governance so no earlier section has to repeat it.