The FDE Motion That Took HappyRobot to $1.2B | Pablo Palafox, HappyRobot CEO

0:00 Intro Implement and move on. That is really not what we do. Like we we really are a partner. We strive to be that partner throughout the transformation. Listening is really important. Understanding what customers are saying and digesting that and knowing where to push back. Same with deployments. I think there's some methodology, but there's definitely a lot of space for that creativity because 1 enterprise deployment might look completely different to the next one. 0:21 Speaker 2 Is there anything that you guys, your deployment teams do specifically to show that first value as quickly as possible? 0:26 Speaker 1 Finding that lowest hanging fruit that also carries a certain amount of weight and importance. 0:32 Speaker 2 What would you tell a founder who's standing up a new FD motion tomorrow? 0:35 Speaker 1 Like utmost respect and care for the customer and for their success and making sure that everything they they learn from a product standpoint comes back into your mother ship I guess. 0:45 Speaker 2 Founder who's maybe scaling from 5 to 60 FD is what was the biggest piece of advice. 0:49 Speaker 1 Keep it super super flat. Start thinking about some form of measuring that impact. 0:54 Speaker 2 Welcome back to the Last Mile. I'm Ivory, Co founder of Contour, and today our guest is Pablo Palafox, the Co founder and CEO of Happy Robot, the AIOS for supply chain and logistics. Pablo scaled Happy Robot from zero to 1,000,000 in revenue in just under 2 years via a heavy FDE motion. 1:14 Today we dive into everything from how Pablo scaled from zero to 60 FD ES, what makes a good FDE to how he structures his team to run as efficiently and effectively as possible. Hi Pablo. I'm super excited to have you on the podcast today. Thanks for joining us. 1:28 Speaker 1 Thank you everybody, super excited. 1:31 Speaker 2 Well, Congrats on the recent round crossing, you know, billion dollar evaluation in less than two years and excited to talk more about FD and happy Robot today. Yeah, curious. You know, you guys are still, you're still flying out to customer sites to deploy even to to this day like what was maybe a fun story from one of the recent deployments that you've been to. 1:51 Speaker 1 Yeah, it's been a little bit since I don't actually deploy maybe like a year and a half, but I was actually recently at an on site with a customer in Connecticut and I really have a lot of fun because you can be part of that scoping, even if it's just with the exact team and executive team. 2:08 And maybe it's just like the high level discussion about what to do and what to build together. It's very energizing. So the the last one basically made me realize that we have a huge opportunity still ahead of us and and every time we talk to customers, we just see more things we can solve together. 2:26 So always exciting to be with the customer. 2:28 "We Didn't Know We Were Doing FDE" Yeah, that's awesome. I mean, now FD is pretty popular, but you guys were really doing it quite early, right? Like you guys were in YC summer 23 batch and started doing FDE like probably one of the first enterprise geared companies to actually start selling via the FDE motion and deploying. 2:43 What made you guys start that motion initially in the early days? 2:46 Speaker 1 Yeah. So we honestly didn't know we were doing it. I was just trying to deploy our beautiful platform back in 2024. Initially was obviously less beautiful than today, but we did have a lot of cool stuff that we needed to put in the hands of our customers. 3:03 And the thesis originally was that we could build agents, in particular voice agents that could solve a lot of the problems that our prospects and logistics, which is the initial niche that we decided to go into were having. In logistics in particular, you have a lot of coordination between the, the different parties. 3:23 You have a lot of phone calls, a lot of emails. And we said, OK, let's build a voice agent to call drivers to see where they're at so that the delivery is not late. My my brother Javi who was working in this space had a lot of those issues. Let's have an agent that negotiates the the rates on freight. 3:38 So we did that, but then the problem was how do we again make people use it. So I think that forward deployed motion that Palantir pioneered really comes to solve for that initial deployment, but also for the new scoping of value, which is I think something that people don't realize for. 3:57 For us the the best go to market lever is really having a four deployed team within the customer and especially even better if they are in a sense paying for that through a big partnership and and transformation project. So, so yeah, I mean to your question, I didn't know I was doing FDA work. 4:13 I was just like Pablo going there, figuring it out, sitting next to the operators and bringing it up to the executive team and be like, hey, we need to do this and I think this is a great opportunity. And then just going back to the operators and getting it done. And little by literally, I realized that the closest we could name that role was what maybe I was like digging into through Palantir. 4:35 I think initially the role we called it like solutions engineering, but that didn't really fully grasp everything because we were not just solutioning really we were also doing the, the, the, the, the scoping and the value realization and the partnership. It was not just like implement and move on. 4:51 That, that is, that is really not what we do. Like we, we really are a partner. We want to we strive to be that partner throughout the transformation. 5:00 No Solutions Engineers, No Pre-Sales, No Post-Sales So do you guys have solution engineers today or no, No. 5:03 Speaker 1 No, no, we decided to just cut, cut down like remove any like levels or titles that are like weird like people do like pre sales and post sales. Now it's like, I mean for us it doesn't work for other companies. I'm pretty sure it might work. No, for, for us in our case, everyone's a forward deployed engineer. 5:21 We do have within the deployments team a bit of a spectrum between more the strategist role like deployment strategies versus the more engineering side of the house. But they're all part of the deployments team and their mandate is scope and build, scope and build. 5:39 And really the way to do that is by being really good at asking questions and listening, which I think is the best 2 traits you can have as a as a deployment person. 5:49 Speaker 2 Yeah. That said, if a solutions engineer were coming from a different company and wanted to be FDE at Happy Robot, what would they need to learn to go from solution engineer to full forward deployed? 5:58 Speaker 1 I think going back to that listening and pushing back, you know, like listening is really important. Understanding what customers are saying and digesting that and knowing where to push back and where to also design the system in a different way. 6:14 Typically, and I say typically a life not being at a company where I've seen solutions engineering. So I'm making a guess here, but what I can imagine happens in in other solution engineering roles in other companies might be something like the account executive says this is going to be billed and then they pass it off maybe to like CSM, like customer success manager. 6:36 And then that customer success manager realizes they need to like build something more technical and they go to the solutions engineer person, that person like, I don't even know what I'm doing here, but I'll just build whatever ticket you give me. I'm making a guess. OK, so this might not be exactly what happens in companies organize that way, but for us, it's very important that the forward deployed team really is part of the initial scoping and part of the broader transformation. 7:02 Post sales. It's both pre and post sales. And actually they they enjoy that a lot. They love being part of that, you know, exposing themselves to both worlds like pre and post sales, if you will, which is also part of why the role is so cool. It's very creative. So you have to be very, very creative. 7:18 I think that's another term to add to your question. Listen, be creative, and know when to push back. 7:25 Speaker 2 Yeah. How do you guys screen for that creativity even in your interview process for FDE? Or is it possible to screen for? 7:31 Speaker 1 I think it's hard to screen for it, especially during an interview process. That is, you know, in a sense you can hack it maybe. So it's hard. It's hard, but I you just feel that someone has that like level of huh, what if, like, what if I could do that? 7:47 Like in in if you're like going through a case study and suddenly that person realizes in the middle of an explanation that something might be wrong and they like take us back and like propose something else. I don't like you almost sensor it, but it's it's hard. It's. 8:02 Speaker 2 Hard, yeah. I think that's awesome that you guys have the same FDA go through pre sales and post sales and like don't split it up if you don't have to, right? Because there's a lot of context that gets lost otherwise sometimes people can't do the whole cycle, which is why companies will split it up. But I'm curious, do you think every company that says they have FDS, do they actually need FDS? 8:21 Or are there certain types of companies that really do need FDS? And is there something special even about logistics in the space that you guys in such that you need a true like full FDE? 8:32 Speaker 1 I mean to today we serve enterprises and logistics, broader supply chain both on the so-called asset side or the the carriers, ocean carriers, tracking companies, airlines, also the shipper side, manufacturing companies, distributors. 8:48 We've also been able to now partner with folks in the Telca space. We had folks like Deutsche Telekom or Orange come into our round strategic partners and even even banks and financial institutions like Bankinter, one of the largest banks in Europe. 9:03 So we are now serving for industries primarily supply chain, telcos, energy and utilities and financial services. In all those industries what we see is specifically at the enterprise level is that a that a forward deployed engineer, a deployment strategist, they are the catalyst to the transformation. 9:24 They are the key piece to make that value happen. So I don't know if all companies that say they have Fe ES should use should have that typically, and maybe this is a bit of a rule of thumb. 9:40 The Million-Dollar Rule of Thumb How we think about it is a contract should be around 1,000,000 either as a land or as a expand as in the 1st 18 months, maybe first 12 to 18 months. That's my, my current rule of thumb. It might change later on, but I we see that if a partnership cannot get to that 7 figure realm, it's not necessarily a transformation that we can invest in moving forward. 10:05 We might just do it because it's a customer that we really want to work with and like we might even train them on the platform because ultimately we're a product company. So we are building a product that they can build their agents on top of, but we might just not leverage our forward deployed engineers there. 10:21 Why They Killed the Pods Yeah. 10:21 Speaker 2 Yeah. One thing I also really like about what you guys did was you have these pods of Fdes and you guys started that pretty early and you vertically into pods for different of those industries that you guys have. Yeah. Tell me more about those pods. And is that change, Is that model changing? 10:38 Is that helping you guys? 10:39 Speaker 1 Scale that. We killed it in in a way like we killed it in that we didn't want to have, how to put it like we didn't want to have folks. I must be entitled to like own a pod Like, Hey, I'm like, I lead the insurance vertical or I lead like the freight forwarding vertical. 10:57 Like it just happens naturally. Like if you're doing account work and your deployment strategy is an FD doing really cool shit. And and then you just naturally become the, the expert in that, in that territory and people will naturally gravitate towards asking you questions about that space. 11:14 So now it's more of a knowledge share. We actually renamed a lot of like the Slack channels that we had like tracking pod, like forwarding pod insurance, but it was like knowledge share. We, we try to stay away from, you know, like the chasing down of titles and rather index on impact. 11:39 Like something that we can talk about later is how do you measure performance? And the the answer, and we can dive deeper into it later is, is impact. And obviously impact is a very broad term that we can define in a minute. But that is what we try to stay away from like any chasing of titles, any like internal chasing of titles, by the way, because externally you can make up whatever title you want on, on LinkedIn. 12:05 I tell folks like, do you want to put like head of retail, like go ahead tomorrow, do you want to change your role and like be head of finance, like head of finance deployment? Go do it. I mean, ask me first maybe, but do it like especially if you're going to talk to like a, an exec of one of those Fortune 100 or Fortune 500 companies, they want to take you seriously. 12:28 They they need to take you seriously. So they need to see some of that title. 12:35 Speaker 2 Yeah. 12:35 Astronauts and Commanders I mean, I'd love to talk about that point you mentioned about impact. How do you guys measure at Happy Robot? Do you measure it differently in different verticals, different deployment strategies versus FD ES? Yeah. 12:46 Speaker 1 No, we definitely try to have everyone as part of the same bucket. Yeah, internally we have a fun name for them, which is astronauts. It's like our astronauts like like they're exploring the world and and cool shit. 13:01 So our astronauts, they deployment strategies and for deployed engineers, they they really haven't been measured to be honest so far too much. We've just made sure that we hired really smart people and self-taught and self-guided individuals that can almost like know what to do and what things to index on. 13:25 Obviously that has a limit, which is those individuals they also want to grow and as much as they can self guide themselves, they also want to have someone that gives them some guidance and and helps them grow to the next level. So one thing that we did identify is that need for some coaching and for some just peer feedback. 13:47 So we're, we've been doing some digging on to that. Both Palantir and consulting companies have these framework, which is basically, it's not revolutionary, but basically if you're working on different projects, which you might even within the same account, let's say one of our biggest customers, they have 5 subdivisions and it's almost like 5 different companies. 14:10 So you might be working, let's say you're an FD on one of those subdivisions of the account. You might be working with me on one segment, you might be working with someone else on the other segment of the company. So how do I, how, how do we measure your work? 14:26 Like you're working across different places. So how to solve for that is having a sort of lead or as we call it internally a commander. And it's another fun name, basically a manager that is not really a manager because they cannot really fire you. 14:46 But at the same time they're, they aggregate feedback, let's put it that way. They aggregate feedback from the different places you're working at, different accounts, different SAB accounts. And they really transfer that feedback over to you as that FDE or DS. 15:05 And they help you grow and they tell you, hey, I really like you're not really doing this Gray like you should be building more and like not fearing going into the platform. Like sounds like in these call to this customer, you were like not super trained. 15:20 Like it's been 3 months already and you don't really know what the platform looks like. Like that's bad. If you're a deployment strategist, for example, which typically earns more on the on the strategy side, less on the building. Same for an FDE, like AFDE, like you need to step up on your value capture abilities and like on your discovery abilities, like you need to articulate better the the proposition and, and know how to dig deeper and push back. 15:46 Don't just like build whatever ticket or thing they ask you to build. No, I guess that's, you're not that type of engineer. You're an engineer that asks the annoying questions to the customer. So yeah, it's it's that that that framework where you have that so-called commander, as we call it internally or some form of mentor who who aggregates that feedback from the different places. 16:09 Speaker 2 What's the right ratio like commander to number of deployment strategist FD, ES? Do you have you guys arrived on a perfect number I. 16:15 Speaker 1 Might have to tell you in a few months. We're just like we've been rolling it out slowly for a few months and now we're like double down, doubling down on it again. As much as I want to say like, you know, we have everything under control, like what a company would we, we have been exploring very quickly. 16:32 I think the best thing is having a company where individuals are again really, really savvy and really smart and, and high energy and they want to just do things and try things. And that has gotten us so far. And I think we can still continue doing that even without this commander framework. 16:47 Obviously, we want to operationalize the company a little bit more, but it's surprising what you can do with really smart individuals that are extremely, again, self-guided. And we've gotten here so far. One thing that I typically say is if you want to have unicorns and people will tell me, no, you cannot like rely on unicorns forever. 17:06 "Let Them Be Unicorns" And like, I don't know if that's right. I think you can definitely rely on unicorns if you let them be unicorns. Otherwise they're going to fucking go leave the company, that's for sure. Like if you start giving them like a shit ton of guard rails and like, what's the thing that horses wear? 17:22 Like like the thing that doesn't let them see. 17:25 Speaker 2 Oh yeah, the blinders are blinders. I don't know what they're actually told. 17:28 Speaker 1 Something like, I guess blinders is a good, but if you give everyone like their little like corridor and blinders and like they cannot just do anything else than that, which is by the way, at some point we were thinking about doing something like that and, and I realized it was getting scary and like boring. 17:43 Like, like we're going to have like this process where like the FD is just like a solutions engineer just building the freaking SOW or whatever document. That was scary for many of the of the four deployed engineers and deployment strategies because they, they loosed, they were losing that create TVT, right? 18:02 So, yeah, I mean, I'll, I'll let you know. I think right now we have maybe 5 astronauts for commander or something like that. I think we're like a team of 60 or 70 right now. 18:13 Speaker 2 On the FD side. 18:14 Speaker 1 Yeah, on the deployment side, deployment studies in FDUS, yeah. 18:18 Speaker 2 Nice. And I'm curious like you mentioned you took a lot of inspiration from like consulting side Palantir as well. Like what do you think carries over? Well, he mentioned SOW too. That's like a pretty consulting first like concept a lot of tech companies don't do SO WS, maybe PS teams do, but when did you guys adopt even the SOW and some of those consulting esque terms and methodologies? 18:41 Speaker 1 We might have already been like a team of 20 more or less and we realised we needed some frameworks, not too many. Like avoid over indexing on any particular methodology or framework because as we say internally or many people say, playbooks are poison. 19:01 Playbooks Are Poison Or rather frameworks over playbooks, which is basically there's no like recipe for success in a deployment. Obviously you do want to have some form of high level framework. 19:14 Speaker 2 Like there is like what good looks like generally, yeah. 19:17 Speaker 1 Exactly. But it's, it's a bit of an art, but there's both art and science, same as in sales. By the way, we were just discussing today in the old hands how sales is both a mix of methodology and the art of it. 19:34 Same with deployments. I think there's some methodology, but there's definitely a lot of space for that creativity because 1 enterprise deployment might look completely different to the next one. And you don't want to bring preconceived playbooks or like this is what we've done with like you're a competitor. 19:53 So like this is what I'm going to implement here. Like imagine the customer hearing that and they're like, what do you mean? Like we don't even do that. Like that even if we operate in the same space, we are completely different companies. So that's the risk that you need to avoid. You know, like thinking that just because you've deployed in one industry and with a particular set of customers, you can now just copy paste at the enterprise level. 20:15 We realize that didn't work. That's why we kind of. Kind of move towards and double down on the enterprise and just build a platform that serves them versus the mid market. We are not as good for the mid market prospects as others because we just don't have a a pre build point solution for any particular workflow or use case, not even for any particular function, right? 20:43 Speaker 2 Yeah. You mentioned there is some sort of rubric that the commanders use to evaluate the astronauts. What is included on that rubric? Do you have that ironed out and does it does how every deployment strategist FDE like how they execute vary quite a bit and can 2 completely different approaches both be like great heavy robot deployments? 21:02 Speaker 1 So we, we are actually in the process of ever defining that for, for me the biggest point here is impact, which is what that rubric comes to measure can be delivered in different ways. It's not all revenue. 21:19 I mean, obviously ARR is the biggest metric as a company you obviously want to follow. But what about NDR, net dollar retention? Well, you need to make sure that you are expanding and retaining your customers. 21:35 What about NRR? So like all of the metrics that you, that you, that you want to follow should be achievable by the deployment team. Like they, they should be able to do stuff that affects those metrics. So yes, maybe helping close a deal is good, but what about building A use case that is irreplaceable and that is super sticky and value add? 21:58 Obviously it's not sticky if it's not adding value in such a way that the customer just cannot live with it, which is good because if they are seeing value, that's why they want to stick with us, you know? So for me, yes, revenue expansion obviously is key. 22:13 But thinking about how to expand and, and retain customers is also important. And it's maybe less visible typically because maybe you, you tweak something in a deployment that makes it stinky, but it's less visible. You have to maybe go deeper into the deployment to understand that that was really what helped solidify that deployment. 22:31 For example. Those are like the two main points. And then things that deployments helps a lot with is training others. Just helping others grow is also very helpful and it's part of the impact that you can drive internally. 22:46 And then the 4th one that we are looking at is helping the product. The deployments team falls under the Office of the CTO with Louis. 22:57 Speaker 2 The DS and FDS or. 22:59 Speaker 1 Both, yeah, they're an extension of the product. They're an extension of the product in that they are the best way to learn what the product should have and should be. And ultimately, what we say is that Hamper Robot's product is a composition of the platform per SE and the deployments. 23:19 Because again, if you just threw out the platform to 90% of our customers, they would not know how to leverage it. As of today at least, maybe the other 10%, yes, we do have folks that are like internally almost hiring like AI managers or like AI specialist, call it internal FDS, which is weird because obviously it's their own company, but they are hiring people internally to build on the platform, which is really cool. 23:43 They actually have teams dedicated to hyper robot, which is obviously very nice to hear. But yeah, I would say those are the points that as a rubric, if you will, you can use definitely not like how many calls did you have with a customer? He's like great you had. 23:57 Speaker 2 4 is not better. 23:58 Speaker 1 2020 meetings with a customer good for you. What was the impact? Did you help close Apoc or a proof of value? Did you help unblock a situation with the CTO that did not believe in US and actually convinced him with in this particular moment on a of a of a demo that This is why they should build with HAP robot? 24:17 Like that's impactful. Not just like numbers of like meetings or agents build or not even like tasks completed by agents. Like what does that mean? What is the, the value created for agents for, for the customer? It's very easy to fall into the simple metrics, emails automated, phone calls automated or you want to see like what's the actual impact? 24:40 And that's also part of the role description of the deployment scene. What's that impact you're driving within the customer? 24:46 Speaker 2 Right. Like qualitative, not just quantitative, 100% emails, calls, etcetera, 100%, yeah. 24:51 Why Deployments Reports to the CTO I want to also dig into the point you made about the deployment team sit under this Chief Product Officer, the product branch. I've seen it a lot of ways at different companies. Sometimes it's like more sales or like OPS more. It's sometimes it's CTO, like product side rate and sometimes DS and FDS are like two different orgs, but they work together. 25:09 When did you guys make that decision? How did you guys decide to do product? Because obviously there's a lot of like product incorporating feedback back into product, but it's also kind of a sales role. Like how did you guys think about that? 25:20 Speaker 1 Yeah, I mean it. It is indeed as I mentioned before, our best go to market lever. It's not necessarily a sales role because in a sense you are advocating for the success of the deployment and the value creation, not that the account executive or the sales team doesn't, but obviously their incentive is to, to maximize revenue for the company. 25:41 And as such, we you need to have that friction between those teams, healthy friction so that you're optimizing for both at the same time. And you find a good local minima if you're minimizing whatever function you want to minimize of value for a customer and value for our own company, right. 26:04 So we decided to really put them as that office of the CTO team around January when I like at the time I was, I guess leading that team. 26:19 I couldn't continue doing that and it was just best to have Louise kind of take over so that I could focus on the other things that I need to do. But sometimes I kind of realize I would prefer going to working on deployments. 26:35 It was a lot fun, a lot more fun than talking to investors. But we got to we got to do that from time to time. And honestly, talking to customers is the best part. Like I really enjoy that a lot. It's really how I get my, my, it's my drag. 26:53 No, like it's, it's so exciting when someone gives you that insight or that idea and you're like, I immediately want to solve it. Like it's yeah, two question before who do you look for? It's problem solvers, right? And people with high levels of curiosity and, and attention to detail. 27:10 But yeah, decision was that was at that time and I think it's been a good one. We keep them very close to product. They're advocating for for that successful deployment. Maybe in the future we we change it, I don't know, but. 27:23 Speaker 2 Yeah. And one important metric for deployment is how fast they can get customers to value even during the POC phase where, you know, you're still kind of selling and making sure that they're committing to longer term relationship or expansion or anything. 27:35 Fake the Data, Customize Every Demo Is there anything that you guys, your deployment teams do specifically to show that first value as quickly as possible? Like unblock customers, build useful things for them as soon as possible when you start? 27:45 Speaker 1 So one thing that we do really well is finding that lowest hanging fruit that also carries a certain amount of weight and importance for the customer and just building something hacky in hours, maybe even before we even meet that customer because we've done our research and we customize the demo a lot. 28:04 We do customize any demo we do. It's super, super customized or it should be highly customized. And what I tell the team is you cannot justify in this era and not customizing every demo experience as much as you can because you have so many resources to analyse that customer to, to learn about them, to even get their latest news and like have Clotter or whatever, like give you a summary of what you should build. 28:28 Because again, even if we are talking about the same industry, 2 customers in the same industry might have different problems. You just have to know where they stand. So I think for, for us, like the, the, the quick hacks around maybe faking up some data like it doesn't, I mean, you can tell them, hey, this is obviously a fake data. 28:46 We haven't really worked yet together. But like, I imagine this is how your data looks like in, in our platform, you have like 3 layers, You have workflows, That's where you build agents. You have twin. Twin is our context layer. This is where agents kind of keep their memory and and and store insights that they kind of really store anywhere else. 29:05 And then you have apps Apps is basically a coding agent that we have internally think about coding apps. Sorry, not coding apps like things like like lovable or code like you almost embed, we embedded that into into into hamper robot. 29:21 And then you can have a coding agent build interfaces for the purpose of showing the work agents are doing. So it's really impactful when you go to a customer and tell them, good to meet you guys, we've built this for you. And then you show them a platform that looks like a like AUI, that looks theirs. 29:39 They're like, oh, this is interesting. And then you show them an agent that speaks in their language or in in their company language that does things that they do, that is working on data that they seem to acknowledge as familiar, that is extremely impactful. 29:55 And they're like, OK, if you're doing this for just a demo, you can do crazy things if I give you access to my actual data and my actual team. So that is how you win, that you earn that trust. I say that we are in the game of earning the trust of customers. 30:10 It's really a trust game. Like if they don't trust you with their problems, how are you going to grow within the account? So it's all about that trust. And if you don't show you can be trustworthy from the beginning, you're not going to get far. 30:21 Speaker 2 Yeah. And So what you mentioned, right, like there's this generative almost like UI layer that showcases what the agents are doing. Does that mean for two different customers of Happy Robot, does their interface look quite different? Exactly. That's the beauty of it. 30:34 Speaker 1 It's it's personalized software, you know, that's why we don't have any particular point solution for any function or industry. It's all highly custom and it can be because you can build UIS and apps and even data schemas that are tailored to their specific situation. 30:52 Yep. Which is crazy to say that we can do that today. I mean, thank you. Lots of LLMS and things like that. 30:59 Speaker 2 Yeah, yeah. And people mentioned a lot this trust aspect that you just talked about too, right? I remember there was a quote that you said of people come to us not just for the product, but for advice because you guys have seen, you know, fright deployments across every sector, like so many of their competitors even maybe dig more into that cool of like do some customers come to you guys not even for the product, but because happy robot, you know, can solve our problems, whatever they may be? 31:25 Speaker 1 Yeah. I mean, ultimately the product is just a catalyst to make something happen. Yes, I will say that it is very nice to have a product that caters to the CT OS as well. Because the CT OS of our customers, because we win them over generally they they see it as a way to extend their engineering capabilities because it's, it's a very interoperable and transparent platform. 31:49 It doesn't really block or or hide any prompts or any like insights. It's just all there. It's all there. It's all like it's almost like a developer tool, if you will. It's got like amazing documentation. You can MCP through it. 32:06 The reason why we haven't really opened it up to the world is maybe because we want to keep our enterprise brand and we just want to keep it more like that. But it's it's highly CTO worthy. But but I would say that, yeah, customers do come to us for that, for that trust in solving their problems. 32:22 So I mean, what we were saying before, no, like if, if I have a problem, who am I going to trust that the person that maybe has an amazing shiny hammer, but like hasn't ever built a house or someone that has, yeah, like an amazing set of tools, but has done a lot of houses And they, they know how a house can crumble or not. 32:48 So they, they also seek that. No, like that expertise. That's it's a bit of a chicken and egg because when we started, we didn't have much of that. But you earn the trust with early adopters and then you go from there. It's just that compounding a trust that you have to earn everyday and, and even within a customer, you have to earn their trust over and over. 33:08 You have to, we say you have to earn the trust to do more work because to, to really capture all of the value in the enterprise, you have to have some, some way to wield the intelligence that LLMS offer and put it towards a good goal. 33:29 It's not about just throwing an LLM to the problem. No, like the, the hammer thing. Actually, if you just throw a shiny hammer and, and in this case a shiny LLM to the problem, maybe that's not going to solve it. You need a platform and you also need a team to wheel that hammer and, and build something amazing. 33:44 But if you want to wheel more houses for your customers, you, you definitely want to show that you do that one first house really well. So that's important for us as well. Like the, the, the knowing when it's done, like it's not done until it's the job is not done until it's done kind of thing. 34:01 Which by the way, it's, it's hard because there's so many freaking shiny things every day. We didn't have a robot. Like I see a new project. I want to go after that. It's so much fun. I've been working on this industry or this customer for like 6 months. Like I want to try something else. I mean, I get it like I've been there, but you also get a lot of pleasure when you get things to the finish line. 34:21 Speaker 2 Right. And that goal post is always moving within the counts within, you know, new LMS coming, new Hammers coming out. 34:27 What Broke Between 25 and 60 FDEs You got to adjust them as well. And I'm sure this is also why you guys have grown your FDE team so quickly, right? You were 25 a year ago, even now 60 and probably started out, you know, just a few, yourself included. I'm curious along that journey where, where have things broken and where have you guys made changes to make sure that what you're doing well at like 5 or 10 FDS has now scaled well to 60? 34:55 Speaker 1 I mean, I will not say that we are, I will not be the one saying that we are perfect. We have so many flaws and so many things to improve. And if you ask anyone of our folks in deployments, they'll have a lot of ideas to improve. And there's hopefully that always is the case. 35:12 With that in mind, I do also acknowledge that I, I think we have been like really freaking awesome team, probably because of letting, because, because we've let them be that special team. Like we've let them be unicorns, as I was saying before, we've let them keep their creativity. 35:32 I was mentioning before how at some point, maybe around last year this time, we were starting to think, hey, we need some structure. Every company goes to like the, we need structure, we need processes. And it is enticing because it simplifies things for you. 35:49 It simplifies things for. 35:50 Speaker 2 The leader. 35:51 Speaker 1 For for, for the leader, for the company. It's nice when processes internally help you do things better, but does it help the customer? Do those internal processes help the customer? Does the fact that consulting companies and we, we love many consulting companies, we're partnering with them and doing cool stuff with them. 36:12 But does the fact that consulting companies having 7 levels of whatever like engineer 123475, I mean now they're having like 4 deployed engineer level 1234. I saw like a four deployed manager, which I mean the way they're thinking about it is definitely miles away from how we're thinking about that commander, which is, is a super flat organization versus like a hierarchy and processes and reporting lines that kills creativity. 36:41 The fact that you're now chasing levels versus chasing value in the customer you're working with. That sets the tone completely different. So I think that's something that we've kept really well. The no hierarchy, like no chasing levels. 36:59 You the the only hierarchy is within accounts. There there is account, there is hierarchies. Basically you let's say you're deploying on customer Pablo logistics and I am deploying on Ivory telco. 37:16 Yeah, I might be the enterprise lead of that account, which basically means I am the ultimate responsible for that successful deployment slash technical lead. It's we, we, we don't have to go into the details, but let's say enterprise lead and technical lead, there are two roles that we might sometimes have in an account depending on the size of the account. 37:34 If the account is extremely big, we do have like those two roles. If the account is still smaller in our journey, we just have like an enterprise lead. So let's say that we are both enterprise leads in our accounts. Well, I might actually be working for you in your account as an FDE and you might be working for me in my account as ADS. 37:52 So that is the hierarchy. But it's beautiful because it turns around now, like tomorrow I might be working for you tomorrow you work for me. That, that is, that is how you grow in a company like Hamper Robot, through more ownership. 38:04 Speaker 2 Yeah, makes sense. And your FD ES, you know, they want fright by sitting next to the customers, understanding their workflows every time you expand to a new vertical, do you have to hire like an industry expert? Do you repurpose existing FDS onto it? Like what's the process of, you know, starting a new type of deployment, a new industry? 38:21 Speaker 1 The process is is simple, or rather the the tool to expand is simple. Just listening. If you listen, people will tell you so much. I was a newbie in collections and I spoke to someone once that give me just like a master class in an hour and and and that that was like the seed to us understanding that space better. 38:49 We didn't know anything about utilities a year ago and now we pretty much understand like the intricacies of it. Same with the telco space that we're now going into for the past few months or insurance, home and auto insurance, which is primarily what we've found a lot of success. 39:07 Just listen to what they have to complain about in their day-to-day and you can build solutions for for them. You can build a transformation, you can give them a transformation really. So that that is really there. There's no secret there. I mean, obviously you do have to have door openers that can help you maybe get into a certain company and it's always, you know, nice to have that. 39:28 But even our, in our case, we had, we had a few folks from other industries, I think I think 1 telco customer. We, we have, they got through us, they got to us through knowing that we work with DHL so that that you never know like companies from different industries, they might even be a reference customer so. 39:50 Speaker 2 Yeah. And without the concept of pods, how do you know in that new deal, in that new industry, how do you know who should be working on that deal? Is it who's available, who's had experience before or how do you guys decide internally? 40:03 Speaker 1 So this is another balancing act, another one of those like order versus chaos and you know like order for you or chaos for you versus order for the customer, right, chaos for the customer. So it's it's another one of those balancing acts because you can have folks that are highly specialized in an industry and that is sounds like good for the customer because they bring expertise, right. 40:27 But they might also start getting their minds a little bit rotten after a few, a few a few months or years or whatever working on that industry. So it's always good to bring some refreshers like some refers minds into the mix, someone that hasn't really worked on that specific industry. 40:44 They will bring fresh perspectives into the mix. So we have a staffing team. The solution basically was building a staffing team. And maybe that answers the question better, who's now basically constantly thinking about that. So we have the staffing team and we also have something that we call deployment execution. 41:01 Deployment execution is, is a, is a, another team really that is overseeing those frameworks that we, that we want to have, not those playbooks, but like that, that high level framework and being that enabler and that assist to the, to the, to the team. 41:21 And we have the sessions where we would go and just every every week we have these so-called Cortex sessions for each account that we think is like a key account and where we check in with the team like, Hey, have you done this? 41:36 Have you tried that? In a sense, it's very similar to what the commander now starts to do, which is how to help you new FDE navigate the organization, even our own organization, so that that is how we know where to put people now through the staffing team. 41:54 Why FDEs Don't Get Commission Right. And I want to go back to this point of how do you evaluate a good FDE like what do you screen for? How do you evaluate them on the job, right? Is it really through like customer feedback, you know, if customer and e-mail says, you know, they help me resolve this issue, are there quantitative metrics that should be used and then tied to that, you know, some companies are thinking should I tie it to a sales type Commission bonus on top? 42:17 Is there like any kind of reason not to do that as well? 42:22 Speaker 1 Yeah, I wouldn't tie it to a a Commission per SE. Otherwise, I mean you, it loses a little bit of the, of the, of the magic. They become more, I think some might want to become more mercenaries just without wanting actually. 42:41 Like if you give someone like a, like a, like a Commission on a deal, then you chase down the wrong things for the customer. So it's back to the, are you optimizing for the customer or for yourself? So in this case, we want to optimize for the successful deployment of the customer. And all of our deployment folks, they love that drag, which is seeing the customer succeed. 43:04 They, they, they, they get, you know, that high from deploying something cool at the customer. They're problem seekers, problem solvers. So no, we don't have a Commission per say. We, we have now since recently a bonus structure as in any type of bonus, it's performance based and that performance is really tied to that impact review that we talked about, which we haven't really fully deployed yet. 43:33 We are in the process of implementing it and, and hopefully that surfaces things like that customer feedback or internal feedback about, hey, I think Ivory does an amazing job in this, but she has to learn in that. And that also helps the deployment person in the astronaut or the FD or DS grow. 43:55 It's not only just a measure of the impact or the performance, it's also an indication for you to OK, this is how you can do better and grow, right? 44:05 Speaker 2 Yeah. And you mentioned they do sit under the product org. So a big part of their job is bringing insights from deployments back into the product. How do you determine what goes what's like a one off build versus like what goes back into the product given a lot of it's probably contextual within the account within like importance of that problem? 44:22 Speaker 1 I mean, I'll go back to how I was going through that with Louise, the Co founder back in in the day 2024. I would have a customer call and I would be like you seeing a potential for a new feature or like a potential for yeah, like a new add on or what? 44:39 Whatever it was. And I would immediately go back to Louise and be like, oh dude, we've got to build this. Like, can you build that? Like tomorrow I have a new demo, like let's let's try it tomorrow. He he would be like, I could do you want me to de prioritize the other thing? I'm like, oh shit, no, no, that that's that's important as well. 44:57 So then I would maybe like hack it around and build it temporarily and build a yeah, terrible hacky server. I'm a my background is as a PhD researcher, so all I can do is C++ and and Python. 45:14 So I would just like hack things around. This was before any like coding tools. I mean, cursor was starting to be a thing. It's like the auto complete. But that was already like mind blowing to me. And I would tell Louise and he'd be like, Nah, this is not good. And then when it actually started getting good, he would be like, holy shit, this is crazy. 45:30 But but yeah, like that feedback loop and that the realisation that you have to prioritise is always there. And you know, you might be extremely excited about these things that you need to build for your customer, but then it doesn't really fit into the current road map. 45:48 We might take it in or the product team takes it in and we have these sessions where this deployment to product sessions where we share both ways what's going on. But a lot of it today you can hackily built it, even more so than two years ago. 46:06 So there's no stopping you from trying those things. Even less so in our own platform where you have so much capabilities today, you can, you can build UIS, you can build data schemas, you can build workflows, agentic workflows. So yeah, we, we don't, we tell them not to get stopped by the limitation on the product later on, if it's something worth to integrate, we'll, we'll look into that. 46:31 And typically it ends up happening if it's interesting enough, I guess. 46:34 Speaker 2 Yeah, I resonate with that a lot. Also have very similar conversations with my Co founder of like, you know, I heard this thing from a customer, let's go build it now. But you know, we need to prioritize that it's. 46:44 Speaker 1 A constant struggle. 46:46 R&D and Cost of Acquisition, Not COGS Yeah, yeah. And I, I'm curious, do you guys, I, I think I know the answer to this based on everything you said, but do you guys view FD as R&D or COGS? 46:57 Speaker 1 I, I view it as R&D obviously. But I mean, I say obviously because, yeah, I, I do believe that they're just first of all, more than R&D is almost like cost of acquisition and R&D and more than R&D only it's cost of acquisition and R&D because it's, I mean, Cox is once you've deployed an AI agent or a solution or a transformation for the customer, it's, it's there. 47:23 Let's use the agent thing. Once you've deployed an agent as a entity, it's there, it's working, it's it's providing value. Obviously it has to improve. And we're now building a lot into the platform regarding self improving agents and evals, helping reinforce all of the good stuff. 47:39 Now every what everyone is building towards. But but I would say that, yeah, like we've, we've gone through a fundraise a few months ago and some investors were like, oh, like the margin like like costs, like if, if you're asking those questions, you really don't see that this is not COGS. 47:58 This is, this is complete leverage over the, the, the product road map. Like we move so fast because our FDS are our best users. 48:09 Why the Labs Spun Out Their Deployment Arms So we can iterate super quick. That's why when also in some investors or maybe like bring it up during the round. Hey, like, what about like these deployment companies of the labs detaching those two? Like why, why did cloud entropic or open AI like detach their deployment companies? 48:28 My take is they, they don't really care too much about them. They just see them as, hey, let's try to use that other Ave. to have some more token consumption. We care about tokens. We don't really care about transformations with enterprises and like messy problems and, and and work flows that I don't want to go to the warehouse of these customer or to the operations of these utility or telco, whatever. 48:58 I want to just sell fucking tokens. That's where they make the most money. I might have a naive opinion, no, but but my my naive opinion is they, they really see it as just another revenue source or way to implement more tokens. And therefore, which is my point. 49:15 It breaks the loop. It breaks the loop from product to to, to, to customer feedback versus what we have which is a constant, a constant feedback and a constant iteration between product and deployment. So it's, it's that beautiful reinforcement of the of the product and the deployment. 49:33 Everyday the product gets better, the deployment gets faster. When the deployment gets faster, we can do more things for our customers, hence more things to improve our product with. 49:43 Computer Vision, Munich, and the Name That's awesome. Yeah. Want to talk a little bit about the origin story of Happy Robot as well, including, you know, how you guys got the name, which is pretty cool. So before the voice agent, you guys were actually in the computer vision space. You know what lessons from that actually transferred over to what you're doing now and how you guys deploy today? 50:03 Speaker 1 So I was doing my PhD in computer vision in Munich. Dropped out after a failed internship at Meta. I mean, not really failed, but like it was, it was COVID. It was sad. I was remote. I should have been here in South Salido and I was in Munich and tricky notes forced me to quit and I quit and I'm like, OK, we, we need to do something obviously to, to, to get some money. 50:32 Obviously, I'm simplifying it because we had already been discussing for a while to build something together. But I get Luis and Javi and we start doing stuff together. We build some stuff around computer vision, which was supposedly my background. We get into icommunator. 50:47 Actually we get rejected the first time we get into summer 23. And maybe we entered with, I don't know, $70,000 of, of revenue with that platform that we had built around computer vision and like Pablo's supposed expertise. 51:03 And the, the reasoning why we are called Hap robot is because we were helping robotics companies put vision on their robots. So my brother Javi was like, I mean, we're helping those robots see us and now they're happy. 51:19 So that's the origin story for the name. I think the story, the, the, the, the things that stay, the, the learnings that remain is talk to users. Talk to users as much as you can. Because initially, we were in a little cave apartment. 51:35 They're in somewhere in near north of Munich, Louis and I just building stuff. I think we talked to 1 customer and we said, oh, I think we found something to build. So cool, let's go ahead and build it for them. It's not bad to build for just one subset of customers, but you should constantly be trying to talk to more. 51:50 And that's something we didn't do for the first year maybe, and it bit us a little bit. But yeah, thankfully we were able to in person here in SF with YC and our partners, among them Diana, who who's been amazing, super helpful to us, kind of use that muscle of, of getting out and like challenge you to like try faster. 52:13 I remember the interview process with Diana. She was like, this looks good guys, but you should try to get a few more customers this week. Like what? What do you mean like, so are you getting us in? No, no, no, like before that, try to get more customers and then we'll talk again next, next Thursday. 52:30 I'm like guys, I think she's asking us to like sign more customers in like 2 days. But is she, is she crazy? Because she was not crazy. She was forcing us to be what we could, which is being more ambitious, thinking bigger, doing things faster, not over optimizing for perfection, just getting out there and and trying things out with a customer. 52:51 Speaker 2 Yeah, and you Co founded with your brother and your best friend I believe. And to this day, you know, after 2-3 years, you guys are still doing the same relative roles on the team pretty much. How did you guys kind of split those roles? And you know why hasn't that changed till today? 53:07 Speaker 1 Yeah, that's a good question. I mean, I think I'm not terrible with speaking to customers and I, I, I think they see that passion, even if sometimes I or speak too fast or they don't really understand my, my Spanish accent. 53:25 I, I, I do, I think I, I do transmit that passion and energy to, to, to solve problems for them. So that customer facing deployment was always there. Khadi is extremely visionary, so is Louise. 53:40 They're both very visionary and more like, to be honest, more pragmatic or more tactical and, and maybe less strategic, if you will. Sometimes I like get hung up on the details and I love it. I think that's why I think I'm, I'm good at deployments because I can also go the last mile and like implement things really, really well. 53:59 And I care about those details. And then as much as Luis is less organized on his personal life, or, or, or, or maybe maybe this is, I'll tell a story. I go to university my first day, these guys sitting next to me, no backpack, no pencils, no nothing, no paper. 54:20 He's like, do you have a pen and paper? I'm like, who the fuck comes to like your their first physics class without anything. And now there he had me like with my pencils, my collars, like my notes, like super orderly like this guy asking me for that. That was Luis. Then turns out though, that in his code world, he's extremely, extremely good, extremely orderly and and clean. 54:42 So perfect CTO by the way, also perfect sales guy. Like he's so good at just like explaining things. He, he, he uses very simple terminology. He, he understands that not everyone thinks in his own, you know, code terminology in worlds and words. 55:00 So also really good at that. So he could perfectly be doing sales as well. But yeah, I think and Javi again, brings that vision and that strategy and obviously that finance and back and business background. Like he, he's extremely good at the, the, the first principles. 55:18 Really he's, he's, he's really first principles thinker and he sees like things he calls bullshit really quickly. And that's that's good on on on a sales and commercial team as well. 55:29 Quickfire: When an FDE Motion Is Worth It----------------------------------------🔗 Ivory TangLinkedIn: / ivorytang X: https://x.com/ivory_tang🌐 Visit Contour: https://usecontour.ai/#FDE #ForwardDeployedEngineer #EnterpriseAI #AIdeployment #B2BSaaS #SolutionsEngineering #Logistics #SupplyChain #HappyRobot Yeah, I want to do some quick fire questions, the first one being what has to be true for a company to spin up AFDE motion for it to be worth it? 55:41 Speaker 1 I'll start with tactical or maybe I just, I will say the tactical thing, which is make sure that that customer that you're deploying an FDE on can grow into a big partnership. As a rule of thumb, maybe you can use that million ACV. 55:58 If not, at least you should get product ideas or, or or logo uses or I'm being extremely tactical for those folks out there. Maybe more philosophically, I think if you're building a product that today needs has some gaps or needs some, some bridging, but you know that longer term it's going to be something that just remains now that stays and you don't need people just deploying more and more and more on the on the things that you've already deployed. 56:30 You know what I mean? Like you can deploy new things and new value but not on the existing value. Then I think it makes sense to have an FD. 56:37 Speaker 2 Yeah. And sometimes people use FD as a cover for we don't quite have this product yet, especially, you know, when companies are too early on and they say we have, you know, 5 FDS or something. How would people know that that's what they're doing FD for? And what would you say to a founder who's maybe in that stage? 56:54 Speaker 1 Yeah. I mean, I don't think it's necessarily bad as long as on the tactical side again you get to that revenue number. I mean ultimately it's all about revenue and ARR. So if you get to a point where your deal sizes are 30K and they never grow, you definitely don't want to do FDA motion. 57:16 You just want to build something that is almost self served. But it's fine to, I mean, every founder is deployed for deployed at the beginning. So it's, it's fine to do that as long as you think you knew you need to do it. It's it's hard to say. It's hard to explain. No, I mean, as a founder yourself, like what do you know? 57:32 It's, it's like crossing the the bridge towards, you know, I need to look for profitability almost now. It's it's. It's a tricky question, but. 57:41 Speaker 2 Yeah, makes sense. And we talked a lot about all these traits that make a good FD. Is there a particular like role that people come from that you would think would make a good FD but consistently might fail? 57:52 Speaker 1 No, no, I, I would say you can find good deployment folks like deployment strategies and forward deployment engineers and really any corner of the industry as long as they are highly curious, they have high slope and they want to learn. 58:10 So, yeah. And I have not seen like any particular role that has failed us really. 58:14 Speaker 2 Yeah. And what's the biggest FD cliche that you think is actually true? 58:19 Speaker 1 That's a tough one. What do you think? 58:23 Speaker 2 I mean, there's a lot of cliches out there. 58:24 Speaker 1 Including like what is? Maybe give me a cliche or a few? 58:28 Speaker 2 Yeah, maybe like FD ES or some people call solutions engineers FD ES for instance, maybe FD ES they always have to be engineers or they have to be technical. 58:40 Speaker 1 But that's maybe one. I mean, we, we do, we do think that being technical is good. But you can become technical. I know. I mean, I don't know if being a physicist is being technical because I know physicists that haven't coded in their life, but they are still good deployment strategists. 59:01 Maybe they don't go as deep as like connecting the telephony system to the customers, but they they can think systems. No, especially in this era. I don't, I don't think like the the background is going to matter as much. Which begs the question, what are we teaching to our kids? 59:20 Yeah, it's cool. 59:21 Speaker 2 Yeah, yeah. And what do you what would you tell a founder who's standing up a new FD motion tomorrow? 59:28 Speaker 1 Keep it super simple and just hire people. Give them hire good people, give them leeway, give them space to be creative with their with their account work and make sure that that feedback comes back to the product. So that that ultimate care like utmost respect and care for the customer and for their success. 59:50 And making sure that everything they learn from a product standpoint, not necessarily, again, at least in our case, from the specific use case perspective, but rather from the product. Capabilities comes back into your mothership I guess. 1:00:04 Speaker 2 Yeah. And then same question, but a founder who's maybe scaling from 5 to 60 FD is, what was the biggest piece of advice that you think would have helped you if you had to do that motion again? 1:00:14 Speaker 1 Yeah, keep, keep it super, super flat. Start thinking about some form of measuring that impact, whatever that impact you think should be in your case. But can the organization relatively flat give them that flexibility, give them that ability to be in different places pre post sales and just yeah, let them be unicorns as as I. 1:00:35 Speaker 2 Mentioned, yeah, what? At what point do you think you need Afd leader? Like more than one layer, even though you're still keeping it maybe 2 layers relatively flat. 1:00:43 Speaker 1 Yeah. I mean, we're still figuring it out. We might never have one. We might have one. I in a sense it's more like enablement. I mean, we, we have these deployment execution team, which is not a, not a, not a, not a manager per SE or not a leader, but more so an enablement to the rest of the team. 1:01:03 So I think you can get away with that a lot, but who knows? 1:01:06 Speaker 2 Should everyone have the execution teams or like when do they come into play this? 1:01:09 Speaker 1 Deployment execution team is is particular to us. The name maybe is not even clear to folks, I think. I think it's more like someone that is thinking constantly about making sure that everyone is properly enabled, helping commanders have all the right tools to to to be good mentors, helping FD ES, to, to have all the right training for good scoping. 1:01:32 So it's more of that enablement really. 1:01:34 Speaker 2 Gotcha. And then the last question, this is really broad and feel free to answer it in like logistics of May and anything really just life in general, like what's something you changed your mind on in the past year or something that surprised you? 1:01:48 Speaker 1 I, I think what you initially think has to happen as you grow is you, you hire a lot of, a lot of XX and a lot of, a lot of like old people in a sense. 1:02:04 And I, I, I think that is partially true. Like you can, you can grow a fantastic team with very young and hungry individuals unless, and this has been our case, you find old people that are like, like a young person in an old body, like, like people that are like, are never aging. 1:02:26 And we're, we've been very likely to to have that. But yeah, what, what I definitely think is true is avoiding any bureaucracy in politics, like trying to stay as as fresh as possible as much as you can. I don't know if we'll be able to do that. I hope so. 1:02:41 But that that has been the culture that we want to keep. And people do acknowledge that we have a, a really wholesome and and hardworking culture. As one of our folks say, Achille, our head of strategy, he says this is as if an NFL team was family owned. 1:02:58 Like it's, it's very high paced. You're not going to be playing and you're going to be on the bench if you don't perform. But but, but, but but we are a family. 1:03:07 Speaker 2 That's awesome. Well, this was super insightful, Pablo. Thank you so much for being here and learned a lot from how you guys have been scaling your FDA org and thank you so much.