From 3dfc6383e29ed7fdf5b5538d7129a3124cc75f1d Mon Sep 17 00:00:00 2001 From: Philippos Savvides Date: Sat, 30 May 2026 12:25:39 -0700 Subject: [PATCH 1/2] feat: demand-validation toolkit + knowledge from sibling repos (v2.1.0) MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Folds content from three sibling repos — Cracking Higher Ed (SXSW EDU 2026), the JTBD Switch toolkit, and ASU+GSV 2026 Summit Intelligence — into the knowledge base, centered on demand validation. - New: data/demand-validation.md, data/jtbd-interviews.md, data/defensibility-moats.md, data/ai-risk-and-trust.md, data/buyer-demand-signals.md - Fixed data/higher-ed-jobs-atlas.md from 11 to the full 15 jobs - Augmented procurement-guide.md and pilot-benchmarks.md with summit-sourced buyer/pilot realities; added case-study + job-statement issue templates; updated README, ARCHITECTURE.md, CLAUDE.md (count-agnostic) - Bump to 2.1.0 Sources CC BY 4.0 (Cracking Higher Ed, summit) and MIT (JTBD), attributed in-file; summit and JTBD material labeled practitioner signal, not peer-reviewed. Co-Authored-By: Claude Opus 4.8 (1M context) --- .github/ISSUE_TEMPLATE/case-study.md | 20 +++ .github/ISSUE_TEMPLATE/job-statement.md | 23 ++++ ARCHITECTURE.md | 6 +- CHANGELOG.md | 14 +++ CLAUDE.md | 4 + README.md | 6 +- VERSION | 2 +- data/ai-risk-and-trust.md | 73 +++++++++++ data/buyer-demand-signals.md | 121 ++++++++++++++++++ data/defensibility-moats.md | 88 ++++++++++++++ data/demand-validation.md | 147 ++++++++++++++++++++++ data/higher-ed-jobs-atlas.md | 39 ++++-- data/jtbd-interviews.md | 155 ++++++++++++++++++++++++ data/pilot-benchmarks.md | 26 +++- data/procurement-guide.md | 18 ++- 15 files changed, 727 insertions(+), 15 deletions(-) create mode 100644 .github/ISSUE_TEMPLATE/case-study.md create mode 100644 .github/ISSUE_TEMPLATE/job-statement.md create mode 100644 data/ai-risk-and-trust.md create mode 100644 data/buyer-demand-signals.md create mode 100644 data/defensibility-moats.md create mode 100644 data/demand-validation.md create mode 100644 data/jtbd-interviews.md diff --git a/.github/ISSUE_TEMPLATE/case-study.md b/.github/ISSUE_TEMPLATE/case-study.md new file mode 100644 index 0000000..f7237b8 --- /dev/null +++ b/.github/ISSUE_TEMPLATE/case-study.md @@ -0,0 +1,20 @@ +--- +name: Share a Case Study +about: Share your experience applying the demand-validation framework at your institution or startup +title: "[Case Study] " +labels: case-study +--- + +**Institution or company type** (e.g., R1, community college, online program, K-12 district, corporate L&D, early-stage startup) + + +**Journey phase(s) involved** (Pre-enroll, Apply, Onboard, Select & Enroll, Course Experience, Graduate & Beyond — see `data/higher-ed-jobs-atlas.md`) + + +**Which diagnostic questions did you apply?** (from `data/demand-validation.md`) + + +**What did you find?** (signal vs. noise — be specific) + + +**Key takeaway** diff --git a/.github/ISSUE_TEMPLATE/job-statement.md b/.github/ISSUE_TEMPLATE/job-statement.md new file mode 100644 index 0000000..7cd2f6e --- /dev/null +++ b/.github/ISSUE_TEMPLATE/job-statement.md @@ -0,0 +1,23 @@ +--- +name: Suggest a Job Statement +about: Propose a new validated job for the higher-ed jobs atlas +title: "[Job Statement] " +labels: job-statement +--- + +**Journey phase** (Pre-enroll, Apply, Onboard, Select & Enroll, Course Experience, Graduate & Beyond) + + +**Person** (role, not title — e.g., "prospective student comparing programs," not "student") + + +**Struggling moment** (what is the person trying to do, and what's blocking them?) + + +**Current workarounds** (what do they do today, and why does it fail?) + + +**Proposed job statement** (format: "When [situation], I want to [motivation], so I can [outcome]" — see `data/jtbd-interviews.md`) + + +**Evidence source** (how did you validate this? interviews, data, institutional experience?) diff --git a/ARCHITECTURE.md b/ARCHITECTURE.md index 9aebf9a..16a0885 100644 --- a/ARCHITECTURE.md +++ b/ARCHITECTURE.md @@ -15,8 +15,8 @@ All of it lives in `data/`, in three kinds of files. Structured domain knowledge, grounded in real sources rather than model training data: - **Regulatory** — FERPA, COPPA, and state privacy law (K-12); accreditation and accessibility (higher ed) -- **Market** — competitive landscape by segment, buyer personas, funding landscape by stage, procurement, pilot benchmarks -- **Frameworks** — ESSA evidence tiers, AI-native vs. bolted-on, the higher-ed jobs atlas, and founder traps +- **Market** — competitive landscape by segment, buyer personas, buyer demand signals, funding landscape by stage, procurement, pilot benchmarks +- **Frameworks** — ESSA evidence tiers, AI-native vs. bolted-on, defensibility moats, the higher-ed jobs atlas, founder traps, and the demand-validation toolkit (the 5-question diagnostic plus the JTBD Switch interview method) Each regulatory and market file carries a "last updated" date. Update cadence is roughly quarterly; regulatory data when laws change; the competitive landscape goes stale fastest. @@ -26,7 +26,7 @@ Hundreds of peer-reviewed papers across the major learning-science topics, each ### Operator playbooks — `data/operator-lessons.md` -Dozens of field lessons from operators and investors, distilled and attributed from the public archive of Lenny's Podcast and Lenny's Newsletter, then mapped to selling into schools, universities, and L&D. These are practitioner experience, not peer-reviewed evidence — the research corpus is the evidence layer, and the file says so. +Dozens of field lessons from operators and investors, distilled and attributed from the public archive of Lenny's Podcast and Lenny's Newsletter, then mapped to selling into schools, universities, and L&D. These are practitioner experience, not peer-reviewed evidence — the research corpus is the evidence layer, and the file says so. The same practitioner-not-peer-reviewed labeling applies to the summit-sourced files (`data/buyer-demand-signals.md`, `data/ai-risk-and-trust.md`), which each carry their source and an evidence-tier note. ## How it's consumed diff --git a/CHANGELOG.md b/CHANGELOG.md index be291ec..20afc2b 100644 --- a/CHANGELOG.md +++ b/CHANGELOG.md @@ -1,5 +1,19 @@ # Changelog +## 2.1.0 (2026-05-30) + +### Demand-validation toolkit + knowledge from sibling repos + +Folds content from three sibling repos — Cracking Higher Ed (SXSW EDU 2026), the JTBD Switch toolkit, and ASU+GSV 2026 Summit Intelligence — into the knowledge base, centered on demand validation. Sources are CC BY 4.0 (Cracking Higher Ed, summit) and MIT (JTBD), attributed in-file; summit and JTBD material is labeled practitioner signal, not peer-reviewed. + +- **New `data/demand-validation.md`** — the 5-question demand diagnostic with scoring and the validation depth probes. +- **New `data/jtbd-interviews.md`** — the JTBD "Switch" interview method (four forces, job stories, backward-timeline guide), reframed for edtech. +- **New `data/defensibility-moats.md`** — the exposure spectrum, four moats, and the AI-substitution durability test. +- **New `data/ai-risk-and-trust.md`** — AI's effect on learners and trust, with design responses founders can adopt. +- **New `data/buyer-demand-signals.md`** — the durable jobs institutional buyers switch for, and how to read real demand. +- **Fixed `data/higher-ed-jobs-atlas.md`** — completed from 11 to the full 15 jobs (the phase counts already implied 15). +- Augmented `procurement-guide.md` and `pilot-benchmarks.md` with summit-sourced buyer and pilot realities; added case-study and job-statement issue templates; updated README, ARCHITECTURE.md, and CLAUDE.md. + ## 2.0.0 (2026-05-29) ### Repositioned as a knowledge base diff --git a/CLAUDE.md b/CLAUDE.md index ab5dcef..1128294 100644 --- a/CLAUDE.md +++ b/CLAUDE.md @@ -9,6 +9,10 @@ An open, AI-friendly knowledge base for edtech founders, built by ASU ScaleU. Th - `data/operator-lessons.md` — dozens of operator and investor lessons distilled from Lenny's Podcast and Lenny's Newsletter, mapped to edtech. Practitioner experience, not peer-reviewed; don't present it as research. - `data/ai-native-framework.md` — AI-native vs. bolted-on: criteria, the removal test, architecture patterns, pricing models, and the Karpathy hierarchy. Use it to classify a founder's AI posture. - `data/higher-ed-jobs-atlas.md` and `data/founder-traps.md` — ScaleU's SXSW EDU 2026 higher-ed framework: validated jobs across the student journey with saturation analysis, and the structural patterns founders miss. +- `data/demand-validation.md` and `data/jtbd-interviews.md` — the demand-validation toolkit: the 5-question diagnostic with scoring and depth probes, and the JTBD Switch interview method for discovering and validating real demand. +- `data/defensibility-moats.md` — how an edtech product stays defensible when LLMs can replicate features (exposure spectrum, four moats, the AI-substitution durability test). +- `data/ai-risk-and-trust.md` — AI's effect on learners and trust, with design responses. Practitioner signals from the ASU+GSV 2026 summit, not peer-reviewed; don't present as research. +- `data/buyer-demand-signals.md` — the durable jobs institutional buyers switch for. Practitioner signals, not peer-reviewed. - `ETHOS.md` — the seven principles, starting with "validate demand, not interest." Always cite the source: a named regulation, a paper's DOI, or the named operator. diff --git a/README.md b/README.md index dc71624..d5c404c 100644 --- a/README.md +++ b/README.md @@ -30,12 +30,16 @@ Hundreds of peer-reviewed papers across the major learning-science topics: space - Higher-ed landscape, procurement, and accessibility - Funding landscape by stage — who funds edtech and what they require - Buyer personas, pilot benchmarks, and the ESSA evidence tiers (1–4) +- **Buyer demand signals** — the durable jobs institutional buyers switch for ([`data/buyer-demand-signals.md`](data/buyer-demand-signals.md)) ### ScaleU frameworks -- **AI-native vs. bolted-on** — is your AI load-bearing or decorative ([`data/ai-native-framework.md`](data/ai-native-framework.md)) +- **Demand validation** — the 5-question diagnostic with scoring and depth probes ([`data/demand-validation.md`](data/demand-validation.md)), plus the JTBD Switch interview method for discovering real demand ([`data/jtbd-interviews.md`](data/jtbd-interviews.md)) - **Higher-ed jobs atlas** — validated jobs across the student journey, with saturation analysis showing where everyone's already crowded ([`data/higher-ed-jobs-atlas.md`](data/higher-ed-jobs-atlas.md)) - **Founder traps** — the structural patterns founders miss ([`data/founder-traps.md`](data/founder-traps.md)) +- **AI-native vs. bolted-on** — is your AI load-bearing or decorative ([`data/ai-native-framework.md`](data/ai-native-framework.md)) +- **Defensibility moats** — staying defensible when LLMs can copy your features ([`data/defensibility-moats.md`](data/defensibility-moats.md)) +- **AI risk & trust** — what AI does to learners before you ship a student-facing model ([`data/ai-risk-and-trust.md`](data/ai-risk-and-trust.md)) - **The ethos** — seven principles, starting with "validate demand, not interest" ([`ETHOS.md`](ETHOS.md)) ### Operator playbooks — `data/operator-lessons.md` diff --git a/VERSION b/VERSION index 227cea2..7ec1d6d 100644 --- a/VERSION +++ b/VERSION @@ -1 +1 @@ -2.0.0 +2.1.0 diff --git a/data/ai-risk-and-trust.md b/data/ai-risk-and-trust.md new file mode 100644 index 0000000..7504613 --- /dev/null +++ b/data/ai-risk-and-trust.md @@ -0,0 +1,73 @@ +# AI risk and trust for edtech founders + +What AI does to learners, and to the trust between learners and the people around them, before you ship a student-facing model. For founders selling into K-12 districts, universities, and corporate L&D. + +*Note: these are practitioner signals from the ASU+GSV 2026 summit, not peer-reviewed evidence.* Where a claim is research-backed versus a panel assertion, this file says which. As of the ASU+GSV 2026 summit, the cognition question was the most contested theme of the week, and platform companies and practitioners were not in the same room on it. + +*Source: ASU+GSV 2026 Summit Intelligence — ScaleU. CC BY 4.0. Practitioner signals, not peer-reviewed research.* + +--- + +## The honest caveat, up front + +The single most-cited number at the summit cuts against the hype. Ben Riley (Cognitive Resonance) pointed to Stanford SCALE's review of 800 studies of LLMs in education: only 20 showed causal impact, and virtually none of those were positive. So the research base is thin, and what causal evidence exists is not on the model's side yet. That is research-backed (it's a review of studies). Almost everything else below is panel assertion — operators reporting what they see, not controlled trials. Treat it as signal worth designing around, not proof. + +Riley's framing is the one to hold even if you reject his conclusion: a tool was deployed to roughly 500 million students before the longitudinal data exists. Wait for the RCTs to settle and you decide with a five-year lag. Deploy now without measurement and you become the data. Pick your error on purpose. + +--- + +## The cognition and trust risks + +### Cognitive automation, not offloading (research-backed lean) +Riley named the behavior "cognitive automation," not the gentler "cognitive offloading." He pointed to Carnegie Mellon and UCLA work showing "cognitive surrender" — students lose the ability to do the work once they try without the tool. The field datapoint: Sal Khan's own chief learning officer reported students typing "IDK" into Khanmigo rather than engaging with it. The risk isn't that students think less while using AI. It's that the capacity erodes. — Ben Riley (Cognitive Resonance) + +### Kids don't want the chatbot tutor (operator signal) +Dan Meyer (Amplify) watches one benchmark: whether kids actually want to talk to a chatbot tutor. It has sat flat at roughly 5% for three years. His build rule follows from it — AI as an analytical layer for teachers, never direct-to-student. Joe Davis (KAIT Lab) goes the other direction with the same goal: AI-powered infrared pens that surface where students get stuck inside a problem set, so productive struggle stays the load-bearing part. — Dan Meyer (Amplify), Joe Davis (KAIT Lab) + +### Killing the butterfly (operator signal) +Larry Berger (Amplify) gave the most evocative warning. The capabilities exist, he said, but every AI implementation he sees is "killing the butterfly" — the moment of collective wonder that pollinates the next thousand moments of learning. His board gave him six months to step back from running the company and figure out whether AI can keep the butterfly alive. He does not have an answer yet. That last part matters: a serious operator with every incentive to be bullish is openly unsure. — Larry Berger (Amplify) + +### Sycophancy and the praise problem (operator signal) +Isabelle Hau (Stanford Accelerator for Learning) shared a stat from a visiting scholar: AI models praise children 13 times more often than humans do. Her read as a parent — if a model praises my child 13 times more than I do, kids start to expect it, and human-to-human relationships shift to match. The structural problem underneath: companies are incentivized to optimize for engagement, and sycophancy is a reliable way to get it. Your retention metric and the learner's development can point in opposite directions. — Isabelle Hau (Stanford Accelerator for Learning) + +### Anthropomorphism and developmental risk (operator signal) +Scale makes this urgent. Prateek Maheshwari (Physics Wallah) runs mega-classrooms — 100,000 students in a single live AI session at $40 ARPU — and the student feedback keeps returning to one line: "AI is not judging us." That's the appeal and the hazard in one sentence. Matthew Biel (Georgetown pediatric psychiatry) frames these as "non-mutual transactional" relationships and warns that adolescent development requires rupture and repair, which a model that never judges and never pushes back cannot provide. Paul LeBlanc was blunter: "AI is going to make social media look like a day at the beach." — Prateek Maheshwari (Physics Wallah), Matthew Biel (Georgetown), Paul LeBlanc + +### Tools built for adults, handed to kids (operator signal) +Anton Osika said Lovable hit $400M ARR in two years serving "the 99%" of non-developers, including nine-year-olds running real e-commerce sites. The underlying tools were not built for kids. Imagi exists as the safety wrapper for exactly that reason. If your product reaches minors — directly or because a teacher points it at a class — assume the base model was tuned for adults and the age-appropriateness layer is yours to build. — Anton Osika (Lovable) + +### Falling hope, rising anger (operator signal) +Kevin Roose (NYT) and Casey Newton (Platformer) landed a different datapoint: a Gallup/Walton/GSV poll of 14-to-29-year-olds showed hope about AI down 9 points to 18% in one year, with a third of Gen Z AI users reporting anger. Garrett Lord coined the line that stuck — an "agency divide" between people who manage AI and people AI manages. The learners you serve are not uniformly excited. A meaningful share are anxious or angry, and they can tell which side of that divide a product puts them on. — Kevin Roose (NYT), Casey Newton (Platformer), Garrett Lord + +### The other side of the table (the optimist case, for honesty) +The bull case came from James Donovan, head of learning and cognitive outcomes at OpenAI. His argument: the question isn't whether AI helps cognition but how the model is tuned. Model behavior elicits a human behavior, that behavior ladders up to cognitive outcomes over time, and tuned toward pedagogical alignment you get metacognitive gains. He pointed to a 20,000-student RCT in Estonia (University of Tartu and Stanford) as the model for generating real evidence. Note what this is and isn't: a stated thesis plus a study still running, not a result. Omar Abbosh (Pearson) gave the cleanest synthesis of both camps: "If you use it wrong, you will absolutely get dumber. If you use it right, you can get smarter." The institution's job — and your product's job — is enforcing the difference. — James Donovan (OpenAI), Omar Abbosh (Pearson) + +--- + +## The design responses founders can adopt + +These came up at the summit as concrete moves, not theory. Each is a panel assertion about what's being built, not a proven outcome. + +### Refusal by design +OMA Play's response to the developmental risk for the youngest learners is a screenless device for ages three to five with no face, that takes naps, shuts off at night, and refuses to engage 40% of the time on purpose. The design principle generalizes past toddlers: build friction in deliberately. The product question Hau's anthropomorphism work forces on every tutoring builder — what friction do you build in on purpose, and how do you measure when sycophancy is hurting the learner instead of just retaining them? — OMA Play + +### Age gates and an age-appropriate wrapper +Imagi sits as the safety layer because the frontier tools underneath weren't built for kids. If your product touches minors, the age-appropriateness layer is a thing you build, not a thing you inherit. Expect district-grade equivalents for K-12 to be a category, not a feature. + +### Time caps and screen-time limits +The OMA Play device caps engagement structurally — naps, nighttime shutoff, a designed-in refusal rate. Time limits are a design lever, not just a parental-controls afterthought. For a student-facing tutor, the cap is part of the pedagogy: it protects productive struggle and signals to a district buyer that you are not optimizing a child's screen time to the ceiling. + +### Keep the human as the user, when the evidence is thin +Meyer's "analytical layer for teachers, never direct-to-student" is a posture, not a constraint you're stuck with. Until your own outcome data says otherwise, aiming the model at the teacher (where it surfaces who's stuck, drafts feedback, flags patterns) carries less developmental risk than aiming it at the child. It also clears district AI review faster. + +### The defensible institutional posture +The summit's cleanest default for a buyer, which you can adopt as a product stance: assume model defaults push toward cognitive automation, not learning. Demand productive friction in the student-facing layer. Invest in teacher capability, not chatbot seats. Build the tool that makes the institution's enforcement job easier, not the one that quietly does the thinking for the student. + +--- + +## Cross-links + +- The trust risk has a security twin. A student-facing model that touches FERPA records, reads untrusted content, and can send data out is the "lethal trifecta" — see the data-exfiltration point in [operator-lessons.md](operator-lessons.md). Prompt-injection filters top out around 97%, a failing grade, so architect the exfiltration path away rather than trusting a prompt to behave. +- Whether AI is your product's load-bearing wall or a bolted-on chatbot changes how much of this risk you own. See [ai-native-framework.md](ai-native-framework.md). The deeper the AI sits in the product, the more the cognition and trust questions on this page are yours to answer, not the model lab's. + +*Last updated: 2026-05-30* diff --git a/data/buyer-demand-signals.md b/data/buyer-demand-signals.md new file mode 100644 index 0000000..089df75 --- /dev/null +++ b/data/buyer-demand-signals.md @@ -0,0 +1,121 @@ +# Buyer Demand Signals + +The durable jobs institutional buyers switch for, and how to read real demand instead of polite interest. For edtech founders selling to K-12 districts, universities, or corporate L&D who want to know what actually pulls a buyer off the status quo. + +*Source: ASU+GSV 2026 Summit Intelligence — ScaleU. CC BY 4.0. Practitioner signals, not peer-reviewed research.* + +As of the ASU+GSV 2026 summit, the patterns below came from analyzing switching behavior under the talking points of summit panels: not what speakers said they believe, but what they described doing differently. These are conference panels, not structured interviews. Most narrators were vendors or institutional leaders describing their customers' switches, not their own. Treat the patterns as directional. Validate with your own buyer conversations before betting on them. + +The time-stamped specifics — the dated trend list and the named company roster from the summit — live in the source repo: [github.com/savvides/asu-gsv-2026-summit-intelligence](https://github.com/savvides/asu-gsv-2026-summit-intelligence). This file keeps only the durable patterns. + +--- + +## The jobs buyers switch for + +A job is not a feature or a product category. It's the thing a decision-maker is trying to get done. Buyers don't switch because your tool is better. They switch because the old model hit a wall they can't optimize past. Each job below names the buyer, why they move, and an example from the summit. + +### 1. Reach more people without hiring proportionally more staff + +**The job:** break a structural ceiling. Not "this could be better" but "this cannot grow without costs growing in lockstep." + +**The buyer:** superintendents, provosts, state CTE directors, employer talent leads — anyone accountable for serving a population they physically cannot staff for. + +**Why they switch:** the prior model had a hard cap. Either a physical limit (you can only run so many in-person sessions), institutional inertia (a mandate that never gets implemented across hundreds of sites), or a systemic one (an approach that produces real gains but grindingly slowly). The switch happens when someone finds a model that breaks the ceiling without proportional cost. + +**From the summit:** An employer capped its student work-experience program at about a hundred students a year because that was the in-person limit. Moving to virtual experiences, it now serves 10,000 a year — same employer engagement, 100x the reach. A state CTE director with 500-plus districts watched a personalized-learning-plan mandate go unimplemented for years; schools walked students through plans on paper and checked the box. The fix wasn't a better platform. It was a field team where each person owns a geography, visits schools, and builds relationships with counselors. Technology plus people, not technology instead of people. + +### 2. Stop wasting staff on mechanical tasks so they can do the human work + +**The job:** return time and attention to the part of the role a person was actually hired for. + +**The buyer:** principals, department chairs, CHROs, special-education directors — leaders watching skilled people burn hours on work that crowds out their core function. + +**Why they switch:** the old approach wasn't failing because the technology was bad. It was failing because it required active effort from people who were already overloaded. The new model either removes the effort entirely or adds human support that makes the effort worth it. + +**From the summit:** A corporate L&D leader described a backroom inventory task that ate about an hour of an associate's day; computer vision cut it to twenty minutes. The point wasn't the time saved. It was giving the time back to customer-facing, human work. A K-5 product replaced the "talk to a chatbot and tell it what to do" model with an ambient assistant that listens, helps, and acts so the teacher doesn't have to do anything different. On a teletherapy panel, clinicians estimated about 40% of their time goes to administrative tasks instead of direct work with students — and that 40% is the explicit target a vendor is selling against. The same buyer also names the data-silo version: teachers stuck acting as "human APIs" between systems that don't talk to each other after years of tool sprawl. The job there isn't another tool. It's a layer that stops staff from being the integration glue. + +### 3. Prove an outcome changed, not just engagement + +**The job:** show that the tool moved an individual-level result, not a dashboard number. + +**The buyer:** curriculum directors, provosts, board-accountable superintendents, L&D heads who have to defend a renewal. + +**Why they switch:** prior approaches produced participation counts, logins, and completion rates that couldn't demonstrate anyone learned anything. That measurement vacuum made spend impossible to justify. The new model offers a specific, traceable, individual outcome. + +**From the summit:** A career-navigation vendor tracks where students land on LinkedIn after a program — for one cohort, a third ended up in tech-aligned roles. A destination metric, not a satisfaction survey. A K-5 reading tutor reports kids moving from pre-literacy to a second- or third-grade reading level in about five months at fifteen minutes a day. An education philanthropist pointed to chess.com, where today's typical ten-year-old scores higher than ten-year-olds twenty years ago on a stable, vertically scored system, as proof that individualized practice with measured outcomes works at scale. + +But the same vendor named the anxiety running under all of it: AI "will make it feel better and feel like magic, but actually, is it impacting that destination?" That fear haunts every switch. The worry isn't that the new tool fails. It's that it produces engagement without evidence, repeating the pattern that soured everyone on edtech in the first place. + +### 4. Get my organization through the AI change curve before the technology laps us again + +**The job:** absorb a moving capability frontier without the organization breaking. Distinct from job 2 — the goal isn't to save time, it's to not fall behind. + +**The buyer:** superintendents, provosts, CHROs, district CTOs. + +**Why they switch:** the bottleneck is no longer the technology. It's change management. Capability is sitting unused because institutions aren't ready to absorb it. Buyers who treat announcing a tool as deploying it get burned. Prior enterprise AI deployments make the point: identical-scope projects where one trained its people and one said "start coding" — the second was an outright failure, tens of millions spent for nothing. The takeaway, said twice on stage: "It's not the technology." + +**From the summit:** A live show of hands at a session of 7,000 edtech professionals found only about 15% had enterprise access to frontier coding tools. The capability is there; institutional readiness is not. The buyer is no longer hiring an AI tool. They're hiring a way to get the organization through the change curve. This job fires one-off literacy workshops, vendor-led demos, and the assumption that a tool announcement counts as adoption. + +### 5. Build the thing without becoming a developer + +**The job:** ship something real without hiring engineers or learning to code. The institutional version: wrap a frontier-lab tool so it's safe for students. + +**The buyer:** solo founders, in-house marketers and ops staff, teachers, and increasingly students themselves. For the institutional wrapper, K-12 districts and parent buyers. + +**Why they switch:** the build-it-yourself option now exists at a price and skill level that didn't before. One platform reported serving "the 99%" of non-developers, including kids running real e-commerce sites. Once someone builds something themselves, their frame shifts — a person who watched a website take weeks now sees it take twenty minutes, and their thinking changes. The frontier tools weren't built for kids, so a safety-and-pedagogy wrapper becomes its own product: the expertise is in making things age-appropriate, safe, and educational. + +**From the summit:** This collapses the buyer/vendor line — your buyer can become a builder. For institutions, the derivative job is owning the wrapper layer that makes a general-purpose AI tool safe and pedagogically sound for students. Districts and parents reward whoever owns that seam. This job fires dev agencies, traditional no-code tools, and AP CS as the only on-ramp. + +### 6. Turn a compliance mandate into a delivery system + +**The job:** use the levers of compliance to make student support actually happen — and produce receipts that survive an audit. + +**The buyer:** special-education directors, district CFOs, state DOE leaders. + +**Why they switch:** compliance is structural budget. Wellness is discretionary budget. Special education is federally mandated, with required evaluation and service delivery; when compliance guardrails force the work to happen, that's how the most students get served. Mental health and wellness have no statutory backstop — "so much lip service, so much talk, and so little funding." Vendors that productize the compliance receipt get adopted at the district line and renew. Vendors selling "student wellness" win the pilot, then lose the renewal when the line item gets cut. + +**From the summit:** A teletherapy vendor is winning business by showing, to the penny, every minute of therapy and every IEP documented, attached to the dollars spent. The job is both freeing clinician time and producing the audit-survivable artifact. This is the post-ESSER reality made concrete: per-minute logs, IEP audit trails, Medicaid billing automation. It fires awareness campaigns and "wellness" branding. + +--- + +## Demand signals worth reading + +These are durable patterns in how buyers behave, separate from any single year's trends. Read them as filters on whether the interest in front of you is real. + +### Trust is built through receipts and relationships, not UI + +The most vivid moment across the panels: adoption works "when they have somebody that they already trust and they can really rely on to have their cell phone number and call them and cry over the phone when they can't figure it out." That's not a UX problem. It's a relationship problem. Products that rely on product-led growth inside institutions are likely underinvesting in the human layer that makes adoption stick. Trust also gets built through compliance receipts and through giving people a builder identity. Different vehicles, same need: institutions don't adopt what they don't feel ownership of. Ask yourself who the trusted-human equivalent is for your product, and whether your business model can afford one. + +### One wrong AI answer triggers full abandonment + +Frontline users who get a wrong answer from an AI tool often don't iterate. They quit the tool entirely — "you get a wrong answer, and a lot of people are just going to discount it. I give up." Deterministic or visual outputs (a green-check confirmation, a reading score) carry lower abandonment risk than probabilistic text generation. Where text generation is necessary, visible confidence signals and easy correction loops matter more than your accuracy percentage. This applies directly to any AI tool put in front of teachers or students. + +### Post-ESSER buyers want dollar-attributed outcomes + +The procurement reality: "we are in a value-for-money era in K-12. This is not the ESSER era. I've got to show as a school administrator that I've been thoughtful in spending every dollar." Outcome data alone no longer closes the gap. The buyer isn't asking "did this work?" They're asking "can I show my board exactly what my dollars bought?" Build the receipt layer — usage tied to spend, individual outcomes attached to line items — before you build another analytics dashboard. + +### Institutions suppress their own tools' best features + +A district bought an adaptive tool, then asked the vendor to turn off the adaptive pacing because students who moved ahead became "disruptive and bored" in regular classes. The institution bought the differentiator and then disabled it. This isn't a sales problem you can close around. It's a structural constraint of how classrooms work. If your product has adaptive or personalized features, test whether buyers will suppress them after deployment — feature-adoption audits at 30, 60, and 90 days catch it. Suppression is a leading indicator of churn, not a config preference. + +### Friction is a signal you're reading the buyer right + +A K-5 reading tutor caps usage at fifteen minutes a day. A companion device for ages three to five has no face, takes naps, shuts off at night, and refuses to engage 40% of the time by design. A frontier lab age-gates its main product at 18. These are responses to real parent and pediatric-psychiatry anxiety about screen time and emotional dependency in brain-formation windows — over 70% of teens have used AI for companionship, more than 50% regularly, and the question is no longer whether kids engage but whether anyone shapes how. Products optimizing for daily-active-use as a north-star metric in K-12 will collide with this hard. Building friction in early reads a real signal. It isn't playing it safe. + +### Staff fear job loss before they adopt + +"The first thing people get when they get AI is, am I going to lose my job?" The staff you're asking to adopt the tool are the same staff who suspect it's there to replace them. The "no screens in classrooms" backlash threatens whole teletherapy and AI-companion business models. Anxiety about outcomes, dependency, and jobs is the force that quietly kills switches — and success-story panels systematically underrepresent it. Assume it's stronger than what you hear. + +--- + +## What this means for reading your own demand + +The push that moves a buyer is a structural ceiling, not incremental dissatisfaction. The pull that lands the switch is technology combined with a human relationship layer, not technology alone. The anxiety that almost stops the switch is the fear of engagement without outcomes. The habit that keeps buyers stuck is deploying a platform and expecting behavior change to follow. + +So when you read demand: a buyer naming a wall they can't optimize past is real signal. A buyer who likes your demo but can't name what it would replace or what outcome it would prove is not. Match the signals above against the buyer in front of you before you scale toward them. + +See [buyer-personas.md](buyer-personas.md) for who sits in each of these seats and what gets them promoted or fired, and [procurement-guide.md](procurement-guide.md) for how these jobs translate into the contract, security, and budget process. + +--- + +*Last updated: 2026-05-30* diff --git a/data/defensibility-moats.md b/data/defensibility-moats.md new file mode 100644 index 0000000..fca828c --- /dev/null +++ b/data/defensibility-moats.md @@ -0,0 +1,88 @@ +# Defensibility Moats: Staying Alive When LLMs Can Copy Your Features + +How an edtech product stays defensible when an LLM can replicate its features in an afternoon. For founders selling to K-12 districts, universities, or corporate L&D who need to know whether their core value survives substitution or evaporates with the next model release. + +*Source: "Cracking Higher Ed: Why Startups Miss the Mark" — Philippos Savvides, SXSW EDU 2026. Licensed CC BY 4.0.* + +This file is about structural defensibility. For the architecture side of the question — compounding memory, the data flywheel, and AI-native pricing — read [ai-native-framework.md](ai-native-framework.md). The two are companions: that file asks whether your product is genuinely AI-native; this one asks whether anything stops a competitor from rebuilding it. + +## "AI-powered" is not a moat + +It's a feature layer, exposed to the same substitution risk it claims to solve. Pure software without structural defensibility faces substitution within 18 months. If your edge is "we use AI to generate feedback" or "we summarize student work," a competent district CTO with an LLM and a couple of weeks can put up something close enough. + +So the question isn't whether your product uses AI. It's whether your core value survives replication. Two things make that true: knowing how exposed you are, and building one of the moats that doesn't dissolve when the model improves. + +## The exposure spectrum + +Locate your product on this spectrum first. It tells you how much time you actually have. + +| Exposure | What it looks like | Timeline | +|----------|--------------------|----------| +| **High** | Content generation, summarization, Q&A, template output | Replicable in 12-18 months | +| **Moderate** | AI embedded in a workflow or dataset with switching costs | Replicable in 2-4 years | +| **Low** | A structural moat that AI substitution cannot dissolve | Defensible for 3+ years | + +High exposure isn't a death sentence, but it sets a clock. An AI essay-feedback tool, a study-guide generator, a syllabus-to-Q&A bot — these sit at High. The model that powers them gets better for your competitors at the same rate it gets better for you, and nothing stops a new entrant from starting fresh next quarter. + +Moderate means you've earned some time. The AI is wired into a faculty grading workflow or sits on top of a dataset the institution has come to rely on. Switching costs buy you 2-4 years. + +Low means the thing that makes you valuable isn't the AI at all. It's a dependency you've created inside the institution that a new model can't reproduce. + +## The four moats + +Four structural moats move you down the spectrum toward defensibility. Each one is something an LLM cannot manufacture, because each one lives outside the model. + +### 1. Proprietary data network + +Longitudinal data that improves with usage and cannot be reconstructed by a new entrant. + +A competitor can buy the same model you use. They cannot buy the three years of student-outcome data you've accumulated, where each cohort's results sharpen your next prediction. The value compounds with usage, and a new entrant starts from zero no matter how good their prompts are. + +*Edtech example:* An advising platform that has tracked which course sequences led to graduation versus withdrawal across multiple cohorts at a university. The recommendation engine isn't valuable because of the model behind it. It's valuable because of the longitudinal record of what actually happened to real students at that institution — a record nobody else has and nobody can backfill. + +### 2. Deep integration + +LTI/SIS write-back that creates operational switching costs exceeding the product's price. + +When your product writes grades back into the SIS, syncs rosters through LTI, and lives inside the registrar's daily workflow, ripping it out costs the institution more than the contract is worth. That's the test: switching cost has to exceed price. An LLM can copy your features. It can't copy the fact that your write-back is already wired into the system of record that the registrar and the provost depend on. + +*Edtech example:* A degree-planning tool that writes approved course plans back into the SIS and feeds the institution's official degree audit. A competitor's LLM might generate a better plan in isolation, but the district or university would have to re-integrate, re-test, and re-train staff to switch. The integration is the moat, not the planning logic. + +### 3. Supply-side network effects + +More providers, mentors, or contributors increase quality for every existing user. + +Each new participant on the supply side makes the product more valuable for everyone already on it. A new entrant with an identical model still has an empty network. They can replicate your software in two weeks and still have nobody on the other side of it. + +*Edtech example:* A career-transition platform connecting graduates to employers. Every additional employer relationship makes the platform more useful to every student, and every successful placement makes the platform more attractive to the next employer. A competitor can copy the matching interface but not the roster of employers and mentors who have shown up. (This is the Graduate & Beyond phase — the least-served stretch of the learner lifecycle, where employer relationships are the scarce asset, not the software.) + +### 4. Regulated access + +FERPA, HIPAA, or credentialing compliance that LLM wrappers cannot clear. + +Compliance is a barrier to entry that no prompt clears. A FERPA security review, a HECVAT, a SOC 2 — these take time, process, and standing that a thin wrapper around a model simply doesn't have. The institution's own approval chain becomes your moat: IT security, legal, procurement, accessibility review. A competitor with better AI still has to walk through every one of those doors. + +*Edtech example:* A student-data analytics product that has cleared FERPA review and holds the certifications a district requires before any system touches student records. An LLM wrapper that ingests the same data without clearing those gates can't be deployed at all, regardless of how good its output is. The regulated access is the moat — the model is interchangeable. + +## The AI-substitution durability test + +One practical lens for the AI era. Run your product through it: + +> **Does this product survive an LLM plus a competent IT team's roughly two-week prompt-engineering sprint?** + +Imagine a district CTO or a university IT team sits down with a current model and two weeks. If they can rebuild your core value, you don't have a moat — you have a feature, and you're on the High end of the exposure spectrum whether you admit it or not. + +If your value comes from one of the four moats, the sprint fails. The team can reproduce your interface and your prompts. They cannot reproduce your longitudinal dataset, your SIS write-back already wired into the registrar's workflow, your network of employers and mentors, or your cleared FERPA review. Those live outside the model, so a better model doesn't help the attacker. + +Apply it honestly. The point of the test is to find out which side of the line you're on before a competitor does. + +## The reframe + +Lead with the institutional dependency you create, not the technology you use. + +Founders pitch the model. They lead with "AI-powered" because it's what they built and what feels new. But "AI-powered" is what every product claims now, and it's the part most exposed to substitution. The durable story is the dependency: the data only you hold, the write-back the registrar relies on, the network nobody else has filled, the compliance gates you've already cleared. + +When you talk to a buyer, don't sell the reasoning engine. Sell what it would cost them to live without you. That's the moat. The AI is just how you got there. + +--- +*Last updated: 2026-05-30* diff --git a/data/demand-validation.md b/data/demand-validation.md new file mode 100644 index 0000000..b6af0b9 --- /dev/null +++ b/data/demand-validation.md @@ -0,0 +1,147 @@ +# The Demand Validation Test + +The "how" behind ETHOS principle #1: validate demand, not interest. Five questions that separate real institutional demand from false positives, plus the depth probes that tell you whether your answers will survive a 12-18 month sales cycle. For edtech founders selling into K-12 districts, universities, or corporate L&D before they build, before they pitch, and before they ask for a pilot. + +*Source: "Cracking Higher Ed: Why Startups Miss the Mark" — Philippos Savvides, SXSW EDU 2026. Licensed CC BY 4.0.* + +If you can't answer all five questions, you're not ready. "Interesting" and "funded" are different categories. Enthusiasm is not demand. This file is the test that tells you which one you have. + +The jobs you're validating live in [higher-ed-jobs-atlas.md](higher-ed-jobs-atlas.md). The structural patterns the depth probes reference live in [founder-traps.md](founder-traps.md). The interview method for discovering and pressure-testing these jobs lives in [jtbd-interviews.md](jtbd-interviews.md). + +--- + +## 1. Who is struggling, and what is the struggling moment? + +Not "who could benefit" but "who literally cannot do their job without a change?" + +Name a specific person at a specific institution with a specific problem. If you can't, you have a hypothesis, not a job. + +- **A job:** "Academic advisors at large online programs manually triage 300+ students each term using spreadsheets, missing at-risk students until it's too late." +- **A hypothesis:** "Universities could improve student outcomes with better analytics." + +**Depth probes:** + +- Is the struggling moment in the phase where the person *experiences* the pain, or is it caused upstream? Trace the causal chain back one phase. (See Pattern 2 in [founder-traps.md](founder-traps.md).) +- Is the struggling moment structural (happens to everyone in that role at that phase) or situational (happens to a subset)? Structural jobs have larger markets. + +**Watch for:** If the struggling moment is "students drop out" or "retention is low," you're describing a symptom. Keep asking why until you reach the decision point where things went wrong. The job lives at the decision point, not at the outcome. + +## 2. What have they already tried (and why did it fail)? + +If they haven't tried anything, the job isn't urgent enough to pay for. + +Your real competitive set is not other edtech products. It's: + +- Spreadsheets and manual processes +- Graduate assistants and TAs +- Ignoring the problem entirely + +What they've already hired and fired tells you the actual job. If the current workaround sort of works, your bar for adoption is higher than you think. + +**Depth probes:** + +- Are they using workarounds that technically function but don't scale? Spreadsheets, grad students, and unofficial tool substitutions are signs of a real job with no adequate solution. +- Have they tried solving the downstream symptom without addressing the upstream cause? If prior solutions targeted the wrong phase, your opportunity is the phase they haven't addressed. + +**Watch for:** If "nobody's tried anything," either the job isn't painful enough to pay for, or you're talking to the wrong person. Real jobs always have workarounds, even bad ones. + +## 3. Is there a budget line item? + +This is the single biggest filter. "Interesting" and "funded" are completely different categories. + +Ask the buyer: *What budget would this come from?* Acceptable answers: + +- "Title III funds" +- "IT security budget" +- "Student success allocation" +- "We have a line item for retention tools" + +Unacceptable answers: + +- "We'd have to figure that out" +- "Maybe we could write a grant" +- "Let me check with finance" + +If the buyer can't name where the money comes from, the pilot is innovation theater. + +**Depth probes:** + +- Does the budget sit with the person who experiences the pain, or someone else? If the user and the buyer are different people, you need the job statement for both. +- Can you connect the job to a line item the buyer already has? Student success funding, retention budget, IT modernization, accreditation compliance. + +**Watch for:** Pattern 4 in [founder-traps.md](founder-traps.md) applies here. The student feels the pain but the provider controls the budget. When talking to the budget holder, lead with the provider's job, not the student's experience. "Reduce grading turnaround from 5 days to 1" lands differently than "students feel they're teaching themselves." + +## 4. What happens if they do nothing? + +The cost of inaction must be quantifiable and urgent. + +**These are jobs:** + +- "We lose accreditation" +- "We lose $2M in retention revenue" +- "We violate FERPA and risk federal funding" +- "We can't staff enough advisors to handle enrollment growth" + +**These are hypotheses:** + +- "Students might learn better" +- "Faculty might save some time" +- "It would be nice to have better data" + +If the buyer can't articulate a concrete cost of inaction, they won't fight through procurement for you. + +**Depth probes:** + +- Is the cost of inaction quantified or merely perceived? "We lose students" is perceived. "We lose $X in tuition revenue from students who drop after discovering their credits don't transfer" is quantified. Help the buyer do the math. +- Does the institution even *know* the cost of inaction? Many costs are distributed across departments and invisible to any single stakeholder. + +**Watch for:** Pattern 3 in [founder-traps.md](founder-traps.md) applies here. If the stated cost of inaction is based on stakeholder perception, check whether outcome data tells the same story. If every stakeholder says "the accelerated format is killing retention" but the data says otherwise, the real cost of inaction may be somewhere else entirely. + +## 5. Who else must say yes? + +If the answer is "just me," your pilot will succeed and your deal will die. + +Real institutional adoption requires multiple approvals: + +- **IT:** Security review (HECVAT, SOC 2) +- **Legal:** Compliance review (FERPA, data governance) +- **Finance:** Budget approval and procurement process +- **Faculty governance:** If the product touches curriculum or pedagogy +- **Accessibility:** ADA / Section 508 compliance + +If you don't know the approval chain before the pilot starts, you'll generate great evidence that never reaches the person who signs the purchase order. + +**Depth probes:** + +- For each approver in the chain, what is *their* job? IT's job is risk mitigation. Legal's job is compliance. Finance's job is ROI. Your pitch must address each approver's job separately. +- Have you mapped the full approval chain *before* the pilot starts? IT security review, legal and compliance, finance and procurement, faculty governance if you touch curriculum, accessibility review. + +**Watch for:** If you've only validated with users and champions, you have enthusiasm without procurement. The pilot will succeed and the deal will die. Map every node in the approval chain and understand what job each node needs done before they say yes. + +--- + +## Scoring yourself + +| Question | Strong signal | Weak signal | +|----------|---------------|-------------| +| 1. Struggling moment | Named person, named problem, named institution | "Universities in general" | +| 2. What they've tried | You know the current workaround and why it fails | "Nobody's tried this before" | +| 3. Budget line item | Buyer names the budget | "We'd figure it out" | +| 4. Cost of inaction | Quantified financial or regulatory consequence | "It would be nice" | +| 5. Approval chain | You've mapped IT, Legal, Finance, and faculty governance | "Just my champion" | + +| Score | Verdict | What to do | +|-------|---------|------------| +| **5/5 strong signals** | You have validated demand | Design the pilot to produce the evidence the buyer needs. | +| **3-4 strong signals** | Promising demand with gaps | Address the weak signals before committing resources to a pilot. | +| **0-2 strong signals** | You have a hypothesis, not demand | Go back to discovery. Interview 10 more people who recently made a switching decision in this problem space — see [jtbd-interviews.md](jtbd-interviews.md). | + +--- + +## After the pilot: noise vs. signal + +The five questions above filter demand before you build. Once a pilot is underway, pressure-test the results with the four-question noise vs. signal filter in [founder-traps.md](founder-traps.md). Short version: signal comes from buyers and procurement processes, noise comes from users and champions. If any answer is no, you have enthusiasm, not validation. + +--- + +*Last updated: 2026-05-30* diff --git a/data/higher-ed-jobs-atlas.md b/data/higher-ed-jobs-atlas.md index 2585f60..78aab40 100644 --- a/data/higher-ed-jobs-atlas.md +++ b/data/higher-ed-jobs-atlas.md @@ -6,7 +6,7 @@ ## The Critical Insight -**80% of edtech founders build for the "Course Experience" phase.** It's the most crowded shark tank in the industry, with 15+ product categories fighting for the same tiny sliver of budget. +**80% of edtech founders build for the "Course Experience" phase.** It's the most crowded shark tank in the industry, with 15+ product categories fighting for the same tiny sliver of budget. The biggest opportunities are in the first four phases—Pre-enroll, Apply, Onboard, and Select & Enroll. The pain in these phases is massive, but product coverage is thin. @@ -16,8 +16,8 @@ The biggest opportunities are in the first four phases—Pre-enroll, Apply, Onbo |-------|--------|-----------------| | **Pre-enroll** | **Underserved** | Cost expectations, transfer credit research, format comprehension. | | **Apply** | **Underserved** | Admissions speed, transcript processing bottlenecks. | -| **Onboard** | **Underserved** | Transfer credit clarity, post-admission "dead zones." | -| **Select & Enroll** | **Underserved** | Course info for decision-making, availability, advising gaps. | +| **Onboard** | **Underserved** | Transfer credit clarity, post-admission "dead zones," format readiness. | +| **Select & Enroll** | **Underserved** | Course info for decision-making, availability, advising, degree audits. | | **Course Experience** | **Saturated** | 15+ product categories. Low margins, high noise. | | **Graduate & Beyond** | **Partial Coverage** | Career transition, credentialing, alumni outcomes. | @@ -68,40 +68,62 @@ The biggest opportunities are in the first four phases—Pre-enroll, Apply, Onbo * **The Struggle:** Total silence from the institution. This is where "summer melt" happens. * **The Job:** "Keep me engaged and ready during the void." +### Job 8: The Format Readiness Gap +* **The Moment:** An admitted student is days from starting an accelerated online program with no practical prep for the pace or the tools. +* **The Struggle:** Generic orientation modules don't simulate the real experience, and readiness help is deployed inconsistently across programs. +* **The Job:** "Get me ready for what's actually coming, not just oriented." + --- ## 4. Select & Enroll (4 Jobs) — UNDERSERVED -### Job 8: The Course Selection Blind Spot +### Job 9: The Course Selection Blind Spot * **The Moment:** Enrolled students picking next term's classes. * **The Struggle:** Choosing based on title alone. No workload info = high drop rates later. * **The Job:** "Help me pick courses I won't have to drop." -### Job 9: The Sequencing & Advising Maze +### Job 10: The Course Availability Crunch +* **The Moment:** A student trying to stay on track finds required courses full, offered once a year, or in conflict. +* **The Struggle:** They overload when they can, delay graduation, or transfer out. Online programs still inherit seat-limited, in-person scheduling. +* **The Job:** "Get me into the courses I need, when I need them." + +### Job 11: The Sequencing & Advising Maze * **The Moment:** A student trying to figure out what to take next to graduate on time. * **The Struggle:** Degree audit tools are indecipherable. Human advising is a 3-week wait. * **The Job:** "Tell me exactly what to take next in plain English." +### Job 12: The Degree Audit Black Box +* **The Moment:** A student trying to track progress toward graduation opens the degree audit tool and can't read it. +* **The Struggle:** The one tool built to answer "what's left?" doesn't answer it clearly, so they fall back on spreadsheets and advisor meetings. +* **The Job:** "Show me, in plain language, exactly what's between me and graduation." + --- ## 5. Course Experience (2 Jobs) — SATURATED *Founders: If you're building here, look at the provider side. That's where the budget sits.* -### Job 10: The Instructor Capacity Constraint +### Job 13: The Instructor Capacity Constraint * **The Moment:** A faculty member teaching 200+ online students. * **The Struggle:** They can't give real feedback. Students feel "ignored." The structural feedback loop is broken. * **The Job:** "Help me give high-quality feedback without burning out." * **The ScaleU Take:** Solve the instructor's workload, and you solve the student's experience. Sell to the department, not the student. +### Job 14: The Support Access Gap +* **The Moment:** A student gets stuck and needs tutoring, writing, or math help right then. +* **The Struggle:** Support exists but is disconnected from the course and hard to find at the moment of need. They fall back on YouTube or struggling alone, which deepens the "I'm teaching myself" feeling. +* **The Job:** "Get me help the moment I'm stuck, not after I've already fallen behind." +* **The ScaleU Take:** Like instructor capacity, this is a provider-side structural gap. Wire support into the moment of need and you relieve the student and the institution at once. + --- ## 6. Graduate & Beyond (1 Job) — PARTIAL COVERAGE -### Job 11: The Career Transition Bridge +### Job 15: The Career Transition Bridge * **The Moment:** A student graduating and wondering "What now?" * **The Struggle:** The connection between the degree and the job market is invisible or unsupported. * **The Job:** "Turn this credential into the promotion I came for." +* **The ScaleU Take:** The least-researched, least-served phase in the whole lifecycle. Most institutions have almost no data on post-graduation outcomes. Wide open. --- @@ -110,6 +132,7 @@ The biggest opportunities are in the first four phases—Pre-enroll, Apply, Onbo 1. **Map your product:** If you don't map to a job here, your "problem" might not be an institutional priority. 2. **Check Saturation:** If you're in Course Experience, move "upstream" to an underserved phase that causes the problem. 3. **Follow the Budget:** The person feeling the pain (the student) is rarely the one who pays the bill. Find the provider-side job. +4. **Pressure-test it:** Run a job through [demand-validation.md](demand-validation.md) before you build, and use [jtbd-interviews.md](jtbd-interviews.md) to discover and validate jobs of your own. --- -*Last updated: 2026-04-27* +*Last updated: 2026-05-30* diff --git a/data/jtbd-interviews.md b/data/jtbd-interviews.md new file mode 100644 index 0000000..e99a637 --- /dev/null +++ b/data/jtbd-interviews.md @@ -0,0 +1,155 @@ +# JTBD Switch interviews for edtech + +How to discover and validate real demand by interviewing the people who already switched — and reading the four forces that pushed them. For edtech founders selling to K-12 districts, universities, or corporate L&D who keep hearing "this sounds great" and want to know whether anyone will actually buy. + +*Adapted from the JTBD Switch toolkit (github.com/savvides/jtbd, MIT), itself based on Bob Moesta's Jobs-to-be-Done "Switch" method.* + +People don't buy products. They hire them to make progress. A registrar had a routine before your tool showed up — transcripts in a shared drive, a wait-list spreadsheet, a part-time evaluator. It was terrible, and they were getting the job done anyway. Then something broke. They looked around, picked one option, and switched. Reconstruct that whole story and you learn exactly what to build and how to sell it. Survey the concept and you learn nothing. See [operator-lessons.md](operator-lessons.md): count the workaround, don't survey the concept. + +## The four forces + +Every switch is driven by four forces. Two push the buyer to change. Two hold them back. The switch only happens when push plus pull overwhelms anxiety plus habit. + +``` +DRIVING THE SWITCH RESISTING THE SWITCH +================== ==================== + +Push of the current ──► ◄── Anxiety of the new +situation solution +"what is broken now" "what if it doesn't work" + +Pull of the new ──► ◄── Habit of the present +solution +"what is attracting me" "what I am used to" +``` + +Score each force you find on a 1-10 intensity scale: 10 is the dominant driver of the decision, 1 is barely relevant. The number is directional, not precise — a 3 versus an 8 is meaningful, a 6 versus a 7 is noise. The point is to rank what actually moved the buyer, not to grade them. + +### Push — what is breaking now + +Push is what is actively failing in the status quo. It's always tied to a specific event or pattern, never a vague feeling. "It was frustrating" is not a push. "The transcript backlog blew past the enrollment deadline and we lost the student" is a push. + +- A provost: "Our 7.5-week courses had a 30% drop rate and the board started asking why." +- A transfer student: "My GPA dropped a full point the term I didn't have an advisor who could tell me what to take next." +- A district CTO: "The old gradebook went down during the last week of the term and teachers couldn't post finals." +- An L&D lead: "Completion on our compliance training sat at 40% and audit season was coming." +- A registrar: "Manual credit evaluation took three weeks and students were committing to the competitor that answered first." + +### Pull — what the new thing promises + +Pull is the magnetic appeal of the alternative. It's about an imagined future state, not a feature list. Buyers aren't attracted to "real-time articulation" — they're attracted to the idea that they can tell an admitted student their credit status before the deadline without anyone waiting three weeks. + +- A registrar: "I pictured students seeing exactly which credits would count the day they applied, not a month later." +- A provost: "I wanted to see the drop-risk numbers myself, without asking institutional research to pull a report." +- An L&D lead: "I imagined onboarding a new hire to job-ready in half the time, and being able to show that number to my VP." +- A faculty member teaching 200 online students: "I pictured giving every student real feedback without working until midnight." + +When you hear a pull, keep asking "why does that matter?" until you hit the emotional payoff. The payoff — credibility, not being the bottleneck, looking good to leadership — is the real pull. + +### Anxiety — what scares them about switching + +Anxiety is everything that makes the buyer hesitate. It's the silent killer. People rarely volunteer it, so you have to ask directly: "What almost stopped you?" + +- A registrar: "What if we lose three years of transcript data in the migration?" +- A district CTO: "What if this thing touches FERPA records and we end up with a breach during the pilot?" +- A provost: "What if faculty hate it and I've spent political capital pushing a tool nobody uses?" +- An L&D lead: "What if procurement classifies it high-risk and it sits in security review for six months?" +- A dean: "What if the vendor turns out worse than what we already have, and now I own that decision?" + +### Habit — the comfort of the familiar + +Habit is the pull of the way things already are. People tolerate enormous pain to avoid changing their behavior. Habit is the most underprobed force, because buyers build elaborate workarounds and forget they're workarounds. + +- A registrar: "Every evaluator had their own way of dealing with the old system's quirks. Retraining them felt brutal." +- An advising office: "Our whole intake process was built around the degree-audit tool nobody can read. Someone's entire job was translating it into plain English for students." +- A district: "Teachers had years of materials inside the old LMS. Moving felt like starting over." +- An L&D team: "We had reports the CFO expected in a specific format. Rebuilding them was its own project." + +When someone describes a workaround — "my analyst had a whole process for that" — you've found both a habit force (the comfort of the routine) and a push force (the routine exists because the tool is broken). Probe both. + +## Job stories, not user stories + +The standard "As a user, I want X so that Y" template hides the thing that matters: the situation. It assumes the persona and skips the trigger. A job story puts the moment first. + +Format: **When [situation], I want [motivation], so I can [outcome].** + +The situation is the trigger — the specific moment the job shows up. The motivation is what they reach for. The outcome is the progress they're trying to make. Derived from jobs in [higher-ed-jobs-atlas.md](higher-ed-jobs-atlas.md): + +> **When** a transfer student applies and hasn't seen their credit articulation, **I want** to show them exactly which credits count before the enrollment deadline, **so I can** stop losing them to the competitor that answered first. + +> **When** I'm teaching 200 online students and can't give any of them real feedback, **I want** to draft high-quality feedback at scale that I review and send, **so I can** stop students feeling ignored without working until midnight. + +Notice what the job story forces you to know that a user story lets you skip: the exact moment, the stakes, the alternative they'd otherwise choose. "As an instructor, I want better feedback tools" tells you nothing. The job story tells you when to show up and what you're replacing. + +## The backward-timeline interview + +Every switch follows the same timeline. Your job is to reconstruct it, and the trick is to start at the end and walk backward. People remember decisions; they reconstruct the path from there. + +``` +FIRST PASSIVE ACTIVE DECIDING CONSUMING +THOUGHT LOOKING LOOKING + │ │ │ │ │ + ▼ ▼ ▼ ▼ ▼ +"something "casually "actively "chose this "using the + is wrong" noticing" evaluating" one" new thing" +``` + +- **First thought:** the exact moment they realized things could be different — usually a specific event, like a gradebook going down during finals. +- **Passive looking:** casual awareness. They ask peers, read comparison threads, notice tools exist. Not searching yet. +- **Active looking:** something escalated the urgency. Now they're booking demos and running trials. Find out *what changed*. +- **Deciding:** the moment they picked one. The deciding factor is rarely the feature matrix — it's often emotional or contextual (a dean sat in on the demo and said "buy it"). +- **Consuming:** onboarding, migration, adoption. This is where anxiety becomes real — like realizing you have to re-enter a term of data by hand. + +### How to walk the timeline + +Open with: *"Tell me about the last time you switched from one [category] to another."* If they haven't switched, ask about the last time they seriously considered it. Then walk backward: + +1. **Decision:** "What did you end up choosing? When was that? Who else was in the room?" +2. **Active looking:** "Before that, what else did you evaluate? How did you find them? What triggered you to go from annoyed to actively searching?" +3. **Passive looking:** "Before you were actively searching, were you aware alternatives existed? How long were you in that 'I know there's better but I'm not doing anything' phase?" +4. **First thought:** "Take me back to the very first moment you thought 'maybe I should look for something different.' What happened?" +5. **Consuming:** "After you decided, what was onboarding like? What was harder than expected?" + +The trigger from passive to active is gold. It's usually a specific event — a missed deadline, a bad board meeting, a public embarrassment in front of a superintendent. Probe until you get the story. And shut up: the best interviewers talk about 20% of the time. Ask, then wait. + +### Four interview contexts + +Who you talk to changes the framing. + +**Switched TO you.** The default. Reconstruct their full timeline and all four forces. This tells you why your wedge works and what almost stopped them. + +**Switched AWAY (churned).** Flip the framing: the "old way" is your product, the "new thing" is whatever they left for. The push forces are your failures. Painful, and the most valuable interview you'll run. Add: "What would have kept you?" and "When did you first think about leaving?" Note that "too expensive" is almost never the real reason — a buyer who paid had already accepted the price. Dig past the excuse. + +**Switched between competitors (not you).** They never considered you. You learn the forces in your category without your own product distorting the story. Ask what made them look, what they evaluated, and why you weren't on the list. + +**Currently evaluating (hasn't decided).** Focus on the old way, the first thought, and push and pull. Skip "deciding" — it hasn't happened. Add: "What would need to be true for you to make a change?" and "What's stopping you right now?" The thing stopping them is your anxiety or habit force, live. + +### Probe each force directly + +The timeline surfaces some forces naturally. This fills the gaps. + +- **Push:** "What was the most frustrating thing about the old way? Tell me about a specific time it let you down. What did that cost you?" +- **Pull:** "What first caught your attention? When you imagined using it, what did you picture being different?" +- **Anxiety:** "What almost stopped you? Was there a moment you nearly backed out?" Let silence sit. If they say "nothing," try "if you had to name one risk, even a small one…" +- **Habit:** "Was there anything about the old way you'd miss? Did anyone on your team resist? What workarounds did you have to give up?" + +## Red flags + +These tell you you're getting speculation, not memory. Redirect on the spot. + +| Red flag | Sounds like | Redirect | +|----------|-------------|----------| +| **Hypothetical language** | "I would…", "I think I'd…" | "I want what actually happened. Take me back to that moment." | +| **Vague emotion** | "It was frustrating." | "Tell me about a specific time. What happened?" | +| **Category answer** | "We needed better analytics." | "What specifically couldn't you do? Walk me through the last time it was a problem." | +| **No dates or people** | "At some point we decided…" | "Was that before or after [event]? Who was in the room?" | +| **Feature list** | "It has dashboards and an API and…" | "Which mattered most to you? Why that one?" | +| **Pleasing you** | "Your product is great because…" | "I appreciate that, but I'm after the messy middle. What almost stopped you?" | + +The big one is **"I would."** Hypothetical language means they're inventing an answer, not recalling a behavior. "I would definitely use a tool that does X" is a wish, not evidence. The same problem shows up in surveys: "would you use this" predicts nothing, while a count of people already hacking a workaround predicts everything (see [operator-lessons.md](operator-lessons.md)). Switch interviews are trustworthy precisely because they ask what someone *did*, in a setting where one buyer decides — which is exactly the institutional buying setup. "I surveyed eight teachers" is noise; the registrar who already runs a manual workaround is signal. + +After three or more interviews, patterns emerge: the same push event, the same anxiety blocking the same buyers, the same habit you have to break. That repeated pattern — not any single story — is the job your product actually serves. + +Switch interviews are the behavioral half of validating demand — the questions in [demand-validation.md](demand-validation.md) tell you whether the demand is real before the build; the timeline reconstruction here tells you the story behind it. For the structural reasons edtech founders mistake enthusiasm for demand, see [founder-traps.md](founder-traps.md). For the validated jobs to anchor your job stories against, see [higher-ed-jobs-atlas.md](higher-ed-jobs-atlas.md). + +*Last updated: 2026-05-30* diff --git a/data/pilot-benchmarks.md b/data/pilot-benchmarks.md index b660992..10c6f74 100644 --- a/data/pilot-benchmarks.md +++ b/data/pilot-benchmarks.md @@ -96,5 +96,29 @@ A Memorandum of Understanding for an edtech pilot should cover: - Showing not just "it worked" but "here's what it would look like at scale" - Addressing implementation concerns proactively (training, support, integration) +## Pilot readiness: the hard filters + +Before a structured pilot is worth running, the company must clear five binary gates (from ScaleU's EdTech Pilot Playbook). If any answer is "no," it isn't pilot-ready, regardless of product quality. + +1. **Institutional buyer exists** — a named person at a named institution who would champion it. "Higher education" is not a buyer. +2. **The problem is real** — evidence, not assumption, that the problem matters to institutional stakeholders. +3. **A product exists** — usable today, not a deck or a prototype. +4. **Validation is possible** — you can design a pilot that produces measurable evidence within the cycle. +5. **The founder will engage** — treats the pilot as evidence generation, not a sales demo. + +## The go / pivot / no-go gate + +Decide the three outcomes *before* the pilot starts, so the decision framework already exists when the data lands: + +- **Go** — the budget holder commits to procurement. +- **Pivot** — adjust scope or population and re-test. +- **No-go** — end the relationship, with documented reasons. + +Pilots with pre-agreed success criteria convert at higher rates because the decision is already framed. In the debrief, share the evidence including the negative findings — that's what separates a validation partner from a vendor. + +*Source: ScaleU EdTech Pilot Playbook (ASU+GSV 2026 Summit Intelligence). CC BY 4.0.* + +See also [demand-validation.md](demand-validation.md) and [procurement-guide.md](procurement-guide.md). + --- -*Last updated: 2026-03-31. Benchmarks are directional, drawn from patterns across multiple edtech accelerator programs and university partnerships.* +*Last updated: 2026-05-30. Benchmarks are directional, drawn from patterns across multiple edtech accelerator programs and university partnerships.* diff --git a/data/procurement-guide.md b/data/procurement-guide.md index 4b3b0e4..ab3bec5 100644 --- a/data/procurement-guide.md +++ b/data/procurement-guide.md @@ -46,4 +46,20 @@ Departments and even individual faculty have their own "P-Cards." You can land a 5. **Multi-Year Pre-Pay:** Institutions love budget predictability. Offer a discount for a 3-year deal paid upfront. It helps their budget and your cash flow. --- -*Last updated: 2026-04-27* + +## What institutional buyers told us (ASU+GSV 2026) + +Field signals from a roundtable of university administrators and founders at the ASU+GSV 2026 summit. Durable patterns, not a dated trend list. Practitioner signals, not peer-reviewed. + +- **Bandwidth, not money, is the real blocker.** Administrators said the scarce resource is staff time to evaluate, integrate, and run a pilot — not budget. The ScaleU read: if an institution can't find time for your pilot, the problem you solve probably isn't painful enough for them right now. That's a customer-fit signal, not a scheduling problem. +- **"Dirty pilots" are how buyers dodge the 12-month cycle.** Many run a lightweight, informal test before involving IT or procurement, just to see if anyone actually uses the product. Useful for early signal, but they don't scale, don't transfer to the next institution, and leave no documentation behind. As one founder put it: getting real results in two weeks beats a probability of $50K in six months. +- **Buyers trust a peer's filter, not a peer's verdict.** Evidence from a pilot at one institution is rarely accepted at face value by the next (different students, context, infrastructure). But institutions will readily adopt a peer's evaluation *protocol*. Lead with how you'd help them evaluate, not just your results. +- **Thresholds vary by state.** Arizona's RFP threshold is $100K; Ohio's is $50K; others differ, with state-specific RFP rules. Don't assume one number. +- **The RFP black box.** Non-winning vendors get no feedback — no score, no reason. Budget your RFP effort against those odds, and prefer relationship-based entry at the early stage. + +*Source: ASU+GSV 2026 Summit Intelligence — ScaleU. CC BY 4.0.* + +See also [buyer-demand-signals.md](buyer-demand-signals.md), [pilot-benchmarks.md](pilot-benchmarks.md), and [demand-validation.md](demand-validation.md). + +--- +*Last updated: 2026-05-30* From 142d927415af09a0451a5d94b185c92788222ac2 Mon Sep 17 00:00:00 2001 From: Philippos Savvides Date: Sat, 30 May 2026 12:28:09 -0700 Subject: [PATCH 2/2] docs: make issue-template file paths clickable links (Gemini review) Converts the plain-text data/ paths in the case-study and job-statement issue templates to clickable markdown links so they resolve from a GitHub issue. Co-Authored-By: Claude Opus 4.8 (1M context) --- .github/ISSUE_TEMPLATE/case-study.md | 4 ++-- .github/ISSUE_TEMPLATE/job-statement.md | 2 +- 2 files changed, 3 insertions(+), 3 deletions(-) diff --git a/.github/ISSUE_TEMPLATE/case-study.md b/.github/ISSUE_TEMPLATE/case-study.md index f7237b8..f2c65a2 100644 --- a/.github/ISSUE_TEMPLATE/case-study.md +++ b/.github/ISSUE_TEMPLATE/case-study.md @@ -8,10 +8,10 @@ labels: case-study **Institution or company type** (e.g., R1, community college, online program, K-12 district, corporate L&D, early-stage startup) -**Journey phase(s) involved** (Pre-enroll, Apply, Onboard, Select & Enroll, Course Experience, Graduate & Beyond — see `data/higher-ed-jobs-atlas.md`) +**Journey phase(s) involved** (Pre-enroll, Apply, Onboard, Select & Enroll, Course Experience, Graduate & Beyond — see [data/higher-ed-jobs-atlas.md](https://github.com/savvides/edtechfounderstack/blob/main/data/higher-ed-jobs-atlas.md)) -**Which diagnostic questions did you apply?** (from `data/demand-validation.md`) +**Which diagnostic questions did you apply?** (from [data/demand-validation.md](https://github.com/savvides/edtechfounderstack/blob/main/data/demand-validation.md)) **What did you find?** (signal vs. noise — be specific) diff --git a/.github/ISSUE_TEMPLATE/job-statement.md b/.github/ISSUE_TEMPLATE/job-statement.md index 7cd2f6e..2cddab7 100644 --- a/.github/ISSUE_TEMPLATE/job-statement.md +++ b/.github/ISSUE_TEMPLATE/job-statement.md @@ -17,7 +17,7 @@ labels: job-statement **Current workarounds** (what do they do today, and why does it fail?) -**Proposed job statement** (format: "When [situation], I want to [motivation], so I can [outcome]" — see `data/jtbd-interviews.md`) +**Proposed job statement** (format: "When [situation], I want to [motivation], so I can [outcome]" — see [data/jtbd-interviews.md](https://github.com/savvides/edtechfounderstack/blob/main/data/jtbd-interviews.md)) **Evidence source** (how did you validate this? interviews, data, institutional experience?)