Write a PRD for a Schoology Planner

Research and write a privacy-first PRD for a Schoology study planner.

Introduction

30 Second Summary

A study planner can sound useful while students still struggle to decide what to start first. School districts need evidence before they trust another product with student data.

In this project, you will turn an existing Schoology study-planner prototype into an evidence-backed product requirements document (PRD). You will define a differentiated MVP with privacy constraints plus separate prospect briefs for Hanover County Public Schools and Henrico County Public Schools.

What You'll Build

You will open the finished docs folder in Visual Studio Code and see a concise decision package that can support conversations with two Virginia school divisions.

By the end of this project, you'll have:

  • A source-backed research brief that shows where the first product pitch overlaps with Schoology and current planners.
  • A stakeholder-ready PRD that lets you defend a focused privacy-first MVP. Its measurable outcomes and documented Schoology integration dependency make the product boundaries clear.
  • Two distinct prospect briefs that help you lead different discovery conversations with Hanover County Public Schools and Henrico County Public Schools.
  • Secret Mission: Build a measurable pilot scorecard plus a stakeholder interview guide that tests planning behavior without promising better grades.

Are there any prerequisites?

You need existing prototype files plus Visual Studio Code. No Schoology credentials are required because the PRD treats live integration as a future dependency.

Before We Start

Strong product research starts with a clear decision. This is your moment to define whether a Schoology study-planning product is worth piloting and why that decision matters to students.

Set Up the Research Workspace

Existing implementation files reveal what was attempted. They leave the user problem and product decision unsupported.

You will use the existing TypeScript prototype as evidence for a PRD. A separate docs workspace in Visual Studio Code protects the source files from edits.

In this step, get ready to:
  • Open the existing prototype project without modifying its source files.
  • Create a docs folder containing three research files.
  • Document the prototype evidence and its current limitations.
Open and audit the prototype

A prototype inventory separates what the files suggest from behavior that still requires a working run or approved Schoology access. This boundary keeps assumptions from becoming product claims.

  • Start Visual Studio Code using your operating system's application search.
  • Select File from the top menu.
  • Choose Open Folder....
  • Select the existing TypeScript prototype project folder in the system picker.
  • Select Yes, I trust the authors if the Workspace Trust prompt appears.

You will see the project files in the Explorer view on the left. The folder name at the top confirms that the whole prototype is open.

What should you look for?

  • The manifest describes browser configuration and requested permissions.
  • The content script shows how the prototype interacts with a page.
  • The core logic contains the product's planning behavior.
  • The styles control the prototype's visual presentation.
  • The setup notes describe how the prototype is prepared or run.
  • Locate the manifest by looking for the file that contains browser configuration metadata.
  • Locate the content script by looking for code that reads from or changes a page.
  • Locate the core logic by looking for the file that contains planning decisions.
  • Locate the styles by looking for the file that contains visual rules.
  • Locate the setup notes by looking for the file that contains preparation instructions.
  • Keep every existing prototype file unchanged.

That first audit is complete. You can now separate observed file structure from behavior that still needs validation.

Create the docs workspace

The docs folder gives each product decision a dedicated home. Keeping these documents beside the prototype makes the evidence easy to trace.

  • Select the project folder name at the top of the Explorer view.
  • Select New Folder from the Explorer toolbar.
  • Enter docs.
  • Press Enter to create the folder.
  • Select the new docs folder.
  • Select New File... from the Explorer toolbar.
  • Enter research-brief.md.
  • Press Enter to create the research brief.
  • Add the prototype inventory to docs/research-brief.md by pasting this line:
Contains a prototype inventory identifying the existing manifest, content script, core logic, styles, and setup notes; it states what the prototype appears to do, what cannot be confirmed without running it, and that live Schoology integration requires district-approved access or credentials.

What Does This Inventory Capture?

This sentence records three evidence boundaries.

  • The existing files show what the prototype appears to do.
  • A working run is required to confirm its behavior.
  • Approved access or credentials are required for live Schoology integration.
  • Save docs/research-brief.md in Visual Studio Code.
  • Confirm that research-brief.md appears beneath the docs folder.

Research Brief in the Wrong Place?

Drag research-brief.md onto the docs folder in the Explorer view if it appears beside the folder.

Help me place my research brief inside the docs folder in Visual Studio Code.

  • Select the docs folder in the Explorer view.
  • Select New File... from the Explorer toolbar.
  • Enter prd.md.
  • Press Enter to create the PRD workspace.
  • Add the PRD workspace text to docs/prd.md by pasting this line:
