This is Part 5 of my 7-part series on business literacy for DevRel. Start with Part 1 if you missed it.

We’ve covered sales, marketing, and finance. But there’s one group we haven’t talked about yet - and they might be your most valuable partnership in the entire company: Product.

Not because product managers are inherently better than anyone else (though the good ones are pretty great). But because strategic product leaders sit at the intersection of everything. They see the business from a unique vantage point that can be incredibly valuable to DevRel.

A good product partner is worth their weight in gold. They’re your early warning system, your business intelligence source, and your reality check all rolled into one.

What Product Actually Does

At the most basic level, product management is about figuring out what to build, why to build it, and making sure it actually gets built.

But that simple description hides a ton of complexity:

Product managers (PMs) are responsible for:

• Deciding what features/capabilities to prioritize
• Understanding user needs and market opportunities
• Working with engineering to build the right things
• Collaborating with go-to-market teams (sales, marketing) to position and launch features
• Measuring whether what they built is actually working
• Saying “no” to a lot of things (this is actually most of the job)

Product sits at the center of a bunch of competing pressures:

• Sales wants features that will close deals
• Marketing wants things that will generate buzz
• Engineering wants to build technically interesting things
• Finance wants efficient use of resources
• Customers want their specific problems solved
• Executives want the product to support business strategy

The PM’s job is to synthesize all of this and make decisions about what the product should become.

Meet the Product Team: Roles You Need to Know

Chief Product Officer (CPO) / VP of Product: Sets the overall product vision and strategy. They’re thinking about where the product needs to be in 2-3 years, not just next quarter. They usually report directly to the CEO.

Director of Product / Senior PM: Usually owns a major product area or domain. They’re thinking strategically about their area while managing other PMs.

Product Manager (PM): Owns a specific product or feature area. They work day-to-day with engineering teams to ship features. This is who you’ll probably work with most.

Technical Product Manager (TPM): Like a PM but more technical. Often owns platform, API, or developer-facing products. If you work at a developer tools company, TPMs are your people.

Product Marketing Manager (PMM): We talked about these folks in the marketing post, but they sit between product and marketing. They take what product builds and figure out how to position and message it.

Product Operations / Product Ops: Help PMs be more effective by managing tools, processes, and data. They’re the behind-the-scenes folks making product teams run smoothly.

How Product Thinks About the World

Product managers live in a few key frameworks. Understanding these helps you speak their language:

The Product Roadmap

This is the plan for what gets built when. Roadmaps are usually organized by quarters or releases, and they’re always wrong (because priorities change).

Roadmaps are political documents as much as planning documents. What makes it onto the roadmap and what doesn’t tells you a lot about what the business values.

User Stories and Jobs to Be Done

PMs think about user needs in terms of “user stories” (as a [role], I want to [do something] so that [outcome]) or “jobs to be done” (when [situation], I want to [motivation], so I can [expected outcome]).

This is useful for DevRel because it’s how you can frame developer feedback. Instead of “developers want feature X,” try “when developers are trying to debug production issues, they want observability into what the system is doing, so they can identify root causes faster.”

Prioritization Frameworks

PMs are always prioritizing. Common frameworks:

• RICE: Reach, Impact, Confidence, Effort
• Value vs. Effort: Classic 2x2 matrix
• Kano Model: Basic needs vs. performance needs vs. delighters

Understanding how your product team prioritizes helps you frame feedback effectively.

Success Metrics

Good PMs are all about metrics:

• Activation: Did users do the key action that shows they “get” the product?
• Engagement: Are users coming back? How often?
• Retention: Are users sticking around over time?
• Feature adoption: Are users actually using the new thing we built?
• Time to value: How quickly can users get value from the product?

Notice how some of these overlap with PLG metrics? That’s not an accident.

Why Product Matters So Much to DevRel

Here’s where it gets interesting. Product is uniquely positioned to give you intelligence about the business that you can’t get anywhere else.

They See Across Functions

A strategic PM talks to:

• Sales (what’s blocking deals?)
• Marketing (what’s resonating in the market?)
• Customer success (what are customers struggling with?)
• Engineering (what’s technically feasible?)
• Finance (what can we afford?)
• Executives (what’s the strategy?)

They’re synthesizing information from everywhere. If you have a good relationship with product leadership, they can give you context on what’s really happening across the business that you’d never get from any single function.

They Know What’s Coming

Product knows what’s on the roadmap before it’s public. This is incredibly valuable for DevRel:

• You can prep content in advance
• You can understand strategic direction
• You can give early feedback on how developers will react
• You can plan your activities around major releases

They Need What You Have

As a devrel, you’re sitting on a goldmine of information that product desperately needs:

• What developers are actually struggling with
• What features developers are asking for (and why)
• How developers talk about problems in their own language
• What the competition is doing (you see it at conferences and in communities)
• Which parts of your product confuse people

This creates natural reciprocity. You help them, they help you.

They Fight Similar Battles

Good PMs face the same challenge you do: they have to translate between technical reality and business objectives. They have to advocate for what’s right while acknowledging business constraints.

You’re natural allies.

The Product/DevRel Partnership

When done right, the Product/DevRel partnership is incredibly powerful:

DevRel provides Product:

• Raw, unfiltered user feedback from communities
• Market intelligence from conferences and events
• Early signals about what developers care about
• Reality checks on how features will be received
• Developer perspective on product decisions

Product provides DevRel:

• Early access to roadmap and upcoming features
• Context on why decisions were made
• Understanding of strategic priorities
• Cross-functional intelligence
• Air cover when you need to push back on requests

The Feedback Loop

One of DevRel’s most valuable contributions is being a structured feedback channel from developers to product. But this only works if you do it right:

