TeacherAid: When Research Changed the Product
I co-founded a two-person AI EdTech venture, led educator discovery and product architecture, helped build a Python/OpenAI MVP, and then used conflicting expert evidence to challenge the original thesis rather than treating a working prototype as validation.
Co-Founder & Product Lead · Oct 2024-Apr 2025 · Product discovery, sprint planning, Python, OpenAI
The first job was making the hypothesis testable
TeacherAid started as an AI EdTech product idea. The working product direction was to turn teacher materials into adaptive assessment and targeted review experiences. As product lead, I worked across discovery, product architecture, sprint planning, and MVP development rather than separating research from delivery.
The two-person team built enough of the concept to make interviews concrete. The Python/OpenAI MVP could generate assessments, track confidence, identify weak concepts, and guide targeted review. That made the product easier to discuss with educators than a slide deck or abstract AI pitch.
I treated interviews as evidence, not a sales exercise
I led more than five educator interviews. The point was not to collect compliments or prove that teachers liked AI. We were trying to understand whether the proposed workflow solved a meaningful enough problem, how it fit into existing teaching practice, and which parts of the idea were actually useful.
The surviving project records do not contain the underlying interview transcripts, exact senior-expert comments, or enough usage data to reconstruct adoption. I therefore do not present a fabricated quote, an inflated validation count, or a claim that the MVP proved product-market fit.
Product decision path
The useful output was a changed decision, not a defended idea
The available evidence supports the sequence below. It does not preserve the exact expert quote or enough data to claim adoption.
1 · Hypothesis
Teachers need faster adaptive assessment workflows
Start with a product thesis about turning teacher materials into assessment and targeted review experiences.
2 · Build
Ship enough product to make the idea concrete
A Python/OpenAI MVP generated assessments, tracked confidence, identified weak concepts, and guided targeted review.
3 · Research
Put the thesis in front of educators
More than five educator interviews supplied evidence about the real workflow rather than validating the idea by default.
4 · Decision
Conflicting expert evidence changed the plan
The team challenged the original thesis and defined a future pivot instead of treating a working MVP as proof of adoption.
A working MVP was not enough reason to continue
The important outcome was conflicting expert feedback that materially weakened the original product thesis. Instead of treating the technical progress as sunk-cost justification, we challenged the plan and defined a future pivot.
That distinction matters to me. Building something proves that a team can execute. It does not prove that the customer problem is important, that the workflow is right, or that the product deserves more time. TeacherAid became an early lesson in separating delivery evidence from market evidence.
What I would preserve from the project
- Interview before expanding the roadmap, even when the prototype is technically exciting.
- Build enough product to make customer feedback specific rather than hypothetical.
- Record contradictory evidence instead of averaging it into a vague positive signal.
- Keep adoption claims separate from MVP capability and interview interest.
- Allow stopping or pivoting to count as a successful product decision when the evidence changes.
Outcome
TeacherAid did not become a scaled product during the documented Oct 2024 to Apr 2025 venture period. The portfolio value is the product judgment: a two-person team moved from hypothesis to MVP to educator evidence, then allowed the evidence to change the direction.