Engaging, activating, and retaining developers

This case study differs from others as it condenses 2 years worth of work into a cohesive story around our onboarding efforts, leading to a 55% increase in engagement, a 44% increase in users creating/adding their graph, a demo experience accounting for 30% of new onboards, and an increase in enterprise trial signups from >1% to 4% (30 new signups per week).  

Jump to screens

Overview

What is Apollo GraphQL?

Apollo is on a mission to make the world’s data more accessible by making APIs easier to build and scale, and currently a leader in the marketplace for offering what's known as "Federation", or, an API gateway. This API gateway provides developers with a customizable run-time platform where both front and backend teams can seamlessly work together while building, testing, and monitoring their graph using Apollo's GraphOS platform.

There are a lot of complicated ways to describe what Apollo does, but to make it as simple as possible (since this portfolio is for recruiters, designers, and other non-developer personas), GraphQL is like having a menu at a restaurant where you can pick exactly what you want to eat, instead of having to order a pre-made combo meal. With regular APIs, you might get too much or too little information because they give you a fixed set of data. But with GraphQL, you can ask for just what you need, making things faster and more efficient. It helps websites and apps load quicker and makes it easier for developers to get the exact data they want.

Whether you binge-watch a series on Netflix, plan faraway vacations from your phone, or read international news online, you’ve likely used Apollo’s technology this week.

Problem overview

Why aren't users signing up on our GraphOS platform engaging or converting?

When I started at Apollo, only 8% of 10,000 new users progressed through the initial step of onboarding, and just 0.1% converted. At Apollo, activation represents a user that creates/connects at least one graph instance in GraphOS with their own data sources. There was no dedicated team consistently analyzing the customer journey or addressing pain points, leaving many questions about potential pathways and how they influence customer behaviors based on their background and role.
‍
Onboarding initially followed a one-size-fits-all approach, funneling every user—regardless of background, knowledge, or intention—into the same flow that required providing an API endpoint. This drove significant drop-off rates, prompting a shift towards tailoring experiences based on each persona's specific jobs to be done and aligning with our enterprise-level goals. Early insights revealed that over 60% of users entering the product sought to learn about GraphQL but lacked an API endpoint, preventing more than half of our incoming users from accessing the product.

Through two years of refining our onboarding process, we encountered over 100 potential issues and use cases. The key takeaway from this work is the importance of creating a seamless onboarding experience that educates, activates, and supports non-GraphQL users as they transition smoothly through our low-touch product and education-driven approach.
‍
Key areas of focus throughout my time at Apollo work were as follows:
  • Build & enable a self-serve enterprise trial experience (conversion drivers 🚀)
  • Create an experience that educates, activates, and supports non-GraphQL users (engagement drivers 🌟)
  • Build to scale; create product-led experiences vs sales-led (company growth đŸŒ±)
  • Increase the amount of incoming high-quality leads within our sales funnel (sales & revenue drivers 📈)
  • Enable users to easily (and quickly) build a proof of concept for their business use cases (activation & conversion drivers 🎯)
  • This project involved nearly everyone in the company. My role was to collaborate with cross-functional stakeholders from marketing, sales, developer experience, product, engineering, and community teams to maintain alignment. Key efforts included integrating existing product experiences into onboarding flows, standardizing user-facing language for features, refining information architecture and user navigation, and managing user-facing communications like emails, in-product banners, and developer documentation

Project outputs

  • Apollo's self-serve enterprise trial
  • Tailored pathways based on persona & jobs to be done
  • Introduced project containers for user graphs, reducing the confusion on "what the supergraph is" and "what the container is".
  • Apollo's product demo: allowing users to explore the full suite of features without requiring their data sources
  • A clearer narrative on our ideal customer persona (enterprise) + their activation path
  • In-product resources and pathways to other Apollo products, like Odyssey, our GraphQL tutorial and certification platform
  • Standardization of user-facing language for features
  • A research database containing customer contact, background, and use case details for future research efforts

Outcomes

  • The self-serve enterprise trial sign up flow improvements resulted in a 300% increase for Apollo enterprise trial sign ups on a weekly basis, from <1% to 4% (eg: 30 new users per week), which now accounts for 50% of all incoming sales leads.
  • Early results of the enterprise trial sign up flow showed an 18% success rate as compared to our free product (10%).
  • Onboarding work reduced flow drop-off by 45% post-implementation, with overall engagement rising from 8% to 55% of our 10k user sample size.
  • V1 of the onboarding survey identified user goals, role/experience, and graph use cases, which enabled our developer experience team to prioritize the product demo experience, which now accounts for 30% of onboards.
  • V1 survey results influenced marketing updates for tailored introductory content in onboarding and nurturing emails, offering more introductory content for developers who are just getting started with GraphQL.
  • Adoption initiatives help de-risk traction with customers as outlined in our FY25 Cloud Product Strategy, by providing frictionless abilities to self-serve into the product and purchase without talking to sales.
  • We went from 0 users in our Apollo research community to over 6,000 contacts including their roles, use cases, and experience through our Amplitude implementation, an effort I drove with our Astro team.

