What Does a
Dev-First PMM Do?
The job title is the same as any PMM. The work is different. A practitioner walks through the four workstreams, the artifacts that actually ship, the metrics that matter, and what should not be on the plate.
By Daria Dovzhikova · Updated May 2026
TL;DR
- Four workstreams: positioning, launches, competitive intel, sales enablement. Each one needs technical credibility, not just craft.
- The PMM owns the customer-research loop and the docs-as-marketing surface. Without those two, the role drifts into generic content management.
- Things that should not be on the plate: demand-gen execution, paid media ops, MQL chasing, gated webinar production. Different function, different person.
The shape of the role
A developer-first product marketing manager is a senior strategy-and-execution role at the intersection of product, engineering, sales, and the developer audience. The title is identical to PMM at a generic B2B SaaS company. The job is meaningfully different because the buyer evaluates hands-on, the proof is technical, and the channels reward credibility over reach.
The role attracts a particular kind of generalist: comfortable with code at the reading level, comfortable with sales conversations, comfortable with executive strategy debates, comfortable shipping written work that the engineering team will fact-check before it goes live. None of those skills alone is unusual; the combination is.
For a deeper definition of what makes the role developer-first, see developer-first PMM — the longer reference covers the principles. This page covers the day-to-day.
The four workstreams
Most weeks the PMM is making progress on all four in parallel. Different weeks the weight shifts. A launch month skews to workstream two; a strategic-replan quarter skews to one. The plate is genuinely full; this is why pretending PMM and DevRel are the same role usually breaks.
Positioning & messaging
Customer interviews, positioning statement, hero copy, key messages, sales talk track. This is the foundational workstream that every other workstream depends on. The PMM owns the customer-research loop end to end and refreshes positioning on market, product, or motion shifts.
Product launches
Multi-week launch plans that ship with a technical artifact: docs landing, working code sample, blog post that survives a Hacker News audit, sales enablement materials. Co-owned with engineering on the technical claims and DevRel on the community surface. Not co-owned with PR.
Competitive intel
Tracking OSS alternatives, adjacent ecosystems, and direct vendor competitors. Producing teardown documents, battle cards, and competitive talk tracks. Updating the docs and marketing site whenever a competitor moves. This work compounds — the team that does it well for two years builds a near-unfair sales advantage.
Sales enablement
Discovery question scripts, technical demo paths, objection-handling docs, ROI frameworks that hold up under engineering review. The PMM equips the sales team to have a conversation that a developer respects. Without this, sales reverts to feature listing, which loses to a competitor whose PMM did the work.
A representative week
Monday: review the customer interviews from the previous week, code the transcripts for the positioning refresh. Two interviews on the calendar for Thursday.
Tuesday: sit with engineering on the launch coming in five weeks. Walk through the API surface, identify the two unique attributes, draft the working code sample. Push back on the demo path that requires a tutorial; ask for one that ships value in under three minutes.
Wednesday: competitive intel half-day. A competitor shipped a new tier; tear down the pricing page, update the battle card, send a brief to the sales team. Update the comparison page on the marketing site if the move is meaningful.
Thursday: two customer interviews. Lunch with the head of sales to walk through the new objection coming up in deals — does the messaging need to change, or does the sales talk track. Afternoon writing the docs landing rewrite that has been in draft for two weeks.
Friday: founder sync. Write the weekly update — what shipped, what is blocked, what changed in the customer-research findings, what is coming next week. End of day, queue the launch content for the following week.
That week does not include any campaign-execution work, any MQL hunting, or any webinar production. Those are different functions. Lenny Rachitsky has interviewed several DevTools PMM leaders on this beat; his newsletter archive is one of the most useful current references on the operating cadence.
The metrics that matter
Four numbers a developer-first PMM should be able to answer for at any moment, with the underlying instrumentation in place.
Activation rate. The share of self-serve signups who hit the first-value moment within the first session. Healthy range 25-40% for most DevTools categories. If this number is moving down, positioning and onboarding are the first places to look.
Win rate vs the named alternative. The competitive-intel workstream produces this number. If the team is losing to the OSS alternative more often than two quarters ago, that is a positioning problem or a proof problem, not a sales problem.
Time from self-serve signup to first sales conversation. The PLG-to-sales handoff metric. If this is too short, the free tier is starving sales of activated accounts; if it is too long, the team is letting accounts go cold. Both signal a broken expansion loop.
Share of voice in the relevant community.Unprompted organic mentions in the category's primary forum (Hacker News, the relevant subreddit, the category Slack). This is the slow-moving leading indicator on whether the brand is earning presence. The PMM is not the only owner; they are accountable for the trend.
For a longer treatment of how to instrument and report against these, see the case studies — the worked engagements show how the metrics move under actual fractional and full-time PMM motion.
The author
Daria Dovzhikova is a fractional PMM with 12 years inside developer-first companies, including 7 years at JetBrains and senior roles at Lightrun and Odigos. She has run developer-first PMM at every stage from seed to growth, including positioning resets, product launches, and competitive teardowns against OSS alternatives. More on the about page or in the case studies.
FAQ
Is developer-first PMM a real specialization or just regular PMM?
Real specialization. The job title is the same; the artifacts, channels, and proof types are different enough that a senior enterprise PMM dropped into a DevTools company without prior developer-audience reps usually underperforms for the first 12 months. The reps that matter: shipping technical content the audience actually reads, running positioning research on a developer ICP, working with engineering on docs IA, owning launches that include code samples instead of webinars.
Who does a developer-first PMM partner with day to day?
Engineering on docs, technical content, and launch artifacts. DevRel on community presence and content distribution. Sales on competitive intel and battle cards. Product on roadmap input from the customer-research loop. Marketing operations on the activation funnel. The PMM is in the middle of all of those conversations, which is why the role attracts generalist-shaped seniors who can hold the technical conversation without flinching.
What is the difference between developer-first PMM and DevRel?
DevRel is community-facing: tutorials, conference talks, sample apps, Discord presence, ecosystem partnerships. PMM is strategy-facing: positioning, launches, competitive intel, sales enablement, pricing. The two roles overlap on content production and brand voice. The cleanest split is that DevRel is the externalization of the technical story, PMM is the internalization. Both functions are needed; conflating them is the most common DevTools org-design mistake.
What does a developer-first PMM not do?
Demand-gen campaign execution, paid media operations, MQL chasing for the sales team, gated webinar production, sponsorship logistics, and most events marketing. Those are valid functions; they are not what a senior developer-first PMM should be optimizing for. When a fractional or new hire is being routed to those workstreams, the role is being misused.
What is a reasonable team size around a developer-first PMM?
At seed stage, the PMM is often a team of one with founder partnership on positioning and technical content. At Series A, the team expands to PMM + DevRel + technical writer. At Series B, add a product marketer per major product line and a content/SEO operator. Headcount expands faster than most founders expect because each new workstream (competitive intel, sales enablement, launches) is genuine work, not overhead.
Looking for one of these?
12 years of developer-first PMM.
Fractional engagements covering all four workstreams. See past work in the case studies, or scope a 20-minute intro call.
See case studiesReady when you are.
Discovery calls are 20 minutes. First one's on me.