From mobile app to mobile developer tool with Gabriel Savit from Runway

Gabe 0:00
We were building for ourselves. And we were building for the mobile world and this kind of user, the classic, we were solving our own problem. And I think that's how you see it pay off well, down the line.

Jack Bridger 0:12
Hi, everyone, you're listening to scaling dev tools, the show that investigates how decimals go from zero to one. I'm joined today by Gabe savate, who is the CEO of runway and runway as a mobile release management platform. Gabe, thanks so much for joining. Could you share a little bit about yourself and runway and how you got to where you are today?

Gabe 0:34
For sure. Thank you, Jack for having me. excited, so excited to be here and share a bit about what the team and I are up to, and how we got here. So. So yeah, runaway mobile release management, to sort of underlying themes that we might come back to. One is automation. Understanding, there's like a lot of moving pieces in, in this sort of release cycle for mobile teams playing out across a lot of tools. And this is more than just your build pipeline. So we sort of connect to Ci CD, but we also sort of span from your version control a lot of the gate wrangling that part of the process through project management tools through, of course connecting to the different app stores. And, and then also testability, monitoring tools to capture sort of health of releases. So connecting across the US and automating as much as possible end to end, for folks, without any scripting or diverting product engineers resources to the less fun stuff. So that's one side. And the other big one is around collaboration and how teams work together. And understanding especially for mobile, there's a lot of interdisciplinary involvement, there's a lot of sort of gated steps, because you're shipping binary. And creating a place where this sort of cross section of a team engineering product, QA, engineering managers, other stakeholders, they can all get eyes on the state of releases what's happening across the team to chip in along the way. And so it really turns into sort of this collaboration tool as well. So long winded explanation to try to paint some of the picture of what we're building. Yeah. And

Jack Bridger 2:19
it's, it's, it's a mobile teams, it's always hard in the sense, like, what version of the app, are you testing and all this sort of, like, it's always, you know, obviously, different app stores and stuff, always a pain still, right? For a lot of teams by using runway.

Gabe 2:37
Yeah, there's a lot of I mean, there's a lot of things to keep tabs on and across a team of any kind of scale, you're gonna have all sorts of different sort of, maybe Feature Focus teams contributing. I mean, again, it's like this, this many to one where you have a lot of folks, different parts of the company may be working on mobile, and that all has to sort of coalesce into one place, and then ship with a single binary. So there's that sort of coordination angle, there's always sort of the versioning problem with shipping again, for mobile or binary, you have this long tail of different versions that you have to support. So having a clear picture of what your user base is actually seeing what they're all on, sort of wrangling the different flavors of builds that you might be distributing. And, of course, the third party ecosystem problem. So dealing with Apple and Google, who, interestingly, increasingly, people have probably heard of the apple review process where every time you submit a new version, folks on the Apple side, need to get eyes on it and check it out and might might reject the update. Google does that too. And anecdotally, increasingly, on the Google side, which is interesting. So So yeah, that's sort of a third party element that creates a lot of uncertainty in the process for teams. And yeah, there's a lot to kind of stay on top of increasing number of different platforms to ship for different flavors that you can ship for, from smaller form factors, like watches to TV stuff, of course, to phones themselves. So yeah,

Jack Bridger 4:12
yeah, that's so awesome. And I always felt like the mobile experiences a lot kind of lacking compared to what web developers have. And like, there's, there's a lot more like configuration and just like doing kind of annoying stuff in mobile, I feel like

Gabe 4:29
yeah, that's a that's part of what led us here is these two, two kinds of things happening at once one mobile is continuing to grow as an important platform for for companies. Users are spending more time on these other platforms and it becomes bigger and bigger revenue driver curve for these these companies. So increasing importance at the same time, you're not seeing sort of matching attention paid to the mobile or development and release experience. So tooling is lagging behind a little bit. And just sort of the specialized stuff that you you kind of need to have in place to, to be very smoothly and collaboratively shipping updates and going through the whole process there. That sort of lagging. And that's where we are fitting in. And that is, that's also part of the part of the origin story. We're a team of our founders are former mobile engineers, including myself. And so we've lived that experience, you know, building and shipping for mobile on different kinds of teams, different skills, different kinds of products. And kind of compare the experiences we've been sort of work together many, many years ago, at Rent the Runway as their first iOS team. And we all just about all of us dispersed to different mobile teams, but remained friends and started comparing notes and sort of realizing a lot of these sort of pain points, friction, in efficiency, kind of quality issues that exists in the process is common to a lot of teams. Just about all teams, and it sort of manifests in different ways. And, and we thought we could we thought we could tackle it.

