Are the days of developer self-service over?

Speaker 1: Dev gone deep dives. You are.

Speaker 2: Yeah. Well, thank you all for joining. I think this is a topic on which each of you has has a point of view because you work for companies who are either looking to tackle this through a product or your product itself is is perhaps one that faces this kind of issue. So what are the risks that your organization faces when a developer signs up for the first time? So Kelly, would you maybe mind taking us through how that applies to to your company?

Speaker 3: Yeah. So Twilio does a lot of things now. We have communications Apis, customer engagement Apis, but I think one of the things that this applies the most to is the way that we work with Tele companies. And so Twilio works with global tele providers all around, the world. And so we have to basically have agreements under the hood of the Twilio Apis with these tele providers saying, you know, our Apis are going to not be abused, and we're not going to be abusing the services that, you know, you provide for for us.

Speaker 3: And so I think one of the things that we risk when we have this kind of self service onboarding is making it so that one of our providers shuts off access that may impact customers that aren't abusing our Apis. And so I think some of the risks that you you get with these types of things It's always money. Right? Like, people are are going to be looking at spending more money than they want to or Fraud is taking advantage of different accounts. But I think there's kind of the the customer trust risk that you have there too, whether or not that's a a customer that is doing the fraud knowing or somebody that, you know, has their credentials taken advantage of that ends ends up impacting other customers.

Speaker 3: Because of the the fraud that was happening in there. So I think that's one of the ways that that it impacts our services.

Speaker 4: Thank you. Chris Christina christina, I'd love to hear from from you as well when it's like.

Speaker 5: Yeah. So, great answer. I totally appreciate that perspective. Because I will say I'm probably another layer down. Right?

Speaker 5: Because we have merchants consumers and developers. So we have, from an Api perspective, the challenges that are faced with not only our developers, but, the impacts that come from a merchant and consumer perspective that ultimately, land with the developers. So we we, ultimately, I think for me, I'm really passionate about ensuring that the developer's experience from an onboarding perspective is seamless. And, when we talk about the layers, I have to think of the experience between the developers and the merchants. So what does that experience look like between the two of them as an operation model and ensuring that we are, consistently thinking about that developer experience to ensure that you know, we're not creating friction with the self serving onboarding that we're trying to enable.

Speaker 5: And I I will say that I'm, of sound mind of myself. Like, I've done a ton of research to know that, in our space, developers are very influential to merchants, and and ultimately, they are the ones who are deciding. So I don't think in my opinion, we we and our space can even think of not creating a self serving onboarding experience because of the fact that developers wanna test it. They wanna play with. They wanna see if it works and and fits the use case.

Speaker 5: And in order for them to be able to influence or even suggest a solution to a merchant. They've gotta be able to try it.

Speaker 2: So Sean, you you... You're at Google for for quite some time and and, you know, with a huge range of product offerings there in different different channels that that that that sold through. You must have seen all sorts of different forms of risk.

Speaker 1: Yeah. So I actually worked in a space not to differ than Twilio. So I worked on business communication products there. And Ask Twilio is, like, one of the developer partners that we worked with very closely. So we kinda had a similar level of risk, I guess where you know, we worked on a product that was not Sms, but was Rcs business messaging, which is, essentially the evolution Sms, and we provided Apis that people could create, you know, rich chatbot experiences over this channel.

Speaker 1: And certainly, you know, initially, we actually steered away from self serve when we first launched the product because of the, sort of the, challenges that come along with that in terms of managing, you know, fraud and abuse and and and so forth. But over time, we as we got better at sort of handling those and we understood the market better, we introduced self serve onboarding. But even with that, you know, there's always risk that someone's going to you know, have to take advantage of the system in some way. Or even not necessarily take advantage in in terms of, like, I'm signing up, and I'm going to, I'm purposely trying to use it, but actually, using it in a way that they think is effective for their business that actually feels like spamming or something like that. I think is a risk that is not talked about as much, and it's a little bit of, like, a gray area when it comes to these types of platforms where.

Speaker 1: I like, hey. Like, everybody, every company wants to do marketing. Every company wants to do sales. And there's, like, a, you're you kinda are constantly telling the line between like persistence and annoy with those types of of things that had been messaging. And when you add platforms like, email, Twilio, you know, the products I worked on at Google, you can cross that line without, you know, necessarily intentionally doing that because you're seeing, maybe our Delivered to your business, but you're actually...

