S4 E13: Connecting High-Throughput Message Routing: Scaling the Core Tech of Courier with Troy Goode

0:02 [SPEAKER_00]: So our customers have a bunch of different templates, a template for each of the kinds of different notifications they send. [SPEAKER_00]: In each one of those, they have to kind of set up the rules. [SPEAKER_00]: Like, here are the channels that we support, we support push, we support Slack, we support email, whatever. [SPEAKER_00]: Let's say you have 40, let's say 100, let's say you have 200 templates who want to do that over and over again. [SPEAKER_00]: So I abstracted those rules out and to something called a delivery strategy.

0:24 [SPEAKER_00]: So go create a delivery strategy and then you can attach that delivery strategy to these templates. [SPEAKER_00]: So [SPEAKER_00]: You only have to do it once. [SPEAKER_00]: Amazing. [SPEAKER_00]: I was sure that customers are going to be so thankful for this. [SPEAKER_00]: Nobody understood it. [SPEAKER_00]: At all, I'm Troy Good, I'm the founder and CEO of Currier.

0:48 [SPEAKER_01]: This is Code Story, a podcast bringing you interviews with tech visionaries who share in the critical moments of what it takes to change an industry and build and lead a team that has your back. [SPEAKER_01]: I'm your host Noil Abhart and today how Troy Good created the smartest in fastest way to deliver notifications.

1:14 [SPEAKER_01]: All this more on Code Story.

1:20 [SPEAKER_01]: Troy Good is based in San Francisco, this family of three kids. [SPEAKER_01]: Their age is 10, 8, and 2, so they're back in diapers. [SPEAKER_01]: He finds family life super rewarding, loves to go outside to the park and spend time with his family. [SPEAKER_01]: His parents had a boat when he was growing up and they lived in a rural area. [SPEAKER_01]: He used to sail as a spectator, not a sailor, down a nearby river in Virginia. [SPEAKER_01]: As he got older, he missed the simple piece yet required work that came with sailing, so he picked it back up as an adult.

1:52 [SPEAKER_01]: He's worked on several startups as a VP of Engineering and CTO, and at one point he was building a collaboration tool when he was trying to mimic the hierarchy of slack notifications. [SPEAKER_01]: He figured out it was not only difficult to build, but every developer was recreating this in their solution. [SPEAKER_01]: He decided to solve this problem and build it one last time. [SPEAKER_01]: This is the creation story of Currier.

2:24 [SPEAKER_00]: So courier is the fastest way for developers to build notifications for their app. [SPEAKER_00]: Whether that be email notifications for a web app, push notifications for a mobile app, SMS, in-app, maybe Slack or Microsoft Teams. [SPEAKER_00]: If you're sending message to your users from your app, right? [SPEAKER_00]: So not user-to-user, not a marketing message, but your app communicating with your users. [SPEAKER_00]: We want to be the kind of one-stop shop to make it as easy as possible to just plug it in.

2:51 [SPEAKER_00]: So the same API call that you would make to carry this in an email is the same one that you would make to send an SMS, a Slack message, a push notification. [SPEAKER_00]: So if I rewind back about 10 years, I was at a company called EllicBum and I led some of the US engineering teams. [SPEAKER_00]: So I'm an engineer by trade, been an engineering leadership for quite a while. [SPEAKER_00]: We had a great exit there, ultimately took the company public and sold it to Oracle, and we built marketing automation software.

3:16 [SPEAKER_00]: So messaging infrastructure for marketers, and our customers were typically tech companies. [SPEAKER_00]: And after that, I went on and I was VP of Engineering and CTO with a couple of their startups. [SPEAKER_00]: And while I kept noticing, was that we had mark automation systems in place, they were great. [SPEAKER_00]: And what I noticed was that the product and engineering teams were still spending a lot of time building messaging infrastructure. [SPEAKER_00]: They weren't able to use HubSpot where these other products for kind of the key say transactional and engagement notifications that our product was sending.

3:47 [SPEAKER_00]: It was just too much work and it was really targeted at a different audience. [SPEAKER_00]: It was targeted at marketers. [SPEAKER_00]: And there was an inflection point at one point where I had a team that was building a collaboration product. [SPEAKER_00]: And we took a lot of inspiration, if you will, from Slack, in how we built that. [SPEAKER_00]: And one of the things that we were inspired by was notifications. [SPEAKER_00]: Slack does, I think, an amazing job at this. [SPEAKER_00]: And nobody's perfect, but I think there's some of the best.