Bad feedback: “Developers want dark mode”

Good feedback: “I’m seeing consistent requests for dark mode from developers who code at night. The specific pain point is eye strain during long coding sessions. This came up in 15+ community conversations last month, and competitors X and Y both shipped this recently.”

Bad feedback: “This new feature is confusing”

Good feedback: “In office hours, 3 out of 5 developers got stuck at the same step in the new onboarding flow. The confusion is around [specific thing]. Here’s a recording of where they got stuck.”

Strategic product leaders eat this stuff up because it’s specific, actionable, and helps them make better decisions.

Not All PMs Are Created Equal

That said, not every PM is strategic. Some are just feature factories, cranking out roadmap items without understanding the broader context.

A comment that inspired this post mentioned this perfectly: not every product leader can “get their heads out of the sands of features/roadmap, nor are they all observant of business value themselves.”

Look for PMs who:

• Understand the business model, not just the feature list
• Can articulate why something is being built, not just what
• Talk to customers and users regularly
• Have opinions about strategy, not just execution
• Are curious about the market and competition
• Actually understand the technical implications of their decisions

These are the ones worth partnering closely with. The others... well, you can still work with them, but don’t expect the strategic partnership.

How Product Decisions Happen (And Where You Fit In)

Understanding how product decisions get made helps you influence them:

Input gathering: PMs collect input from sales, customers, community, market research, executives, etc.

Prioritization: PMs use frameworks to decide what’s most important

Roadmap planning: Decisions get formalized into “we’re building X in Q2”

Execution: Engineering builds it

Launch: Product goes to market with help from marketing, sales, and (hopefully) DevRel

Measurement: Did it work?

DevRel can influence at almost every stage:

• Input: Share developer feedback
• Prioritization: Provide market context
• Roadmap: React to plans, suggest adjustments
• Execution: Give technical feedback during development
• Launch: Create content, drive awareness
• Measurement: Share qualitative feedback on how it’s landing

But you have to be in the conversation to have influence. Which means building relationships.

The DevRel Seat at the Product Table

Some DevRel teams are deeply integrated with product. Others are completely disconnected. If you’re in the latter camp, here’s how to change that:

Start small: Ask to sit in on a product planning meeting as an observer Provide value first: Share useful feedback before asking for anything Speak their language: Frame things in terms of user problems and business impact Be consistent: Show up regularly with valuable input Don’t be precious: Accept that you won’t always get what you want Understand constraints: Product is making trade-offs; understand what they are

Regular Touchpoints That Work

Consider establishing:

• Monthly sync with product leadership: Share what you’re hearing, get context on roadmap
• Feedback review sessions: Present synthesized developer feedback quarterly
• Early access to betas: Get hands-on with features before launch
• Launch planning collaboration: Work together on go-to-market for major features
• Roadmap input sessions: Provide perspective on upcoming priorities

Product Gives You Business Intelligence

Here’s something nobody talks about: a good product partner can be your best source of business intelligence.

They’ll tell you things like:

• “Sales is really struggling in the enterprise segment right now”
• “We’re shifting strategy toward [market] next year”
• “The exec team is worried about [competitive threat]”
• “Marketing’s campaigns aren’t converting well”
• “There might be budget cuts coming”

Why do they know this? Because they’re in all the meetings. They see the cross-functional dynamics. They hear what’s really going on.

And if they trust you, they’ll share it. This is incredibly valuable for planning your DevRel strategy and seeing what’s coming.

Essential Product Terminology

Let me give you the vocabulary:

MVP (Minimum Viable Product): The smallest version of something that delivers value. Often used as an excuse to ship incomplete things, but the concept is sound.

Product-Market Fit: The magical moment when you’ve built something that a market actually wants. Most products never achieve this.

Feature parity: Having the same features as competitors. Often overvalued by sales, undervalued by product.

Technical debt: The accumulated cost of quick-and-dirty technical decisions. Always more than you think.

Dogfooding: Using your own product internally. Good PMs do this religiously.

Beta / Alpha: Early versions for testing. Alpha is usually internal, beta is usually external but limited.

GA (General Availability): The feature is fully launched and available to everyone.

Sunset / Deprecation: Retiring a feature or product. Always painful, usually necessary.

OKRs (Objectives and Key Results): How many product teams set goals. Objectives are qualitative, key results are measurable.

What This Means For Your Work

Understanding product doesn’t mean becoming a PM. It means:

• You can provide product with valuable, actionable feedback
• You can anticipate what’s coming and plan accordingly
• You can understand why certain decisions are made (even when you disagree)
• You can be a strategic partner instead of just a feedback conduit
• You have access to cross-functional intelligence that helps you navigate the business

Product is your window into how the whole business is working - the headwinds, the tailwinds, the tensions, the priorities. Use it.

Finding Your Product Partner

Not sure who to connect with in product? Start here:

1. Identify the PM who owns your developer-facing products (API, SDK, CLI, etc.)
2. Reach out with value: “Hey, I’m hearing a lot of feedback about [thing]. Want to chat?”
3. Be low-maintenance: Respect their time, be organized, come prepared
4. Look for strategic thinkers: Find the PMs who see the bigger picture
5. Build the relationship over time: This is a long game

And if you find a great product partner? Hold onto them. They’re rare and incredibly valuable.

Next up: we’ll talk about Product-Led Growth and how it changes everything about the relationship between product, DevRel, and go-to-market. Spoiler: in PLG companies, product and DevRel become deeply intertwined.

Questions about working with product? War stories about great (or terrible) product partnerships? Let’s hear them in the comments!

---

Previously: Part 4: Finance 101

Next up: Product-Led Growth