What DevRel Taught Me About Product Management

I spent six years building and leading DevRel at Auth0 and Okta after being a full stack developer, including content, events, ambassadors programs, developer marketing channels, organizational development, and multimillion dollar budget management. Then I got laid off in an unceremonious email at 6 am, and while I was figuring out what to do next, I watched the industry split apart around me. DevRel leaders I knew and respected were sitting unemployed for months, some for over a year. Budgets were tighter, AI was accelerating (and commoditizing) content creation, and the jack-of-all-trades DevRel role was once again fracturing into two tracks: product and marketing.

Part of the problem is structural. DevRel usually sits under marketing, but the work it does is closer to product. Reaching developers is a long-term proposition. You’re building trust, educating, creating awareness, and nurturing adoption over months or years. That kind of impact is hard to capture in a quarterly business review. When an exec asks “what’s the ROI of DevRel?” and the honest answer is “developers are nuanced and the payoff compounds over time,” that doesn’t survive a budget cut. DevRel becomes an easy target because its value is real but hard to prove in black and white terms.

As Swyx once put it, DevRel has always been a “shadow product team.” The question for me was whether to make that official or keep living in the gray area.

I decided to make it official. I joined an AI startup as Director of DevRel, got pulled under the product org a few months in, saw an opening to take on the public API, and worked my way into a Staff PM role. Seven years of DevRel experience turned out to be the best PM training I could have asked for.

Two groups of people tend to read articles like this. The first is DevRel folks who are curious about product management but feel like making the switch means starting over. The second is hiring managers who see DevRel on a resume and mentally file it under “marketing.” This post is for both of you.

My Path

My career looks like a zigzag on paper. After a few years in financial services, I started training financial advisors on trading software at a fintech company that’s also a registered investment advisor platform. Then, I became a software developer building out web applications and APIs for a finance company and a renewable energy nonprofit. I then jumped into DevRel and stayed there for seven years across three companies, going from individual contributor to running a global team. And now I’m a product manager for an AI platform.

The through-line has always been the same, though: sit between the people building the product and the people using the product, and make both sides better. At the fintech company, I was the person the advisors called when the trading software didn’t make sense, and I was the person who walked that feedback back to the product team. As a developer, I sat in architecture discussions arguing about API and UX design and what would actually make sense for the people consuming our services. In DevRel, I had a different title and a travel budget, but I was spending most of my time gathering product feedback, teaching developers about complex topics like authentication or AI engineering, and translating that “developer intelligence” into usable feedback for the company — what I’d later call building a developer motion.

Every role made me better at the next one, even though I couldn’t have predicted any of it.

Making the Move

I joined Writer as Director of Developer Relations in April 2024 to build the function from scratch. A few months in, the company pulled my team under product to handle developer experience ahead of our major AI Studio launch. I was unofficially product managing the SDKs, the documentation, and partner integrations like LangChain to build Developer Experience from 0 to 1. That felt like natural DevRel work, the “shadow product team” in action.

That restructuring put me closer to the product org than many DevRel leaders ever get. I was sitting in product planning meetings, contributing to roadmap discussions, and building relationships with engineering leads who would later become my counterparts. I also hired a Python engineer, developer experience engineer, and developer advocate to grow the function.

While that was happening, I kept watching the industry. More DevRel leaders out of work. The split accelerating. I could see where things were heading everywhere but San Francisco and New York.

When the company needed a PM for the public API, I saw my opening and raised my hand. It wouldn’t have worked if our head of product and CTO hadn’t been willing to give me the shot, but I’d spent months proving I could do the work. I’d shipped the SDK releases and integrations. I’d built the team. The track record was there.

Taking on the API changed everything. Suddenly I was owning the API strategy, making product decisions that affected every developer building on our platform, and carrying the weight of outcomes rather than just influencing them. My scope grew from there. More projects, more teams, more accountability. By the time my title officially changed to Staff Product Manager, I had successfully evolved from a documentation-focused function to a full product management and developer experience organization lead. The title caught up to the work, but the work had been intentional for months.

What Changed

Much of the day-to-day work transition was smooth. I already understood developers, knew how to prioritize, could run cross-functional launches, and thought about the product holistically.

