A recruiter asked me last month what I'd been building since HiveNet. Not what I'd been thinking about. What I'd been building.
I rattled off the list: multi-tenant platform, 26 shared packages, ActivityPub federation, a content pipeline that compiles from D1 to KV at the edge, a community website for my neighbourhood in Dublin running on the same infrastructure as the commercial product. Nine hundred commits and change.
She paused. "So you've been doing engineering work?"
No. I've been doing product work. I just happen to also be the one typing the code.
The argument everyone keeps having
PM Twitter rehashes this every few months: should PMs code? The consensus lands somewhere around "no, but it helps to be technical." Fair enough if you're embedded in a full team with engineers and designers and a product org above you. That setup has a wall you can throw specs over, and people on the other side who catch them.
A lot of product work doesn't look like that. Early-stage, platform, internal tools, solo founder. The feedback loop between "what should we build" and "what happens when we try" runs in hours, not sprints. There's no wall. There's you and the consequences.
When I left HiveNet, I could've waited for something that matched my CV line by line. Instead I started building. I wanted to come out the other side as a better PM, not just a more rested one.
What I actually learned
The code itself doesn't matter. What matters is the chain of judgement calls the code wrings out of you — calls a PRD would've either dodged or gotten wrong.
BulkheadOS runs multiple brands on shared infrastructure: a community site, a personal site, a task management product. Early on I tried sharing UI components directly across tenants. A CSS change for one brand broke another. I kept trying to fix it as a technical problem until I realised it wasn't one. It was a product boundary problem. Tenants needed to be weightless shells: config, brand CSS, content, nothing else. All shared logic lives in packages. I called it the Anti-Gravity principle. No planning document I could've written upfront would've told me where that boundary needed to sit. I had to hit the coupling to find it.
Something similar happened with language. I built a content engine where data moves from D1 (source of truth) to KV (read cache). The word "compile" showed up in my code months before it appeared in any document. Once I started saying "content is compiled" instead of "content is synced" or "content is cached," the whole mental model sharpened. That's ubiquitous language in practice, except I didn't find it in a DDD workshop. I found it in a function signature.
The platform has 22 architecture decision records. I didn't write those out of some love for process. I wrote them because my ADHD brain will absolutely revisit a settled decision three weeks later, convinced it never made the call. ADR-019 exists because I shipped a modal that rendered outside the theme boundary and broke every tenant's brand colours. That failure became a rule, the rule became a document, and now the mistake can't repeat itself. From the outside it looks like engineering hygiene. From the inside it's product work — preventing an entire class of future wrong turns.
I also have 21 operational gotchas logged in the platform's memory. Every one came from running the system, not from planning it. The worst: deleting one specific config file causes every SSR route to silently return 404. No error. No warning. Blank page. You lose an hour, you document it, you move on. No amount of upfront thinking would've caught it.
Where I waste my own time
I should be honest about the other half of this.
I will spend three hours tuning a CSS animation that maybe twelve people will ever notice. The building feels productive. The product work is somewhere else entirely, and knowing that in theory doesn't stop me from doing it in practice. I once spent an entire Saturday getting a scroll-triggered fade to land exactly right on a page that gets about forty visits a month. My girlfriend asked what I'd accomplished and I genuinely struggled to answer.
Building also doesn't teach you market positioning, pricing, or distribution. Those need different muscles — conversations, competitive analysis, actual customers — and I don't get enough of those inputs when I'm heads-down in an editor. The risk is that you wander into the engineering for its own sake and convince yourself it's strategy. I catch myself doing it. I haven't fully solved it.
The gap
Every senior PM between roles gets the same unspoken question: what were you doing?
Most people answer with some mix of interviewing, consulting, and thinking. Fine answers. Hard to show receipts for.
What I can point at is a production system. A platform that serves real users, federates with the Fediverse, and runs five domains on one Cloudflare Worker at zero marginal compute cost. I applied RICE with a domain pass, signal scoring, and KCS documentation practice against real constraints, not hypothetical ones. The frameworks behaved differently under pressure than they did on paper. Discovering that gap is the whole reason to build.
The gap on my CV isn't empty. It's the most concentrated product work I've done, because nobody sat between me and the consequences of getting it wrong.
The collapsed loop
Product teams talk about build-measure-learn. In a full org, different people own each stage. PM writes the brief, engineering builds the thing, analytics measures what happened, everyone argues about what it meant. The cycle takes weeks.
When you're the builder, it collapses into an afternoon. Hypothesis, prototype, real behaviour, adjustment. You can't lie to yourself about the state of the product because you tried to use it ten minutes ago.
I wouldn't tell anyone to work like this permanently. It doesn't scale and the bus factor is one. But as a way to learn a domain deeply and come out with a credible body of work? I haven't found anything quicker.
Want to talk about builder-PM careers or how BulkheadOS works? Get in touch.
