Comment on page
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.
Video
“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.
- It’s important to tailor your DevRel initiatives to your company’s business model and your team structure.
- Set up objectives for your team.
- 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.
- 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.
- 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.
- 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.
- Cultivating a thriving developer ecosystem is difficult if you can’t get your internal teams excited about the product.
- 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.
- Interviewing developers.
- Developer survey.
- Developer community
- Feedback form
- Documentation
- Meeting and researching with 1st party, 2nd part and 3rd party developers.
- Organize the feedback into themes
- Each section was a different theme
- Custom fields to track user stories by dev personas.
- Start reframing some of the developers needs to encompass some of the broader customer and business needs.
- Represent developers at company planning.