In April, I wrote about what made Prova feel real: the sprint engine, the billing, the evals, the boring operational work that separates a demo from a product.
That post was true when I published it. The sprint-first architecture I described — authored sprints, rubric reviews, adaptive routing, the Operator and Builder paths — was genuinely working. It was the right engine.
What I didn't know yet was that the curriculum layered on top of it was still wrong.
Not wrong in a way you would catch from a demo. Wrong in the way that only surfaces after you have authored every rubric, traced every user path, and asked the question nobody had forced me to ask until mid-May: what exactly makes this hard for a free chatbot to replicate?
Between mid-May and late June, the curriculum was rebuilt twice. Each time, I replaced something I had previously been confident about. Here is what each rewrite was actually about.
The 3-lane architecture (May 26–June 1)
By late May, the product had a problem. It had 33 sprints, and three very different audiences — operators redesigning workflows, builders trying to ship a first useful slice, and leaders trying to transform teams — sharing 7 of 9 sprints and calling the remaining two a track. That was a menu, not a spine.
Breadth is not a moat.
So I built what felt like the rigorous answer: a layered architecture with a shared Layer 0 foundation, then three audience lanes (Operator, Builder, Leader) with their own dedicated sprints, all sourced from the course's 16 templates and published corpus. 38 units across 5 unit types. Concept, exercise, sprint, project, checkpoint — each with different completion semantics.
On paper, it looked like a real curriculum.
What broke was not any individual sprint. It was the structural assumption underneath the whole thing: that more lanes and more sprints made the product more defensible.
They don't.
Hamilton Helmer's 7 Powers framework names this explicitly. Power comes from barriers — structural advantages that competitors cannot replicate just by deciding to. Adding sprints to a path is not a barrier. It is operational surface area. A generalist chatbot matches breadth instantly with zero friction.
The 3-lane model added coverage. It did not add depth. I had built the wrong thing, and I did not see it until the architecture was deployed and every sprint was written.
I had authored 24 new sprints for the 3-lane model, sourced from the course's templates and published corpus. The architecture looked rigorous on paper. I was proud of it.
The lane system was decommissioned the same week it shipped.
The one rule (June 2–22)
The second rewrite did not begin with sprints. It began with a strategy question.
I sat down and asked: if Prova's only defensible edge is something that a horizontal AI tool structurally cannot adopt, what would that edge be?
The answer landed in three reinforcing layers:
Vertical depth (the wedge). A marketer who ships a brief-documented campaign workflow, with real measurement and a decision gate, to an advertising-grade standard. That is not something a chatbot can produce from a prompt.
Scaffolding (the activation). Most marketers do not know what to ask. The product has to meet them at "I think AI could help with this but I am not sure where to start" and do the work of scoping, sequencing, and standard-setting.
Verified, shipped work to a standard (the proof). Every sprint ends with a submission reviewed against a real rubric. Not "does this look good." Not "is this grammatically clean." But: does this artifact hold up against what an agency operator or media buyer would actually use?
From those three layers, the architecture simplified dramatically.
The 3-lane structure was replaced by one loop grammar: reality-check → brief → plan → run/build → decision-gate → capstone.
Same grammar for all three paths. Different artifacts per path. The operator runs a campaign workflow pilot. The builder ships a working product slice. The leader builds a stakeholder business case and operating model blueprint.
Depth was added only post-capstone: agency extensions, product-depth extensions, org-change extensions. If a user wanted more, they earned it through the spine first.
Breadth did not disappear. It was demoted to evidence-triggered detour modules — short, assigned sprints that appear only when a reviewer detects a gap the authored spine cannot currently address. The data-infrastructure-audit. The vendor-stack-decisions. The table-stakes diagnostic. They still exist. They are just not the route you take unless the product has evidence you need them.
The single commit that formalized this was feat!: replace dual curriculum routing with unified path sequences on June 11. The ! denotes a breaking change. primary_path (operator, builder, leader) replaced learning_track as the single routing axis. There was a feature flag — DISABLE_BRIEF_DRIVEN_RESET_PATH — that walled off the transition until the QA gate passed. Seven legacy sprints were retired from sequencing but kept viewable as history.
The capstone became structural, not a feature. It is the switching-cost mechanism. A horizontal tool can generate a decent sprint packet. It cannot generate a portfolio of verified, shipped artifacts reviewed against advertising-grade standards with a persistent reviewer history.
Before authoring any new sprint or path, ask: which of the 7 Powers does this strengthen, and what is its barrier? If the honest answer is "it adds coverage" with no barrier, it is operational surface area a chatbot already covers — do not build it.
— June 5, 2026, Prova curriculum strategy doc
That rule killed the 3-lane architecture. It killed sprints that were well-written but structurally redundant. It turned the capstone from a feature I had been deferring into a structural requirement. And it is the question I wish I had been asking since March.
The difference between April and June
The product I launched in April was right about the engine. The product I settled on in June was right about the spine.
The engine — authored sprints, rubric reviews, adaptive routing, composed sprint lifecycle — was necessary. A curriculum architecture without a functioning sprint engine is just a syllabus.
But a sprint engine without a defensible spine is just a feature list that free tools are already matching.
The difference between the two products was not more code. It was a better question. "Which Power does this strengthen?" forced me to kill things I was proud of, and to elevate things I had been treating as optional.
I am not claiming the June architecture is finished. Products rarely are. But if you are building a learning product right now, the question is worth asking before you write your next sprint. Because breadth is the easiest thing to add, and the first thing a general-purpose AI will commoditize.
Additional context: Prova is my coaching product for marketers and advertising professionals, with an Operator path for workflow redesign and a Builder path for shipping a first useful slice. It lives at prova.chandlernguyen.com. The 7 Powers framework comes from Hamilton Helmer's book 7 Powers: The Foundations of Business Strategy — this post references the framework but does not teach it; the book is the source.
If you are building a structured product on top of a fast-moving AI layer, I would be genuinely curious: what is the one thing in your architecture that a free tool cannot replicate just by adding prompts?
That's it from me for now.
Cheers, Chandler