Behind the API Interview with Courtney George, Amplitude, ex-Adobe

Welcome! On Behind the API, we talk to the people who work to build awesome API products about their journey, learnings, and overall approach.

On today’s session for Behind the API, we are joined by Courtney George. Currently Head of Design for Data at Amplitude and ex-Adobe Developer Experience.

To request an invite to Astral for your low-code API Portal and Developer Success Tools, blast off with us here.

Transcript (from

Speaker 1 0:04

Welcome on behind the API. We talked to people who work on awesome API products and talk to them about their journey and their learnings and their overall approach on today's session for behind the API. We're joined by Courtney George, currently head of design for data at amplitude X, Adobe for developer experience. So to start us off Courtney, thank you for being here. Andy was just give us a little bit of background on your current role and where you're based out of.

Speaker 2 0:29

Yeah, definitely. First, just want to say thank you so much Kirby for having me. I'm really excited for this chat today. Uh, so my team at amplitude focuses on the foundational layer of ingesting data, governing that data, ensuring that it's all accurate and comprehensive so that when companies want to get insights, they're doing so unclean data and then able to turn those insights into action. Um, and I'm currently based out of the bay area in the south bay, kind of grew up here, left for school, and then couldn't resist the beautiful weather. So came back

Speaker 1 1:06

Nice. And I'm currently a new user of amplitude. So I'm going, starting to go through that experience, but, um, from the design and leadership role, you're new to amplitude. So what caused you to go there from Adobe? And we'll talk a little bit about it later, but what are the design challenges that were presented to you, uh, at amplitude and, uh, what's your team starting to sink their teeth into?

Speaker 2 1:28

Yeah, you know, I think it's a really exciting time for amplitude just went public towards the end of last year. So the company is definitely growing. The design team is growing. I like to say we're kind of building, going from a design team into a full design organization. So all of the organizational operational strategy that kind of comes on top of that was really exciting for me to be able to join, um, not to mention kind of a new new domain for me as well, with the data and analytics company. Um, and you know, I think it built upon a lot of my experiences at Adobe kind of building a small team and now being able to take what I had learned and bring that into amplitude. So exciting times for us at amplitude, especially within the data group, there's going to be some exciting things that we're working on over the next year or so.

Speaker 1 2:19

All right. Well, we want to have to, you don't have to tell the secrets yet we can wait breath. Um, but because you are new, let's talk a little bit about, um, you know, whenever you were working at Adobe and you were in developer experience area, I talk a lot about jobs to be done and for the developer persona, um, there's often a very clear jobs to be done that span across all different types of developer experience products. And so, um, you know, you and I were chatting a little bit earlier on slack and I feel like you broke it out in a really nice funnel, discovering API capabilities, consuming documentation, getting credentials and API keys, and then starting to like experience, you know, the value of that product. And so, um, I know you're early in that with, uh, with amplitude, but when you read Adobe, you know, what, where did your team start and turn to think about that and where you can bring delight to users, uh, when you build out the developer experience there.

Speaker 2 3:16

Yeah. You know, I think the first thing was actually Adobe is such a large company internally. I think we talked about developers in a different way. We talked about their journeys in a different way. Um, but, but our team was kind of built to look at the holistic experience end to end from discovery all the way through distribution. So our first step was who are the different personas in the developer ecosystem. It's not just developers, there's marketers, there's designers who are helping the developers there's decision-makers. Um, and how do they all interact with each other? And also where do Adobe's internal personas fit in? You know, the people that are either creating the API APIs or creating the documentation, the partner managers, the community managers, the people that are then reviewing the submissions. So one of our kind of early projects that we did actually had nothing to do with externally focused surfaces. It was how do you create those personas and how do you create a journey map that aligns everybody? So then when we're talking about, Hey documentation or the developer console, we all understand who the personas are and where are they in that overall journey?

Speaker 1 4:32

And you, um, when I think about personas and maybe when there's not attention being applied, like at the level that you are, people just think developer persona is just some bearded person that's, you know, kind of in a dark room. And you're kind of saying like, Hey, there's a whole team here that needs to feel engaged and almost go through that same journey. And so when you guys were kind of breaking out and Sue me now, and you mentioned a few different personas, like the marketing manager and maybe product different designer, where did you feel like there was the most, uh, ground to gain and understanding like personas that have been left out of the integration experience up until you sort of refreshing?

Speaker 2 5:11

Um, you know, I think it was the decision makers, um, depending on the product at Adobe, some were more mature than others. Some had higher demand than others. Um, but before you really even get the developers involved in, in a lot of ways, you have to convince people that this API or this technology, whatever it is that you're building is going to solve the problem that the company has. If you can't do that, if you can't get past the here's, what Adobe can do for you. And this is how you can do it. You're never even going to get the developer in the room to actually start building it. So I think there was a lot of work upfront on how do we talk about our API APIs? How do we show these things? How do we have documentation that even before you really do a deep in, it's really easy to understand and you can see there's been a lot of investment in that area.

Speaker 1 6:03


Speaker 1 6:05

I'll go ahead.

Speaker 2 6:06

I was gonna say, I think that was kind of for an external persona one to really focus on, I think from an internal persona, when we were thinking about within Adobe is for all of the, um, the team members that were reviewing submissions that would then end up on a marketplace, like plugins for Photoshop or Adobe XD. Um, we hadn't really paid too much attention to what their journey was to ensure that it was easy and it was fast and it was efficient. Um, because if that wasn't efficient, if it took too long to review a submission that then directly affects the developer experience, Hey, I submitted this three weeks ago. Why haven't I heard from it? And I, we didn't want those kinds of conversations to be happening because that does impact, um, you know, the ROI on somebody building on top of your technology.

Speaker 1 6:57

You know, recently I was working a little bit on a full Greenfield, um, API offering and I pulled out the journey map tool, and we were going through all of those stages in the funnel. Uh, when you were thinking about some of those different scenarios, like you just mentioned like a weighting paint point that could be found like on a submission, what do you feel like are some common pain points that maybe are overlooked, uh, that just really come out when you start breaking down the journey map and thinking about, you know, time to first value.

Speaker 2 7:28

Yeah. You know, I think, I think we talk a lot about time to hello world, right? The first API call, how quickly can that happen? But I think before that is how quickly can somebody understand the value of the API that you're bringing before they're in code? Um, how do you understand the different use cases that it can solve for? Um, and then, you know, obviously there's the, how do you get credentials and build on top of it, but then after I've built it, how do I ensure people will come? You know, this is not a, an internal workflow tool that I'm building for my own company. And it's something that I'm going to put to public market and list on Adobe exchange or the creative cloud marketplace. Um, like I've put all this work in, I want kind of a guarantee or something that that's going to be discoverable. So I think there's kind of the distribution aspect of it, all that that tends to get overlooked because once people build it, I wouldn't customers come in. That's something that Adobe really had to show, um, the developer partners.

Speaker 1 8:33

Yeah. So whenever I think about new product managers, one of the things I interviewed for a storytelling and what I hear a lot, and what you're talking about is do you want to understand the value? And then what stories can I tell people, uh, to inspire them? Um, and I know that you had shown me a little bit of the Photoshop demo playground, which I think is just awesome and my engineers, all of it as well, but what were some of the different storytelling tools that you guys feel like you experimented with and you know, what hit, what didn't?

Speaker 2 9:03

Yeah. You know, I had a wonderful designer on my team who is leading, leading that project alongside the Photoshop team. And we got to rely on them. They know their customers very well. They knew the problems that they were solving. So it was a matter of how do we bring that together into a visual representation of the API. You can go and say, Hey, we can auto crop a bunch of images and auto tone them, but there's nothing like seeing it actually happen. Here's a bunch of images that I've brought in. And I think, I can't remember where we landed, but I think if you like sign in, you can bring in your own images and auto crop that together. What does that really look like with my files or with, even with sample files? How does the auto tone work? I think, especially for creative software, it makes sense, like you really want to be able to visually see that. So I think we knew a lot of the stories that sent over some of our enterprise customers were, were coming to us with around having an influx of hundreds or thousands of images for a catalog and how do I, you know, crop them and tone them all the same. So they all kind of have that consistent look and feel for, for my catalog that I can then use in a bunch of different areas. So then it was just a matter of how do I bring that to life and be able to visually see that together

Speaker 1 10:26

So much, so much earlier in the user journey journey. And then time to first, hello world is like, is my story resonated? So you've got kind of first resignation and, uh, you know, so when you're, when you're talking about and knowing that you're just a design leader, I'm sure that, um, a bunch of creative ideas, you know, came forward on how might we tell these stories? So what advice would you have to a new product team who says, Hey, I'm trying to get my story to resonate. And how do you, how would you advise them to test some of those things qualitatively, quantitatively, you know, which tools in the UX toolkit, would you say these just do these things and you will see the truth.

Speaker 2 11:07

Yeah. You know, I think actually this is a principle for, for amplitude, which is customer is a part of the team. I think if you're trying to tell somebody the story, the best thing you can actually do is listen to the story that they're telling you, what are the problems that they're trying to solve? Where, where are their lost hours or high costs, because somebody's having to do something really manual that maybe we could automate if we had an API. Um, I don't think it's about, I don't think you have to force your story to resonate. If you're telling the right story, it should be resonating. And now there might be different stories for different types of customers or different types of problems that they're solving. But I think the most important thing tooling aside is getting that in front of customers, testing it early, saying, okay, this is what I heard from you. This is what, how I think we could solve it. Give me feedback. Is that going to solve your problem? Let's do a demo together. And let's have you run with an early version of the API. And like just continuing that feedback loop with customers that will let you know if your stories resonate.

Speaker 1 12:15

So you had mentioned an amplitude, the company's growing and like new things are happening. Um, what would be your advice to a company on how they should structure a winning team if they were going to launch a new API offering? So they say, Hey, Courtney, you know, we hired you as a consultant. We want to launch API for widget co who do we need to hire and what do they need to do?

Speaker 2 12:41

Yeah. You know, I think you need people that are comfortable talking to customers. You need, of course, engineers that know the ins and outs of actually building an API and what that means. Um, I would be remiss if I didn't say you needed a designer on your team. Um, I think, especially in this case, a service designer or like a UX focused designer, um, there might not be as much visual design that you, you would need. Um, but I think having a service designer who understands like the front of the stage or the customer facing touch points, as well as behind the stage or the like internal, uh, touch points, how those all map together into a holistic end to end journey is especially important when it comes to building an API, because there's a lot that you're not going to be able to see the developer doing, or be able to kind of get into that mindset. So really being able to map out, um, would be maybe a unique person that you might need on the team to kind of bring everything together.

Speaker 1 13:49

Yeah. It was, I'm talking to Matt who does as developer relations at most if the other day. And he was really showing me some tooling that they had created to know when a customer is struggling to integrate, you know, it's like throwing you some flags if you're getting, if they're getting a lot of errors and to your point about service design, it's really designed okay. In the event that the happy path is not so happy. How do we want to then design that kind of service to get them back on track? And I think it kind of gets a little bit to your, um, your encouragement to be thinking about journey maps and like, okay, let's start first with the customer journey and all the different personas and making sure their needs are met. So it sounds like you guys have a nice, uh, set up for my widget code. That's going to launch their ultimate team. So in thinking about companies launching new API APIs, you know, I was thinking, well, I should talk to Courtney about pitfalls. They should avoid. It sounds like one pitfall to avoid is just having the right kind of team structure. What is the second thing that you would advise on like, Hey, if you want to reduce of this thing falling on its face, here's something that you can also think about as a risk mitigation.

Speaker 2 14:58

Um, I would say the two is one, make sure your API is solving a problem. I think there's many times that I've seen, we've got this really cool technology. Everyone will want to use it. That might be the case, but the storytelling is super important. Um, and if you don't have that, nobody may understand the cool technology that you're bringing to light with your, with your API. So I think that kind of discovery to make sure it's solving real problems. Um, and the second one is how are you tracking success? Like, what metrics are you using? Is it the number of people who signed up for the beta? Well that's interest, but are they actually using the API? And even if they start using the API to your earlier point around, are they hitting a bunch of errors? Is it a happy path? Is it not a happy path? So I think being able to kind of put in place different metrics of success, um, to make sure that your API is doing what you would like it to do, and the customers are finding value in it.

Speaker 1 16:01

That's awesome. Um, thinking a little bit about tracking and, um, but not exactly going there, you know, if a new company is launching an API and they come to Courtney and they're like, what are two tools or vendors that you love, uh, from the ideation to the implementation and optimization? What are two things where you say, Hey, put this in your product stack, what would be some recommendations that you would have

Speaker 1 16:29

Other than apple?

Speaker 2 16:32

I'm going to say you kind of, that would be a really great one, but okay. Not using amplitude. Um, honestly I'm a sucker for Atlassian software, like confluence and JIRA in terms of project tracking. Um, that's been one that's been really great. Uh, we just recently implemented JIRA for the design team at amplitude, which has just really helped with all of our, like workings with cross-functional partners and just being able to manage and track what we're working on as well. Um, so I think just from a ensure, everybody on the team is working together towards the same goal, um, that any sort of project management software goes, goes a long way there. I'm trying to think if I have any unique ones that I can

Speaker 2 17:20

think about, there's one that's maybe not specific to API, but is a new one that we've been using called glean, um, which is basically like a workplace assistant. It brings together all of your internal, like slack, Google docs, outlook, whatever, whatever it is, brings it all together. And so you can just search across. Um, so I can just go like quarterly planning and it brings up literally every sheet. So I have to have 50 tabs open and Google Chrome trying to remember all of these links, um, just in terms of efficiency, that's actually been really, really nice product to have,

Speaker 1 18:00

I thought you were going to say segment and then connect it to amplitude.

Speaker 2 18:04

I mean, also that works, I think in terms of tracking, of course, um, I think amplitude does a great job of that. So, but I couldn't use it because I'm a little bias,

Speaker 1 18:14

So a little less internal, more external, you know, as a design lead. Um, you know, I'm just going to assume that you have great taste. And so with that, when you look at two external companies, other than Stripe, you have, who do you go to when you're like coming to check out their developer experience and maybe kind of pick up a few things for inspiration, where do you kind of go to keep tabs on people that are really spending the time like you are on this space?

Speaker 2 18:41

Yeah. Um, I mean, Stripe is Stripe for, for a reason. I think they do a very fantastic job of even just the discovery part of it. Um, let alone everything else. But I think one that we actually looked at for inspiration back when we were redoing the Adobe developer console was box, um, you know, I think box had a very natural way of using their developer console. Um, and it was pretty straightforward and intuitive, uh, everything from like being able to get your keys to then distribute your box app. That was one that was, um, maybe not one that everyone knows. Um, but I, it could, you could see that they spent a lot of time kind of working on that and making sure that experience was, was really useful. Um,

Speaker 2 19:36

another one I think, would be

Speaker 2 19:41

slack API, I think because it is so robust and now slack is in every company, pretty much, there's a lot that you can do with slack. And I've seen, um, you know, I've been hiring some designers and design interns that are using building a slack app as one of their projects for school. So it kind of, you have that breadth of people who are just starting out able to use it as well as the really powerful, like workflow automation capabilities that slack has. And they've done a good job at kind of enabling anybody along that path to be successful.

Speaker 1 20:24

Nice. You know, so in the, in the spirit of hiring, um, let's say for example, we're going to launch a new, uh, API and, you know, I assume that there's going to be engineering on that team, as you mentioned earlier, people that know the functionality and also will probably be part of this developer experience, but what advice would you have maybe even for like an internal transfer, a product manager, a designer that's going to transfer to go over and work on this developer experience team and kind of overcoming the imposter syndrome of like, can I be successful here? Will it be too technical?

Speaker 2 21:00

You know, it's really not that different. I think, especially for a designer, we are taught the design thinking methodology. You still do apply that methodology. It's just into a different realm, you know, instead of if you were in creative cloud and you were working on career, like your target audience where creatives, this just has a different target audience that are developers, they all have their own needs, they have their own opinions. It's just a matter of learning who those users are and becoming an expert there. Yes, it is slightly more technical. We spend a little bit more time with engineering, understand, like, what are the differences in authentication methods and what does <inaudible> mean versus, you know, something service to service. But once you kind of get past all of that, that's to me, no different than learning what it means to ingest and govern data. And what are the processes there? You know, I think it's just a matter of applying yourself to understand that domain, understand your users like they were anybody else. And maybe it might be, take a little bit longer to understand some of those topics, but there's a lot of opportunity here in terms of just, it's a really exciting space because not everybody's really figured out how to create an API product. So I think designers and product managers are very needed in this area. Um, so if it doesn't scare you or don't let it scare you because there's a lot of opportunity once you get in there

Speaker 1 22:40

Grow through being uncomfortable, maybe

Speaker 2 22:42

Yes, that is one of my favorite things to do as a manager is just push everyone a little outside their comfort zone. And I always say, if you're comfortable, you're not learning.

Speaker 1 22:54

So, you know, obviously you're new to amplitude settling into a new adventure. And so could you tell us a little bit about maybe a space where you've grown maybe from sometimes have been uncomfortable at Adobe that maybe you're going to apply that to your next challenge to amplitude?

Speaker 2 23:11

Yeah. You know, Adobe is like 18,000 people. They're a huge enterprise company. I had the unique opportunity of building a team from scratch in an area that previously didn't have a design team. Um, so we were working with people that didn't really know how to work with a design team. Um, all of them were really excited, uh, and working in an area even within Adobe design where not many people have an opportunity to build a team that has never existed because there so many teams. Uh, so I think that kind of uncomfortable. How do I navigate this? How do I, you know, bring in processes? How do I get resources? Um, because it's a new area that hasn't been well-defined, how do I kind of navigate all of that? That to me is everything that I'm building upon at amplitude, just at a larger, larger scale, because instead of my small team, within a large structure, it is our entire design team at the whole company is kind of at this place of what is the organizational and operational strategy that we need to have as a design organization to succeed. So I'm building upon what I kind of learned at Adobe and applying it to amplitude.

Speaker 1 24:32

That's nice. Well, cause we conclude, I will give a plug for amplitude. Uh, being a new user of the platform is already very intuitive. So I'm excited to see where you guys take it from here and unlocking even more developer delight or putting manager Andrew, as they're coming through to start to track their metrics.

Speaker 2 24:50

Thank you so much. It was a pleasure to chat with you.