What we were working towards

Jobs to be done, outcomes, and how we measured the success of our anticipated outcomes.

Job to be done

Demonstrate GraphOS's value with minimal user effort

Prioritize understanding developer persona needs and showing them exactly how GraphOS can help them. Currently, users are required to provide an API endpoint (92% drop-off) to experience the product. Showing value early requires relevancy to their use case and de-coupling requirements for connecting code/data.

Job to be done

Introduce product-led, self-serve experiences

Enterprise plans rely on a sales-led experience to inform potential customers on what GraphOS is, what it does, and the use cases it solves for. t's near impossible for developers to do this without sales intervention. Time to value is long - with buyers typically deciding after 3-6 sales meetings.

Job to be done

Replace a funnel approach and strategize based on the users stage

Users need clear guidance on maximizing value after setting up a graph. Developers spend hours in documentation trying to identify the most valuable features, and some users are unaware that GraphOS offered the features they need. Getting set up is such a massive task (weeks+) that it overshadows the benefit of our feature set.

Measuring success

An increase in enterprise sales

% of users converting from enterprise trial to enterprise sales. Enterprise trials are offered on a 30 day basis, but we believe increasing that to 90 days increases the likelihood of users embedding GraphOS and GraphQL into their workflow and influencing conversion.

Measuring success

Onboarding completion rates

The % of users making it to the final step of onboarding before the activation cycle. Apollo's Cloud offering is primarily a self service product so getting started with the product and activating needs to be easy and low friction.

Measuring success

Activation rates (graph creation)

Activation is defined as a user successfully setting up 1 or more graphs in GraphOS using their own data sources.

Measuring success

Misc: Increased engagement with Odyssey and the product demo

Integrating pathways into onboarding increased visibility for our tutorial and educational products built by the developer experience team. The demo directly contributes to successful onboardings and activations, while Odyssey, our free hands-on tutorial resource, strongly correlates with user retention

Project workflows

01

Problem discovery

A deep dive into the problem area. This would vary depending on the project outcomes, but typically involved marketplace research, competitive analysis, utilizing previous insights, and heuristic evaluations of our current product.

02

Listening tours

Working alongside talented developers meant utilizing them for interviews if needed. Listening tours involved internal stakeholders as well, ranging from marketing and developer experience to sales and leadership.

03

Amplitude configuration

Amplitude is implemented in parts of the product that have helped us measure unified onboarding impact - which has helped us understand the levers users engage with as they come into the platform. Its allowed us to measure our work in a self-serve manner, creating a scalable foundation for teams to build on and work with too. This project was driven without any support from my
immediate team; I had to work with product partners to get this lifted.

04

Target persona

While our general focus is on developers; front end, back end, and full stack, we continued research to understand who our enterprise buyer was. Understanding the tech lead persona allowed us to tailor the experience for users looking to build proof of concept with the intention to purchase.

05

Validation loops

We built narratives around our personas for each project and brought those back to stakeholders and cross-functionally team members to maintain alignment, share learnings, and receive buy in.

06

Continuous growth

Keeping the conversations going in addition to continually measuring our work allowed us to work iteratively and make changes as needed when new learnings became available. Onboarding is a good example; where our learnings led to 3 phases of work.

Growth and driving adoption within product

My first 8 months at Apollo were focused on Growth work. Our growth cycle focused on enterprise enablement through our self-serve onboarding tools and enterprise trial.
‍
With our organization being sales led, it became difficult for growth at Apollo to implement product-led practices. Leadership dissolved Growth as a function and restructured the team back to its original roots, focused on identity and permissions. Once this change went into place, I was concerned about the remaining gap in our onboarding experience, personas, and adoption.