4:07 [SPEAKER_00]: You know, if I were to add, mention you, you know, we were in the same Slack account and I said, hey, [SPEAKER_00]: at NOAA looking forward to connecting later today. [SPEAKER_00]: Well, that's only valuable to either of us or to Slack if you know that I mentioned you. [SPEAKER_00]: And so the way they do that is they say, okay, Troy just had mentioned NOAA is NOAA inside the product right now. [SPEAKER_00]: If so, let's send him an in-app notification. [SPEAKER_00]: If he's not, but he has downloaded the mobile app and accepted, you know, we've got the push token for him.

4:33 [SPEAKER_00]: Let's send a mobile push. [SPEAKER_00]: And finally, we'll send an email if there's nothing else we can do. [SPEAKER_00]: So it's a great, let's do that. [SPEAKER_00]: Let's kind of mimic how Slack works. [SPEAKER_00]: Pretty quickly, learn that it's harder than you would think. [SPEAKER_00]: Like I just described it in 20, 30 seconds. [SPEAKER_00]: It takes a lot more time than that to build it. [SPEAKER_00]: And it was going to take enough time that I decided I can't take the team to have them focus on this.

4:53 [SPEAKER_00]: I'm going to go buy this. [SPEAKER_00]: So basically took out my checkbook, walked down the Twilio, you guys must have this, and learn basically no, they didn't, they pointed me to a few services that I could spend a whole lot of time streaming together when I talked to Amazon, same story, and long story short realized everybody was building this themselves, and as an engineer it felt like the, you know, don't repeat yourself a violation. [SPEAKER_00]: This is not something that everybody should be building themselves.

5:19 [SPEAKER_00]: Let's build this one last talk.

5:23 [SPEAKER_01]: Tell me about the MVP, tell me about how long it took you to build, and what sort of tools you used to bring it to life. [SPEAKER_00]: I started the company in April 2019, and like a little bit of extra background, two weeks later, we were exept into why commonator. [SPEAKER_00]: The interesting thing there is, is unlike a lot of YC companies, I didn't have any customers yet and I did not have a live product. [SPEAKER_00]: My YC summer was spent hustling like crazy to not just get customers, but to have a product to get customers with.

5:56 [SPEAKER_00]: So it was a mad dash to build that MVP. [SPEAKER_00]: I had like a little bit of working code before I applied, but not a ton. [SPEAKER_00]: And it was really turned that into MVP. [SPEAKER_00]: For the last 10 years, I've really loved JavaScript programming, TypeScript programming. [SPEAKER_00]: I frequently write things in Node.js and react. [SPEAKER_00]: That's what I picked for the initial MVP of career, and that is still what we're using today. [SPEAKER_00]: So we used a, you know, create React app to spin up the front end.

6:23 [SPEAKER_00]: We've subsequently switched to next to that. [SPEAKER_00]: Yes, used Node.js with something with time called AWS Amplify. [SPEAKER_00]: As kind of a serverless backend generator, we're still serverless, but we've eventually migrated to the serverless.com framework. [SPEAKER_00]: That's really the tools that I used to build the MVP. [SPEAKER_00]: And it was all hosted on AWS using kind of native AWS capabilities,

6:50 [SPEAKER_01]: With any MVP, you've got to make certain decisions and trade-offs of what you can do in the short-term. [SPEAKER_01]: You've got to cut features, you've got to accept technical debt, things like that. [SPEAKER_01]: So tell me about some of those decisions and trade-offs that you had to make and how you cope with them. [SPEAKER_00]: So like the way career works is, you know, a customer sends an API called a career. [SPEAKER_00]: They also plug in the providers that they want to use for the channels they want to send to.

7:14 [SPEAKER_00]: So for example, let's say you're sending the email and you want to use send grid as your email provider.

7:20 [SPEAKER_00]: You plug it into a web interface that career provides, and then when you send the API a call to career, we do a few things, but one of the things is we route that message to the right channel for that user. [SPEAKER_00]: We then template that message, so we take the data that you pass in as JSON, basically render a templated message using a template you create inside of that visual interface, and ultimately we deliver it to that sender to account. [SPEAKER_00]: there were like three kind of key things that had to work for the MVP.