Jack Bridger 6:19
Yeah. So you took a lot away from that. Experience. Ones stupid questions, everyone very well dressed in the wrong way. Team.

Gabe 6:29
Yeah, our female colleagues, for sure, sort of Rent the Runway. Yeah, doesn't do Menswear. And so yeah, but they had a nice employee perk. And it was a good way of getting folks to dog food, the product, of course, where folks could be renting renting stuff. And And yeah, that was fun. So stylish office.

Jack Bridger 6:51
That's, that's awesome. And so how did you kind of get started? Was it like, you were just like, in a bar or something like everyone talking like, Oh, this sucks. Like, we should just fix this or?

Gabe 7:02
Yeah, it's, it's actually, it's interesting. We saw, like I said, we, you know, remained friends, even though we ended up working different places, you know, we're in touch regularly, but it really came together, there's sort of a lining of stars, and came together during COVID. And so we were all in separate places, and actually had a group that was like a group thread, maybe on WhatsApp and kept in touch there. And we had actually always talked about working together more in a sort of agency setting or setting up something like that, where we could all because we had the full, you know, the full spectrum of everyone you need and just create the sort of little small agency and build awesome apps where people work together that way. And then we sort of, you know, broaden that and started talking about what are some other problems we can solve? What would it look like to kind of build a build a startup together, and literally started with a shared this WhatsApp thread and then a shared Google Doc? And, yeah, I mean, I guess I don't know the initial sort of trigger, like what you're good at all. But once that was there, we started dropping in some, some ideas. And one of one of my co founders dropped in the release management idea. jotted some notes there. And it immediately resonated. The, the process of running a release was something I remembered like viscerally different teams set this up differently. But very often, on a team, if you don't have a dedicated sort of person for this or a team, you will share the load across your different engineers, and maybe PMS, maybe QA. And so there's this rotation that set up where for any given release, and you might be releasing weekly or bi weekly, it would be like common for, for kind of fast moving mobile teams. There's gonna be a different point person each time, it's like a round robin. And so I remember it every time it was my turn. You know, if you have a largest team, your turn is not so often but it's just often enough. It comes around you have forgotten how to do everything, you go into this sort of checklist that lives in like a spreadsheet somewhere, Doc, it's not kept up to date, there's like little holes and gaps, you end up needing to ask other folks for kind of their input along the way. And it's also just a week or two weeks of split attention. You know, you're having to keep tabs on the release and keep track of progress and looping the right people at the right time. And for for a product focus engineer, that's not that's not fun. You want to build you want to you know, do your do your job and not kind of be a traffic cop or kind of manage to sort of admin that comes along with releases. So yeah, kind of visceral and it resonated immediately, and we all sort of started circling around it. We were like why? Why? had we've been dealing with these spreadsheets and Docs and like, Why was there so much confusion and noise on Slack? Each and every time we released, there really should be a better way to take over some of the workload, again, with automation, but also for the parts where you do need to collaborate, give that a home and sort of like, make more transparent the key piece of info that just each and every release, we're getting passed back and forth, just ad hoc. So yeah, we kind of took that and ran with it. Yeah, what was

Jack Bridger 10:33
the first like, kind of step or? Or launch? Or how did you get started?

