Product Launch Checklist Example for an Early-Years EdTech Product

Summary

We are ready to launch Nimbletots for Schools to a limited first cohort, not to open it fully. Of the four must-pass gates, two are green (safeguarding, onboarding) and two are amber (data protection, support), so the recommendation at this go/no-go review is a staged launch held until the two amber gates clear.

The pilot has already de-risked demand — 9 of 12 settings said they would pay to continue ^[4] — so the open work is not proving educators want it, but proving we can run it safely, lawfully and supportably beyond the 12 settings we hand-held through the pilot. Two blockers remain: the Data Protection Impact Assessment and the controller–processor terms are still in legal review ^[2], and the out-of-hours safeguarding and incident escalation rota is not yet staffed ^[1]. Both must reach green before any setting is onboarded; everything else on the checklist is complete or on track.

Why this works — Opens with the actual launch decision and its condition, then names the exact blockers — a reader knows in two short paragraphs what is being asked, what is done and what is holding it, which is all a launch-checklist summary should carry.

Launch Activities and Owners

Every launch activity, its owner, status and target date is tracked below. Three activities are launch blockers (marked ⛔), all concentrated in data protection and incident cover; the rest are complete or on track for the 25 July go/no-go review.

The critical path runs entirely through the three blockers, not through product or engineering. Engineering shipped the launch scope on time; what gates the launch is legal sign-off and incident staffing, which is why the recommendation is staged rather than full.

Why this works — Puts every launch activity in a real owner-and-status table rather than prose, so accountability is unambiguous and the critical path is visible at a glance — and it deliberately concentrates the blockers in one place so no other section has to re-list them.

Cross-Functional Readiness

Each launch area is inspected against a stated bar and carried as a grouped set of pass/fail checks with a status. Three areas are green; data protection is amber and is the gate we treat as non-negotiable.

Safeguarding and welfare — GREEN

Because children use Nimbletots inside Ofsted-registered settings, every launched feature must sit comfortably within those settings' safeguarding and welfare duties under the EYFS statutory framework ^[1].

• ✓No child-to-child or child-to-stranger messaging, and no public user-generated content anywhere in the child experience
• ✓A setting can control who sees a child's data and can remove a child promptly
• ✓All new activity content reviewed by the Head of Learning Design for age-appropriateness for 3–7 year olds
• ✓A named safeguarding contact owns incident handling, against a written safeguarding position ^[1]

Data protection and age-appropriate design — AMBER (must reach green)

A product likely to be accessed by children must meet the ICO's Age Appropriate Design Code — the Children's Code and its 15 standards — starting from the best interests of the child ^[2].

• ✓High-privacy defaults, data minimisation, geolocation off, and no behavioural advertising ^[2]
• ✓Profiling used only to adapt learning, and off by default for anything else ^[2]
• ☐Data Protection Impact Assessment signed off (drafted; awaiting final sign-off) ^[2]
• ☐Controller–processor agreement executed, with the setting as controller, Nimbletots as processor, and a defined retention schedule (in legal review) ^[2]

Onboarding and setup — GREEN

A setting should get value in a single session without a support call; in the pilot we onboarded 40 educators by hand, and at launch that has to be self-serve.

• ✓An educator can create classes, add children without collecting excess personal data, and assign first activities in one sitting
• ✓EYFS-aligned progress summaries generate correctly and read clearly for staff and parents ^[1]
• ✓A documented time-to-first-value target with a fallback if setup stalls; pilot signal supports the design, as 78% of children used the product in ≥6 of 8 weeks once set up ^[4]

Go-to-market — GREEN

Pricing, positioning and settings-facing materials are ready so demand can be captured without over-promising.

• ✓Schools-tier pricing and packaging confirmed
• ✓Sales enablement one-pager and settings FAQ published
• ☐Launch comms and waitlist sequence finalised (on track, not a blocker)

Why this works — Groups the launch into the areas a cross-functional reader cares about, ties each to the actual standard it is inspected against, and carries each as a checklist with a status rather than good intentions — making the one amber gate that must clear impossible to miss.

Monitoring, Support and Contingency

Support and monitoring must match how educators actually use the product — during the working day in term time — and must have a fast, staffed path for anything that looks like a safeguarding or data-protection concern. This is the second amber gate.

In place

• ✓Term-time support hours published, sized against active classes rather than sign-ups (pilot educator weekly-active ran at 83% ^[4])
• ✓Public status page and a known-issue triage process
• ✓Product and error monitoring on the educator dashboard, with alerting on failed logins, failed class creation and progress-summary generation errors

Not yet in place — launch blocker

• ☐Out-of-hours safeguarding and data-incident escalation rota staffed and tested ^[1]

Immediate post-launch checks (first two weeks)

• Time-to-first-value for each new setting against the documented target
• Volume and category of support contacts, watching for onboarding friction
• Any safeguarding or data-incident report, tracked to acknowledgement and resolution time

Contingency trigger: if a single safeguarding concern is not acknowledged within the published SLA, or if safeguarding or data-incident reports in the first two weeks exceed what the rota can absorb, we pause new sign-ups and hold the cohort at its current size until the escalation path is proven. For a child-facing product bought by regulated settings, an unstaffed out-of-hours path is a launch blocker, not a launch-week fix — general support being ready does not close this gate.

Why this works — Covers the monitoring, support cover and incident escalation the real checklist calls for, then uses the required counter-evidence block to state the explicit contingency trigger and to name the single unstaffed path that keeps this a blocker rather than a formality.

Go/No-Go and Sign-off

The decision reduces to four must-pass gates. Two are green (Safeguarding, Onboarding) and two are amber (Data protection, Support), so the recommendation is not a full launch.

Recommendation: open a limited first cohort of roughly 20 to 30 settings once the two amber gates reach green, then review the operational load before widening to the broader England market of 46,600 Early Years Register providers ^[3]. A staged launch confirms the load is what we modelled before we take on volume we cannot yet safely support.

Go criteria (all must be true to launch the cohort)

1. All four gates green.
2. DPIA signed off with no unmitigated high residual risk to children's data ^[2].
3. Controller–processor agreement executed, with a defined retention schedule ^[2].
4. Out-of-hours safeguarding and incident escalation rota staffed and tested ^[1].
5. Self-serve onboarding verified end to end for a cold setting, meeting the time-to-first-value target.

Sign-offs required

What would change this view — from staged launch to a full stop: if the DPIA surfaces a high residual risk we cannot mitigate, or if legal cannot agree controller–processor terms that a setting's own data-protection officer would accept, the schools launch stops rather than slips ^[2]. We cannot lawfully process children's data in regulated settings without them, and no amount of demand from the pilot offsets that.

Why this works — Converts the four gate statuses into a single honest go/no-go with concrete go criteria, a named approver for each area, and the required counter-evidence block stating the condition that would turn a delay into a stop — which is the whole purpose of a launch checklist.