Speaker 1: You might actually be annoying a huge amount of people in the process.

Speaker 4: Thank you. Yeah. I'd love to follow up with a with another question if I may. And And the question is why why are developer targeted products more at risk than those aimed at other groups?

Speaker 1: I'm happy to to start. Please. Thank you. So I think a lot of it has to do with, the problem space. So and you think about in our, in the physical world, You know, there's always risk for abuse and for fraud and these types of things.

Speaker 1: But At a much more local level. Like, if I go to a, a, a bar in my local neighborhood, and they want to, ask me, you know, I have to prove my age. I show my Id. In theory, that person could see that Id, memorize it, maybe to memorize every Id that they see that day. And there's some level of risk that they could use that information to do some sort of harm.

Speaker 1: But that's much different than me posting a picture of my driver's license on Twitter or it being exposed during, like, a data breach. So the... There's, like, a difference in terms of we have, like, locality essentially in the physical world, whereas the digital world and in particular for developer products where you can programmatic dramatically do things at scale, suddenly you're talking about like, global impact of something that maybe outside of the digital world is, like, fairly small, fairly low risk, even if something happens, it's not gonna be too too bad in comparison to being able to exploit, like, millions or even, you know, billions of people.

Speaker 3: Yeah. I definitely think it's a scale problem. Right? Because you can test these things really easily and see if you can get away with fraud and abuse at a scale that might be really profitable to somebody that's trying to take advantage of that.

Speaker 2: And so then there's the the scale, which is, you know, the great thing about everything, you know, it's the good thing as well as the bad thing for for for green software. But I guess as well, maybe is it is it easier to hide what you're doing sometimes. So without getting into creating a handbook to develop Api fraud. I'd love to know some of the some of the techniques that people use because I think the reason that I was interested in this topic is the, as I said in introduction, particularly in the payments on open banking space, there was a time in in in Europe when to use an open banking Api, you had to have approval from the national regulator for for banking, and that meant putting down huge amounts of deposit money and so on, whereas now it's been a little bit more relaxed, but that balance between fraud and and openness is having a real impact on both vendor and potential customer business opportunity. So yeah.

Speaker 2: What are the sorts of things that people are doing that are making this such a problem?

Speaker 1: So I I think there's So I think there's a couple of. So I think one is, like a psychological thing where... In a lot of ways this much easier to fraud someone in your home at at your computer where you don't have to actually see what the impact of what you're doing. All you see is maybe the positive impact of that of, like, oh, well, I'm like, you know, making money or or something like that. Is much harder to do that, I think in person as, like, a, you know, a g that's, you know, manipulating people in person.

Speaker 1: That's a much you know, feels much more, like, dia in some ways, like, from a psychological standpoint. So I think there's, like, a a disconnect that happens in the in the digital world that allows you to kinda feel like you have a little bit more freedom to to take advantage of these types of systems. But I also think that even though there are these challenges, there's also... I think we're getting... We we also have a lot of facilities to it, now available where...

Speaker 1: I think, in some ways, we're getting better at, like, detecting some of this stuff. You know, there are companies like, you know, sip science that use Ai to try to, determine patterns of behavior of, of, people who are, you know, causing fraud and systems. I'm sure Paypal has all kinds of things you know, going on in there in terms of machine learning in. I don't know, like, if you can name a single company that turned off self serve because they couldn't manage to sort of cost benefit ratio that you're taking on with self serve. So if that's, like, you're sort of way you need to go to market because your go to market is targeting developers that I can put in, like, a credit card and pay on a monthly basis, then, it's kinda hard to to to scale to the long tail without having self serve.

Speaker 2: Yeah. But I I I don't think I've seen personnel, I don't think I've seen companies who are saying we... The risk is too great and so we're gonna switch it off. What I have seen are discussions in companies where it will be used as an excuse, not by people who favor a top down business model. They'll say, well, in our industry, you know, it's too risky just to let anyone sign up.

Speaker 2: So we we have to do the deals on the golf course or over expensive sushi, whatever it is. Yeah. So

Speaker 3: I mean, I that we see a lot is, like, there's... Like, you have to sign up to use our service. Right? So we we have some, like, lead generation that sense. But, like, we never know if somebody...

