What 10 Years in Technical Content Taught Me About Product Management

I spent nearly a decade commissioning and managing technical publications — books on machine learning, cloud infrastructure, data engineering — before moving into product management full-time. When I made the transition, people assumed it was a leap. It wasn't. It was a translation.

The skills I'd built in technical publishing turned out to be core PM competencies in disguise. It just took me a while to see them that way — and to articulate them that way to hiring managers.

Market research is market research

Commissioning a technical book requires understanding what developers will want to learn in 12–18 months — not today. You're betting on a technology trend, a skill gap, an emerging paradigm. You talk to practitioners, read conference schedules, track GitHub repositories, study what's being searched but not yet taught. You build a thesis, commission the work, and find out 18 months later whether you were right.

That's product discovery. The output is different — a book instead of a feature — but the intellectual process is identical. I made early calls on LLVM, Kubernetes, and ML tooling. Most held. A few didn't. Both kinds taught me something.

Managing authors taught me stakeholder management

Authors are brilliant, opinionated, busy people who have agreed to do something extremely hard — write a technical book — on top of their existing jobs. Getting a manuscript from contract to publication, on time, at quality, requires the same skills as getting an engineering team to ship: clear requirements, realistic timelines, early identification of blockers, honest conversations when things go sideways.

The difference is that authors have even less formal accountability than engineers. There's no sprint planning, no standup, no Jira ticket. You're managing entirely through influence. That turns out to be excellent training for product management, where formal authority is also largely absent.

Deciding what not to publish

The hardest part of commissioning isn't saying yes. It's saying no — to a well-written proposal, from a credible author, on a technically legitimate topic — because the market timing is wrong, or the differentiation isn't there, or you already have three books in that space.

I turned down a proposal on a now-mainstream framework because I misjudged how fast the community would grow. That one still stings. But the discipline of making explicit bets and being honest when they don't land transferred directly into how I run roadmap reviews today.

What I'd tell anyone making a similar transition

If you're coming from a non-traditional PM background — technical writing, editorial, research, consulting — the skills you have are more transferable than the job market's pattern-matching would suggest. The challenge is translation, not acquisition.

Don't describe what you did. Describe what problem you were solving, what constraints you were operating under, what decisions you made, and what happened as a result. That's the language of product management. Once you learn to speak it, the experience underneath starts to look a lot more relevant than it did before.