Case study ·
CS-01
·
Minerva
One platform instead of two. Beta partners built curriculum 20% faster.
A 0→1 platform to build, teach, and grade curriculum in one place, replacing the two legacy tools it outgrew.
01
Built for one university, then sold to many
Minerva’s platform began as a custom tool for one university: build, teach, and grade curriculum around its science-backed teaching model. Then the internal tool became a product. As partnerships grew to dozens of schools worldwide, both legacy tools strained, and feature delivery kept slowing while the business shifted toward self-serve. The company’s commercial future was riding on a one-school tool, and CourseBook became the cornerstone of Minerva’s product direction.
The strain compounded into three problems, each with a real cost:
An outdated platform. Two apps meant two codebases, two logins, ten years of design and tech debt, and nothing mobile-friendly. The cost: slower releases and climbing support.
Custom-built for one school. Rigid by design, and no LMS integration: rosters, grades, and attendance were re-created by hand, and “normal” grading didn’t fit. The cost: unscalable manual work and unmet partner needs.
An evolving business model. Self-serve was coming, and the old architecture had no room for it, or for content reuse later. The cost: a widening feature gap for the future.
Field note
When people build spreadsheets to survive your product, they’re filing a bug report. Read it that way.
02
The obvious path was to merge the tools. I pitched that we build new.
The team’s plan was the sensible one: integrate the two codebases and account systems, and keep modernizing in place. After four years designing for both tools, I read it as a dead end. The rigidity lived in the object model, and a merge would preserve it; we’d still be shipping ten-year-old products that didn’t work for users. So I argued for a new MVP on Minerva’s recent workbook infrastructure: one tool, one simpler mental model, no debt. How that call was earned, and what it cost, is the first record below.
On advocacy
When the call is risky, go build the evidence. A pitch with a working prototype attached stops being an opinion.
How might we offer a simple, modern tool for creating, delivering, and assessing pedagogically sound curriculum on any device?
03
Three calls: build new, borrow the familiar, kill the clever
Most of this project’s shape came down to three decisions. Here they are the way I keep them: the call, the alternative it beat, why it won, and what it cost.
Honest ledger
Killing the Queue hurt for about a day. Watching instructors not need it didn’t hurt at all.
Drawing the MVP line. One more call ran through all three. With the legacy system headed for sunset, I worked with the PM to prioritize what day one required: importing existing materials, easy duplication across courses, and admin management. Migration risk lived there, so those made the cut. The AI assistant and in-class insights were deferred as immediate follow-ups, on the record, with reasons.
04
Build, teach, grade: three workflows, one page
What if everything was just… a page?
That question became the object model. Class slides, polls, group work, readings, homework: everything is a page, mobile-friendly and built from drag-and-drop blocks, text and video through questions and AI interactions. Courses are sets of lesson plans, folder-like workspaces that keep people focused, and every page carries three modes: edit, present, grade. The page an instructor builds is the exact page a student opens, which is why the tool needed no training.
In miniature
The collapsible sidebar: structure for curriculum developers, focus for instructors. One control reconciling two users.
05
Beta partners built 20% faster and graded 27% faster
I’m so excited about this! It is so simple and will save so much time.
Instructor
Beta partner
This is fantastic! My only question is: When can we have this?
Instructor
Beta partner
06
What I changed beyond the interface
A case study flatters the screens. The more durable changes were organizational — including two years leading design at Minerva, managing a designer and mentoring three interns — and they sort honestly by what I changed versus what I owned:
Product direction I changed
The feasibility prototype changed the org’s plan from merging two codebases to a greenfield platform. The pitch became the roadmap.
System I designed
The design system built alongside CourseBook sped front-end work 40% (internal estimate) and outlived the project as shared infrastructure.
Team practice I established
A standing testing cadence with instructors: mid-fi rounds and regular working sessions on the live prototype became routine, not an event.
Execution I owned
Migration risk from the greenfield call moved into my MVP plan: import, duplication, and admin management made day one.
07
The clever idea died first. That’s the lesson.
What survived testing was the boring-familiar system, and that’s exactly why instructors trusted a brand-new tool with their live classes. I protect my favorite ideas less now, and test them earliest, because clever that doesn’t survive contact with users is just decoration. There’s more here than fits one page.
Closing note
Slow is smooth, smooth is fast. The early alignment work is why seven months was enough.