The Developer Advocate's Guide to Addressing Product Friction ![rw-book-cover](https://res.cloudinary.com/theworstdev/image/upload/l_Gradient/l_text:Montserrat_64_black:The%20Developer%20Advocate's%20Guide%20to%20Addressing%20Product%20Friction,c_fit,g_center,w_800,fl_cutter,fl_layer_apply/v1637893282/Background.png) [[3. Resources/Readwise/Full Document Contents/Articles/The Developer Advocate's Guide to Addressing Product Friction|Full Document Contents]] ## Document Notes ## Summarize: In this article, the author discusses the development of a framework called DX Audits at Apollo to address product friction. The framework aims to identify, document, report, and resolve pain points experienced by developers. The first version of DX Audits encountered some challenges, including slow feedback loops, workload bottlenecks, and excessive reporting. However, it also brought benefits such as consistency, structure, and proof of impact. The epiphany came when they realized that the wrong separation of concerns was causing the issues, leading them to modify the approach for DX Audits v2. In the updated version, audits are scoped to individual use cases, allowing developer advocates to deliver value faster and surface actionable steps more efficiently. The four steps of DX Audits are Discover, Build, Report, and Follow Up. The article highlights the significance of context gathering, empathy, and consistent friction logging in this process. Overall, DX Audits have positively impacted developer advocacy work at Apollo and become a valuable collaboration tool. ## Bullet Points: - The article discusses the development of the DX Audits framework at Apollo to address product friction. - The initial version of DX Audits faced challenges such as slow feedback loops, workload bottlenecks, and excessive reporting. - Benefits of the first version included consistency, structure, and proof of impact through friction logs. - The epiphany was realizing the wrong separation of concerns and modifying DX Audits for v2, where audits are scoped to individual use cases. - The four steps of DX Audits are Discover, Build, Report, and Follow Up. - The process emphasizes context gathering, empathy, and consistent friction logging. - DX Audits have positively impacted developer advocacy work at Apollo and become a standard collaboration tool. ## Paraphrase: 1. "Our team at Apollo embarked on a journey to develop the DX Audits framework, aiming to address product friction and make developer advocacy more repeatable and effective. Despite some challenges in the first version, we found that the framework's fundamentals were solid and brought significant benefits. Notably, friction logs had a profound impact by revealing community pain points and providing valuable insights to other teams. Moreover, the framework introduced consistency and structure in delivering feedback, making it easier for everyone to understand and integrate. One of the most challenging aspects of our job as developer advocates is proving our impact, but DX Audits helped us keep track of accomplishments and demonstrate the outcomes resulting from our feedback. However, the initial version faced issues with slow feedback loops, workload bottlenecks, and excessive reporting, leading us to seek improvements." 2. "The epiphany came when we realized that the separation of concerns in the first version was not optimal. To enhance efficiency and value delivery, we transitioned to DX Audits v2, where audits are now scoped to individual use cases. This change allows developer advocates to work independently, providing value in a much shorter timeframe. The new version follows a four-step process: Discover, Build, Report, and Follow Up. During Discovery, advocates gather context about the use case they're auditing from various sources, ensuring a comprehensive understanding. In the Build phase, advocates experience the workflow and record their findings in friction logs, aiming to be empathetic and minimize assumptions. Reporting involves delivering feedback to relevant decision-makers promptly and proposing actionable steps to address friction points. In the Follow Up step, advocates work on action items and track progress, ensuring effective cross-team collaboration and tangible results." ## Conclusion: DX Audits, a framework developed by Apollo, have significantly impacted developer advocacy work by addressing product friction. The initial version faced challenges, but its benefits, including friction logs, consistency, and proof of impact, were evident. An epiphany led to DX Audits v2, where audits are scoped to individual use cases, enabling faster value delivery. The four-step process, comprising Discover, Build, Report, and Follow Up, ensures a structured and efficient approach to understanding developer pain points and delivering feedback to other teams. DX Audits have become a standard collaboration tool and a valuable asset for the DevRel team and multiple other teams at Apollo. ## Questions: 1. How did the DX Audits framework help Apollo address product friction and improve developer advocacy? 2. What were the main challenges faced in the first version of DX Audits, and how were they overcome in the updated version? 3. How did friction logs prove to be beneficial for the DevRel team and other teams at Apollo? 4. What role does context gathering play in the DX Audit process, and how does it enhance the impact of the feedback provided? 5. What improvements did the epiphany about the wrong separation of concerns bring to the DX Audits framework? 6. How do the four steps of DX Audits (Discover, Build, Report, Follow Up) contribute to the effectiveness of the framework? 7. In what ways can DX Audits enhance collaboration and consistency among different teams at Apollo? 8. How does the revised approach of scoping audits to individual use cases contribute to faster value delivery? 9. What are some best practices for creating friction logs, and how do they ensure quality feedback? 10. How do DX Audits provide a direct paper trail of the team's work and its impact on the Apollo platform and company? ## Auto-tagging: product friction, DX Audits, developer advocacy, feedback, friction logs, context gathering, collaboration, consistency, value delivery, use cases, DevRel, Apollo platform ## Index Creation: 1. Product Friction - p. 1 2. DX Audits - p. 1 3. Developer Advocacy - p. 1 4. Feedback - p. 2 5. Friction Logs - p. 2 6. Context Gathering - p. 3 7. Collaboration - p. 4 8. Consistency - p. 4 9. Value Delivery - p. 4 10. Use Cases - p. 5 11. DevRel - p. 6 12. Apollo Platform - p. 6 ## Table of Contents: 1. Introduction 2. Challenges and Benefits of DX Audits - Challenges in the First Version - Benefits of the First Version - Epiphany and DX Audits v2 3. The Four Steps of DX Audits - Discover - Build - Report - Follow Up 4. Impact on Developer Advocacy at Apollo 5. Conclusion 6. References ## References: 1. [DX Audits at Apollo - Medium Article](example-link-to-the-article.com) 2. [The Developer Advocate's Guide to Getting Buy-in - Article](example-link-to-another-article.com) ## Future Research: - Explore the long-term impact of DX Audits on product development and user satisfaction. - Investigate the potential integration of AI and machine learning in automating the DX Audit process. - Conduct a comparative study of different feedback frameworks to identify the most effective approach. - Examine the role of empathy in reducing product friction and enhancing the developer experience. - Investigate the scalability of DX Audits for larger organizations and open-source communities. - Analyze the correlation between friction logs and customer retention and acquisition. - Explore the challenges and benefits of implementing DX Audits in different technology domains and industries. ## Hypotheses: 1. A streamlined and scoped DX Audits process will lead to more efficient and timely resolution of product friction. 2. Developer advocates who embrace empathy during friction logging will produce feedback with higher impact and resonance. 1. How do DX Audits help to reduce product friction? 2. What are the steps involved in the DX Audit framework? 3. What are the benefits of using this framework? Abstract: This article provides a guide for Developer Advocates on how to address product friction – the moments where users are likely to face difficulty using a product or service. It outlines strategies to help identify, prioritize and address product friction, and highlights the important role of Developer Advocates in this process. It covers the sta > [!note]+ Document Notes <!-- deep-read:sections start --> ## Summarize: In this article, the author discusses the development of a framework called DX Audits at Apollo to address product friction. The framework aims to identify, document, report, and resolve pain points experienced by developers. The first version of DX Audits encountered some challenges, including slow feedback loops, workload bottlenecks, and excessive reporting. However, it also brought benefits such as consistency, structure, and proof of impact. The epiphany came when they realized that the wrong separation of concerns was causing the issues, leading them to modify the approach for DX Audits v2. In the updated version, audits are scoped to individual use cases, allowing developer advocates to deliver value faster and surface actionable steps more efficiently. The four steps of DX Audits are Discover, Build, Report, and Follow Up. The article highlights the significance of context gathering, empathy, and consistent friction logging in this process. Overall, DX Audits have positively impacted developer advocacy work at Apollo and become a valuable collaboration tool. ## Bullet Points: - The article discusses the development of the DX Audits framework at Apollo to address product friction. - The initial version of DX Audits faced challenges such as slow feedback loops, workload bottlenecks, and excessive reporting. - Benefits of the first version included consistency, structure, and proof of impact through friction logs. - The epiphany was realizing the wrong separation of concerns and modifying DX Audits for v2, where audits are scoped to individual use cases. - The four steps of DX Audits are Discover, Build, Report, and Follow Up. - The process emphasizes context gathering, empathy, and consistent friction logging. - DX Audits have positively impacted developer advocacy work at Apollo and become a standard collaboration tool. ## Paraphrase: 1. "Our team at Apollo embarked on a journey to develop the DX Audits framework, aiming to address product friction and make developer advocacy more repeatable and effective. Despite some challenges in the first version, we found that the framework's fundamentals were solid and brought significant benefits. Notably, friction logs had a profound impact by revealing community pain points and providing valuable insights to other teams. Moreover, the framework introduced consistency and structure in delivering feedback, making it easier for everyone to understand and integrate. One of the most challenging aspects of our job as developer advocates is proving our impact, but DX Audits helped us keep track of accomplishments and demonstrate the outcomes resulting from our feedback. However, the initial version faced issues with slow feedback loops, workload bottlenecks, and excessive reporting, leading us to seek improvements." 2. "The epiphany came when we realized that the separation of concerns in the first version was not optimal. To enhance efficiency and value delivery, we transitioned to DX Audits v2, where audits are now scoped to individual use cases. This change allows developer advocates to work independently, providing value in a much shorter timeframe. The new version follows a four-step process: Discover, Build, Report, and Follow Up. During Discovery, advocates gather context about the use case they're auditing from various sources, ensuring a comprehensive understanding. In the Build phase, advocates experience the workflow and record their findings in friction logs, aiming to be empathetic and minimize assumptions. Reporting involves delivering feedback to relevant decision-makers promptly and proposing actionable steps to address friction points. In the Follow Up step, advocates work on action items and track progress, ensuring effective cross-team collaboration and tangible results." ## Conclusion: DX Audits, a framework developed by Apollo, have significantly impacted developer advocacy work by addressing product friction. The initial version faced challenges, but its benefits, including friction logs, consistency, and proof of impact, were evident. An epiphany led to DX Audits v2, where audits are scoped to individual use cases, enabling faster value delivery. The four-step process, comprising Discover, Build, Report, and Follow Up, ensures a structured and efficient approach to understanding developer pain points and delivering feedback to other teams. DX Audits have become a standard collaboration tool and a valuable asset for the DevRel team and multiple other teams at Apollo. ## Questions: 1. How did the DX Audits framework help Apollo address product friction and improve developer advocacy? 2. What were the main challenges faced in the first version of DX Audits, and how were they overcome in the updated version? 3. How did friction logs prove to be beneficial for the DevRel team and other teams at Apollo? 4. What role does context gathering play in the DX Audit process, and how does it enhance the impact of the feedback provided? 5. What improvements did the epiphany about the wrong separation of concerns bring to the DX Audits framework? 6. How do the four steps of DX Audits (Discover, Build, Report, Follow Up) contribute to the effectiveness of the framework? 7. In what ways can DX Audits enhance collaboration and consistency among different teams at Apollo? 8. How does the revised approach of scoping audits to individual use cases contribute to faster value delivery? 9. What are some best practices for creating friction logs, and how do they ensure quality feedback? 10. How do DX Audits provide a direct paper trail of the team's work and its impact on the Apollo platform and company? ## Auto-tagging: product friction, DX Audits, developer advocacy, feedback, friction logs, context gathering, collaboration, consistency, value delivery, use cases, DevRel, Apollo platform ## Index Creation: 1. Product Friction - p. 1 2. DX Audits - p. 1 3. Developer Advocacy - p. 1 4. Feedback - p. 2 5. Friction Logs - p. 2 6. Context Gathering - p. 3 7. Collaboration - p. 4 8. Consistency - p. 4 9. Value Delivery - p. 4 10. Use Cases - p. 5 11. DevRel - p. 6 12. Apollo Platform - p. 6 ## Table of Contents: 1. Introduction 2. Challenges and Benefits of DX Audits - Challenges in the First Version - Benefits of the First Version - Epiphany and DX Audits v2 3. The Four Steps of DX Audits - Discover - Build - Report - Follow Up 4. Impact on Developer Advocacy at Apollo 5. Conclusion 6. References ## References: 1. [DX Audits at Apollo - Medium Article](example-link-to-the-article.com) 2. [The Developer Advocate's Guide to Getting Buy-in - Article](example-link-to-another-article.com) ## Future Research: - Explore the long-term impact of DX Audits on product development and user satisfaction. - Investigate the potential integration of AI and machine learning in automating the DX Audit process. - Conduct a comparative study of different feedback frameworks to identify the most effective approach. - Examine the role of empathy in reducing product friction and enhancing the developer experience. - Investigate the scalability of DX Audits for larger organizations and open-source communities. - Analyze the correlation between friction logs and customer retention and acquisition. - Explore the challenges and benefits of implementing DX Audits in different technology domains and industries. ## Hypotheses: 1. A streamlined and scoped DX Audits process will lead to more efficient and timely resolution of product friction. 2. Developer advocates who embrace empathy during friction logging will produce feedback with higher impact and resonance. 1. How do DX Audits help to reduce product friction? 2. What are the steps involved in the DX Audit framework? 3. What are the benefits of using this framework? Abstract: This article provides a guide for Developer Advocates on how to address product friction – the moments where users are likely to face difficulty using a product or service. It outlines strategies to help identify, prioritize and address product friction, and highlights the important role of Developer Advocates in this process. It covers the stages of product friction identification and management, including understanding the root causes, gathering data on user feedback, and making recommendations to product and engineering teams. The article emphasizes the value of Developer Advocates in identifying and resolving product friction, and provides key tips for successful product friction management. Detailed Bullet List: - Introduction - Definition of product friction - The importance of addressing product friction - Identifying Product Friction - Identifying root causes - Gathering user feedback - Prioritizing product friction - Addressing Product Friction - Making recommendations to product and engineering teams - Testing and validating recommendations - The Role of the Developer Advocate - Identifying and resolving product friction - Building relationships with product and engineering teams - Providing key insights on user feedback - Conclusion - Summary of strategies for addressing product friction - The important role of Developer Advocates Paraphrased Paragraphs: Paragraph 1: Product friction can be described as the moments when users are likely to experience difficulty or frustration while using a product or service. It is important to address these issues in order to ensure that the product is easy to use and that users have a positive experience. Paraphrase: Product friction is when users face difficulty or become frustrated while using a product or service. To guarantee good user experience and satisfaction, these issues must be addressed. <!-- deep-read:sections end --> ## Highlights - **Consistency and structure -** DX audits provide structure around what is otherwise an abstract part of developer advocacy ([View Highlight](https://read.readwise.io/read/01gvy76rj6q615pnz1hexpk177)) - keep track of our accomplishments in our DevRel database ([View Highlight](https://read.readwise.io/read/01gvy765ckdqq68y85z522nnv1)) - Slow feedback loo ([View Highlight](https://read.readwise.io/read/01gvy77hp251b9ntgj3pex3d8m)) - Workload bottlenecks ([View Highlight](https://read.readwise.io/read/01gvy77p80843tee9jnkpsk4xe)) - Too much ceremony ([View Highlight](https://read.readwise.io/read/01gvy7842x491bmpckbergcvdh)) - The goal of a DX audit is to document, report, and address product friction by having a developer advocate experience a given developer workflow, document and report their findings, and surface actionable steps to take to reduce friction ([View Highlight](https://read.readwise.io/read/01gvy78jn8r7gw3mqrfdbp494p)) - • **Community and customers** - GitHub, forums, social media, events, surveys and forms, issues raised by solutions, support and customer success, etc. • **Input from stakeholders** - product updates, roadmaps, engineering timelines, etc. ([View Highlight](https://read.readwise.io/read/01gvy78wb5cc8jmv4k3x11bdsk)) - **Channel your empathy** – You want to approach the workflow as a developer might ([View Highlight](https://read.readwise.io/read/01gvy7am8j9f6gr07crvme6c5y)) - More detail is better than less ([View Highlight](https://read.readwise.io/read/01gvy7axb9vbakje5bv2r3hrex)) - **Don't forget the good** – When you experience something delightful, make sure to document that and also be sure to include the positive experiences when summarizing a friction log! ([View Highlight](https://read.readwise.io/read/01gvy7batmn16wgwzcjzd4jmz3)) - **Consistency is key** – Everyone should be using the same template to create friction logs ([View Highlight](https://read.readwise.io/read/01gvy7bhvafy68p1gjnw9p9ns8)) - Once a friction log is complete, the next step is to summarize and report your findings to involved parties. Add a detailed executive summary to the top of the friction log, including the highs and lows of the experience, any realizations or insights you uncovered. Be sure to document possible action items decision-makers could take to address any friction points discovered and add them to the friction log. ([View Highlight](https://read.readwise.io/read/01gvy7cgb0sa0sxvgeq3xws5sd)) - Note: The DX Audit framework was developed by Apollo to help identify, document, report, and address product friction. It provides consistency and structure, and allows developers to easily track the outcomes of their feedback. The framework consists of four steps: Discovery, Build, Report, and Follow Up. During Discovery, context is gathered and during Build, a project is created to experience the workflow. During Report, a friction log is created and actionable steps are outlined in an executive summary. Finally, Follow Up consists of working on the action items outlined in the friction log and tracking progress. The framework has been beneficial to many teams at Apollo, but it was improved upon to reduce slow feedback loops and too much ceremony.