Developer Experience for Partners & Customers: Trends and Best Practices

In this discussion, Kelly Sarabyn interviews Sid Maestre, Director of Developer Relations and Advocacy at Lob, about building and scaling developer relations programs that support both customer and partner ecosystems. Sid draws on a decade of experience across PayPal, Xero, and Lob to share practical strategies for prioritizing developer experience, collecting feedback, and making the case for developer relations investment.

Understanding Partner Developer Experience vs. Customer Developer Experience

Sid frames partners as a special kind of developer, but notes that the relationship dynamics differ significantly from traditional developer evangelism. While both require strong documentation and smooth API onboarding, partner decision-makers often include business development professionals and founders who prioritize ROI and business justification before committing engineering resources.

Partners want to understand what your partner program is about, the benefits, and what they have to do to become a partner. They definitely do their due diligence before they start building.

This means successful partner relations require both technical excellence and direct relationship management, with dedicated touchpoints for business stakeholders alongside developer support.

Core Priorities for Starting a Developer Relations Program

For organizations launching developer relations functions, Sid emphasizes starting with foundational elements before scaling:

• Documentation as the top priority: Developers consistently rank documentation as their number-one need. Quality documentation means clear presentation, easy navigation, up-to-date content, and accuracy. Nothing frustrates developers more than outdated information that wastes their time.
• Frictionless API access: Remove barriers to experimentation by simplifying the process to get API keys. Avoid requiring credit cards or lengthy approval processes, which slow adoption and create poor first impressions.
• Thoughtful partner journey design: Create clear pathways for potential partners to enter your ecosystem. A poorly managed partnership inquiry process that disappears into a black hole sabotages relationships before they begin.

Rome wasn't built in a day. Those are some good places to start.

Building API Specifications and SDKs at Scale

Sid shares lessons learned at Xero about managing multiple SDKs across languages. Early on, the platform team stated their API support ended at the endpoint, lacking bandwidth to maintain SDKs. However, as the company grew and financial institutions began integrating, the need for official, supported libraries became clear.

The solution involved creating API specifications using OpenAPI standards, which automated SDK generation across multiple languages. When the API changed, updates rolled through to all supported libraries simultaneously. This single source of truth approach also enabled the documentation team to build interactive API explorers from the specification.

If you're trying to pull multiple pieces of data from different places, and you don't want the developer to have to make a series of a dozen API calls to collect their data, you can construct those queries. GraphQL is a great solution for that.

Sid acknowledges that while REST remains the standard, companies should explore webhooks and event-driven architectures for use cases where developers shouldn't need to poll constantly for data.

Collecting Qualitative and Quantitative Developer Feedback

Developer feedback comes from multiple channels, each valuable but biased toward different perspectives:

Qualitative approaches:

• Engaging directly with vocal developers, especially on social media, often leads to productive conversations once initial frustration is vented
• Developer forums where community members answer each other's questions and surface common pain points
• In-person events like road shows and roundtables, where developers feed off each other's ideas and co-create solutions
• Feedback voting tools where developers prioritize desired features

Quantitative approaches:

• Analyzing API logs to surface 400 and 500 error codes that indicate technical problems
• Tracking patterns in bulk creation, pagination needs, and rate limit issues
• Monitoring how developers move through integration stages to identify bottlenecks in the partner onboarding process
• Examining time spent at each stage to optimize velocity and qualification

Looking at API logs and talking through code with developers helped them discover they had a bug—moving one API call outside a loop solved their problem entirely.

North Star Metrics and KPIs for Developer Relations

KPIs should evolve as the program matures. Early-stage programs focus on recruitment and quality onboarding. As the function scales, metrics should track:

• Partner progression velocity: How quickly partners move from inquiry through launch stages and where they get stuck
• Stage-specific duration: Average time spent at each onboarding phase to identify optimization opportunities
• Partner success outcomes: Numbers of launched integrations, marketplace placements, and long-term engagement

Tracking where partners stall in the journey reveals whether process hurdles are too high or if support gaps exist.

Making the Business Case for Developer Relations Investment

Sid identifies the fundamental challenge: developer relations doesn't have a direct line to revenue, making it vulnerable to budget cuts when leadership priorities shift.

Effective arguments for investment connect to business outcomes leaders already care about:

Your product is actually part of a world of products, and no customer wants their data sitting in a silo where they're not able to share it with other apps they use on a daily basis.

Key talking points include that small business customers use an average of 18 different applications, and at Xero, customers who connected two or more apps saw a significant drop in churn. When presented as a lifetime value driver rather than a cost center, the investment case becomes stronger.

For programs that already exist but lack executive support, Sid recommends prompting leaders to revisit the original business case rather than defensively justifying the function:

Get them thinking about why we decided to go in this direction. Inquire if the strategy changed, and if this function is not a priority anymore.

Key Takeaways for Developer Relations Programs

• Start with documentation quality and frictionless API access before scaling advanced features
• Invest in API specifications to automate SDK maintenance across multiple languages and reduce support complexity
• Collect both quantitative API usage data and qualitative developer feedback through multiple channels
• Track partner progression velocity and identify stage-specific bottlenecks to optimize onboarding
• Ground the business case for developer relations in customer lifetime value and retention metrics rather than abstract advocacy benefits
• Partner decisions involve business stakeholders as well as developers, requiring both technical excellence and relationship management
• Communities require ongoing investment and ownership to avoid becoming ghost towns

‍

--

This podcast is hosted by Pandium, the only embedded integration platform that facilitates faster code-first development of integrations, allowing B2B SaaS companies to launch integrations at scale without sacrificing customization and control.

Learn more about Pandium here: https://www.pandium.com/

To access more resources and content on technology partnerships, integrations, and APIs, check out our blog and resources page below.

Blog: https://www.pandium.com/blog

Resources on Technology Partnerships, Integrations, and APIs: https://www.pandium.com/ebooks