Gabe 10:38
First, it was a whole bunch of interviews. So we obviously had the firsthand experience, we already had a good amount of, you know, conviction about the problem space, and what a solution maybe could look like. But we wanted to validate that. And so before we started writing a single line of code, we set up as many calls as we could, with folks in our network, former teammates, folks that we knew working in mobile and other teams, friends of friends, like any connections on different kinds of teams, different sizes of teams, we, we had the thought early on that this is something for for mobile teams, period. That's kind of the ICP, if you're more than maybe more than two mobile engineers working on something and shipping it regularly, this is something for you. And so we had a lot of conversations with a lot of different kinds of teams. And had a lot of questions. And also just let people talk and sort of describe their existing process to get a sense for sentiment around it, who was involved. And other pain points and friction that we might not have identified. And so that was super helpful. And it wasn't 100% hit to be honest, like we had, we had to have a mix of the the personal conviction and some of these additional data points. Because often you talk to folks on teams who maybe they are part of a larger team with a rotation, and don't have to deal with this process so much. So maybe they last ran a release a while ago, it's out of their mind, and they're not really remembering the pain and the frustration and the friction that exists. And so you get a sort of listen, acute response. And then sometimes you talk to folks who are actually not involved in the process, again, depends on the team setup. And, you know, we should have been, obviously, and tried to get to someone closer to the process, but you have folks who sort of are viewing it from the outside, if you're on a team that sort of has a subset of folks or different group running releases, you can kind of look from the outside and be like, Oh, works pretty well, you know, we get our work in, we get our PRs merged in QA, and, and then they just, you know, go out the door with the train. And so it's harder to, you know, pick up on on some of the pain and friction that exists and also the failure modes, it may look to you as if you're just merging code and it goes out the door. But sometimes that feedback loop is not closed, where you're shipping regressions or maybe there's some integration kind of issue with other work going in. And it's someone's job to sort of triage and solve that. And so, so yeah, a blend, something we found is like, releases aren't always top of mind for for everyone on a on a mobile team at any given time. And so mixing the inputs from from interviews, and also the personal experience in that conviction. And then, and then going from there.

Jack Bridger 13:42
Yeah. And so you kind of had some feeling that there was this issue, you had a little bit, but there was still not, you know, full, you know, 100% this is this is absolutely guaranteed to work. What was it? Like, then what was the next step after that, once you kind of gathered that feedback?

Gabe 14:00
Yeah, I mean, we got to a point where we were kind of happy with the direction the feedback and input we had, and and then we started building. You know, that's first and foremost, that's what our team background is my background. Engineer, and product focused engineer, I guess you'd say, which is true of a lot of mobile folks, this is also sort of a factor I think in this whole deal is in the mobile world, you have a lot of engineers who love building product and so they're naturally less less into the whole tooling and and automation and scripting stuff. That has changed a little bit as mobile has matured and you get more specialists who do kind of mobile tooling, mobile DevOps automation stuff. But but you tend to find more of these product engineers who would love to just with no with no friction and no no other tasks on their plate, just build and ship product. So anyway, that's our team's origin. And so we got to work building I think We were pretty heads down building for maybe three, four months, it'd be a bit longer. And it all kind of blurs together now, and tried to get an MVP into people's hands, ASAP. And this was really tough, because the nature of runway as a tool is that it is very broad, it's meant to connect across your whole tool chain. So there's a lot of different tools involved. It's meant to sort of cater to these different sort of roles on the team. And a pretty expensive process. And to kind of go to market with an MVP of that is, is hard. And we felt that the the sort of breadth of the framework aspect was was inherent like it's, it's crucial. So thinking about the scoping are starting with one integration, one part of the process, we, we didn't have confidence that we could go out there and really get that as a foot in the door and also weren't excited, but it wasn't the vision. And so I guess, you know, people, people offer different advice on this front in terms of how you scope things, how you sort of, maybe kind of chop things up, to get something out quickly and get an MVP out quickly. We wanted to at least get the Brett into the MVP, even if it was a thin. So we talked about the tool being kind of like, very broad, but thin to start with kind of this, this layer sits on top gives you just enough of this sort of connective tissue that you start getting a sense for what what sort of power it can bring. So anyway, that's how we started, we built sort of the end to end piece with a first set of integrations, ASAP. And we started obviously talking to a few teams from our network that folks had been on before, and tried to give it to them to to give this first version a shot. And that's also a no mean feat, because and this is something we're still contending with. And still kind of we've come a long way on but because runways so broad and so fundamental, it is sort of it becomes very tightly coupled to how teams do things, it becomes sort of like part of the fabric of the way these teams are working. That's obviously great. Once you're in the door, things are sort of up and running, it becomes the new, the new normal, the better way of doing things. Before that. It's tricky, because like we we pop up in so many different parts of a team's process. And we affect or could affect, or be used by so many different people on the team. And so there's some sort of behavior change, perhaps some friction, to convince folks to even try it. Because from the outside, it feels like there might be some lift for a team. We weren't charging at this point, of course, the first few pilots, you know, free, give this a shot. So in theory, there's no hurdle there, there's no friction, but still, it can be seen as disruptive to a product engineering org, you know, operating and shipping at scale, they need to make sure their releases are getting out the door. And they have very busy engineers who sort of can't be, you know, onboarding, are learning a new tool. So yeah, that was one of the early early kind of frictions is built just enough that folks want to give it a try, it's going to have a couple of nuggets of kind of time saving value there for them or, or kind of the the better way of working that improves kind of how the team's collaborating reduces some of that, that overhead. And enough that it it sort of outweighs the little bit of work they might need to put in as well.