Speaker 3: We don't always know if somebody signing up to use us at a hack on or if they're signing up to use us at a company where they're potentially looking spending, you know, thousands and thousands of dollars. And so I think what you're touching on right is, like, this idea that one of the arguments against self services is that you have that lead generation that sales driven that top down approach. And I think that's one of the things that I think of is my responsibility is to fight back against that mindset of, like, the reason not to do self serve is because, you know, we're gonna frame it in this conversation of risk, but we really want this because we're used to having the sales touch point. We're used to, like, being able to understand the the use case so that we can, like, hand hold them through how to implement this and make sure that they're... You know, maybe we're making sure that they're not doing anything nefarious.

Speaker 3: But I think that's our responsibilities is is developer relations professionals in order to build the guard rails as much as we can to prevent that type of behavior from developers, you know, like, yeah, you mentioned, like, doing stuff that maybe isn't necessarily nefarious, but is going to make something that is abusive or spam. It's up to us to have the documentation in place to to tell people the best practices on how to do things and design the Apis in a way that, you know, guides them to do that and makes it harder for them to make those mistakes. And I think that's something that, like, I have conversations about, you know, with some of the Apis that we have is there's certain Apis that we have that are completely self service, and then there's some, like, if you want a a short code with Twilio, you have to go through some additional approval processes. And I think there's different reasons for that that, like, we explained to the developers and some of that makes sense to people. And so I think one of the things that we're thinking a lot about is, like, what are the things that need to be self service and what, like, where on the scale can you, you know, basically explain why it's not?

Speaker 3: And is that something that you can gain the developers trust provide a sandbox whatever it needs to be in order to make that experience as seamless as possible without frustrating someone.

Speaker 1: Yeah. I think oh, go ahead, Chris.

Speaker 5: I was just gonna say... So from, my perspective... And I have a question on on the back end of this. But, from my perspective, I would say that I am aligned with all of them. It's definitely challenging with regards to our experience with getting into this ecosystem and doing the things.

Speaker 5: I'll say from a product perspective, because a lot of the times, what I'm doing is is listening and learning from the developer ecosystem, where I sit in the world. I'll say that, I feel truly that developers are misunderstood from the business. And and I say that because I I don't know why. I, it... Maybe it's a human thing, but people are very scared of technology.

Speaker 5: Like, the underlying, like, technology. So like, they don't wanna have those conversations and that's why I sit with the people I said. I love I love having technical conversations with developers. And I also, like, being able to provide an opportunity to voice technology and and not be afraid of you know, creating a sandbox. And and so my question was actually gonna be, like, how much is self service being impacted because organizations aren't creating or simulating, like, use cases or simulating things instead of saying, here's out...

Speaker 5: Here's everything. There's the entire Api. Do it yourself, backwards figure out our business rules, figure out, like, how much of that is impacted because we're not simulating the experience versus, like, expecting that I don't think about you... Developers don't expect us to give them every single piece of detail, but they expect to understand how it works. They expect to understand, like, and be able to see it.

Speaker 5: So I just wonder how much simulation of an experience isn't being prioritized, and that's what would create a inability to self serve onboard.

Speaker 2: Well, I think with question.

Speaker 4: Okay. I was

Speaker 3: just gonna say, I've been having conversations more and more about, like, the the value of, like, that simulation, the sandbox environment. Right? And I think that you see this with companies like, stripe, you know, do this where they provide everybody loves the the credit card number 424242, etcetera, because... It's it's a real Api experience, but, like, it was something like that. You're not actually charging something.

Speaker 3: And I think that is something that you can think about, like, with other Apis. It might have this kind of risk is, like, how can you create that sandbox experience or one of the things that we've been using is this idea of progressive trust. And so if you have, like, when you onboard with Twilio, you... In a trial account, you can only send Sms to a verified number, and that's usually your personal number. And so that's, you know, one example of, like, you're onboarding with us.

Speaker 3: You can't immediately send 10,000,000 text messages like, with a trial account. And so... But once you know, you give us a credit card. That's one way that we're like, okay. Maybe you're serious about this.

Speaker 3: Maybe you give us a business address you're more serious about this, we have a way to contact you if something goes wrong. Again, whether it's an nefarious or not. That idea of, like, you build up some trust with the business, and then we kind of unlock the doors from there. But I think to your point, it's very important that we have that kind of, like, simulation in that sandbox environment for people to get started, whether or not that is, like, granting them. Or because they...

Speaker 3: Like you said, they don't want the entire case to the kingdom right out of the gate. They want to also be kind of showing what to do and how to how to onboard with your Api in a way that makes sense progressively.

