AMA: Salesforce Senior Director of Product, Agentforce AI Platform, Deepak Mukunthu on Developer Product Management

You show impact, not theory. Engineers will value you if you do that.

For example:

• Better onboarding → higher activation → real revenue impact

• Cleaner API design → fewer support tickets

• Prioritization → prevents wasted engineering effort

Framing helps:

“PM isn’t here to tell you what to build, it’s here to make sure we’re building the right thing.”

This is a classic trap.

Engineers are valuable, but they’re not always representative.

Approach:

• Validate with broader user data (not just internal opinions)

• Distinguish between “what I would use” vs “what most users need”

• Use evidence: usage data, customer feedback, support tickets

A useful line:

“You’re an expert user. Most of our users aren’t.”

A huge one, especially for developer products.

Engineers bring:

• Reality on feasibility and complexity

• Strong opinions on design and usability (often valid)

• Insight into long-term maintainability

The best setups are collaborative:

• PM brings user problems + priorities

• Engineering brings how + constraints

• Together, you shape what actually gets built

If PMs ignore engineering input, the product suffers. If engineering drives everything without user validation, it also suffers.

Self-serve is everything. If developers can’t succeed without talking to you, you’ve failed.

Key things that matter:

• Time to first success < 5 minutes

• Clear, copy-pasteable quickstart

• No unnecessary auth/setup friction

• Great error messages (this is underrated)

• Docs that are task-oriented, not feature dumps

• SDKs that feel natural in each language

Also: measure real behavior, where people drop off, not what you think is happening.

Should be technical enough to:

• Understand API design, trade-offs, and constraints

• Read code and reason about systems

• Have meaningful conversations with engineers

But you don’t need to be the best engineer in the room.

What matters more is:

• Product judgment

• Empathy for developers

• Ability to simplify complexity

A few big ones:

• DX as a competitive advantage
  Great APIs aren’t enough, experience wins.

• Shift toward platforms, not just products
  Extensibility and ecosystems matter more than standalone features.

• AI-assisted development
  Changes how APIs, SDKs, and tools are consumed.

• Observability of developer journeys
  Teams now track onboarding, drop-offs, and usage like growth teams.

• Docs as product
  Documentation is no longer an afterthought, it is the interface.

Extremely closely, arguably closer than in most PM roles.

• Internally: daily collaboration with engineers on design and trade-offs

• Externally: constant feedback loops with actual users (Slack, GitHub, forums, customer calls)

For Dev PMs, engineers aren’t just builders, they’re also:

• Proxies for your users

• Early warning systems for bad design

• Co-designers of the product

Following are critical stakeholders that you need to focus on to be effective and successful:

• External developers (most important)

• Engineering teams

• Developer relations / advocacy

• Support & solutions teams

• Business stakeholders (pricing, GTM)

For Dev PMs, external users often matter more than internal stakeholders.