Jack Bridger 18:59
Yeah, I was actually gonna ask on your like very first customer or like first user, do you remember how you kind of persuaded them to give you a shot? Yeah,

Gabe 19:12
it was a lot of a lot of dialogue, for sure. We looped them in like even before we just like handed something over. They were definitely involved as we were building out the MVP. So I guess we could call it design partner, for sure. Make them feel a part of the process. And of course, in doing so, make sure you're hitting some of the high notes that they would want to see out of the gate. So there's a lot of conversations like that for sure. We were also Yeah, I mean, it's a bit of luck, or maybe we generated this but like you get someone who really believes in the vision. And so they're they're going to understand, you know, this MDP is going to be a shadow of of what's to come, but we're going to buy and now we're going to help you kind of build it out because we Like the direction it's going, we can see kind of where this is headed. So you get that buy in again, like rapport building. And of course, we had these connections from past teams, but working with them, as we sort of laid out and started to build towards that vision. Getting that buy in and, and going from there.

Jack Bridger 20:18
Yeah, that's, that's amazing. How many of these kind of like very, very invested people early on did you have? Because it seems like you probably wouldn't need that many. Or maybe you couldn't even manage? Having many of those are the beginning.

Gabe 20:32
Yeah, we had. I think we had three that was kind of the first cohort was three teams. Who, yeah, more or less look like our current ICP, like medium to largest teams, shipping critical mission critical mobile products. And, and yeah, so we started with those three. And, yeah, it was a lot. Of course, we also during this time, we were in yc. So we were going through the batch and working with these teams, too. And there was a lot, a lot a lot going on. But But yeah, it went pretty well, all things considered.

Jack Bridger 21:14
Yeah. And how do you kind of, like they're probably sending you like, we need this, we need this like, I would, I would be guessing that that's happening a lot. But then you probably also have like your own ideas about where things should go and stuff? Or, like, how was that kind of

Gabe 21:32
period? Is it is a good question. There's a balance to be had there for sure. And I think this varies by teams and what you're building and how you're building. But we, again, had this early conviction and an early picture of not just this sort of the next steps, what this will look like, you know, in the next version, we ship but also like, further out into the future, these bigger pieces, other pieces we want to bring in. And so we were lucky, or maybe again, this is just sort of aligning with with the sort of the market and the end user. We we didn't have to sort of deviate wildly from the overall vision while still taking on board like plenty of feedback and ideas. And that's also I think, maybe the nature of the platform, because the vision is so broad. There's all these different pieces that we know, we want to do a lot of the feedback and requests fit into that big vision. And then it was just a matter of reprioritizing if we wanted to, this is a thing that that yeah, we knew we wanted to do. If we get a sort of burning requests for it, maybe we can bubble it up the priority list. And so yeah, there was nothing like to sort of disruptive, I guess, on the sort of roadmap, a lot of it was fitting in nicely. And it was just a little bit of the sort of dance of prioritizing for folks. Certainly, once you have paying customers, this gets harder, of course, to balance and you need to, you know, balance dancer requests and balance division and prioritize correctly, even if folks are trying to throw some money at you for something but but yeah, it's all worked out pretty well. And again, I think goes back to just the fundamental idea of like, we were building for ourselves, and we were building for the mobile world and this kind of this kind of user, and there's just been enough alignment there that that it's kind of continued to work, the classic, we were solving our own problem. And I think that's how you see it pay off well down the line. More, more tactically huge thing for us. And we still make heavy, heavy use of this slack Kinect. Game Changer. Just like certainly the early days, but with almost all of our customers, it is a paid sort of support level now. But we will also open it up for folks that are running trials with us. And just the sort of speed and ease of communicating, they're answering questions, kind of assuring teams as well, you'd become a kind of a fly on the wall, and almost an extension of some of these teams. And when I think that's really appreciated, and they know that they're talking to well, the founders oftentimes, but also engineers, fellow engineers, fellow mobile engineers, folks who have worked on mobile product, and that that has been huge. Because again, like big platform touches a lot of stuff. And, and we want to kind of partner with teams through that sort of that warming up kind of period. So yeah, it's like Connect has been has been big. It is not infinitely scalable. So that's going to be something that's that's coming for sure. I know there are tools for this now actually. But but making sure that We're not overwhelmed with this stuff, but it's been alright so far.