Speaker 1: Yeah. We could... I worked on something similar to that where we... One of the products that I worked on at Google called business messages where we had, like a progressive for a certain type of partner. So you could you could register...

Speaker 1: You could kinda get into the Sandbox environment all self serve, but then to actually launch the experience on like Google search. You know, there was a, you know, a more lengthy vetting process to do that because that's something that's, like, could be really bad for for consumers if it was the the wrong type of thing that was being launched. And, personalization would be, like, the biggest risk there, where I pretend to be Walmart or something. And then, but for for certain people doing that, it's very high scale, we would create, they would have have a a more in deaf process to that that partner essentially, and then they would be able to launch at scale, but it was a progressive launch, you know, start with 10 then a 100 or a thousand or something like that, you kinda like Bill trust. But I was thinking about this.

Speaker 1: I think I think one of the challenges that companies have. Especially with the growth in, like, sort of like, know, Api economy, like, developer first products is, I think what ends up happening is, a lot of companies, like, rush into self serve without thinking through necessarily the potential implications for their business. So then it's like an afterthought when these types of, like, like, a abuse scenarios maybe happen. Like, I think the holy grail for any product is, like, you know, self serve. People sign up.

Speaker 1: They put the credit card in. I never need to, like, touch anything. I don't have, like a big salesforce that I have to to run. Like, it's just, you know, you know, making money hand over fist and just, like, the the, you know, developing the product. Like, that's great.

Speaker 1: But I think the... There... There's... To make that flywheel to get to that point where we have that flywheel and everything smooth. There's a lot of thought that goes into, I think the companies that have done this really well at scale.

Speaker 1: That they're, thinking ahead of time of, like, you know, do we need that Sandbox environment. Do we need this kinda progressive build, like, building of trust. And I think there's a lot of people that are, like, companies things that end up, like, rushing into maybe self serve because they they wanna get to that whole your out experience that kinda thinking through the impact of that. And then The other thing too is there's, like a a balance of power that happens, I think, between products and and and self serve and the companies that have sort of the most power in the relationship. So if you take, for example, a company like Apple when they first launched onto ios, it was quite a process to build an Ios app and get that approved into the market.

Speaker 1: But people were willing to put up with it. Because all of that friction because of what that would give them. And similar with Apple business chat today, it takes quite a bit of effort to get approved onto Apple business chat. But people are willing to do that because then it opens you up to this massive massive... Or, massive market.

Speaker 1: Of people who are on ios devices. So Apple sort of holds the power there and people are willing to put up with of less than optimal experience. Now if you're a startup up, this is starting out, and no one, like, cares is what you do, then you need to significantly lower the barrier of friction, to get started. So then I think that's when you can potentially run into these problems where you're, like, you need to shortcut this sign process as much as possible because you're trying to get eyeballs, you're trying to get people to use your product. But then if you're successful, you end up I think running it into these abuse scenarios where maybe you weren't ready for self serve, if that makes sense.

Speaker 3: I really like that discussion of, like, how companies hold power with, like, developers and these types of things and I, I hadn't really thought of it that way, but I think that kind of ties back to the example of, like, if you're going to buy a short code Twilio. Like, you're pretty serious about using the product. And the reason that you would do that is because you wanna send a lot of messages at scale. Right? And if you're at that point, you've already tested out the product, you're willing to spend a little bit more effort because you understand what that's gonna get you.

Speaker 3: But I think for a lot of these companies, like, if you're a developer signing up for Paypal and you just wanna, like, test out the product. I'm assuming that, like, there's... You wanna be sure that that experience is useful for people in a way that gets them started, get them successful gets them to that Aha moment before, you know, they have to go through and talk to somebody in sales.

Speaker 5: Yeah. We... And we definitely see, like, just what I've heard in in the community, you know, they wanna they wanna test the things, and it's interesting because, the complexity that comes from the payment space. Like, I want to... Or...

Speaker 5: I'm I'm developing a solution for a merchant who wants to do payments every two weeks, and they wanna be able to do this that the other. So to describe that in a way, and then simulate that so that they understand how it works and how to recreate that, I think is probably the complexity that comes with that. And why it's so important, I believe to simulate because there's so many different use cases for payments. I mean, do you want ios? Or do you have an app?

Speaker 5: Do you have it in the web browser? Do you have it? I mean, it's if... There's so many use cases that it it definitely becomes overwhelming? And, as a developer who's just trying to understand how to solve my problem.

