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:
  • Biggest challenges in DevRel
  • 🚩 Takeaways:
  • Don’t assume you know what developers want.
  • Don’t assume your developers know your product.
  • Don’t assume all of your developers are the same.
  • Ask the hard questions to a broader set of developers.
  • Ways of gathering Developer Stories
  • Structure and organise your findings in a more actionable format
  • Include your stakeholders.
  • It’s also about customers and the business .. not just developers.

Was this helpful?

Export as PDF

Build the Platform Your Developers Actually Want

Biggest challenges in DevRel is determining which among the numerous possible activities is the most leveraged. Jeff schnieder answers how he and his team solved their challenges at Asana.

PreviousHow do you design programs for diversity?NextMeasuring dev rel programs far beyond marketing activities

Last updated 3 years ago

Was this helpful?

Summary:

“I encourage everyone who hasn’t to see the value and actually connecting with your developers one-on-one so you can learn from their stories and feel their pain.”

  • It doesn’t really matter if it’s on the phone or through video or in-person,

    • as long as you’re kind of connecting one-on-one and asking them open-ended questions.

  • Don’t Assume your developers

    • Want what you do

    • Are all the same

    • Know your product

  • Put on your researcher Hat

  • Make your finding in researchable format

  • Include your stakeholders --

    • don’t get overprotective by the process.

  • Frame your findings to support your customers and business.

Scribbles:

  • It’s important to tailor your DevRel initiatives to your company’s business model and your team structure.

  • Set up objectives for your team.

Biggest challenges in DevRel

  • Determining which of the numerous activities is the most leveraged,

  • How should the docs be improved

  • Move to the OpenAPI spec

  • Writing code examples

  • Creating SDKs

  • Speaking at conferences

  • Fostering a dev community

  • Answering technical questions

  • integrating with partners

Quote Our initial thought was, you know, we’re developers so we know what developers want. We’ll just choose the things that seemed useful to us. Wrong.

🚩 Takeaways:

Don’t assume you know what developers want.

  • Generalize developers of your platform

    • 1st Party Developers - Engineers that build integrations on our API.

    • 2nd Party Developers - Work on/for customers.

    • 3rd Party Developers - Build apps for many asana customers to use.

  • It can be difficult to actually track down the developers and get that first handful of meetings.

  • Really hard to understand the behaviour of your users until you have one-on-one conversations and meet with them and listen in person.

Don’t assume your developers know your product.

  • Not everyone loves your product as much as you do.

  • Reevaluate our developer experience.

    • Writing an object hierarchy doc to explain the elements of your product.

Don’t assume all of your developers are the same.

  • Create distinct personas and expand each a bit more.

  • Creating different developer tracks for each group.

  • Packaging all of these developer interviews into case studies and presenting them to numerous teams across your organisation.

Importance of internal platform evangelism.

  • Cultivating a thriving developer ecosystem is difficult if you can’t get your internal teams excited about the product.

Ask the hard questions to a broader set of developers.

  • Choose your research methods and goals before you start talking to users.

  • Ask open-ended questions.

    • Give people the space to speak their minds.

    • Get out of your own way, let your developers tell you what they experience.

  • Come in with an open mind.

    • If you come in with an opinion, you risk only hearing the evidence that supports that hypothesis.

Ways of gathering Developer Stories

  • Interviewing developers.

  • Developer survey.

  • Developer community

  • Feedback form

  • Documentation

  • Meeting and researching with 1st party, 2nd part and 3rd party developers.

Structure and organise your findings in a more actionable format

  • Organize the feedback into themes

    • Each section was a different theme

    • Custom fields to track user stories by dev personas.

Include your stakeholders.

It’s also about customers and the business .. not just developers.

  • Start reframing some of the developers needs to encompass some of the broader customer and business needs.

  • Represent developers at company planning.

Video