7:46 [SPEAKER_00]: One is that API layer, right? [SPEAKER_00]: The second was routing, queuing, like basically like being able to accept all these messages and process them and ultimately like deliver the message and the third was that template layer. [SPEAKER_00]: And the template layer is probably the thing that got dialed back the most in the MVP because I knew that I wanted a visual drag drop builder for the templates and that's pretty hard.

8:11 [SPEAKER_00]: and that was one of the first things as we staffed up. [SPEAKER_00]: We who we had to go back and rebuild.

8:17 [SPEAKER_01]: Well then so from there, how did you progress the product and you need to talk about rebuilding? [SPEAKER_01]: You talk about you know moving the product forward and maturing it. [SPEAKER_01]: How did you progress the product? [SPEAKER_01]: And then you know I'm interested in to how you built your roadmap. [SPEAKER_01]: How did you decide what was the next most important thing to build? [SPEAKER_00]: a big part of what we do, right, is as I mentioned, connecting to downstream providers like Sengrad.

8:41 [SPEAKER_00]: And so what I found when I first started pitching career around was, I would quickly find, oh, okay, yeah, but that's looks interesting, but I don't use Sengrad. [SPEAKER_00]: I use Milka. [SPEAKER_00]: So the first thing I did, I remember going to the YC dinners and as soon as dinner was over, it was like, open my laptop out at the table, kind of like ignore everybody else and just add as many providers as I could. [SPEAKER_00]: Because what I wanted to do, I wanted to make sure that when I talked to people, they told me that they didn't want to use career because they didn't think it was good or not important or something like that, not because, oh, you don't support the integration I need.

9:17 [SPEAKER_00]: Building out those integrations was really key to that. [SPEAKER_00]: Pass that. [SPEAKER_00]: There was a really instructive and influential article for me that I read a number of years ago about product management. [SPEAKER_00]: And the summary of the article was, though this author recommended taking every product idea that you have, whether you're coming up with it yourself or you're hearing it from the market and being diligent about bucketing it into one of three buckets. [SPEAKER_00]: One is game changers, one is showstoppers, and the other is distractions.

9:45 [SPEAKER_00]: And basically game changers were, here are the things that if we build it, we have confidence that people will buy us because we built it. [SPEAKER_00]: Showstoppers were, here are the things we have confidence that if we don't build it, people will not buy us because we didn't build it. [SPEAKER_00]: Right, and the integrations I focused on initially were showstoppers. [SPEAKER_00]: and the distractions are like everything else. [SPEAKER_00]: And honestly, to this day, most of my favorite ideas and favorite features that like I would love to have on the road map, fall in the distractions bucket.

10:12 [SPEAKER_00]: And so this bucketing strategy was incredibly helpful for us to think about like, what's the fastest way to pursue product market that here? [SPEAKER_01]: Where did you get that bucketing strategy? [SPEAKER_01]: Did you make it up your on your own? [SPEAKER_01]: Was that something you followed? [SPEAKER_00]: Definitely not. [SPEAKER_00]: It was just some random blog post. [SPEAKER_00]: So, um, but it's it's served us well. [SPEAKER_00]: So hopefully, you know, uh, big thanks to the author at unfortunately, I don't remember who who wrote that.

10:34 [SPEAKER_00]: I read it many years ago. [SPEAKER_00]: But yeah, I read it. [SPEAKER_00]: Read it online. [SPEAKER_01]: I can feel the the engineer can relate to the engineer and you with the list of things that maybe won't aren't going to be the things you're going to work on or the things you really want to work on because they're the fun problems to solve. [SPEAKER_01]: Well, let's switch to team. [SPEAKER_01]: So how did you build your team and I'm interested in what you looked for in those people to indicate that they were the winning horses to join you?

11:00 [SPEAKER_00]: I was a solo founder, fortunate to raise a seed round pretty early, so we had the capital to work with, and the first like six hires were all engineers, right? [SPEAKER_00]: It was really the focus was, this is a developer tool, there's a lot to do here, we need to have an amazing experience on multiple different fronts, SDKs, API, everything, so it was really hiring for engineers. [SPEAKER_00]: first engineer Riley she was somebody that like what I what I found was especially when you're so so early you have to be so aggressive in kind of pursuing somebody.