Speaker 5: Where do I start? I don't I don't even know.

Speaker 2: So then if... What would the practical advice be to people who are responsible for that onboarding flow right now? And, you know, they face their desire is to create something that says friction free as possible. But they have another team in the company who quite rightly are saying, Well, we gotta balance that with all these risks that we see. So how how do you argue your corner for friction free onboarding without seeming really naive, I guess.

Speaker 3: I think that this was touched on a little bit already, but there's there's Apis for this. Right? Like, anyway, Have to go through some... I think it's funny because you as a company, like, can use an Api like Sift science, and this is actually, like, what I work on at Twilio is all of our account security Apis. And it's funny because that started out a lot with, like, two factor authentication, phone verification, these things that introduce some friction.

Speaker 3: People are more or less used to now, but, you know, it takes time and, you know, there's a funnel for all of that. But one of the things that we're focusing on more is this frictionless. Stuff, this background authentication, trying to get information about a people about people and about accounts that sign up that are don't take any time and don't take anything away from the self service experience. And I think one of the things that we think about a lot is this idea of, like, risk profiles, step up authentication. You can use these background signals, you know, for determining how risky someone is, and then if you run into a scenario either by identifying someone through an Api, you know, like, sift, like, some of the stuff that Twilio offers, you can determine it is this something that we want to run then more authentication and introduce this friction on or is this something where we're going to only unlock a certain instead of features for these people if they don't...

Speaker 3: If they're a risk or profile until we do additional bedding. And so I think one of the first places to start is, like, figure out how much that you can do without adding the friction because I think there is a lot of, opportunities out there to you know, email, risk profiles, phone number risk profiles, bot detection. There's lots of Apis out there that you can build into your onboarding flow, and I think most people are already doing this at this point, but I think thinking of that is not just like, a a silver bullet, but also as that, maybe this is a a way that we can divide up people into different risk profiles, and then if you're a risk account, then take them down that more friction full path.

Speaker 1: Yeah. I think that's a great point. I think a lot of it I think you need to, also, like, assess, like, what are the goals that you're trying to accomplish? Like, does like, frictionless sounds great? But, does that necessarily, you know, is that gonna lead to, like, a, like, moving the needle for your business Ultimately, it depends on, I think, like, where you are as a company, what kind of customers you're targeting?

Speaker 1: Like, if you're really talk to targeting customers that are signing, you know, multi year contracts. Then that might not make sense for your business. And maybe someday you do self serve, but it's a, you know, it depends on, like, what stage your company is and what your resources are and where you wanna focus your attention. And then I think the other thing too is, like, if you think, like, okay. Well, we really need to do self serve onboarding, we wanna reduce friction as much as possible.

Speaker 1: That's gonna lead us to success. Then you wanna understand the risk. So if there are people in your company that have this hesitation or they understand. Okay. Well, this could happen or this could happen, You need to kinda work through those risk scenarios.

Speaker 1: Figure out like how do you balance the, or, like, you, essentially balance risk with friction in a way that's going to be successful. And there's you know, there's different techniques you can use. Like, it there's people are probably familiar with the idea of like, running a post mortem where you can run, like, a prem mortem essentially where you look at your system and you go through at each stage and you're, like, if someone gets to hear what is the worst case scenario and then how do we protect against that. So you need to kinda... Like, I've saying earlier, like, this stuff can't be an afterthought, it's something that has to be kinda baked in the design process from the beginning.

Speaker 5: I wanna you piggyback on both because I loved absolutely both of those answers. I also think, outside in thinking. I think that the phases that a developer is in in your ecosystem is extremely important to think about? I think we often oftentimes... So we're we're talking onboarding, but what about when they come back and then they get that two factor authentication or if they're in the middle of development, and then they have to validate.

Speaker 5: Like, it... It's it's in my mind, the end to end experience, including onboarding, and then so on. And if we don't consider the phases of the developer's life lifecycle within that that experience, we're gonna always create friction. And yeah. I mean, I I definitely think that there's that, act I'm gonna talk product owner, as a product owner, the stakeholder management and ensuring that as a product owner, I'm bringing that developer's voice back to those that are determining that that model of risk and and what that experience looks like.

Speaker 5: And ensuring that that, you know, we're not creating a friction environment. I will say that, I think, you know, generally speaking, you're... I mean, at least my goal is to keep someone in the ecosystem. Right? And I think that what we don't necessarily think of is because there's so many Api because there's so many different solutions and so many corporations and organizations, it's very easy to drop a company and and move on.

