Improving Developer Onboarding Through Intelligent Data Insights

A developer platform lives and dies by it's developer community. When huge problems need to be solved, it's easy to make valuable improvements, but what do you do when those are solved and you still see high bounce rates on your site, low developer application completion, and generally poor adoption of your product? This is where your data can save you.

In this talk we'll run through:
- How to track valuable developer path insights, from moments of anxiety to time to first valuable call.
- Overlaying support and ticketing information on top of developer path data to decrease developer friction.
- How to create automated analytics systems to measure success.
- When these systems should be built, before it's too late.

Transcript

1. Improving Developer Onboarding Through Intelligent Data Insights Jonathan LeBlanc Director of Developer Advocacy @ Box Email: jleblanc@box.com
2. Why is the Data Important? When you have big problems, solutions are easy. When those are solved how do you determine what will make any measurable impact? Jonathan LeBlanc • Director of Developer Advocacy @ Box • Twitter: @jcleblanc • Email: jleblanc@box.com
3. Agenda for Today Identifying Hurdles: Using pull based data analytics to identify developer hurdles. Improving Transparency: Using pushed based data systems to decrease churn and reduce ticket volume. Improving Onboarding: Using this data in practice. Jonathan LeBlanc • Director of Developer Advocacy @ Box • Twitter: @jcleblanc • Email: jleblanc@box.com
4. Part 1: Identifying Hurdles
5. 1 Identifying key moments of anxiety Jonathan LeBlanc • Director of Developer Advocacy @ Box • Twitter: @jcleblanc • Email: jleblanc@box.com
6. 1 How it translates to developer onboarding Jonathan LeBlanc • Director of Developer Advocacy @ Box • Twitter: @jcleblanc • Email: jleblanc@box.com
7. 1 What metrics are we looking for? Jonathan LeBlanc • Director of Developer Advocacy @ Box • Twitter: @jcleblanc • Email: jleblanc@box.com Time to first call How long did it take the developer to make their first valuable API call? Developer journey vs support Which pages / paths did the user follow, which pages did they leave on, and what support requests did they file?
8. 1 How do we obtain these metrics? Jonathan LeBlanc • Director of Developer Advocacy @ Box • Twitter: @jcleblanc • Email: jleblanc@box.com Determine onboarding channels: What systems will a developer go through to make their first API call? This includes support channels. Unify the tracking identifiers: You need a way of tracking the non logged in user uniformly through these channels, such as a tracking ID. Remove edge / non-valuable data: Single path occurrences are outliers and should be ignored. Valuable time to first call metrics should remove auth requests and any test samples that skew the data set. Don’t lead your data: If you have to makes leaps based on your anecdotal information to come to a conclusion, you’re missing a channel. Anecdotal information should only help bolster a data proven conclusion.
9. 1 Enhance with Anecdotal and Support Information Jonathan LeBlanc • Director of Developer Advocacy @ Box • Twitter: @jcleblanc • Email: jleblanc@box.com Time to first call Support tickets, feedback / community systems, and anecdotal customer support requests are typically major areas to determine methods for decreasing time to first call (e.g. improving auth docs) Developer journey vs support Customer feedback, major areas of support requests, and direct ticket request information are all prime supporting information for Improving developer onboarding and products.
10. Part 2: Improving Transparency
11. 2 Roadmap Transparency Jonathan LeBlanc • Director of Developer Advocacy @ Box • Twitter: @jcleblanc • Email: jleblanc@box.com
12. 2 What should the roadmap focus on Jonathan LeBlanc • Director of Developer Advocacy @ Box • Twitter: @jcleblanc • Email: jleblanc@box.com Avoid exact timelines: Using terminology to denote near, medium, and long term targets avoids being seen as unreliable if dates slip. Avoid roadmap changes: Only display what you can commit to, such as a 3-6 month timeframe. Use it as an engagement mechanism: Collect feedback on what people want / don’t want on the roadmap, then use that to improve it.
13. 2 Changelog / Release Notes Jonathan LeBlanc • Director of Developer Advocacy @ Box • Twitter: @jcleblanc • Email: jleblanc@box.com
14. 2 What should the changelog include? Jonathan LeBlanc • Director of Developer Advocacy @ Box • Twitter: @jcleblanc • Email: jleblanc@box.com Granular scoping: Ability to filter changes based on relevant topic, such as API changes, breaking changes, particular product lines, etc. Subscription: Treat it as an independent service, allow users to subscribe to updates via RSS feed, email, text, etc. Overshare: Breaking changes, enhancements, upcoming major changes, maintenance, and the like should be shared. This isn’t a newsletter where you’re worried to communicate too often.
15. 2 API Uptime Status Indicator Jonathan LeBlanc • Director of Developer Advocacy @ Box • Twitter: @jcleblanc • Email: jleblanc@box.com
16. 2 What should the status indicator include? Jonathan LeBlanc • Director of Developer Advocacy @ Box • Twitter: @jcleblanc • Email: jleblanc@box.com Granular statuses: Ability to filter changes based on relevant topic, such as API changes, breaking changes, particular product lines, etc. Subscription: Treat it as an independent service, allow users to subscribe to status changes for any granular area of the APIs / services via RSS feed, email, text, etc. Immediate and continuous posting: When service changes occur, they need to be reflected immediately. Status updates should be posted regularly until problems are rectified.
17. Part 3: Improving Onboarding
18. 3 Using the Data: Documentation Rebuild Example Jonathan LeBlanc • Director of Developer Advocacy @ Box • Twitter: @jcleblanc • Email: jleblanc@box.com
19. 3 Using the Data: Documentation Rebuild Example Jonathan LeBlanc • Director of Developer Advocacy @ Box • Twitter: @jcleblanc • Email: jleblanc@box.com Source: Box developer site at https:/ /developer.box.com Core data sources: User site path, time on page, exit rates, and bounce rates. Supporting sources: Support ticket data, forum feedback, direct customer feedback, and independent audit. Resulting improvement: Page view increase: 2x Bounce rate decrease: 68.68% -> 24.64% Exit rate decrease: 60.12% -> 24.19%
20. 3 Improving Transparency Example Jonathan LeBlanc • Director of Developer Advocacy @ Box • Twitter: @jcleblanc • Email: jleblanc@box.com
21. 3 Jonathan LeBlanc • Director of Developer Advocacy @ Box • Twitter: @jcleblanc • Email: jleblanc@box.com Source: Box Pulse at https:/ /pulse.box.com Core driving factor: Direct customer feedback, transparency improvements Requirements: All feedback is under strict SLAs, all teams responsible for responding and assigning a status to feedback within a given period of time. Resulting improvement: 2834 independent pieces of feedback, 225 delivered, 332 being researched, 247 under consideration, 7 in beta, and 74 on the roadmap. All within 3-4 months of being launched. Improving Transparency Example
22. Wrapping up our topics Identifying Hurdles: Using pull based data analytics to identify developer hurdles. Improving Transparency: Using pushed based data systems to decrease churn and reduce ticket volume. Improving Onboarding: Using this data in practice. Jonathan LeBlanc • Director of Developer Advocacy @ Box • Twitter: @jcleblanc • Email: jleblanc@box.com
23. Thank You https:/ /speakerdeck.com/jcleblanc Jonathan LeBlanc Director of Developer Advocacy @ Box Email: jleblanc@box.com