Before I wrote my first PRD, I designed a coding and robotics curriculum for K-12 students, scoped by age group, iterated against feedback from students, parents, and instructors, and delivered under a budget that did not move no matter how good the idea was. I didn't call any of that "product management" at the time. It was exactly that.
A curriculum is a roadmap with a user base that can't fake it
A software roadmap is a bet about what users will value, validated slowly, often through proxies like engagement metrics that lag reality by weeks. A curriculum has none of that lag. A ten-year-old will tell you, immediately and without diplomacy, when a lesson doesn't work. A parent will tell you, at pickup, whether their kid is excited or just compliant. That's a better feedback loop than most B2B software teams get in a year.
Scope a learning outcome to the youngest, least experienced learner in the band who still needs to hit it, then layer complexity on top for the rest. Design for the top of the band and you lose the bottom silently, and never find out until they quit.
The constraint that shaped the product
Budget and staffing were not hypothetical numbers on a slide. They were the reason a curriculum that looked good on paper sometimes had to ship smaller. Running multiple concurrent programs under tight capital constraints meant every "nice to have" module competed directly with an instructor's paycheck, not with an abstract opportunity cost.
That's a sharper version of a constraint every product person claims to respect and few feel. When the constraint is real, prioritization stops being a workshop exercise and starts being a decision with a face attached to it.
Most roadmaps are prioritized against imaginary scarcity. Mine was prioritized against payroll. It's a different discipline entirely, and it's the one that teaches you what "no" costs.
Partnerships as a distribution channel, not a sales line item
Managing B2B partnerships with schools, sports clubs, and corporate clients was, functionally, a go-to-market motion. Each partner had their own constraints on what they could adopt, when, and at what price, and negotiating those agreements taught me the same lesson enterprise software sales teams learn the hard way: a great curriculum nobody can adopt inside their existing structure is not a great curriculum. It's an unshipped one.
What carried over
When I moved into software product roles, the vocabulary changed. BRDs instead of lesson plans. Sprints instead of terms. Compliance instead of parents. The underlying job didn't: define the outcome, scope it to the person with the least room to spare, iterate against feedback that's honest whether you want it to be or not, and respect a constraint that doesn't care how good your idea is.
If you want to know whether someone has product instincts or just product vocabulary, ask them to design something for a constraint that hits a real budget line and a real kid's attention span in the same afternoon. The vocabulary won't help them. The instincts will.