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.
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.
Last updated