Collaborating with Developer Relations Part 3: Product and DevRel

• 

  Patrick WoodsCo-Founder & CEO
  Orbit

In part three of our series, we dig into opportunities for product and DevRel teams to work together. Check out Part 1 :DevRel and marketing and Part 2: DevRel and sales to learn about more collaborations.

Of the various teams within a company, DevRel and product may have the most in common. Both tend to have a shared sense of customer pain points, a deep understanding of the product, and a desire to solve real business problems. Both teams are often composed of current or former engineers who are expanding their skills beyond the code.

Yet, while DevRel teams represent the product in the field, both on stage and in conversations with developers, product teams tend to understand and shape more of the internal machinery required to bring the product to market.

This distinction informs the perspective of both teams and provides context for the many ways product and DevRel teams can work together to impact the company and community.

Collecting User Feedback

The first opportunity for collaboration revolves around collecting feedback from customers in the field and delivering it back to the product team at HQ. While product teams already engage in some form of customer input, DevRels receive the raw and unfiltered opinions of developers in the real world at high velocities in places like events, hackathons, and workshops.

As a result, DevRels have a visceral sense of what matters to developers and what doesn’t, and how product choices impact developers with different profiles. They can discern the beliefs and opinions of the community, and uncover ideas that might not surface in formal customer interviews led by the product team.

In action: DevRel teams should share a feedback report to the product team each time they come in from the field. The report should include information about key conversations that they had, covering both the feedback given and the profile of the developer they spoke with.

Community Involvement

As the company grows, it’s important that DevRel not become the sole source of field-level developer insights or a bottleneck of important information. To help scale up the developer feedback process, DevRel teams should help product teams connect with the community online and offline.

DevRel can help Product discover important conversations on Twitter, engage with customers in community Slack groups, and reply to product-related questions on the company forum. Additionally, DevRel should invite the product team to meetups and events where they can immerse themselves in the developer perspective firsthand.

The goal is for DevRel to empower the product team to drive their own developer discovery process, and become comfortable and confident members of the community in the process.

In action: DevRel should ask for volunteers from the product team to speak at company-hosted meetups. Full-length talks work, but so do quick updates about where the product is headed. This is always a topic of huge interest to the community.

Product Roadmap

DevRels are often the first people to know if a new release or product roadmap decision has struck a chord with the community, or not been received as well as hoped. They receive feedback from developers quickly, and if product decisions adversely affect the community, that feedback can be harsh.

If the DevRel team is kept aware of product roadmap and releases, they will be better prepared to set the narrative and answer any questions or complaints that come in. Product should take advantage of DevRel’s public relations role here. The better the DevRel team knows what’s coming, especially as it affects free & self-service plan users, the more successful they can help a launch be.

In action: Schedule a monthly DevRel and Product sync and make time to discuss the roadmap. Encourage DevRels to share roadmap requests they’ve gotten in the field.

Pricing and Self-Service Plans

Pricing changes represent important and delicate transitions in the development of a product.

As with roadmap decisions, the DevRel team feels the impact of pricing changes more swiftly than others in the organization, but that also means DevRel can provide meaningful input into pricing discussions.

There are several risks associated with implementing pricing changes without input from the community. First, independent of that input, product teams can lose sight of what developers can actually build within the constraints of various pricing tiers. A free tier is useless if devs can’t actually make anything meaningful, given volume limits, feature gates or other constraints. Without substantial, real-world projects built on the free tier, there will be a lack of developers engaging in the external advocacy essential to driving future growth.

Surprising developers can also adversely impact the brand. Developer trust is hard to earn and easy to lose, and few things violate that trust more severely than unpredictable or unfriendly pricing changes.

Without influence from DevRel and input from developers, product decisions in a growing company may end up focusing only on the needs of large customers. Executives need to hear regularly from the DevRel team about the success stories in the community, so that their product and pricing decisions continue to serve the developer segment well.

In action: DevRel should be the owner or a key stakeholder of the free plan and sign off on changes to pricing, volume, or features. DevRel should survey developers quarterly to determine if the free plan is meeting their needs and monitor the quality of free plan projects created to see if they are sending the right signal about your product’s capabilities.

Product Usage Data

At Orbit, we believe that data improves developer experience. In our post about the collaboration between DevRel and marketing, we discussed ways for marketers to train the DevRel team on their tools for gathering and analyzing marketing data. Similarly, product teams collect and analyze data covering SDK usage, activation rates, adoption of certain APIs and features and a lot more. Product should make sure that the DevRel team knows what product data is available and how to access it.

The DevRel team can use this data to be more targeted and efficient. For example, if 90% of product usage comes from the PHP SDK, the DevRel team may choose to ramp up PHP-focused outreach and sponsorships.

In action: Set aside time in the DevRel and Product monthly sync to share and discuss data. Give DevRel team members access to the product analytics platform so they can do their own research.

Collaborating to Build Projects

As both share a builder’s mindset, product and DevRel can collaborate to create projects that showcase the power of the platform or add value on top.
One real-world example is how the search feature of Algolia’s documentation came to include search results from the community forum. Algolia is an API for search, so it was very important to us that our documentation search worked really well. But we also wanted to take the experience a step further and index conversations from the community forum. Now when developers search the documentation, they get results from both, without having to search in two different places.

This usage of community data to enrich the product was made possible through a collaboration between Algolia’s product, engineering and DevRel teams. Algolia’s DocSearch is another collaboration that combined product and community thinking to create more awareness for Algolia in the open source community.

Other projects like TwilioQuest illustrate how insights from hosting workshops can lead directly to a product-like investment in developer education. In the case of TwilioQuest, the observation from the workshop giver, Kevin Whinnery, was that the Powerpoint-driven training sessions weren’t very engaging, but an immersive adventure for learning the platform could work better instead.

Product and DevRel: Working Together to Build Customer Insights

DevRel and product teams both aim to understand the customer perspective at a deep level. DevRel’s perspective comes from a high number of raw conversations and observations in the field with mostly free and self-service plan users. Product’s perspective tends to come from more structured user research and interviews of paying customers.

Together, the customer insights of both of these teams together is stronger than either team alone. It’s important that recurring time is set up between the teams to share what they’re planning and learning.

As we’ve seen throughout this series, DevRel teams can act as a force multiplier for other teams across a company by adding more developer perspective to their efforts. This effect is strongest with marketing, sales, and product but also happens with other teams like customer success and HR.

When the developer perspective permeates the whole of a developer-focused or developer-serving organization, marketing becomes more confident, sales more effective, and product more informed. A well-integrated developer relations team helps make this happen and the effectiveness of their own efforts is increased in the process.

If you enjoyed this series on Collaborating with Developer Relations from Orbit, be sure to check out other devrel content in the Heavybit Library.