Empty PRD workspace file created for the Schoology study planner.

Why Create the PRD File Now?

This placeholder confirms that the PRD has a dedicated file. The next step replaces it with the first product hypothesis.

  • Save docs/prd.md in Visual Studio Code.
  • Confirm that prd.md appears beneath the docs folder.

PRD Text Not Showing?

Select the prd.md tab before pasting the sentence. Check that the file sits inside docs.

Help me fix my PRD workspace file in Visual Studio Code.

  • Select the docs folder in the Explorer view.
  • Select New File... from the Explorer toolbar.
  • Enter prospect-notes.md.
  • Press Enter to create the district research workspace.
  • Add the district research workspace text to docs/prospect-notes.md by pasting this line:
Empty prospect-notes workspace file created for district research.

Why Separate Prospect Notes?

This file keeps district-specific evidence separate from the general product requirements. Later research can give each school division its own findings.

  • Save docs/prospect-notes.md in Visual Studio Code.
  • Confirm that prospect-notes.md appears beneath the docs folder.

Prospect Notes File Missing?

Select the docs folder before creating prospect-notes.md. Recreate the file there if it appears elsewhere.

Help me create the prospect notes file in the correct folder.

Verify the research workspace

The workspace is ready when the three documents match the intended starting state. A final comparison catches misplaced files or accidental edits before the research begins.

✔️ Awesome, I've got everything!

Your three workspace files are saved inside docs. Keep the existing prototype files unchanged.

ⓧ I'd like to double check the full code

  • Compare docs/research-brief.md with this complete file:
Contains a prototype inventory identifying the existing manifest, content script, core logic, styles, and setup notes; it states what the prototype appears to do, what cannot be confirmed without running it, and that live Schoology integration requires district-approved access or credentials.

Research Brief Check

The complete research brief records the apparent prototype evidence and the limits that still require validation.

  • Compare docs/prd.md with this complete file:
Empty PRD workspace file created for the Schoology study planner.

PRD Workspace Check

The complete PRD file contains the placeholder that marks where the product hypothesis goes next.

  • Compare docs/prospect-notes.md with this complete file:
Empty prospect-notes workspace file created for district research.

Prospect Notes Check

The complete prospect notes file contains the placeholder for later district research.

Before you check, picture the three filenames you expect to see beneath docs.

  • Expand the docs folder in the Explorer view.
  • Open research-brief.md.
  • Open prd.md.
  • Open prospect-notes.md.
  • Compare each file with the complete versions above.

You will see research-brief.md, prd.md, and prospect-notes.md inside docs. The research brief will identify the five prototype areas and the Schoology access dependency.

Your workspace now separates research from implementation. The original prototype files remain unchanged.

Your research workspace is ready. Next, you will turn the prototype inventory into the first product hypothesis.

Write the Product Hypothesis

Your Visual Studio Code workspace now separates prototype evidence from the source files you already inspected.

A deliberately simple product hypothesis turns that evidence into a pilot decision for the Schoology study planner. Its visible assumptions give the next competitive review something concrete to test.

In this step, get ready to:
  • Frame the pilot decision in a clear PRD header.
  • Define the primary student and planning problem.
  • Connect the initial value proposition to an end-to-end student scenario.
Frame the product decision

A product requirements document records the decision a team needs to make. Its header keeps that decision beside the document owner and current state.

What belongs in the header?

  • The Working title field gives the product the temporary name Schoology Study Planner.
  • The Owner field names you as the person responsible for the document.
  • The Status field uses Draft to show that the hypothesis still needs testing.
  • The Date field records 2026-09-08 as the drafting date.
  • The Decision field asks whether a Schoology study-planning product is worth piloting. It also states why that decision matters to students.
  • In the Explorer sidebar from earlier, select docs/prd.md.
  • Replace the existing placeholder sentence with a complete header using the five fields above.
  • Save docs/prd.md.

You should see a compact header that identifies the document and the pilot decision it supports.

Define the student problem

Problem framing gives the hypothesis a specific person and decision to support. Here, the planning gap begins after due dates become visible.

Keep the problem precise

The Primary user section identifies a high-school student managing work across classes.

The Problem statement section separates seeing due dates from deciding when to begin. It also covers deciding how to begin.

  • In the docs/prd.md tab, draft both sections below the header using the criteria above.
  • Save docs/prd.md.