11:37 [SPEAKER_00]: I recorded her pretty hard right like what I found with her that that is kind of the profile that I think is the right fit especially for the first few folks is she was experienced right so it wasn't a really junior position she had she had quite a bit of experience in our stack I'm normally somebody who [SPEAKER_00]: I don't necessarily care a lot about how what particular programming language you have experienced in. [SPEAKER_00]: But I think for those first few hires, that is important because as time goes on, there's a bunch of onboarding processes that make some of this fungible.

12:08 [SPEAKER_00]: But early on, it's like, hey, you need somebody that's contributing day two, right? [SPEAKER_00]: Day one is like, ramp them up, day two, all right, let's ship some features. [SPEAKER_00]: So she had experience in the tech stack that we were using and she had a real hunger

12:24 [SPEAKER_00]: So she was at a larger company and she'd actually been, you know, part of a smaller company that was acquired Really was frustrated by kind of the slowdown that that comes with that acquisition process and being part of a larger company She's amazing at you know, you find a problem. [SPEAKER_00]: You hear things from customers that they're unhappy with and you don't put it on a road map and solve it [SPEAKER_00]: Two months later, you figured out how can we resolve this for that customer today?

12:49 [SPEAKER_00]: And she just had that hunger and that was, I think, the key thing that we were looking for for many of her stars and frankly, commonly still look for today.

13:00 [SPEAKER_01]: So switch to scalability. [SPEAKER_01]: Did you build this to scale efficiently from day one? [SPEAKER_01]: Are you fighting this as you grow? [SPEAKER_00]: We built it to scale from day one. [SPEAKER_00]: That was important to me. [SPEAKER_00]: I, the good fortune of, as I mentioned, having worked at a messaging company previously, that dealt with incredibly large volumes of scale. [SPEAKER_00]: So I knew from the beginning that this was going to eventually be a problem for us. [SPEAKER_00]: And you know, sometimes it's okay to be like, that's future me's problem, right?

13:27 [SPEAKER_00]: In our particular space, scale is not one of those things that you want to do that with, because you can have a small customer that all of a sudden has a ton of scale coming through on one day. [SPEAKER_00]: It's not a linear growth. [SPEAKER_00]: And so we had to build it to scale immediately. [SPEAKER_00]: And so, made the decision from the beginning to make this a serverless app. [SPEAKER_00]: We don't have a single EC2 server. [SPEAKER_00]: We don't have a single server of any kind.

13:50 [SPEAKER_00]: Everything is functional. [SPEAKER_00]: So it's all land-of-functions, processing messages off of cues, and convenience of streams. [SPEAKER_00]: And we have pretty tight limits around the size of those functions and execution velocity and memory load. [SPEAKER_00]: And that's something we've paid attention to since day one. [SPEAKER_01]: It's interesting, you know, the serverless popularity that's going on right now with the, and you mentioned using Lambda. [SPEAKER_01]: So how is the maintenance for Lambda functions or things like that?

14:19 [SPEAKER_01]: So to speak, versus server. [SPEAKER_01]: And I get, I get the, the value of a smaller set of functions, but as that gets larger, it seems like it's, it'd be a lot to maintain. [SPEAKER_01]: Can you talk about that? [SPEAKER_00]: Here's what I would say. [SPEAKER_00]: I would say serverless is still at the point. [SPEAKER_00]: If your product is not a really natural fit for it like ours is, I don't know that it's worth it yet. [SPEAKER_00]: But it's getting there. [SPEAKER_00]: I think for API products like ours or other products that can have huge spikes in demand that need to be serviced immediately.

14:49 [SPEAKER_00]: I think it's already the superior solution. [SPEAKER_00]: I've been incredibly happy that we made that decision early on. [SPEAKER_00]: I have not regretted it at all, but the debug experience, the deploy experience, the maintenance experience, is like demonstrably worse than just like a traditional Rails app. [SPEAKER_00]: So it can get complex. [SPEAKER_00]: We spent a lot of time thinking about how to improve this, and it does take a lot of our cycles to build out infrastructure internally to make sure this all flows nicely.

15:19 [SPEAKER_00]: There's also a lot of community projects that are making this easier. [SPEAKER_00]: So I mentioned earlier, we used serverless.com, which is kind of a framework to build this out as a monorepo, so it kind of starts to look like a monolith, but under the hood, under the hood, it's being deployed as serverless functions. [SPEAKER_00]: that does help a lot. [SPEAKER_00]: I would definitely recommend using something like serverless. [SPEAKER_00]: There's a few other variants of that that AWS offers.