Speaker 5: Like, it's extremely easy. So, you know, from a developer's perspective, we we just... I could... I take their voice into consideration, manage the stakeholders and ensure that I'm thinking from the outside in, not from the inside out.

Speaker 1: Yeah. Yeah. I think, like, doing back, I think, like, you, so building what you're saying back to one of the things I mentioned about goals. Like, if your goal was self serve is you wanna give people a chance to play with the product because you think that that's how the best way for them to understand how your product can, like, be a solution for them. Then there's...

Speaker 1: I think there's ways of you know, crafting a solution to to solve that problem that don't necessarily give them sort of the keys of the kingdom like, like, Kelly was saying that, you know, you can sign up in Twilio. You're... You can send, you know, messages to certain phone numbers and things like that. But is not like you get a short code and you're starting to send messages, you know, text messages from, like, the short code of Walmart or target or something like that immediately. There's a lot more involved to get to that stage.

Speaker 1: And so I think the... If your goal

Speaker 3: is clear. I wanna do not allow that.

Speaker 1: Yeah. So if your goal is really, like, I want people to be on to play with the systems so that I can convince them that this is like a a good product thing that's solve the comes. Like, there's lots of ways of doing that without them having a need to go to, like, live production where you kinda bring on all this risk into your system.

Speaker 3: I think this is actually another interesting point about, like, one of the things that people are sometimes worried about too is that, like, you can, like, write an infinite loop with some of these Apis and all of those sudden of oops. Like, you're talking to support about the large bill that you ran up. And so sometimes, like, limiting the amount that somebody can do upfront is beneficial too because then they're not as afraid of, like, oh, crap. I don't really know what I'm doing with this Api. Like, there's benefits of, like, scoping the self serve.

Speaker 3: Opportunities from a, like, a billing perspective and making sure that people are, you know, discovering and playing on of the Api responsibly.

Speaker 1: Yeah. That's that's a good. I I think another thing to that companies don't necessarily think about sometimes when building self serve onboarding is, the risk that actually brings to their company not for using fraud, but for you know, bad, like, a bag developer experience. Like, you you can create something where someone can sign out. But if you don't have the, like, the documentation that's available or, like, you know, Sdk or, like, all these other components and ask that someone needs in order to be successful to product.

Speaker 1: You might actually be kinda, like, shooting yourself in the foot where is it might be better to kinda, like, walk through... Walk people through, the process to start with list so that you know, like, here's, like, the friction points is where people getting stuff rather than just kinda, like, opening up the gates from day one. Like, you have to really think about, I think the more holistic picture. And all the things that go into making, like, a really successful vu experience. If that's the path that you wanna go down.

Speaker 1: And that takes a while to kinda get there, I think.

Speaker 2: So then in effect the friction that you introduced through progressive permissions. Actually, you can tie into teaching someone, the platform. Will

Speaker 1: they Right. Yeah. I think if it, like... It's like a video game. You, you don't start out a video game on level one, well, maybe in the nineteen eighties, but nowadays, the way the are built.

Speaker 1: You start out pretty modest. You know, you can jump. Maybe you can, you know, punch somebody or something like that. And then, you know, sixteen hours later level, you know, 23, you're, you know, str thing and you got all kinds of weapons and you're, you know, you you're... You look like a, you know, some sort of side board using the the game controller.

Speaker 1: But it takes all this stuff to build out to that skill set. And I think it's similar with developer products. But you don't wanna just be, like, alright, here's, like, all the Apis and go nuts It's like... People don't learn that way. It's more, more of a progressive learning.

Speaker 1: So it takes a lot of thought, I think to work through what it is that people need at the up upfront and then kinda like, building on that. And, that takes time, like, working with more directly with developers understanding what they experience was like, where the friction points are, where the types of things that they need. And it's hard to kinda build that in the vacuum. You really... Just like any product, it's kinda...

Speaker 1: Is gonna fail the first time that encounters real users so you need to, kinda I think, not necessarily rush into that. Start with hand holding, make sure people be successful and then when you get to a stage where you feel like that you... Can build all that stuff that people can be successful on their own, then you can kinda open it that up and and give it a try.

Speaker 4: I love that. Thank you. One one one question I'd love to ask. And maybe this is more of a of a of an open ended question I'd I'd love to hear from the three of you. If I wanted to start building a self service program from from my for my developer tool.