Jack Bridger 25:03
Yeah, that it seems like that would be especially for for someone like runway where you're, as you said, for better and worse for the challenge and the benefit, you are very, very essential and kind of like, difficult thing that people do care about. And when it goes wrong, it's very, very bad if, like, if someone can't ship a release, they're very, very concerned. And so having someone in from your team who is like, very, has a lot of expertise that is suddenly now like, a part of their slack organization must be like a real big selling point. Whereas if it was like, you know, a kind of a small thing that Sony, they, you know, only deal with once a year, and, you know, they probably don't want that anyone from that team joining the organization. On slack.

Gabe 25:52
Definitely, it's, it's something that, again, we need to be mindful of balance, that's a recurring theme as soon as it's balanced. But you know, you don't want to cross the line into a sort of, or maybe you can, but we're not trying to cross the line into like services, you know, business. And we're not, we're not there, for sure. But if you go further in that direction, it kind of turns into that. And for sure, like, sometimes there's a bit of it feels like a bit of appetite for that kind of thing. Where folks do want that sort of extension of the team in a more formal way. And then that reassurance and that resource. So you could probably go in, I mean, it turns into sort of a tooling DevOps agency model, and maybe just, maybe some examples. I've recently but not wanting to cross that line. And I think we're okay there. But, but yeah, another place to balance.

Jack Bridger 26:47
Yeah. Maybe the next question is maybe fast forwarding a little bit, because I guess there's like, so you did your first cohort. But I guess at some point, you were like, Okay, right, we've got something that people like, and we need customers, we need to show that we've got growth. Could you talk a bit about like, the about that period? And what you did at first to start getting customers?

