Developer Relations

Areas of Impact

• Ability to scale our services without needing to linearly scale the number of people on our team
• Organizational awareness of the value our team is providing
• Connecting with other product teams, and having them engage with us, making noise
• Having a clear strategy that shows how we are measuring impact

Developer Experience Research

Problem Statement Definition

• Helps PO to create the roadmap
• Who are the stakeholders and user personas?
• What problems do they want us to solve?

Marketing Publication about the vision for

• Common Services that a team hosts for others to make API calls to and request access to,
• Common Components for teams to run themselves,
• Shared Libraries for teams to reference in their code,
• Examples Applications to demo capability,
• Code Template to show implementation
• Teams creating their own common services and contributing back to the community (public, bcgov, etc)
  • The mindset and architectural decision to build it to share

Measure Value of features

• Operations, continuing to support
• User group that we could reach out to, to check in on how we are doing
• Score/metrics for feature health, accessibility, reading level (best practices)

Acceptance Testing

• For new features that we are building
• Formal user engagement sessions (demos, observation testing)
  • Task completion success rate, time to complete, experience
  • Identify acceptance tests that could be automated (each acceptance test should have a business case for its existence)

AAARRRP

Awareness, Acquisition, Activation, Retention, Referral, Revenue, Product

"Pick work that has a high AAARRRP score" See the Introduction to AAARRRP for an example of how to score your efforts.