You should see one named primary user and one focused planning problem below the header.

That boundary now gives your hypothesis a specific student decision to improve.

Connect the promise to a student scenario

The initial value proposition connects the planning problem to a product benefit. The student scenario checks whether that benefit supports a complete journey.

What must the scenario cover?

  • The student discovers an assignment.
  • The student estimates the effort required.
  • The product suggests a start date.
  • The student sees an obvious next action.
  • The student marks the work as complete.
  • Write an Initial value proposition section below the problem statement.
  • Save docs/prd.md.

You should see a clear first-pass promise that responds to the planning problem.

  • Add a Student scenario section beneath the value proposition using all five journey beats above.
  • Save docs/prd.md.

Before you review the complete page, do you expect every part of the student's journey to connect back to the planning problem?

  • Scroll to the top of docs/prd.md.
  • Confirm the header includes the working title, owner, status, date, and pilot decision.
  • Confirm the primary user is a high-school student managing work across classes.
  • Confirm the problem statement separates due-date visibility from deciding when and how to begin.
  • Confirm the initial value proposition responds to that planning problem.
  • Trace the scenario through assignment discovery, effort estimation, suggested start date, next action, and completion.

You should see a first-page product hypothesis with a complete header. It should name the high-school student as the primary user.

The problem should separate visible due dates from the decision about when and how to begin. The value proposition should lead into a scenario covering every required journey beat.

You've turned the prototype evidence into a product hypothesis that stakeholders can inspect and challenge.

Your first hypothesis is now visible and testable. Next, you'll compare it with Schoology and current planners to find where the pitch overlaps.

Stress-Test the Competitive Pitch

Your first PRD now has a clear student problem. It also has a complete student scenario.

This step uses competitor analysis to test whether the initial promise is distinct. You will compare Schoology alongside Studyo before checking Shovel alongside IntelliPlan.

In this step, get ready to:
  • Build a cited comparison matrix for the four products.
  • Classify the first hypothesis against the market evidence.
  • Close the brief with an assumptions register that supports a reframe verdict.
Build the comparison matrix

A comparison matrix turns broad product claims into evidence you can inspect cell by cell. Empty or uncertain cells stay visible instead of becoming accidental assumptions.

Matrix structure

Use these product rows:

  • Schoology.
  • Studyo.
  • Shovel.
  • IntelliPlan.

Use these comparison columns:

  • Product.
  • Schoology support.
  • Assignment import.
  • Effort input or estimation.
  • Workload forecasting.
  • Study scheduling.
  • Next-action guidance.
  • District controls.
  • Pricing visibility.
  • Evidence source.

Evidence for Each Row

  • Schoology: The student home documentation covers assignment status plus due-date surfaces. The Workload Planning documentation covers cross-course assignment counts plus workload views.
  • Studyo: The student overview documents Schoology as a homework source. The task documentation covers workload plus planned dates plus dated steps.
  • Shovel: The product page does not display Schoology in its platform list. It markets duration-aware scheduling plus workload warnings plus converting deadlines into work dates.
  • IntelliPlan: The product page markets Schoology sync plus effort estimation plus priority ranking plus weekly schedules. Its pricing page publishes a free price.

Treat pricing as an evidence-status check. Record that a reliable public amount was not verified when the reviewed sources do not support one.

Treat district controls the same way. Public product claims do not prove that a school division permits installation or approves student-data handling.

  • Return to docs/research-brief.md in the editor from earlier.
  • Add a Competitive Comparison section beneath the prototype inventory.

You should now see a separate heading for the market evidence below the existing prototype findings.

  • Build the matrix from the rows plus columns above.
  • Cite each product row with the relevant official source links.

You should see four product rows beside nine comparison fields. Every row should end with evidence links.

  • Save docs/research-brief.md.
Expose where the pitch overlaps

The initial value proposition now faces the evidence test. Its scenario only counts as differentiated when the matrix cannot already explain the same student benefit.

Before the comparison, hold a number in mind for how many parts of the initial promise will remain unique.

  • Switch back to docs/prd.md from earlier.
  • Read the initial value proposition without editing it.
  • Trace the student scenario from assignment discovery through completion.
  • Return to the comparison matrix in docs/research-brief.md.
  • Highlight each matrix cell that matches part of the initial scenario.

