Product Owner with technical judgment.
I defined, built and maintained a platform now used by around 200 students and teachers to form some 30 project teams a year. I write code, so when I say something isn't worth building, I know what I'm turning down.
The evidence
- ~200
- usersplatform in production across 2 academic years
- ~300
- project ideasprocessed end to end
- ~30
- projects a yearacross two years of a technical program
- 0
- prior experiencedefining product when I started
That last one isn't a joke. It's there because it's the question you'll have after reading the first three.
TIC Platform
Ideation and team formation for a technical high-school course ran on a shared sticky-note board with no roles and no permissions. Students posted ideas, teachers color-coded them to approve, and project applications went into the comments. One teacher transcribed all of it into Excel by hand. Students recolored rejected ideas to get them through, and sometimes it worked: the teacher who rejected an idea wasn't the one who later formed the teams.
I built the platform that replaced it. It started as a proof of concept for a narrow question — if I code it myself, how far do I get quickly? — and grew term by term until it covered the whole process.
The decision that defines the product is one I turned down. I was asked to have the platform assemble teams automatically by matching applications to projects. I didn't build it: the real criteria are implicit, a teacher knows which profiles won't work together, and that lives in no form field. Every name assigned to a team decides where that person spends the next several months. It has to be an intentional click.
Read the full case(decisions, build vs. buy, what didn't work)
How I work
I talk to developers as a peer, not as a middleman.
I write code. When I estimate, I know whether the number makes sense. When I define a requirement, I know which of the three ways to solve it will cost triple. Your team won't have to translate anything for me.
Ten years teaching.
A teacher's daily work is carrying a vision, holding it in front of people who don't share it yet, and explaining the why behind the what. It's the core competency of the role, and almost no one coming from the technical track brings it.
I'd rather have a well-reasoned "no" than a long backlog.
The case above is largely an inventory of what I decided not to build: automated matching, public applications, AI-assisted idea writing. It's the least visible part of the job and the one that most determines the outcome.
Other projects
HT Lab
Analysis tool for Hattrick managers, built under a CHPP license approved by the game. Lineup optimization, season result estimation and stadium planning. Node/Express, PostgreSQL.
Color palette generator
Palette generation and management with six types of color harmony. Astro, Supabase, Vercel.
Where I stand
I don't come from a formal Product Owner role in industry. I come from having had to decide what to build, build it, and keep it running with real users for two years, with no team and no budget.
If your team needs someone who already knows how things are done at your company, that's not me. If it needs someone who can decide what's worth building and argue it as an equal with the people who'll build it, let's talk.
If you got here from a message of mine, reply to it and we'll pick it up there.
Twenty minutes, no CV and no process in between. If you'd rather, tell me where your product is right now and I'll tell you what I'd do with it.