I presented this work to engineering leadership, which eventually made its way to C-suite. The pitch was for product to carve out an adoption team, focused on improving developer workflows/making it easy (develop, preview, ship). Growth was a misunderstood function at Apollo, drawing a lot of confusion in what exactly growth enabled. I wanted to close that gap by positioning growth as an extension of Adoption, with adoption acting as the umbrella for all things onboarding related.

    The Adoption Pitch

    "Customers are more likely to adopt GraphOS if it mimics the same speed and efficiency they expect when using GraphQL. We lose customer opportunities due to current product friction, the time it takes to first integrate or add services, then concurrently see that value or a-ha relative to our users once that's done.

    Adoption will work alongside DX to improve the funnel for onboarding customers, allowing them to implement GraphOS into their workflows faster and reduce the time it takes to build their first use case.

    Adoption will build the paths that move customers towards adoption of the entire suite of GraphOS functionality. The Adoption team and the Developer Experience team would have a strong partnership to split work between onboarding, removing friction, reaching a-ha, and optimizing pathways. Both teams would collaborate cross-functionally across product teams as needed, based on product initiatives. DX ownership would focus on the explorer/evaluator persona. Adoption ownership would focus on the explorer/beginner personas.

    Over time, this team will be responsible for working alongside product partners to monitor the experience and make adjustments as we learn about new friction points."

    Data points from research on the impact of unclear IA and onboarding in Studio [Gusto ($400k ARR), Dow Jones ($112.5k)]:

    • Wayfair ($875k ARR) customer Greg Wardwell warns enterprise customers may be less likely to adopt Apollo if it takes them considerable time to onboard their teams to the interface or create proof of concepts easily. Previous research by our UXR givesthe same insight from different customer cohorts.
    • Research conducted by Shili (our UXR) shows that in today’s current onboarding flow, there is no “aha” moment with developers who don’t know they are creating a router and supergraph.
    • Sephora ($199k ARR) – Power features linked to sales/conversion drivers such as schema contracts highlighted by Nick Beach @ Sephora as the key seller that pushed Sephora to the point of purchase, are multiple levels deep within the product, requiring Apollo resources ($$) to intervene. This is an opportunity to reduce resource cost and enable either 1) awareness -> engagement -> adoption or 2) try -> “aha” -> conversion.

    Onboarding work

    V1: Onboarding Survey

    As we invest in the Cloud experience, the Product brief: Enterprise Self-Serve Trial, and become both more customer-centric and data-driven, this is a priority to solve in order to:

    • Deliver the right messages/value at the right time (personalization & messaging).
    • Enable faster intervention if we’re seeing wrong fit - e.g., someone with high intent for self-hosted signs up for Cloud and doesn’t activate (SKU fit).
    • Better understand our audiences and their intentions (segmentation & use-case expansion)
    • Potentially intercept folks signing up with high fit/intent with Sales more effectively (direct monetization & activation opportunities)

    Outcomes

    Onboarding v1 guided our prioritization for further growth and onboarding work when defining end-user OB paths, including the different levers we introduced in v2 for new users that created different paths of engagement. (eventually reducing drop-off by 44%)

    • 50% of 13k users had/have no graph
    • 70% of 13k users are coming for personal reason (non-work related)
    • 44% of 13k users want to query an endpoint, and 24% of them want to improve skills

    OB v1 showed us the majority of users coming here do not have a graph and are still learning - incoming users who fit a PQL is smaller than we had anticipated. Learning that >50% of users don't have a graph helped us prioritize adding the Spotify demo into onboarding, which now accounts for 30% of onboards.

    V2: Introducing self-serve enterprise trials and a rebrand

    As a new organization owner/user, those segments want to be able to select a plan for their organization during the onboarding process based on their needs. To facilitate this, we needed to adjust our organization creation experience and give customers the ability to self-serve their plans.

    Outcomes

    • New user research database created with a version b including an opt-in, taking our available customer data base from ZERO customers to 1k+ customers opting in to future research opportunities within 3 months of launch.
    • The self-serve enterprise trial sign up flow improvements resulted in a 300% increase for Apollo enterprise trial sign ups on a weekly basis, from <1% to 4% (eg: 30 new users per week), which now accounts for 50% of all incoming sales leads.
    • Early results of the enterprise trial sign up flow showed an 18% success rate as compared to our free product (10%).
    • In Q4 product was responsible securing at least 3 sales meetings at the beginning of Q4 and doubled within 2 weeks to 6 meetings.

    V3: Unified onboarding pt 1

    Apollo's onboarding experience started with one CTA: “provide user with an endpoint”. Without an endpoint, users could not get started with Apollo GraphQL, nor could they explore the platform or try features. Onboarding V1 was the first phase of Unified Onboarding. This work brought several changes to Studio, our developer tooling platform, including a new sidebar navigation that replaced all previous L1 navigations and removed the need for a top-bar. This onboarding was initially targeted at free-tier plan customers that had not created a graph in Studio, as an effort to reduce dropoff and improve engagement, moving users closers to successfully activating on the platform.

    • Unified onboarding is the primary reason DX was able to prioritize Spotify Demo.
    • Historic drop-off data (this chart is only applicable for the time before Dec 1, 2023): of 10k users landing in Studio, only 8% move to the next step.
    • My work alone influenced these decisions - surfacing transparent details on data and security, taking a progressive approach building context, educational tooltips, improved user-friendly language, adding pathways on our landing screen for demo, odyssey, REST connectors backdoor, and boilerplates.

    Outcomes

    • Onboarding work reduced flow drop-off by 45% post-implementation, with overall engagement rising from 8% to 55% of our 10k user sample size.
    • Adding additional pathways for users led to increased engagement with product levers that saw little to no engagement previously, such as our Odyssey platform.
    • Unified onboarding provided the proof of concept necessary to drive adoption initiatives in Q1 of 2024

    V3: Unified onboarding; pt 2 paid tiers and brand refresh

    Cloud as a self serve product: right now Dedicated is sold via sales-led which has generated user research and a strong feedback loop to inform product development, but this has limited growth. Cloud lends itself well to self service because it has a lower implementation complexity compared to Enterprise (or self hosting router). This drove our decision to add pathways within onboarding for our paid "dedicated" tier.

    Existing users adding subgraphs utilizing services (AWS connection) and Cloud Router settings/management

    Misc; Clarifying information architecture: adding project-level containers