You should find at least three overlaps. The shortfall is intentional because it shows that the first pitch does not yet provide a defensible reason to exist.

Where the First Pitch Collides

  • Assignment discovery overlaps Schoology's assignment status plus due-date surfaces.
  • Workload awareness overlaps Schoology Workload Planning plus Studyo's workload fields.
  • Start-date planning overlaps Studyo's planned dates plus Shovel's duration-aware scheduling.
  • Effort-led prioritization overlaps IntelliPlan's effort estimation plus automatic priority ranking.

These vendor claims establish market positioning. They do not establish independent performance or adoption.

Classify the Findings

  • Already offered: A cited product source supports a matching capability.
  • Unverified claim: The idea needs student interviews or product testing.
  • District need unresolved: Public evidence does not answer an approval or governance question.

Unresolved district needs include data access plus installation approval plus privacy review. They also include support ownership plus the route to approved software.

  • Add a Hypothesis Stress Test section beneath the matrix.
  • Organize the findings under the three evidence labels above.

Your stress test should now name at least three overlaps. It should also separate unsupported claims from district questions that public product pages do not resolve.

  • Save docs/research-brief.md.
Record assumptions and reach a verdict

An assumptions register tracks the beliefs that could change the product decision. Each assumption needs a validation method before it can become a requirement.

Assumptions to Track

Use these columns:

  • Assumption.
  • Current evidence.
  • Risk if wrong.
  • Validation method.

Create one row for each area:

  • Student behavior: Students will estimate effort plus act on a suggested next step.
  • Schoology access: Approved access can provide the assignment data the planner needs.
  • District installation: Division approvers will permit the prototype mechanism or a supported integration path.
  • Teacher involvement: The first useful version can work without adding a teacher workflow.
  • Privacy approval: Minimum data collection can satisfy division review.
  • Separate planning surface: Students will use another planning view when its benefit is clear.
  • Add an Assumptions Register beneath the stress-test findings.
  • Build six rows from the areas above.

You should see a validation path beside every assumption. Claims without direct evidence should remain visibly unverified.

  • End docs/research-brief.md with Verdict: Reframe required.
  • Save docs/research-brief.md.

Before the final review, hold a prediction in mind about whether any unsupported differentiator remains.

  • Scroll from the comparison matrix to the assumptions register.
  • Confirm every product row ends with an official source citation.
  • Confirm the matrix contains all nine comparison fields.
  • Confirm the stress test identifies at least three overlaps.
  • Confirm the assumptions register covers all six required areas.
  • Confirm the final line reads Verdict: Reframe required.

You should see a cited four-product comparison followed by classified findings. The brief should finish with six assumptions plus the reframe verdict.

Strong work. Your research brief now separates verified market overlap from the questions that still need interviews or technical validation.

Your first pitch has exposed its limits. Next, you will turn that evidence into a focused student-controlled MVP.

Define the Privacy-First MVP

Your comparison matrix showed that the first pitch overlaps with Schoology and established planners. That evidence now forces a sharper product choice.

This step turns the overlap into a privacy-first MVP. The product becomes an explainable, student-controlled planning layer.

In this step, get ready to:
  • Replace the initial pitch with a differentiated product promise.
  • Define the prioritized MVP scope alongside its boundaries.
  • Document the privacy constraints alongside the integration dependencies.
Reframe the product promise

A differentiated promise names the transformation that begins after a student sees a due date. For this planner, the valuable decision is when to begin.

All edits in this step belong in docs/prd.md. The existing TypeScript prototype remains unchanged.

  • Switch back to docs/prd.md from earlier.
  • Find the initial value proposition in the first-page PRD.
  • Replace the initial value proposition with turn Schoology due dates into a realistic, student-controlled study plan with an obvious next action.
  • Save docs/prd.md.
  • Review the first page in the rendered preview.

You should see the revised promise beside the existing product decision. The promise should focus on converting due dates into an actionable plan.

Why this promise is narrower

Schoology already displays assignments alongside due-date information. The revised promise begins where that visibility ends.

The student can estimate the work ahead. The student can also understand the next action.

Set the MVP boundaries

Prioritization protects the first release from becoming another broad planner. Each requirement must support the revised promise directly.

What earns MVP priority?

