01
The gap was technical fluency, not product instinct.
Ten years in digital marketing put me next to this work without doing it. Customer research, analytics, building websites, and sitting across from business owners who wanted something and could not always say what. Then a year as a project manager at a marketing and web development company, running ten to fifteen client projects at once and coordinating designers, content people and a remote development team. The work was marketing websites, not complex software.
That is not product management. What it gave me was years of standing between somebody who wants something and the people who have to build it. What it did not give me was the vocabulary to know what those people were actually telling me.
That is a specific gap, and it has a specific cost. If you are the person between a stakeholder and a development team, you need to understand the constraints that team works under. Not to write the code. To anticipate what is possible, relay it accurately, and push back credibly when something is not feasible.
Nothing I found taught that. Courses teach you to code, or they teach product frameworks with the technology left as a black box. The thing in between, what a product is actually made of, aimed at somebody who will never open an editor, was not there.
The shape I wanted did already exist, for a different audience. The Odin Project takes everything scattered across the internet about learning to code and turns it into one sequenced path a person can actually finish, and that structure was the model here. Duolingo was the second influence, for what makes something worth opening on a Tuesday night. That half turned out to be the mistake, and it is section six.
You do not have to be an expert. You have to know enough to tell a two day change from a two week one before you promise it to somebody.
02
Two journeys, and neither one is a prerequisite.
Software Builder is what a product is made of. Nine units and 110 lessons, from what software actually is through the internet, the frontend, databases, APIs, identity and security, shipping, scale, and finally AI.
Product Management is what to build and why. Eight units and 86 lessons, covering product thinking, discovery, strategy, specs, prioritization, delivery, metrics, and the politics of shipping.
They are independent on purpose. Neither is a gate on the other, and they meet whenever a product decision turns out to be a technical one, which is most of the interesting ones.
The order is not arbitrary. AI comes last in Software Builder, and not because it is the hardest thing in there. An AI feature is a call out to somebody else's service, with a bill attached, a key you have to keep secret, and your users' data going somewhere. Teach it before any of that is understood and you get exactly the hand waving this whole thing exists to stop.
What is deliberately not taught
Nobody is taught to write code. Code turns up only as something to read, the way you would read a contract without being a lawyer. No lesson is about one company's product, because those are vendors rather than ideas, so they appear as examples inside a lesson instead. Frameworks get named where somebody will actually hear the word in a meeting, and explained only as far as the tradeoff they represent.
Deciding what a course refuses to cover is the same job as deciding what a product refuses to do. It is what stops it turning into everything.
03
Every lesson starts by breaking what you already believe.
Explain something first and the reader nods along. It all makes sense while they are reading it, and three weeks later, in the conversation that actually mattered, they have nothing. That is how nearly every technical course for non-engineers fails, and it was the first format I threw out.
So a lesson starts by asking what you already think. Guess a number, lock it in. Then it shows you why the guess is wrong. Being wrong out loud is what makes the right answer stay.
That costs something. For every topic I have to work out what a smart person who has never met it would probably assume, which is much slower than writing down what is true. A few topics have no obvious wrong answer to break, and those open with a situation instead.
The second decision is the one I would argue hardest for. Every lesson ends with the same card, and it cannot be skipped: how to say this out loud to an engineer, and what it changes about a decision you are going to make.
Making it mandatory does a second job I did not plan for. If I cannot write that card for a topic, the topic probably does not belong in here. The rule that forces every lesson to be useful is also the rule that stops the curriculum growing forever.
04
Mastery instead of streaks.
The obvious version was sitting right there. Points, levels, daily goals, a streak counter. Everybody recognizes it, and it does work, if what you want is for people to keep coming back.
I did not use any of it, for two reasons. A streak punishes you for missing a day, and losing one is one of the most reliable ways to make somebody quit an app for good. And points count how much you did, not how much you understood. For something whose only job is teaching, that is measuring the wrong thing on purpose.
Instead every topic sits at one of three levels. Seen, you finished the lesson. Understood, you passed the check at the end. Can Explain, the topic came back two days later, then a week later, then three weeks later, and you still had it.
The map shows what is actually understood, and it cannot be inflated by grinding.
Two smaller rules came out of the same thinking. The app never takes a checkmark away: if review shows decay, mastery slides from Can Explain back to Understood, but the check stays, because automatically un-checking finished work is the same psychology as a broken streak. And every marker is manually toggleable in both directions, so somebody who already knows a topic can mark it without sitting through the lesson. The automatic behavior is a convenience, not an authority.
05
Ten ways to teach, and nothing built twice.
There is a version of this project that quietly turns into an engineering project. Build a screen from scratch for each lesson and every one can be exactly right, and meanwhile the app keeps getting built and the writing never happens. Go the other way, one template for everything, and it stays cheap right up until every lesson feels identical and nobody finishes a unit.
So there are ten kinds of interaction, built once and reused everywhere. A guess that gets broken. A small simulation. A walk through what happens, step by step. Two things side by side. Sort these into piles. Pick what you would do. A real document with notes on it. A quiz. Flashcards. Explain it back in your own words. Plus the card at the end, which is the one that is never optional.
A lesson is a file that says which of those to use and what goes in them. So writing a new lesson means writing, not building. Across everything written so far those ten turn up about 480 times, and that is the only reason a curriculum this size is finishable by one person.
The rule I set myself matters as much as the ten. I do not get to add an eleventh until at least three topics are clearly badly served without it. Without a rule like that, every awkward topic becomes an excuse to go build something new, and the writing stops again.
06
What I got wrong
I built the whole teaching format on a bad analogy.
The original brief was more Duolingo than online course. So the first lessons were five interactive screens clicked through one at a time, with the explanation squeezed into a reveal box after each interaction.
Then I opened the first one and could not tell what I was looking at or what I was supposed to do. Worse, it taught me nothing, because there was almost nothing to read. Duolingo works for language because language is drillable. A concept is not. You cannot learn what software is from a sequence of quiz prompts.
A lesson is now one page you scroll, with real explanation in sections and the primitives demoted to checks in between. The ten primitives survived unchanged. What changed is that they stopped being the lesson. Reading lessons take far longer to author, roughly a thousand words of genuinely good explanation each, and that is the actual work of this project. Pretending otherwise was the error.
Three design directions got rejected before one worked.
The first two, a plain wireframe and then a calm editorial look with serif headings and generous whitespace, both got rejected for looking machine made. That reaction turned out to be correct and worth understanding rather than arguing with: light, serif and airy is the default output of every generative tool right now, so it reads as generated regardless of how well it is executed.
The third attempt overcorrected into full candy colors and read as noise, because color was scattered across every element without meaning anything. What worked was chunky structure with disciplined color: one hue per card, and the hue signals which unit you are in, so color became navigational instead of decorative. Green and red are reserved for correct and incorrect and nothing else may use them.
I wrote it for myself before I noticed.
Early copy had drifted into addressing one specific reader, which reads oddly to anybody else and makes a product look like private notes.
It is now written for a category I happen to belong to: anyone who is not an engineer but has to build software or work closely with people who do. Product people, founders, designers, analysts. Assume no coding ability, assume real intelligence, never assume a job title. The difference sounds small and it is the difference between a notebook and a product.
07
Anyone can open it. Nobody will find it.
The app is hosted, and it is served with a header that keeps it out of every search engine. Follow a link and it opens, with no login and nothing to sign up for. Search for it and it does not exist.
That combination is deliberate, and it comes down to what I am willing to be responsible for. I have not verified every technical claim in every lesson to the standard I would want before somebody who found this in a search result starts repeating it in a meeting. Teaching somebody the wrong thing about how software works is worse than teaching them nothing, because they will repeat it confidently in a room where it matters.
Somebody who arrives from this portfolio has context. They know who wrote it and why, and they can weigh it accordingly. Somebody who arrives from a search for how databases work has none of that, and the same sentence carries a different weight.
Hosting it is easy. Being wrong in public, to somebody who had no reason to doubt it, is the part I am not willing to do yet.
What changes it
A review pass over the technical claims, unit by unit, by somebody who builds software for a living. That is specific and finishable, and it is the only thing between this and being genuinely useful to strangers.
The mechanism is one file. Cloudflare serves an X-Robots-Tag header on everything, rather than a robots.txt rule, because a disallow blocks the crawl and not the indexing. A blocked crawler can still list a bare URL it found linked somewhere, and having blocked it, never reads the instruction telling it not to.