# Build the Platform Your Developers Actually Want {% embed url="" %} Video {% endembed %} ## 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.