The strongest requirements help a student convert a distant deadline into an editable plan. Rank these capabilities by their contribution to that outcome.

  • Editable effort estimates. Students can correct the amount of work assigned to an item.
  • Test and project back-planning with task breakdowns. Students can turn a distant due date into smaller planned steps.
  • Explainable prioritization. Each recommended next action shows the factors that placed it first.
  • Manual overrides. Students can change the suggested order or timing.
  • A focused student view. Students can see the current plan without district administration features competing for attention.
  • Add a Prioritized MVP requirements section to docs/prd.md by ranking the five requirements above in the same order.
  • Save docs/prd.md.
  • Review the rendered section to confirm that all five requirements are visible.

You should see a five-item sequence that starts with editable estimates. It should end with a focused student view.

Use non-goals to hold the line

Non-goals prevent familiar product ideas from quietly expanding the MVP. These five boundaries keep the first release focused on student-controlled planning.

  • Generative AI. The MVP does not generate plans through an open-ended assistant.
  • Grade prediction. The MVP does not forecast academic results.
  • Teacher surveillance. The MVP does not provide monitoring dashboards about individual planning behavior.
  • Academic-improvement claims. The MVP does not promise improved grades without supporting evidence.
  • Live production integration. The MVP does not claim a working Schoology connection before district approval. Technical validation must also happen first.
  • Add a Non-goals section to docs/prd.md by listing the five boundaries above.
  • Save docs/prd.md.
  • Review the rendered section to confirm that it contains five explicit non-goals.

You should see clear limits on automation, prediction, surveillance, product claims, and live integration.

What belongs in the minimal data table?

A minimal data table connects every stored field to the product promise. Include a purpose alongside the source and lifecycle of each field.

  • Assignment title. This identifies the work being planned.
  • Course label. This gives the assignment enough class context.
  • Due date. This anchors the back-plan.
  • Student effort estimate. This records the student's editable expectation of the workload.
  • Planned start date. This records when the student intends to begin.
  • Task steps. These make the next action visible.
  • Completion status. This records whether the planned work is finished.
  • Manual edits. These preserve the student's changes to the plan.
  • Add a Minimal data table section using the columns Data element, Purpose, Source, and Retention or deletion rule.
  • Save docs/prd.md.
  • Review the rendered table to confirm that every data element has a stated purpose.

You should see a compact inventory of the fields required to build an editable study plan.

Measure planning behavior

The first success measures should test whether students can create and maintain plans. They should avoid claiming that the product causes better grades.

  • Plan coverage. Measure the percentage of captured assignments with a planned start date.
  • Planned-start follow-through. Measure the percentage of assignments started by their planned date.
  • Plan maintenance. Measure the percentage of changed assignments whose plans are updated.
  • Add a Pilot success metrics section to docs/prd.md using the three measures above.
  • Save docs/prd.md.
  • Review the rendered section to confirm that it contains three planning-behavior metrics.

You should see three measurable behaviors. None of them should treat grade improvement as a proven outcome.

Document privacy and integration constraints

Privacy by design turns student-data protection into a product constraint from the beginning. The PRD must define those limits before any district-scale integration is attempted.

What must the privacy constraints cover?

  • Minimum data collection. Collect only the fields required for the disclosed planning purpose.
  • Authorization. Require student or parent consent when applicable. A district contract can provide authorization for approved purposes.
  • Access and correction. Give students a way to inspect their stored information. Give them a way to correct it.
  • Deletion. Define how student information is removed after an authorized request.
  • Retention. Keep information only for a documented period tied to the planning purpose.
  • Secure transmission. Protect student information whenever it moves between approved systems.

Virginia's student-data requirements support these constraints.

  • Add a Privacy constraints section to docs/prd.md by covering the six constraints above.
  • Save docs/prd.md.
  • Review the rendered section to confirm that each privacy constraint is explicit.

You should see a complete data lifecycle from authorized collection through deletion.

What must the technical constraints cover?

The current Chrome extension remains a prototype mechanism. Its technical boundaries should reflect the single planning purpose.

  • Minimum permissions. Request only the Chrome permissions required by implemented prototype behavior.
  • Packaged extension logic. Keep functional logic self-contained within the submitted extension package.
  • Prototype status. Describe the extension as a demonstration of the experience. Do not describe it as a live Schoology integration.

Chrome's permissions policy supports the minimum-permissions constraint. Its Manifest V3 policy supports packaged logic.

  • Add a Technical constraints section to docs/prd.md by documenting the three boundaries above.
  • Save docs/prd.md.
  • Review the rendered section to confirm that the extension is described as a prototype.