Gabe 27:16
Yeah, yeah. I mean, the kind of most concrete answer really what opened the first, or the next, I guess, cohort of customers and paying customers happened coming out of yc. And so, you know, if there's, if there's one thing I can say about sort of having gone through YC, pros and cons, whatever one of the big pros is, is a well, there's two actually, one is the the community. Of course, like YC alums are composed of many mobile first or mobile forward, you know, companies who have gone on and done really well and are big now. So we definitely leaned into that. It's, it's not a whole lot better than just like pure cold outbound, but it's slightly warmer sometimes. So we lead into that, and we landed a few first customers that way. And then the other sort of thing is inbound. And this is not, you know, this is not sort of advice that you can just go and turn on and make happen. But there were a few nice bikes coming out of YC, different sort of coverage and stuff, where we got kind of noticed and picked up for the first time. And that definitely led to our first like big, big spike in inbound interest. And we had a lot of a lot of great demos coming off of that. And a whole bunch of feature requests, like the platform was still still relatively in its infancy. And so features integrations, having all these integration points, but only supporting like, maybe one or two tools that folks use it, each of these points, a constant thing, and it's still a thing. And we're trying to just keep hammering out the kind of the most commonly used tools across the world for all these different kinds of mobile teams, which takes effort. So there's just a lot of great demos where it's like, oh, but like, we want to integrate XYZ tool at runway is project management. integration point. It's like not ready yet, you know, start a trial, we'll try to prioritize it's the whole whole kind of, again, trying to sort of balance and take on the demand and cater to the unique needs of all these different teams. But, but once again, this is what this is what we've sort of signed up for. We are this Plug and Play platform that should adapt to and work with the whole variety of ways of doing things. So different workflows, and also the different tools that teams use. Yeah, so you know what we're getting into. So you have a lot of demos, you work with teams, you expand that sort of that pool of research, of understanding The like myriad ways that teams do things, how they have things set up. And that was super valuable too. Even if we were having these discussions with teams didn't go anywhere, more data points, more inputs to understand the next time we encountered teams like this. These are some things they might be looking for. And so further, like feeding and prioritizing roadmap was huge. Yeah. So the first Yeah, the first cohort paying customers that mix of I mean, concretely outbound, and inbound. And we went from there. And the thing that started happening, which is, which is great, and we want to lean into and leverage however we can, you can't force this, though, is sort of the network effect. We're focusing on that a lot this year. But becoming not just a known name. But like a known kind of tooling. We are, we're category creating here, this is this is a new, there's a new thing in team stacks. And so we need to go out and sort of make people aware of the fact that like, there is a solution. And there's a better way to be doing things. And it's worth giving it a try. And you need to sort of define language around it, which we still are kind of working on. But the whole category creation playbook, like really defining a language and really running with it in every kind of title, every space, not something we've done, as deliberately, as we probably shouldn't be doing. So it's something we're looking at. And then yeah, so becoming a known name, but also unknown category, like someone is on a team, wondering if they can offload all this friction and like burden around releases, like, yeah, there's a, there's a tool for that, like there's release management platform, you should go, go look for one of those. So that's slowly takes hold. And then you have folks telling their friends in the mobile world, especially these days is a lot of kind of turnover on teams and folks jumping across the different teams. And ideally, they've had this awesome experience. Using runway making their lives easier at a previous team, they come to a new team, and suddenly they're back in this old mode of like, annoying, burdensome, error prone releases. And so they, they think of us and they raise it to the team, and it kind of goes from there. So that's that great sort of motion that you really want to get get towards that has started happening as we have become more known as this, as a kind of tool has become more more understood. It's easier for folks, for example, who bring us over to other teams, to not have to tell the whole story themselves, which can be hard. There's more sort of existing dialogue and existing knowledge there, if that makes sense.

Jack Bridger 32:41
Yeah, yeah. Yeah, it makes sense. It seems like, like a few factors kind of combining to mean that I guess there's a lot of conversations involved this as I would imagine, compared to some other tools, maybe people are less likely to just discover it, discover runway set themselves up, start using it in the team, it might be a bit more like having to overcome their four forts around Mike, and really explain it and have a conversation.

Gabe 33:14
Yeah, for sure. And that's been a big area of focus, what is the what is the go to market motion actually looks like most closely. And there's a few there's a few different sort of motions, but for sure, all of our customers at some point are going to end up on a call with usually me or with our one of our AES, there's going to be kind of a demo slash sync. And it can happen at different points in time. So there's kind of like a fully Sales Lead motion, folks come in, they might loop in some folks on the team. And then we have a demo. conversation starts from there. And, and then goes, there's another motion since we launched self service, which was important to us, where the first action someone takes is to sign up. That's cool, because they can start poking around. But until relatively recently, there wasn't a whole lot you could do and get set up. If you didn't have. You didn't have the buy in from your team, you didn't have the sign off on larger orders that you might need to go and connect a bunch of integrations. There's kind of these, just like process related roadblocks that exist. And so what we focused on is like, keeping that keeping that entry point open, folks can sign up they can come in have their first experience. It's not going to be a full on aha moment right away, because you're not going to be able to get all connected, but focusing on on ways to start the conversation in the product and start educating people about how it can look and feel. And so we've built out we have a sandbox, but also within the product. If folks have pieces that aren't connected, yet, we built out little toggles to toggle on demo mode. And it's going to fill in a part of the product with some representative kind of data. And just start planting those seeds start getting a sense for what things look like. And so folks can get started that way, we do have some teams that will sign up, and they'll do what they need to do on their side to start connecting integrations up and running. And then maybe never talked to us but but maybe end up on a call just to tie up some loose ends, address some lingering questions and, and go from there. So, so Yeah, but you're right is a complex product. And very often for the kinds of teams we most most often are kind of in front of, there's steps, there's buying, there's consensus building, and all of that slows down a sales cycle, it also pushes it a little bit away from self serve, to try to sort of treat self serve as for now this changes to when we get a little bigger for sure. But for now, kind of Legion, keep the door open, be welcoming, get folks in, start the conversation. And, and go from there. It takes many touches. You know, maybe someone has seen sponsorship in a newsletter, maybe they've seen us at an event. Maybe they come into the product, they poke around. There is a multi touch sort of like education process that can happen. So you just want to make sure you're there in different ways for different folks on the team when they're when they're ready to talk or explore.