What was genuinely new: the depth of quantitative analysis, owning actual revenue metrics, and the rigor of formal product processes like roadmap reviews, sprint planning that actually determined what shipped, and writing specs from which engineering would build. In DevRel, you influence the product. In PM, you own it. That’s a different weight to carry.

The biggest surprise was social. In marketing and DevRel, you make friends by saying yes. Yes to the partnership, yes to the conference, yes to the customer request, yes to the content idea. You build relationships by being helpful and accommodating. In PM, you’re constantly saying no. Sometimes it’s to a million-dollar customer in favor of a different million-dollar customer. Sometimes it’s to your own engineering team. You have to have conviction about your priorities, back them up with judgment, and be okay with the fact that not everyone is going to like you for it. That was a real adjustment after years of being the person whose whole job was making developers feel heard and supported.

I also had to learn to let go of the DevRel identity. After nearly eight years of building community, writing content, and standing on stages, it’s strange to step back from that. Your identity still says “DevRel” in the hearts and minds of everyone who knows you. After all, I literally wrote a book about getting started in DevRel. That takes time to shift.

What I’d Tell You

If you’re in DevRel and you’re curious about product: you’re not starting over. You’re translating. Many of the skills are already there. What you need is the language, the frameworks, and a company where you can demonstrate PM work before you have the PM title.

My path required some luck. I landed at a company that was willing to restructure, with a head of product and CTO who gave me the shot when the API role opened up. But luck only gets you the opening. I had to recognize it, be strategic about positioning myself for it, and then work extremely hard to make it real. The SDK releases, the partner integrations, the docs and team-building: all of that happened before anyone offered me a PM title. I built the track record so that when the opportunity appeared, saying yes to me was the obvious move. (I wrote more about this approach in re-purposing day job work to make career moves.)

If you’re in a DevRel role right now, start paying attention to where the product gaps are. Write the spec before anyone asks you to. Own a piece of the roadmap and ship against it. Build the track record so that when your opening comes, you’re ready.

If you’re a hiring manager: the best PMs for developer products are the ones who’ve spent years in the trenches with developers. They know what developers actually need, not what a survey says they need. DevRel on a resume is a credential, not a detour.

Skills That Transfer

So what actually carries over? Here are the specific skills I built in DevRel that I use every day as a PM.

Community Listening Is Just User Research

At Auth0, and then at Okta after the acquisition, I managed a developer newsletter that grew to over 100,000 subscribers. That’s a lot of developers telling you things, and not through formal surveys. It shows up in messy, unstructured ways: Discord messages at 11pm, GitHub issues filed in frustration, conference hallway conversations where someone intercepts you and says “hey, can I ask you something about the SDK?”

You learn to hear patterns. Three unrelated developers in the same week mention that the token refresh flow is confusing is a signal, not a coincidence.

Product management calls this “user research” and has formal methodologies around it. DevRel people have been doing it informally for years. The difference is that PMs write it up in a PRD. DevRel people write it up in a Slack message to the engineering team and hope someone reads it.

When I became a PM, I already had the muscle for listening. What I had to learn was the rigor: the frameworks for turning signals into prioritized requirements. The instinct was already there.

Content Strategy Is Product Positioning in Disguise

Every blog post, tutorial, and video I ever made in DevRel forced me to answer the same question: why should a developer care about this? That’s positioning. You just don’t realize it when you’re doing it because you’re too busy fighting with screen recording software and remembering what you need to say on camera.

At Okta, when I was running developer channels, content strategy was the job. I owned the developer newsletter reaching 100,000+ developers, oversaw the social media and video strategy, and connected dots from those to the community content tactics. Every piece of content was a positioning decision: what do we want developers to understand about our product, and how do we get them from “I’ve heard of this” to “I’m building with this”? That’s the same question a PM answers when writing a product brief or planning a launch narrative. The format is different but the thinking is identical.

Writing a quickstart guide is an exercise in understanding your product’s time-to-value. If you can’t get a developer from zero to “wow, this works” in under five minutes, you have a product problem much more than a content problem. I learned that lesson over and over again, and it shaped how I think about product design now.

At Writer, when I was still technically running DevRel, I shipped our SDK 2.0, the largest release to date, adding application retrieval, async jobs, knowledge graph integration, and model delegation. The act of writing the docs and launch article, of having to explain the new API surface and walk developers through adopting all those new capabilities, forced me to think like a product manager months before anyone called me one.