Speaker 4: What what are some what are some pieces of advice, some some some scars perhaps that you'd love to warn me about?

Speaker 5: I go first. I think, you know, it it one of the things that I tried to keep top of mind is that a developer in the ecosystem is a customer in one way or another. What whatever customer is defined to you. Right? So a developer in the ecosystem is a customer.

Speaker 5: And in order for the developer to have a good experience, you not only have to think about the happy path, but what about the unhappy path? How is that developer gonna get support? How is that developer going to be monitored or are engaged in the ecosystem of the support systems? Are are they gonna have you know, the ability to know that on the other side of technical support, whoever the support team is, they're gonna be able to know what Apis they're using what Api calls they did. How many times they got a 400, five hundred two hundred how they're gonna get through that with the support.

Speaker 5: So I think for me, it's in that onboarding, not only are you thinking of the developer's experience and how successful they're gonna be, but you also have to think of the business and the operations and how how you're gonna... How you're gonna, like, create a frictionless environment between the two of them?

Speaker 3: I spend most of my time thinking, like, one step before that, and I really appreciate that perspective because I I feel like what I think a lot about is getting people to that, like, A aha moment as fast as possible. And so somebody comes into Twilio and they say, like, hey. I wanna send a two factor and, like, check a two factor authentication one time passcode. I wanna get them doing that. As quickly as possible.

Speaker 3: And so my goal with the the types of functions that I do, the blog posts Write, like, the code samples I provide is to make sure that they're equipped to get up and running, have the token sent, be able to check the token. Again, like, that Aha moment is a really... Like, a satisfying experience for a developer no matter what Api you're using. And there's certain things at Twilio that we we do that well and there certain products that were not great. At doing that.

Speaker 3: And I think that's sometimes due to Api design. Sometimes that's due to the documentation. Sometimes that's due. To just a general product complexity. I think sometimes you can't avoid, like, that taking a little bit longer if it's something that, like, you have to embed a mobile Sdk into your application.

Speaker 3: That's not necessarily something that's gonna happen in five minutes. But I think, like, one of the things I advocate a lot is that, like, very first getting started experience and trying to make that successful and satisfying experience for the developer and as little amount of time as possible. And there's tons of things that I'm skipping over. And because of that. But I think we're...

Speaker 3: I'm lucky that we're, you know, a big enough company now that we have lots of people coming at this from different angles to... So I can advocate for that kind of getting started experience while somebody else is pushing back on, like, the well, how do we capture that, like, support experience after. And I think you you do need these different perspectives in the room.

Speaker 1: Yeah. I think I think that I think that's great. I I think a little bit that happens before you can get to that stage too is that you need to understand even the use... Like, your use cases. So you know, the the fact that, like, you know, Twilio has been around a long enough, To understand probably a, a, a lot of types of use cases for different verticals, so you can kinda optimize down that path.

Speaker 1: But if you're, like, an earlier stage company, and you have an Api that you're bringing to market, you might not actually understand all the types of use cases or the things that people wanna accomplish with it. So I think before you can kinda try to optimize down a path, you need to to start by, like, actually talking to people who using your Api. And that's probably something you should, you know, continually do throughout the, you know, your company's of life. But I think my, like, number one advice would be just, like, figure out how to talk to people and figure out what it is they're trying to accomplish and what hurdles they're they're running into. And then that.

Speaker 1: And then from there, you can start to build, you know, prototype things, minimal viable products, and it's really this cycle of, like, design, test, iterate a get feedback iterate, and you just kinda keep doing that in the the shorter you can make that cycle and the faster you can spin that flywheel of learning, then, I think that's, like, how you end up creating, like, a great product. And then, additionally, when it comes to developer experience, I think, like, one of the missteps that companies could sometimes make. Is they don't think of like, the the product experience, the Apis, the docs, the Sdk is kind of one unified product. You end up with a situation where each of those things are owned by different parts of a company. And if you can see the org chart in the representation of those assets where the docs looks like a completely different thing than the Api reference in the Sdk in the product.

Speaker 1: And the companies to do the best job in the world I think with creating a great dollar experience, especially when it comes to, like, self serve onboarding. All those things kinda, like, work very nicely to get. They're all kinda building off each other. You go to the Sk and maybe that lead you into the product and the product can lead you into the docs, and they kinda all, like, like, sing together in some way. And I think I always think about it is, like, you wanna create, like, a a Disneyland ride where people are having this like, great experience, but they, like, if you're in a Disney I'm right, you're not getting off the ride to go, like, explore.

