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). Â
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.
Jobs to be done, outcomes, and how we measured the success of our anticipated outcomes.
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.
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.
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.
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.
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.
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.
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.
"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)]:
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:
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%)
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.
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.
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.
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.