15:39 [SPEAKER_00]: I'm sure there are others as well. [SPEAKER_00]: Having some sort of management layer, I think is key here, but it will not get you all the way to the point of simplicity as say just a monolithic reality. [SPEAKER_01]: So as you step out on the balcony, and you look across all that you've built with career. [SPEAKER_01]: What are you most proud of? [SPEAKER_00]: Definitely what I'm most proud of right now is the relationship that we have with our customers. [SPEAKER_00]: You and I were introduced by one of our customers and I think that as a team and as a product we're incredibly focused on delivering value to those customers and building an amazing feedback loop with those customers.

16:15 [SPEAKER_00]: and this is one of the things where it sounds like silly because like shouldn't everybody do this but like demonstrably most startups don't and frankly even some of the successful startups i think don't do this particularly well and i i have a few vendors that that we use that i get really frustrated by because i see the experience that's being delivered to me and and that things like support and things like documentation where it feels to me like my relationship with them as a customer just wasn't valued very highly [SPEAKER_00]: We take that all the way to the other stream as much as possible.

16:45 [SPEAKER_00]: You know, we set up shared Slack channels with customers, even customers that aren't even paying us. [SPEAKER_00]: They're on our free tier. [SPEAKER_00]: We are just hungry for feedback. [SPEAKER_00]: Our engineers are participating in these conversations. [SPEAKER_00]: So many of our customers know our engineering team by name and who's good at what? [SPEAKER_00]: They'll just be like, hey, so and so could you help me with this and we love that. [SPEAKER_00]: We love that transparency, that openness.

17:07 [SPEAKER_00]: And we think that that's building a better product and a better company for ourselves and our customers. [SPEAKER_01]: Well let's flip the script a little bit. [SPEAKER_01]: Tell me about a mistake that you made and how you and your team responded to it. [SPEAKER_00]: There's been plenty, right? [SPEAKER_00]: We're about two years old and so we've got 365 times to mistakes because I'm sure I make one at least once a day. [SPEAKER_00]: The, you know, I would say that like there are company level mistakes and then there are kind of the the product level mistakes a product level mistake kind of like that that that was maybe a bit more specific to to code is just getting abstractions wrong for for our customers.

17:46 [SPEAKER_00]: And sometimes we do this with the best of intentions. [SPEAKER_00]: And so I'll give you an example. [SPEAKER_00]: Early on, when I was building that MVP, one of the things I thought as I was building out is I was like, hey, okay, so our customers have a bunch of different templates and template for each of the kinds of different notifications they send. [SPEAKER_00]: In each one of those, they have to kind of set up the rules. [SPEAKER_00]: Like, here are the channels that we support, we support push, we support Slack, we support email, whatever.

18:10 [SPEAKER_00]: Let's say you have 40, let's say you have 100, let's say you have 200 templates, who wants to do that over and over again? [SPEAKER_00]: So I abstracted those rules out into something called a delivery strategy. [SPEAKER_00]: So go create a delivery strategy and then you can attach that delivery strategy to these templates. [SPEAKER_00]: So, you know, don't repeat yourself. [SPEAKER_00]: You only have to do it once. [SPEAKER_00]: Amazing. [SPEAKER_00]: I was sure that customers are going to be so thankful for this.

18:32 [SPEAKER_00]: Nobody understood it at all. [SPEAKER_00]: And I was really certain that this was the right thing to do. [SPEAKER_00]: And I held on to this feature for way too long. [SPEAKER_00]: Because I was like, but if we, if we don't do it this way, you're going to be like repeating stuff. [SPEAKER_00]: But I still think that that's a problem. [SPEAKER_00]: But ultimately, like customers didn't complain about the repeating themselves. [SPEAKER_00]: They complained about not understanding how to set up and use the product.

18:59 [SPEAKER_00]: So eventually we we I act we asked and we removed the feature and we set up the way that customers had asked and Surprise prize. [SPEAKER_00]: They were much happy. [SPEAKER_01]: I I can totally relate to that and honestly I'm aligned with your original approach So I probably wouldn't be helping you too much in this with this mistake. [SPEAKER_01]: I'd probably be fighting It's probably good that we're not on the team together because we'd be fighting it together So what does the future look like for your product and for your team?