Jack Bridger 36:31
Yeah, that makes sense, like harder maybe to measure and do be very, like, kind of data driven on like, we just need to put this much out budget and and we'll Yeah, it's

Gabe 36:43
tricky. Yeah, that's been very top of mine, to measure the multi touch. The attribution has to be really good. And our head of growth rally has done a lot here to make sure the opposite instrumenting is there for it. But very often I'm I mean, our CRM, I'm sort of looking at a deal. And you see, like, different people who have sort of been interacted with or have have sort of reached out in different places different times. There's a lot interesting, sort of like threads to pick up.

Jack Bridger 37:14
Yeah, yeah. So very, very short side, which CRM two years by the way, just in case anyone listening is thinking about

Gabe 37:21
your we are on HubSpot. Which, yeah. Which does the job. For sure. They are very good at making you pay more for every little extra bit of functionality, and seeds and capacity that you need to add. They've nailed nailed that expand game. But it's a great tool is doing everything we needed to do. And there's a lot you can do with it. So yeah, it's been pretty good.

Jack Bridger 37:52
Awesome. Awesome. Yeah, I don't think we've ever spoken about CRMs actually on on the podcast. So fast. That's awesome. So I think we're coming up to time gape. But I wondered if you wanted to kind of share, like, where you kind of see the future direction? I'm not sure we even quite got up to the current day of runway. But kind of what kind of things you're focused on in the future of roleplay?

Gabe 38:19
For sure, yeah, I mean, high level is a few things. But one of the big ones is actually still what we were talking about earlier, there's these sort of different axes to the product, right, there's the breath, there's like the whips like we are present, we're doing stuff at all these different sort of points of a release cycle. Now increasingly different points of also the development lifecycle more broadly. We want to continue expanding the with the breath in that direction. There's other parts of the process that are not entirely different, like it's all hand in hand. Part of the platform we just shipped, built distro has to do with making, distributing different flavors of builds way easier. And that has a lot to do with releases as you're preparing release candidates, but it's also something that should be happening throughout the development lifecycle. So you can get builds into the hands of testers like QA folks, designers to check stuff, product owners. So anyway, expanding outwards, and then of course, expanding downwards so vertically, we you know, what we were talking about before comparing the the very early days to now, we are so much deeper as a platform for any given sort of part of the platform. There's way more runway you can do way more we can automate way more we can, you know, pull in in surface, but we can go so much deeper. And so that's definitely in focus parts of the process where it makes sense for us to actually sort of go even deeper with some roots and take on more of Whatever might be happening at that part of the process. It's like the high, high level focus, I suppose. If I had to really boil it down,

Jack Bridger 40:09
yeah, amazing, amazing. And yeah, thanks so much for joining, Gabe, if people want to learn more about runway and about you, where can they? Where can they do that?

Gabe 40:22
Let's see about runway runway dot team is our website. There's the usual stuff about the product and stuff, I think, the coolest part of their sandbox, so you can kind of get in there. And you'll see again, a sort of demo instance, you can see a bit about how it looks and feels. So check that out. If you're interested for your team. Of course, you can schedule a demo through the site. And check out our Doc's. Oh, we also have a microsite. We're trying to do more of these. But this is kind of neat. We collect aggregated review times data. And so that's updated live. And you can see sort of like how long the queue is trending on the iOS, Apple side. Some other stats on build processing. Super cool. Yeah. So there's a there should be a link out to that from the site as well. For more on me, I don't have a huge online footprint, to be honest, but most active, sadly on LinkedIn these days. So feel free to reach out or connect on there. And yeah, we'd love to chat to any mobile folks who are curious about what we're, we're up to.

Jack Bridger 41:31
The Amazing. Yeah, well, thank you so much for joining. Yeah, thanks, everyone for listening. Thanks for having me.

Transcribed by https://otter.ai