You should see minimum permissions alongside packaged extension logic. You should also see a clear limit on the prototype's current capability.

Name the dependencies

A future integration depends on access that this project does not have. Naming each dependency keeps the PRD credible.

  • District approval for any use of student data.
  • Schoology API access granted through an approved route.
  • LTI access coordinated with the district system administrator.
  • Technical validation of available assignment fields and synchronization behavior.
  • Privacy and security review before live use.

Schoology's LTI documentation confirms that a district-only installation requires coordination with the system administrator.

  • Add an Integration dependencies section to docs/prd.md by documenting the five dependencies above.
  • Save docs/prd.md.

Before you review the finished page, which boundary do you expect to be easiest to miss?

  • Review docs/prd.md from the revised promise through the integration dependencies.
  • Count the five prioritized MVP requirements.
  • Count the five explicit non-goals.
  • Confirm that the minimal data table is visible.
  • Confirm that the three planning-behavior metrics are visible.
  • Confirm that the privacy section covers six constraints.
  • Confirm that the technical section covers minimum permissions and packaged logic.
  • Confirm that district-approved Schoology access is named as a future dependency.

What should I see?

  • One revised product promise.
  • Five prioritized MVP requirements.
  • Five explicit non-goals.
  • One minimal data table.
  • Three planning-behavior success metrics.
  • Six privacy constraints.
  • Technical constraints for Chrome permissions and packaged logic.
  • Named integration dependencies for district-scale use.

The current Chrome extension remains a prototype. District-approved Schoology API or LTI access remains a future dependency.

Strong work. Your PRD now makes a defensible product choice while protecting student control.

Your privacy-first MVP is defined. Next, you will tailor the product case to Hanover and Henrico as separate prospects.

Create District Prospect Briefs

Your privacy-first MVP now has a clear product boundary. A district conversation needs evidence that connects this boundary to a local approval path.

Hanover County Public Schools and Henrico County Public Schools both use Schoology. Their public pages reveal different governance signals.

You will capture those differences in separate briefs so each conversation starts with verified facts instead of a generic district pitch.

In this step, get ready to:
  • Build the Hanover brief from verified district evidence.
  • Build the Henrico brief from verified district evidence.
  • Give each district a distinct discovery goal.
Build the Hanover brief

Hanover publishes concrete signals about instructional-resource review. It also documents privacy practices and technology ownership.

Each prospect brief uses four lenses: Fit, Verified evidence, Unknowns, and Next conversation.

Hanover Evidence Map

  • In the Visual Studio Code file tree, select docs/prospect-notes.md.
  • Add Hanover County Public Schools as the first district heading.
  • Add the four required subsection headings beneath the district heading.

You should now see the Hanover heading followed by Fit, Verified evidence, Unknowns, and Next conversation.

  • Write the Fit subsection to connect confirmed Schoology use to the student-controlled planning promise in docs/prd.md.
  • Add five cited bullets under Verified evidence using the official pages in the evidence map.

Your Hanover evidence should now cover Schoology use, resource review, Technology Services, the standard data-sharing agreement, and county-managed procurement.

Hanover Discovery Questions

  • The exact resource-review criteria for the current extension remain unknown.
  • The required security evidence remains unknown.
  • The pilot approval steps remain unknown. The expected timeline also remains unknown.
  • Turn each unresolved item in the callout into a question under Unknowns.
  • Set the Next conversation goal to validate resource-review requirements and security expectations.

The final two subsections should now distinguish public facts from questions that only Hanover stakeholders can answer.

  • Save docs/prospect-notes.md.

You have turned Hanover's public process into a concrete discovery agenda.

Build the Henrico brief

Henrico publishes strong strategic alignment for learner-centered technology. Its reviewed public pages leave the software approval route unresolved.

Henrico Evidence Map

  • Return to docs/prospect-notes.md from earlier.
  • Add Henrico County Public Schools as the second district heading.
  • Add the four required subsection headings beneath the district heading.

You should now see a second district section with the same four-part structure as Hanover.

  • Write the Henrico Fit subsection around confirmed Schoology use and learner-centered strategic alignment.
  • Add four cited bullets under Verified evidence using the official pages in the evidence map.

Your Henrico evidence should now cover Schoology use, Journey to 2030, learner-centered instruction, and annual Instructional Technology planning.

