DevRel Scribbles
  • What are Scribbles?
  • Index
  • Developer Advocacy
  • Developer Advocates
  • Life as a developer advocate
  • Modernising Red Hat’s enterprise developer program
  • Engaging 9-year-old software developers
  • Making 22-year-olds love 26-year-old software
  • Dogfooding developer products: gathering insights from internal hackathons
  • How far does your ethical responsibility stretch for the tech your devs create?
  • Outside the lecture theatre
  • How do you design programs for diversity?
  • Build the Platform Your Developers Actually Want
  • Measuring dev rel programs far beyond marketing activities
  • Developer Evangelism
    • Developer Evangelists
    • How to rock a technical keynote
    • The Art of Slide Design
    • The Art of Talk Design
    • The Art of Story Design
    • Dev events beyond 2021
  • Developer Experience
    • The Power of Content
    • Building a Developer Community in an Enterprise World
    • How to lose a dev in three ways
    • Developer relations, why is it needed?
    • The hierarchy of developer needs
    • GitHub is your documentation landing page
    • Docs as engineering
    • Commit messages vs. release notes
    • A11y pal(ly)- crafting universally good docs
    • Inspiring and empowering users to become great writers, and why that’s important
    • Solving internal technical documentation at Spotify
  • Community Management
    • Building community flywheels
    • DevRel = Community Management?
    • Creating high-quality communities
    • How to grow a healthy Open-Source community?
    • Managing communities at scale
    • Using community to drive growth
    • Useful community success metrics
    • Communities aren't funnels
    • How to mobilise your community during a pandemic
  • Managing a DevRel Team
    • Developer Relations + Product
    • Distributed developer relations
    • Understanding company goals
    • DevRel Qualified Leads (DQL)
    • Path to success for DevRel
    • How to move up in your organization
    • Four pillars of DevRel
    • Building your DevRel dream team
    • Managing the burnout burn-down
    • I messed up and I’m going to get fired
    • How to report on community relationships without being creepy about it
    • How to scale a developer relations team
  • Misc
    • Is developer relations right for you?
    • Tooling your way to a great DevRel Team
    • Planning your DevRel career
    • Success metrics as narratives
    • Get executive buy-in or else
    • Introduction to the AAARRRP devrel strategy framework
    • Strategy for developer outreach
    • Connecting dev rel and product
    • Performance DevRel
    • Ultimate cheat codes for healthier travel
Powered by GitBook
On this page
  • Summary:
  • Scribbles:
  • Don't be a bridge to nowhere
  • What can you do about it?
  • Communicate Consistently
  • Be both filter and funnel
  • Close the loop

Was this helpful?

Export as PDF
  1. Misc

Connecting dev rel and product

Bear Douglas highlights the best ways to use that feedback to support your company’s product roadmap and broader strategy.

PreviousStrategy for developer outreachNextPerformance DevRel

Last updated 3 years ago

Was this helpful?

Summary:

  • Communicate Consistently

    • Finding channels that work

    • Assigning somebody from the DevRel team to show up to stand-ups.

    • You’ll always have people’s ear when you’re there with them in person.

    • Giving context in the moment

    • Bring good or neutral news as often as bad news.

    • Get your developers to come and do a brown bag with people who are building your platform.

  • Be both Filter and Funnel

    • Dig deeper on customer requests

    • Communication is key

      • People might want things fixed now.

    • They think that you might have infinite engineering capacity.

    • Communicating back with customers.

  • Close the loop

    • Be transparent about the feature status

    • Show internal teams their impact

  • It’s always an ongoing process and it’s different as teams grow.

  • It’s different as you get new leadership.

  • Every company you’re going to be working at is slightly different.

  • Be consistent about your communication, and that means finding new channels always, that work, the more that you can be what they consider an effective filter and funnel of information.

  • Make sure that you’re closing the loop with both your end customers and your product managers, that’s when people will really understand what dev advocacy is and how it fits into the production process.

  • You are the reliable transmitter of information feedback at scale, qualitative feedback at scale.

Scribbles:

Difference between Evangelism and Advocacy

  • One of the key differentiators is what you’re doing to bring back developer feedback into your product.

  • How are you really advocating for their needs, their requests as it gets baked into your product process?

Don't be a bridge to nowhere

  • James Ward called out in a great talk called “The Seven Deadly Sins of Developer Evangelism” is a bridge to nowhere.

  • Evangelists talk to a lot of people day in and day out.

    • Can be really hard to take the time and consolidate that feedback and make sure that it gets heard, but that is the crux of what we do.

What can you do about it?

  • You have to establish with people what you do and what exactly your role is.

  • There’s a lot of work to be done especially as you’re in a larger company just establishing who on earth you are and why you have any credibility talking about what your customers and what your developers want.

Secret step one – is the legwork of giving people inside your company context on who you are and why you’re saying all these things.

  • Creating a consistent cadence of feedback so the product teams know that you’re going to be coming to them and they know that you’re going to have something valuable to say.

Communicate Consistently

  • Finding channels that work

    • These will change as your company grows.

    • They’ll change as teams grow

    • they’ll change based on team preference.

  • Assigning somebody from the DevRel team to show up to stand-ups.

    • You can weigh in on feedback because you’re there in person.

  • You’ll always have people’s ear when you’re there with them in person.

  • Giving context in the moment

    • It’s easy to engage in that conversation rather than it just being a one-line piece of non-contextualized feedback.

  • Bring good or neutral news as often as bad news.

    • Don’t have to be happy sunshine all the time especially if it’s a lie, but ….

    • Positive to neutral news is just as important as bad news and information about what’s broken.

  • Get your developers to come and do a brown bag with people who are building your platform.

    • Make the first one good, vet that first speaker because if you gather an engineering team together and they come and they get great insight from this developer, they’re much more likely to come back in the future.

Be both filter and funnel

Dig deeper on customer requests

  • How do you be both a good filter and a funnel?

  • Why do you want feature x? What are you trying to do with it?

  • And once you get past the solution that they’re asking for and to the need -- share with the product manager.

Communication is key

  • People might want things fixed now.

    • They always want things fixed now because they don’t have to face the trade-offs.

  • They think that you might have infinite engineering capacity.

    • Like you’re a big company, you’re a big name, so how many people are working on your API, like 50, 60?

    • You can probably fix this in a matter of days.

  • Communicating back with customers.

    • Being transparent about what your trade-offs are will give them much more leeway to be patient with you.

Close the loop

  • Important, both the people who are giving you feedback and the people to who you’re sending feedback to.

  • Be transparent about the feature status

    • Have conversations transparently with your developers.

    • Incredibly valuable both for your product team and for your devs getting an understanding of markets and problems being addressed.

  • Show internal teams their impact

    • Happy news for people to see the impact that they’ve had on other people.

    • One or two slides at the beginning of meetups that talked about how we were keeping customers happy and excited.

    • How are we keeping customers both happy and excited?

Video