19:29 [SPEAKER_00]: Like one of the analogies I like to talk about is being essentially the digital communication version of the UPS store [SPEAKER_00]: So the holidays aren't too far in our past. [SPEAKER_00]: Maybe you sent a gift to a friend or family on the opposite coast, you know, you sent something from Texas to Virginia. [SPEAKER_00]: You have a package of gift that you bought locally, you take it to the UPS store, you tell them the address of who you wanna send it to. [SPEAKER_00]: They give you a few attributes about price versus delivery time, things like that.

19:56 [SPEAKER_00]: You'd make the purchase and boom, the package goes and gets delivered to your friend or family. [SPEAKER_00]: That's not the way digital communications works right now. [SPEAKER_00]: The equivalent of digital communications is if you took it to the UPS store and they're like awesome, we're happy to deliver this package to you. [SPEAKER_00]: Here's a 100 different UPS trucks we have, which truck would you like it on, which road would you like that truck to go down, or would you rather use a train or a plane?

20:18 [SPEAKER_00]: You're really being hyper manual and how you instruct delivery. [SPEAKER_00]: And so our goal is we believe that that's not going to be sustainable, we believe the proliferation of alternate channels is only just getting started and we'll continue to see more and more of those channels. [SPEAKER_00]: And so what we want to really do is build that solution that as a developer, you don't really have to worry about that. [SPEAKER_00]: You can just say, here's the my message, I need to get this to Noah.

20:44 [SPEAKER_00]: and Courier can figure out what's going to be the best channel for Noah right this second, right? [SPEAKER_00]: And that'll be based upon rules for sure, preferences for sure, but also like behavioral impact. [SPEAKER_00]: Like what has Noah typically engaged in? [SPEAKER_00]: As humans, we automatically do this, right? [SPEAKER_00]: Like you and I have had conversations over a few different channels. [SPEAKER_00]: As we get to know each other better, I bet we would figure out which of those channels works best to contact Noah and you would know which channel works best to reach Troy.

21:11 [SPEAKER_00]: Businesses and developers don't do this today and that's what we want to change. [SPEAKER_00]: We want to make it so easy that you just say hey some of this message Noah and curry will figure out and remember for you which is the best way to do that. [SPEAKER_01]: That is brilliant. [SPEAKER_01]: I'm getting out my wallet right now and I'm just going to give you my money.

21:29 [SPEAKER_01]: All right. [SPEAKER_01]: Now, you can sign up for free. [SPEAKER_01]: It's absolutely right. [SPEAKER_01]: I mean, you know, as as a developer, not having to worry about that, is a great problem to solve already. [SPEAKER_01]: But then as a, you know, as a startup founder, you know, knowing that I can send messages and not have to worry about optimal timing or optimal channel, that is massive. [SPEAKER_00]: So kudos. [SPEAKER_00]: Thank you. [SPEAKER_00]: We're still early days, but that's, that's, that's where we're going.

21:57 [SPEAKER_01]: Well, let's switch to you, Troy, who influences the way that you work? [SPEAKER_01]: He named CEO, CTO, architect, really any person that you look up to and why. [SPEAKER_00]: I think the biggest influence here for me, there's been quite a few, but the biggest influence for me was SuperJet Gupta, who was my manager at L.O.K.A.W. [SPEAKER_00]: so he was the VP engineering there over top of both, you know, are U.S. teams that I led as well as our Canadian teams. [SPEAKER_00]: He was in Stilis, he's the SVP of product R&D over it, I'm gonna be called Appian now, that's doing incredibly well.

22:37 [SPEAKER_00]: But he really kind of transformed the way I look at building software and the way I look at building teams. [SPEAKER_00]: One of the things I was amazed by is I'd worked for other, you know, CIOs, CTOs, BPEs and so many of them were used to be technical. [SPEAKER_00]: And one of the things I loved about Superjet was even though he'd been working in the industry for a long time and he'd seen many different transitions to new technologies. [SPEAKER_00]: He was always hungry to not just kind of understand trends and impacts at the high level.