Henrico Discovery Questions

  • The software-review process remains unknown.
  • The pilot-approval process remains unknown.
  • The procurement route remains unknown.
  • The required data-agreement details remain unknown.
  • Turn each unresolved process in the callout into a question under Unknowns.
  • Set the Next conversation goal around product ownership, pilot sponsorship, and the route from instructional need to approved software.

The Henrico brief should now show strong strategic fit without presenting an undocumented approval process as fact.

  • Save docs/prospect-notes.md.

Strong work. You have converted Henrico's strategic signals into a focused set of stakeholder questions.

Verify the prospect split

A useful prospect brief preserves differences between customers. The final check confirms that each district has its own evidence and discovery path.

Before you compare the briefs, predict whether Hanover or Henrico has the clearer public review path.

  • Return to the Hanover County Public Schools heading in docs/prospect-notes.md.
  • Confirm that the Hanover section contains all four required subsection headings.
  • Confirm that the Hanover evidence covers five verified district signals with citations.
  • Confirm that the Hanover conversation goal focuses on resource review and security expectations.

Hanover should show a documented review landscape with precise questions about how the prototype would move through it.

  • Move to the Henrico County Public Schools heading in docs/prospect-notes.md.
  • Confirm that the Henrico section contains all four required subsection headings.
  • Confirm that the Henrico evidence covers four verified strategic signals with citations.
  • Confirm that software review, pilot approval, procurement, and data-agreement details remain explicit questions.
  • Confirm that the Henrico conversation goal focuses on ownership, pilot sponsorship, and the route to approved software.
  • Confirm that docs/prd.md remains unchanged.
  • Confirm that docs/research-brief.md remains unchanged.
  • Save docs/prospect-notes.md.

You should see two separate district sections. Each section should contain Fit, Verified evidence, Unknowns, and Next conversation subsections with citations.

Hanover should lead toward review and security validation. Henrico should lead toward ownership and pilot-path discovery.

You now have two stakeholder-ready prospect briefs that preserve each district's evidence and uncertainty.

Secret mission

Build a Pilot Scorecard

Your PRD defines a focused product hypothesis. Now turn that hypothesis into a pilot scorecard with measurable outcomes, safety guardrails, stakeholder questions, and clear decision thresholds. The result gives district stakeholders a responsible way to continue, revise, or stop the idea.

Clean Up Your Resources

Clean Up Your Resources

Decide whether to keep the local documentation, pause your work, or delete the files. This project has no running services or ongoing costs.

Resources you used:

  • The docs folder contains research-brief.md. It also contains prd.md. It also contains prospect-notes.md.

Keep everything running

No action is required. Choose this option if you want the evidence package beside your prototype for future product conversations.

  • Leave the docs folder in the current project.
  • Use docs/prd.md as the starting point for future pilot planning.

Pause - I'll come back to this later

No process needs stopping because the project contains documentation only. Pausing preserves every research source and product decision for later.

  • Save the three files in Visual Studio Code.
  • Close Visual Studio Code.

Delete - I don't want to use this again

This cleanup has a narrow boundary. It removes only docs, so your existing prototype source files remain unchanged.

  • Select the docs folder from the file sidebar in Visual Studio Code.
  • Delete the selected docs folder.
  • Confirm the deletion if Visual Studio Code asks.
  • Check that docs no longer appears in the current project.

That cleanup is complete. Your unchanged prototype remains available without the research package.

Nice Work!

Nice Work!

You did it. You turned an unchanged TypeScript prototype into an evidence-backed product decision package that supports a defensible pilot conversation without pretending it has live Schoology access.

You've learned how to:

  • Create a cited competitive research brief covering Schoology, Studyo, Shovel, plus IntelliPlan. Separate verified market facts from assumptions requiring interviews or technical validation.
  • Shape a privacy-first MVP around editable effort estimates plus explainable prioritization. Define explicit non-goals. Record district-approved Schoology integration as a dependency.
  • Create separate district prospect briefs for Hanover County Public Schools plus Henrico County Public Schools. Give each division its own verified evidence. Record its unresolved questions. Set a distinct next-conversation goal.
  • Secret Mission: Build a pilot scorecard with a pre-pilot baseline plus planning-behavior outcomes. Add guardrails for privacy, support burden, adoption, plus student autonomy. Pair each assumption with the stakeholder best placed to test it. Set explicit thresholds for continuing, revising, or stopping the idea.

Ready to quiz yourself?