Speaker 1: You're kinda directed down this path where the things are are there to, like, entertain you and create this great experience, but you're being fed that thing. And a lot of thought has gone into what goes into that, you know, feeding process in terms of entertainment. I think a lot of thought has to go into the feeding process for, like, a great developer experience too.

Speaker 4: Thank you. That that's those... These are fantastic points. Thank you. Could it then be argued that that, you know, given that get this is this developer experience and, you know, this this race to the Aha moment, this this sort of, like unified product has such an importance, could it be argued that this should that the sort of, let's call a development of this self serve onboarding experience should could not be an afterthought, but rather part of the development of a product itself?

Speaker 1: Yeah. I really agree with that if that makes sense for your plans for go to market. You know, if that's defined with how you wanna take the product to market, and you need to be thinking game that that probably from the the onset of developing the product.

Speaker 3: And I, Christina, Had mentioned this earlier that, like, even if you are in a sales led motion, and this is something that, like, as Twilio was grown, You know, we started out mostly as a self service company, but now, you know, we have a much larger sales team than we did twelve years ago. But still, like, developers are in the rooms when these decisions are being made, and they're often the ones that are advocating for the solutions that you know, even if they're not the ones with the the company credit card, they're the ones that are influencing those decisions. And so having at least a playground or a sandbox or something where they can try it out and understand, like, what they're going to be working with. Can be really invaluable to even a top down motion as well.

Speaker 5: Yeah. I'm in second all of them. I mean, I just... I totally agree. It's...

Speaker 5: Yeah. No. I'm I'm with everybody else. I have nothing else to add value.

Speaker 4: Thank you.

Speaker 2: Well, look folks. I think it's it's it's clear that the answer to the question post in the round table title is no. So I think we've sold that. That's great. But, I mean, more seriously, I guess my main takeaway from this conversation is the, is the duty of people designing developer experiences to balance that risk with the need for developer autonomy.

Speaker 2: And so developer autonomy doesn't have to be a free for all where you're just thrown into a situation with no guide rails. But rather it's a case of the risk of fraud, the risk of non intentional, but nonetheless, bad behavior is just one of the many things you have to balance in designing the developer experience. And self services is still possible for all sorts different products. If that's your go to market, but it's not just fraud and risk that the that you have to think about it's it's really a whole palette of of different concerns.

Speaker 1: Yeah. I think I think people discount how much work those into integrating a great self service onboarding experience. And they think, like, okay. Well, of course we want that. And we'll...

Speaker 1: You know, you create it. Just like they discount maybe the the impact that might have from, like, a fraud and the abuse the standpoint as well. So I just think, like, I... Anybody who's thinking along these lines to kinda slow down and think deeply about what it means for your business would turning on self service right now. Be a bad idea.

Speaker 1: Like, would that hurt... Actually hurt your brand because you don't have all these other components that go into it, and it would actually end up, like, leading to a worse experience for for customers whereas if you're... Especially if you're early, like, it's really valuable have people in those conversations with with customers. And I understand me... Like, the...

Speaker 1: You want, there's, like, maybe pressure to turn on onboarding so you can really scale, but you might not be ready for that scale. Yeah. And then, the other thing is just, like, if you're going to go down that path, you really... It's really like, a big product decision that you need to be thinking deeply about, not just, like, the risk and abuse scenarios, but kinda like all those components that go into it.

Speaker 5: I, I'm gonna lead lead with I was second, Sean, and I always go around saying, just because we can doesn't mean we should. So, You know, I I... Just because we can doesn't mean we should. So to Sean's point, I think, you know, thinking of that experience end to end and all the things that we've brought up today, I think is extremely important. And just as you can or you think you should.

Speaker 5: Doesn't mean you should. I mean, you you need to make sure that it the experience is optimized.

Speaker 2: Great. Well, Kelly, Sean, Christina, Thank you very much for joining us today. I would just like to ask you, where can people find out more about what each if you're doing or or what can they find you on the internet?

Speaker 3: I am on Twitter at kelly Robinson.

Speaker 5: I'm also at twitter at dev underscore Christina.

Speaker 1: I'm also Twitter, Sean Faulkner, and then you can also find me at our at our company's website sky.com. So you can learn more about what I do for my day job. Dev Con deep dives.