Every role I've held was product management wearing a different badge. I just didn't have the vocabulary yet.
As a founder, I did discovery in the dining room, roadmaps on the whiteboard, pricing with my own margin at stake, and delivery every single day at 9pm. As a data scientist, I kept drifting from building the model to interrogating the brief: why this, for whom, and what changes if it works? The drift wasn't a lack of focus. It was the actual job announcing itself.
At Riedel, the announcement became explicit. Nobody assigned me the product role; the work kept requiring one, and I kept being the person who did it. Use case collection across departments. Business cases and PRDs. Architecture calls made with engineers rather than downstream of them. Epics, user stories, delivery. Governance as part of the build. Adoption measured as the finish line. Fifteen-plus products later, the pattern is not ambiguous.
What I bring to the role is the combination behind that pattern. The founder years mean I write business cases like the money is mine, because it used to be. The data science training means engineers can't hand-wave estimates past me, and I don't hand-wave theirs to leadership. The enterprise AI years mean I treat trust, privacy, explainability, governance as product surfaces, not compliance chores, which in the European market is the difference between products that ship and demos that don't.
So the move to a Technical Product Manager title isn't a pivot. It's a correction: the first time the label will match the job I've been doing across two companies of my own and one global enterprise. The seam between the business and the build is where I've always worked. Now I'm just naming it.