23:06 [SPEAKER_00]: But like, hey, Troy, it's 6 p.m. Let's start hacking on like a side project. [SPEAKER_00]: Let's pick something that we're not going to put a teammate on like because it's just not high enough priority. [SPEAKER_00]: And let's like pick a new programming language and try that, right? [SPEAKER_00]: Let's really understand the pros and cons of the different ways to implement things and really kind of connect at that lowest level with the technology that we were building and that our team was building.

23:31 [SPEAKER_00]: And that really is something that spoke to me as an engineer who was like I was one of those reluctant engineering managers, right? [SPEAKER_00]: And so it was like, oh cool, like I can I can code a little bit. [SPEAKER_00]: Yes, let's do that. [SPEAKER_00]: But also just in how that influence the way that he would relate to the team, how you would better understand, how you'd help the engineers on your team, right? [SPEAKER_00]: It's a lot used to help them if you can actually dig into kind of the possibility space of a bug or of a new [SPEAKER_00]: He was an amazing leader, still talked to him frequently and not as often as I wish I did, but few of them as a mentor.

24:06 [SPEAKER_01]: Well, if you could go back to the beginning, you know, we talked about mistakes earlier, right? [SPEAKER_01]: And a little bit different spin. [SPEAKER_01]: If you could go back to the beginning, what would you do differently, or where would you consider taking a different approach? [SPEAKER_00]: the cliche thing here for a lot of engineer founders that I definitely fell into is not moving fast enough early enough on marketing and just building awareness of the product. [SPEAKER_00]: I was definitely in the camp of let's get the product right.

24:35 [SPEAKER_00]: Let's make sure that everybody loves it. [SPEAKER_00]: Before we really start preaching to the world about career, and that's basically what we did was we waited until we felt like we had product market fit and customers were incredibly happy with us high in P.S. [SPEAKER_00]: etc. [SPEAKER_00]: Before we said okay, let's start to staff up marketing and things about. [SPEAKER_00]: I've definitely learned that that is a flywheel that takes time to spin up, so you'd be much better served.

24:57 [SPEAKER_00]: You're starting to spin that up when you're not ready, so that by this time it's actually running, and spinning around quickly, boom, you want that to be concurrent with your product being ready, rather than having this gap in between.

25:10 [SPEAKER_01]: Well, last question, Troy. [SPEAKER_01]: So you're getting on a plane, and you're sitting next to a young entrepreneur who's built the next big thing. [SPEAKER_01]: They're jazzed about it that can't wait to show it off to the world. [SPEAKER_01]: Can't wait to show it off to you right there in the plane. [SPEAKER_01]: What advice do you give that person having gone down this road a bit? [SPEAKER_00]: First of all, I'd say they're off to a good start, because they're excited to show me the product.

25:30 [SPEAKER_00]: And I would say that most of the really excitable young entrepreneurs that I end up talking to have a problem where maybe they're excited about the idea, but they have an executed and built the thing. [SPEAKER_00]: Obviously, that's like step one. [SPEAKER_00]: build the thing as quickly as possible, get something into customer hands as quickly as possible. [SPEAKER_00]: And then too, start telling the world, right? [SPEAKER_00]: So I think I did the first part of that. [SPEAKER_00]: I did not do a good job at the second part.

25:53 [SPEAKER_00]: I think if you do those two things and if you pay attention to the YC kind of famous mantra, make something people want, that has stood the test of time for a reason. [SPEAKER_00]: If you just focus on making something people want, if you create it quickly, like not just have an idea of something people want, but create something people want. [SPEAKER_00]: and then get into their hands, everything else kind of becomes a reaction to that, an output of that. [SPEAKER_00]: But that is the input you have to do that first.

26:19 [SPEAKER_01]: That's great advice. [SPEAKER_01]: We'll try to thank you for being on the show today. [SPEAKER_01]: Thank you for telling the creation story of career. [SPEAKER_01]: Thanks, Noah. [SPEAKER_01]: And this concludes another chapter of Code Story.

26:35 [SPEAKER_01]: code story is hosted and produced by Noah Labhart. [SPEAKER_01]: Be sure to subscribe on Apple Podcasts, Spotify or the podcasting app at your choice. [SPEAKER_01]: Support the show on patreon.com slash code story for just 5 to 10 bucks a month. [SPEAKER_01]: And when you get a chance, leave us a review. [SPEAKER_01]: Both things help us out tremendously.

26:57 [SPEAKER_01]: And thanks again for listening.