Event-Driven Launches Prepare You for Product Launches

There’s a particular kind of stress that comes from knowing your product has to work live, in front of people, right now.

At Okta, I was once responsible for writing a developer keynote for our beloved principal architect Vittorio Bertocci (riposi in pace). The presentation needed a working demo of passkeys support, and the passkeys feature wasn’t originally scheduled to be done in time. Vittorio and I worked with the engineering team to get a working beta ready for the keynote deadline. Everyone joked about “event-driven development,” but it worked. The deadline pushed the passkeys team to ship, the keynote went great, and the feature launched shortly after.

That’s DevRel at its most product-adjacent. You’re coordinating across engineering, product, and executive stakeholders around an immovable deadline with external visibility. The audience doesn’t care about your internal sprint schedule. They care that the demo works.

Product launches are the same thing, just with more stakeholders and less audience applause. When we shipped support for Bedrock models and guardrails for AWS re:Invent at Writer, it was an overnight coordination effort with a team spanning time zones, hitting a CEO keynote deadline that could not slip. I’d done versions of that coordination dozens of times in DevRel. The stakes were higher, but the muscle memory was the same.

Developer Empathy Becomes User Empathy

DevRel teaches you to think about developers as real people with limited patience and strong opinions, not as abstract “users” in a persona document. You learn that developers don’t read documentation linearly. You learn that error messages matter more than feature announcements. You learn that the gap between “technically possible” and “practically usable” is where products go to die.

When I started doing API deprecation strategy, I was researching 90 days of endpoint usage data, figuring out which endpoints could be safely retired, and then communicating those deprecations to developers who depended on them. I was doing PM work informed by years of being the person who had to explain breaking changes to angry developers. That changes how you deprecate things. You learn to lead with empathy, not with a changelog.

Feedback Synthesis Becomes Requirements Gathering

In DevRel, feedback comes at you from every direction and in every format: a frustrated tweet, a detailed GitHub issue, a casual mention at a meetup, a support ticket forwarded from the sales team. Your job is to take all of that noise and turn it into something actionable.

At Auth0, we released an Angular SDK that was full of antipatterns. It worked, technically, but it didn’t follow Angular conventions and experienced Angular developers could tell immediately. The feedback started showing up everywhere: GitHub issues, conference conversations, community threads, direct messages to me and my colleagues on the DevRel team. None of it came through a formal channel. None of it was neatly categorized. It was dozens of individual complaints that all pointed at the same underlying problem.

We gathered that feedback, synthesized it into a clear picture of what was wrong and what best practices the SDK should follow, and worked with the SDK engineering team to ship a new version that actually aligned with how Angular developers expected things to work. That’s requirements gathering. We just didn’t call it that.

PMs do exactly the same thing, except they put it in Jira. The skill is identical: pattern recognition across unstructured inputs, combined with enough technical depth to know what’s feasible and enough business context to know what matters.

Cross-Functional Team Building Becomes Stakeholder Management

Running a DevRel team means you work with everyone: engineering, marketing, sales, product, support, partnerships. You’re the person who sits in the middle of the Venn diagram and tries to make everyone’s goals overlap. I managed global teams, worked with partner companies on co-marketing campaigns, and aligned with engineering and product marketing on release schedules to guide our developer launches, all at the same time.

When I hear that product management requires “stakeholder management,” I can’t help but chuckle. That’s just DevRel without the booth setup.

What’s Next

I know this is a really hard time in the industry. The job market is brutal, especially for people in DevRel and adjacent roles. I’ve been there. I spent time after my layoff figuring out what was next, watching the field shift under my feet while I was trying to land somewhere. My path worked out, but I know it’s more complicated than any one person’s story can capture. If you’re considering a pivot into product, I hope the skills mapping and the honest look at what changed are useful starting points. Everyone’s situation is different, but the skills you’ve built in DevRel are real and they transfer.

Next up, I’m going to dig into the developer empathy advantage: why PMs who came from DevRel think differently about developer products, and how to make that background work for you instead of explaining it away. If you’ve ever felt like your DevRel experience was a detour rather than a credential, that one’s for you.

Have you made a similar jump, from DevRel or from any “non-traditional” background into product? I’d love to hear how it went.

Also: if you’re curious what my day-to-day PM workflow looks like now, read How I Automated the Worst Part of Product Management.