Episode 80
· 42:24
A lot
Chris Bell:of tools are warranted around, like, marketers because there's a lot of money to be unlocked there. But I think, like, enabling the developer to become a champion, that is really important to really making a sticky product.
Jack Bridger:Hi, everyone. You're listening to Skonion DevTools. I'm joined today by Chris Bell from NOC. And, Chris is very appropriately named as Chris Bell because NOC is, a notification API. You're gonna correct me on this, aren't you, Chris?
Jack Bridger:But
Chris Bell:I am. Yeah. So, hi, everyone, and hi, Jack. Super happy to be here today. Yeah.
Chris Bell:So NOC is notifications infrastructure. We like to say infrastructure rather than just API because we see the value in the service as extending past just like an API surface area. So I think, like, one really good example of what we do is, like, we can power in app notifications as well. So think about, like, the feeds that you see in lots of products, something like Vercel. We power that along with all of the real time behavior that comes with that, that feed as well.
Chris Bell:So I think, like, you know, your deployment fails in Vercel. And in real time, you're on the dashboard and you see a notification pop into your feed. That's all handled behind the scenes by Knox infrastructure. Hence, why we think about ourselves as being beyond just the API surface area.
Jack Bridger:This episode is brought to you by WorkOS. At some point, you're gonna land a big customer, and they're gonna ask you for enterprise features. That's where WorkOS comes in because they give you these features out of the box. Features like skin provisioning, SAML authentication, and audit logs. They have an easy to use API and they're trusted by big dev tools like Vercel as well as smaller fast growing dev tools like Nock.
Jack Bridger:So if you're looking to cross the enterprise chasm and make yourself enterprise ready, check out work OS. We've also done an episode with Michael, the founder of work OS, where he shares a lot of tips around crossing the enterprise chasm, landing your 1st enterprise deals, and making sure that you're ready for them. Thanks, Workhorse, for sponsoring the podcast, and back to the show. Yeah. That's really cool.
Jack Bridger:And I I think sometimes we forget how critical these things can be. Like, I think we were talking before I had a a kind of some difficult instances where I think Riverside weren't notifying me that there was a guest and that the this, it's really cool.
Chris Bell:Yeah. Absolutely. We think notifications is one of those, like, incredibly valuable parts of your product that, you know, provides a lot of customer value in the sense that you need it. It helps your customers get back into your product, engage with what's happening there, but it's also something that you shouldn't need to build. And also to build it really well is actually a lot of effort.
Chris Bell:You know? So what Knock gives you out of the box is this kind of ability to deliver cross channel notifications. So think about mentioned that in app use case as well, but we can also do things like email, push messages, SMS, and then chat apps. So think about, like, Slack and integrating something into Slack and sending notifications there as a source as well. So we do all of that, and then we wrap up lots and lots of complex behavior around, like, batching notifications.
Chris Bell:So let's say that 3 guests arrived in your Riverside room, but you don't wanna get 3 different notifications. You want to get one notification about those 3 guests. All of that that kind of functionality is handled behind the scenes with Knox infrastructure.
Jack Bridger:Yeah. I actually did back in the day build, an app for someone. And I think I told you this, but it was like, there was basically classes. And, you know, essentially, the teachers side wanted to get they wanted to have notifications for when a new student joined their class. And, yeah, we use Firebase, kind of like raw Firebase notifications, and it was, like, a huge part of our our job.
Jack Bridger:So, yeah, it's it's very cool. I wish we'd had NOC at that point. Yeah. So you mentioned, the, like, that you're kinda passionate about making these, like, amazing experiences that, like, people can just use APIs. Could you talk a bit about how you design APIs?
Jack Bridger:Because I know you have some interesting takes on that.
Chris Bell:Yeah. Absolutely. So, yeah, we think about at NOC, you know, let's say that we're introducing a new primitive into our API. So a really good example of this is, last year, we released something called schedules. And schedules is basically like, I want to trigger this notification on this schedule for this set of users.
Chris Bell:So think of it like a managed cron job that you don't have to deal with. Right? And we'll execute that in your users' time zones for you. We when we're approaching a feature like that, we think about it from first principles as, well, like, let's write the documentation, first of all, and then let's design the API around that documentation that we're going to write. And then let's put that out there with a bunch of customers or prospects so we can start getting input into that.
Chris Bell:I think, like, you know, some of this is definitely borrowed from our dev tool overlords at Stripe, who I think we constantly cite as doing some really fantastic things. But it's something that's been ingrained into the early days of what we do here at NARC, where we think about, like, every feature that we're going to bring to market is going through this process of, you know, writing really, like, great guides about how you would actually use that feature in anger when you're actually trying to do the job to be done that that feature enables. You know? And then we start to think about, like, the API design and iterating on that API design to make something that feels really ergonomic before we even write a line of code. And I think, like, part of the value in doing that is that, you know, APIs, yeah, they can be versioned, but, like, versioning APIs is really hard.
Chris Bell:It's really, really difficult. I don't like, if you think about, like, who's doing that best right now, and I think that that is still Stripe. Sorry. I'm gonna reference Stripe twice in, like, a minute. Like Oh,
Jack Bridger:that's great. That's simple for us to go research more.
Chris Bell:Yeah. But I think Stripe's API versioning is really excellent, and they use a date based versioning format. But, like, doing something like that off the shelf and building that into your own API is still a tremendous amount of effort. So we like to think about, like, really trying to get the API right the first time around and really, like, being, like, being methodical about that API design process and making sure the primitives that we're introducing are really well thought out. They map really well to our existing APIs that we have.
Chris Bell:They, you know, they have all of the same kind of attributes, the same stylistic properties. Like, the verbs are the same in those APIs and just really making sure that I think there's, like, an aesthetic quality to this. Like, we always write out, like, what the Node SDK call will look like in that doc so that we can start thinking like, does that feel right? Should it be more like this? Should we swap the, like, the the ideas around?
Chris Bell:Should we move this into a different module? Something like that. So I think, like, that documentation just gives a really good place to start exploring that.
Jack Bridger:Yeah. And, like, I don't even know how to how to ask this, but, like, if you had to dig in a little bit more of, like, you've got this kind of, like, you're opening, like, a a Notion file or, like, what are you your what is that first kind of part of the process, like, to get yeah.
Chris Bell:Yeah. Do what? To get ideas down on paper?
Jack Bridger:Yeah. Just like, you know, you're gonna introduce a new service. Like, what is the very, like, first step you're taking there?
Chris Bell:Yeah. I I love to write out, like so everything that we write at NOC from a product perspective starts with, like, a position in statement. So, like, what are we shipping to market today? Mhmm. That that usually happens in our product brief.
Chris Bell:But that gives a really good framing of, like, what we're doing, and then we write a problem statement about how we're trying to solve a problem for our customers.
Jack Bridger:So what would be, like, for for the example you gave earlier about, like, the kind of, like, cron type notifications, like, how what would be the positioning statement and the problem statement for that? Yeah.
Chris Bell:So the the positioning statement there would be, today, we're releasing our new schedules API that allows you to not have to write a cron job anymore to schedule your notifications. Right? That's like, that's the marketing release that we're trying to say. And the problem statement is as a you know, if we were writing it in in stories, it would be like, as a user, I don't wanna write Cron Jobs because they are they're problematic, they fail a lot, and it's a part of my stack that I don't want to manage myself, and it's something that should be offloaded to not. Right?
Chris Bell:So that frames, like, what we're doing. And now when we think about the external facing customer documentation, we can start to write things like, think think about it more like a guide. Like, okay, so you're gonna set up schedules and those help you trigger notifications on a recurring basis for your audience, you know, or your set of users. And we'll we'll literally, like, write a guide that takes them through, like, what that looks like. And that it's really cool because that sometimes, not all the time, but that sometimes becomes the documentation that we actually ship as well.
Chris Bell:Right? Like, in our doc site.
Jack Bridger:When you say guide, it's like a in a sense of, like, a tutorial? Like a
Chris Bell:Yeah. Like a how you would use this to solve your use case is that kind of guide so that you end up having, like, the building blocks and understanding of that feature so that, you know, if you are like, you know, a a prospect and we're talking to you about this API and how it will solve the use case that you've come to us with. Right? So let's just say you're, I don't know, one of our customers, like, Amplitude. They wanna send, a recurring notification to their whole customer base that summarizes maybe some metrics within the dashboard that you have.
Chris Bell:Right? And here's how you can use that API to solve that particular issue. And we'll write sometimes we'll write customer specific versions of these documents to help frame that problem for them. And, again, like, that's that place where we can start sketching out the API, see what it would be like to use, like, see what they think about it. Does it actually solve their problem?
Chris Bell:Does it make sense to them, you know, as a concept? Yeah.
Jack Bridger:Yeah. That makes sense to me. You're doing, like, you would go, like, SDK first there or, like
Chris Bell:Sometimes. Yeah. Like, I honestly, like, I think one thing that's been really interesting for me so I I write TypeScript a lot, and I also write a lot of Elixir because that's the language we use on the back end here at KNOT.
Jack Bridger:Big in the Alexa world, honey.
Chris Bell:I love it.
Jack Bridger:Big organizer. Yeah. Yeah. No.
Chris Bell:You shouldn't ask me about this because I won't stop talking about it. But, yeah. I so I think what's interesting now for me is, like, I think in TypeScript a lot. When we're designing APIs, like, not everyone not all of our customers use TypeScript, but it's just a really lovely place to start designing APIs be and, like, interfaces because, you know, you can start to think about, like, what's the type signature of this? Like, what properties does it take in?
Chris Bell:Like, does that make sense? Like, should we have different filtering options? And then more often than not, it's kinda easy to back out, like, the REST API and point the backs that SDK method. Right? Then the, like, the API around the SDK method.
Chris Bell:Yeah. So that's kind of how I've been thinking about it these days. I'm really starting with TypeScript and then kind of working backwards from there. Yep.
Jack Bridger:Yeah. It makes sense. It always feels like when you're you know, like, everyone can understand, like, REST, but it it doesn't like, people tend not to, like, you know, use it, like, all day and, like, it's it can sometimes I felt like it just takes a little bit longer to to understand what's going on.
Chris Bell:Yeah. And I think, like, I think the reality is is that you can hide really bad restful design behind a nice SDK anyway. Right? And I think, like, like, a good SDK and good verbs in an SDK that makes sense and, like, the API around that SDK, like, that that is the part that most of your customers are gonna interact. That's their surface area that they're thinking about.
Chris Bell:Right? They're in the docs. They've got their language selected, and that's what they're seeing as the code sample. So, like, I, like, I don't typically look at, like, if I'm on a docs page for an API reference, I'm not thinking about, like, oh, how's the, like, all the nouns and verbs of the rest endpoint constructed or whatever, like, the that is. I'm thinking about, like, what's this feel like to use in my code base when I'm looking at, like, a block of code, you know, from the SDK.
Jack Bridger:Yeah. Yeah. That makes sense. And so when you go to the point where you're getting the user feedback, like, how how does that look like in some have you got any, like, examples of stuff that you've done to get that feedback?
Chris Bell:Definitely. A lot of the time for us, that's a Notion page. And we make, there's we don't have a great way of doing it. So if you know of a better way, please tell me. But we basically clone the document for each customer we want to send it to and send a customer specific version of that doc.
Chris Bell:Right? And then allow commenting on it, and then, like, basically collate the comments, and then use that to inform the next version of the doc that we then send out.
Jack Bridger:And do people do people take the time to give you that feedback?
Chris Bell:Oh, yeah. Like yeah. Like, it's it's awesome. Like, we've been doing this like, when we started doing NOC, like like, literally, we started with the documentation. We didn't start with the the actual, like, product.
Chris Bell:We started writing docs and sharing them out and trying to communicate what we're doing to get feedback. Yeah. And I think that that's just been this, like, interesting long standing principle about how we thought about building products collaboratively. And it's not all, like, super data driven where we're like, yeah. We got 7 comments, so that means that this is, like, great.
Chris Bell:You know? It's nothing like that. It's definitely like vibes, but
Jack Bridger:Yeah. Yeah.
Chris Bell:It still helps it still helps refine exactly what we are doing and articulating it. Right? Like, if someone doesn't get it from reading that doc, like, the doc's wrong or, like, the value proposition of what you're building is wrong. Right? So Yeah.
Chris Bell:I think it helps you really refine your messaging, which ultimately, if you think about being a developer tool, half the time, like, you're trying to explain concepts to developers so they can leverage those to integrate your tool. Right? And that has to be very concise, very clear. We spend a ton of time thinking about just the language we use to explain features and, you know, get that kind of feedback. Yeah.
Jack Bridger:Yeah. That makes so much sense. Because I guess if NOC was, like, very difficult to figure out how to use it, then it's, like, the value prop is, like, half the value prop is gone because, like, then it's just about reliability or something. And not Yeah.
Chris Bell:And I think, like, in our space with notifications in particular, like, we are a flexible set of primitives, really. And that's a lot of words. What does that really mean? Well, it means that we offer, like, different APIs and building blocks so that we can try and solve whatever notification challenge you have, it can translate into NOC. Right?
Chris Bell:Yeah. I think the biggest problem with building very flexible products is it's really hard for you to go, wait. I've got this problem. How does that map to their domain and what they are doing? Right?
Chris Bell:How do how do I think about solving this in NOC? And we have this like, the heart of NOC is this workflow engine. So you start designing the, like, the logic and, the kind of, like, templates, the channels that your notifications go to. So, like Yeah. Like, that is this very, very flexible system, but you need to kind of root the developer or the person doing the implementation in your nomenclature so that they understand, like, okay.
Chris Bell:This is where I start. This is what I need to do. This is how I need to reason about this system over here. You know?
Jack Bridger:And how'd you do that? Because that's quite it feels like quite a hard thing to do.
Chris Bell:Yeah. I would say we are not, like, we're not bad at that, but that is a constant challenge. Right? It's a constant like, the feedback loop there for us has been, like, write the doc, do all that process I talked about around, you know, refining the feature before it goes out, write the documentation, you ship it. But I think, like, as soon as you have a customer, like, stumble over a part of a documentation or not get it, they come to a support channel.
Chris Bell:Right? And they're like, hey. I'm trying to do this thing, but I don't really get how this works or whatever it is. Like, that feedback loop needs to be incorporated into a PR that updates the docs, like, same day. You know?
Chris Bell:Like, that's the kind of process that we like, that that loop, like, we try and relentlessly go through it and just shave off those edges constantly. Right? Like, hey. You were trying to use that schedule's API, but, like, maybe you don't know what a cron is, and therefore, it doesn't make that much sense to you. Right?
Chris Bell:So the language is wrong in explaining that feature. Yeah. So I I would I think, like, this is a challenge for any kind of developer tool that's got that. You've got a complex set of topics that you're trying to distill people to understand. And then there's also this aspect of, like, you don't wanna overwhelm that engineer with all of this upfront.
Chris Bell:Right? Like but that API I've been talking about, this this schedules one, is some advanced API. Like, you might not even have a use case where you need to schedule a notification on a recurring basis. Right? Yeah.
Chris Bell:So you wanna, like, we wanna layer those things in gradually. So you wanna, you know, like, think about, like, the ladder of success so those engineers getting started, but then having like, knowing where to reach or find when they have that kind of need in and they need to, you know, scratch that itch or solve that problem. Yeah.
Jack Bridger:Yeah. And is there any, like, kind of guidance that you have on, like, how to get that right of, like is it just hard, hard work?
Chris Bell:I think, like, that's been a struggle for us recently because the surface area of our products has increased quite a lot over the last year. And I think, like, architecting your docs to help your users, like, feel grounded and not feel overwhelmed is a really hard problem. To plug someone who I feel like is doing this very well, WorkOS, their documentation is fantastic. It truly is. Like, I think having very use case oriented docs, like, they do a really good job of, like, hey.
Chris Bell:I, as an engineer, am trying to build directory sync into my product right now, which is, like, you know, you are an enterprise IT admin. You have a list of users. I need all of those users to be in this NOC account. And I, as a developer at NOC, am trying to integrate that directory sync process. Like, they, like, they have a section of the docs that's like, you're integrating directory sync.
Chris Bell:It's all the topics, all the surface area around that. And it layers in complexity so that you can get to the advanced topics if you need to. You can start off in a really simple path. You know, it's kind of that, like, choose your own adventure of, like, where you wanna get to and what kind of complexity you wanna layer in. And I think that's that's the kind of north star of where we wanna take our documentation experience.
Chris Bell:Like, really good example of this in NOC is, big part of notifications are preferences. Right? Like, the settings that you turn on and off. Yeah. And we have this, like, really flexible preferences model, but it's really hard to get the whole surface area of it if you're just trying to do, like, the simple thing to get started.
Chris Bell:And we have one doc page that's, like, here's everything you need to know. But, like, really, that should be, like, many pages that help you kind of steer and help you solve the, like, the job to be done that you have of implementing, you know, probably some simplistic set of preferences to get started.
Jack Bridger:Mhmm.
Chris Bell:But then open the door if you need to do the more advanced stuff, like really having fine grain user control over, when a a a notification should fire. Like, Vercel use us to do this for all of their usage based alerts. I don't know if you've seen this in Vercel, but you can say, like, when I've spent a 125% of my budget, I wanna be notified. That's all powered with NOC under the hood and uses this really complex part of our preferences model. You know?
Chris Bell:So
Jack Bridger:That's cool. So you is there, like, a part of you that's happy when you see, like, a dev, like, complaining about their bill? Like, that's us.
Chris Bell:Well, I never want people to be frustrated with any other tool. But I there yeah. There but yeah. We're, like, we use Vercel to deploy NOC, and there is this element of pride where, like, well, I guess, when a deployment fails, we're always like, oh, that email is powered by NOC. You know?
Chris Bell:It's kinda cool. And then we're like, wait. We gotta fix the build. You know? Yeah.
Chris Bell:Yeah. That's that's
Jack Bridger:that's the crucial thing. Yeah. Shout out to myself. Yeah. Okay.
Jack Bridger:Awesome. So one thing that we also wanted to talk about is about when you're coming into companies and it's not just this simple thing of, like, hey, I'm gonna use NOC to solve my problem. It's like they are, like, you're dealing with a team who's kind of a central platform team, and then there's other teams branching off who use them, who come in and use them. Could you tell us a bit about why that's hard and, like, what you've learned, in in doing that?
Chris Bell:Yeah. I I love this topic as well. So, yeah, I think, you know, we kinda see these 2 different sales within NOC. 1 is, like, you're a small engineering team. You're buying us.
Chris Bell:Maybe you're you've got, like a an existing set of notifications that you're replacing with NOC, and we're gonna start powering all of your notifications. And then the second sale is really, the one that we've been butting up against a lot over the last year, which is more to this platform team. So, you know, think, your Amplitude. There are 10 different product teams all iterating on their own areas of the product. Typically what happens there is that every product team is building their own set of notifications.
Chris Bell:Maybe they have their own notification services. Maybe they're managing their own notification templates. So, like, you know, the emails they're sending and things like that. And some teams' remit is, hey, we need to centralize this, and we need to have a single service that's powering all of these notifications. Right?
Chris Bell:So that's where NOC comes in, and that's like the part of the sale where we can be really, really effective with these kinds of teams where, you know, we are selling not just the ability to solve notifications for one team, we're thinking about it more as, you know, you're coming in and you're deploying this across many teams, and then you are centralizing the system. We're giving your platform team a single place to observe this. So think about all the metrics that are coming off of it. Like, I'm talking, like, actual, like, sending metrics that integrate into Datadog and things like that. So you can get observability into that system.
Chris Bell:And then the logs that are happening and give them a single place to go to to kind of understand all of the notifications that are going out to customers, in in a single centralized location. So in that model, we are yeah. Your buyer is this platform team, but then that platform team, that they need to facilitate the adoption across all of these other product teams. Right? So the sale becomes you're selling to the platform team in this way where they need to think about, like, the tools that they need to roll this out across all those teams.
Chris Bell:So things like governance, like, how do I allow access to certain notifications, but not allow certain parts of access to certain bits of the product, things like that. And then how do I report on each team's set of notifications that are going out so that I know who to page if in case something's going wrong? You know, things things that are like typical kind of platform engineering problems. And I think as a third party tool, kind of solving those challenges is very different often to solving the, like, individual sale that I talked about before. Yeah.
Jack Bridger:Yeah. And, like, what what is it that is is is harder about it? It's like
Chris Bell:Yeah. I would say the part that's challenging that is it's almost like the enablement part. Right? Like, you are one step removed from the team that's actually doing the implementation. Right?
Chris Bell:Like, you are not you are no longer being like, okay. This team, you are implementing Knock. Here's what you need to do to go ahead and do this. You are setting that team up to then, like, maybe lay a little bit of the groundwork, but then that that team has to help facilitate lots of other teams in basically saying, okay, this is how you're gonna move your emails over to NOC, and this is how we're gonna set up reporting, and this is how we're gonna do all of these different parts. So it's much more like I think the interesting part there is it's it's almost educational.
Chris Bell:So you have to start thinking about what materials do we need to arm that team with in order to for them to be successful. You know? Like, you're almost serving, like, it's like, you are serving that platform team. They are serving their customers who are other product teams. Those product teams are serving the underlying customer for and users.
Chris Bell:You know?
Jack Bridger:Yeah. And so be because I guess, like, in the worst case, you would make you'd spend loads of time setting it up for the platform team. Works for them. They're paying you money. You've got all these, you know, usage that they're paying you for.
Jack Bridger:But no one in any of the actual, like, kind of, like, team product teams, use NOC, and they just do whatever they had before. They don't bother to, like, make the change. And then Absolutely. In 2 years, it's like, oh, okay. Why are we still paying for this thing?
Chris Bell:That is exactly right. And I think, like, you know, you think about, like, driving successful outcomes for customers in that way. Right? Like, success for that platform team looks like some adoption metric. Definitely.
Chris Bell:It's you know, after year 1, we want 70% of our notifications to be going through this service. Right? Or like existing notifications, but we wanted to have layered in this new capability that NOC unlocks. Like, let's say they wanted to start sending Slack notifications and then they need to evangelize that across teams to start powering it as well. So I think, like, yeah, to your point, like, a really bad outcome there is, hey.
Chris Bell:We bought this service, but, like, we haven't been able to help teams adopt it because it's just sat there in the road map or whatever and just been left to die. And, like, it's much better to to build the relationship with the platform team there to help like, help them empower their teams to do the job. You know? So that's that's one part we really think about is, like, how can we be there in Slack with them? How can we help support that customer?
Chris Bell:How can we, like, you know, then be in a shared Slack channel across between that platform team and any other product teams that are helping implement and really, like, give really, really great firsthand support to all of those folks at the same time. Yep.
Jack Bridger:Yeah. Is there ever a time where you kind of, like, you you have this great, like, momentum in a sense with the platform team, but you're getting, like, a lot of red flags around, like, okay. Like, I feel like this is just gonna go and just sit with them and no one, you know, like because I guess it feels like some part of it is, like, you could do it really well, but then it's, like, so you can't you know, you like, you can lead them to the water, but, like, it it feels like there must be cases where it's, like, really hard to get people to, like, actually adopt this when you're removed.
Chris Bell:I I think the I think the challenge in a lot of tools like ours is prioritization on a road map, right, for that product team. And then being able to, you know, like, say, you know, what's important this quarter is prioritizing this notification problem and making sure that we're implementing this. Right? And doing that migration. But I I think often that driver in the platform team setting comes from that team because they're under agreement to, like, deprecate an old service or turn off, you know, a piece of infrastructure that they no longer want to support.
Chris Bell:So I think it it we can be in a good position in that way because, like, you're almost like they're dry they're driving the adoption for you. I Thinking the worst case, like, the other side of this is the platform team couple us to some new capability they wanna build internally. Like like, we've seen this in the past where it's like, hey, we never had, like, a a Kafka real time event stream, and now we want all our notifications to be powered by that. So Yeah. No no one else can adopt this until we've done that infrastructural work, and then we're gonna start powering notifications.
Chris Bell:And then you're kind of just stuck in this, like, waiting period. You know?
Jack Bridger:Yeah. That makes total sense. So it's, like, kind of, in a sense, I just like playing back what you're what you're saying, it sounds like, okay. Like, if you're just working with the platform team, like, you kind of wanna have, like, the pull from one of the product teams as well rather than just be, like, the platform team think it's a good idea to do it. Like, you actually want to
Chris Bell:I think that that's right because usually the driver of, like, why a service wants to be replaced, like, I don't know if you ever think this, but I often like, a saying that I always say is that engineer's gonna engineer. Right? Like, if you let engineers, like, do things, they're gonna be like Yeah. Know what we need to do, replace this service for reasons. You know?
Chris Bell:Yeah. Yeah. And I think sometimes that's not always true for all teams, but I think on platform teams, like, that be true. It's like, what's the new shiny thing we wanna, like, do right now? And I think often with especially with notifications, like, we're delivering value to to customers effectively.
Chris Bell:And I think a lot of our sale, especially at Knock, is about, product teams driving new outcomes. Right? So Mhmm. Like, what does that mean? Well, you know, we've never had an in app notification system, or we wanna start really easily messaging our customers, like, inside of the product, using that as a surface area, and then we wanna rebuild our emails or or, like, you know, layering in that new capability that they couldn't have before.
Chris Bell:And that becomes the driver of why the adoption matters. Right? And then it can spread outwards from there. Yeah.
Jack Bridger:Yeah. And this sorry. This actually gives me, like, a really good interesting at least interesting for me segue is the like, when I was looking at notification tools back in the day, OneSignal was, like, the dominant one. But OneSignal is very, obviously, you know, for everyone else, OneSignal is very much marketed to marketers. And it it feels like, you know, the developer, you know, the docs and stuff, it's like kind of an afterthought.
Jack Bridger:And it's but when you talk about those kind of capabilities, that sounds like the sort of thing that the marketing team would probably care about more than the development team, for instance. So I wondered, like, how, like, you, like, manage, like, who you're talking to and, like, how you approach companies and stuff.
Chris Bell:Yeah. That's a great question. So, yeah, I think the way that you're seeing the world tracks with how we see it. There's there are a swath of marketing tools that exist in the market, like Braze, OneSignal, Iterable. Like, they're all tools that facilitate customer engagement by and large, which is basically sending messages to customers.
Chris Bell:Right? Most of those are owned by marketers, and most of those tools have transactional capabilities. But, like, where we fit in right now is we are really thinking about transactional notifications for products. So think about, like, you know, you're a dating app. Someone matches with you, and we need to send out a push notification and then maybe an email.
Chris Bell:And it's those kinds of capabilities that we're encoding into Knott. And that means that our sale is much more driven by products and engineering, primarily. And I think the interesting part of the market today is, like, there's, like, what we're talking about transactional, then there's marketing, and there's this, like, messy middle, which is, like, life cycle marketing that's kind of owned by product, kind of owned by marketing.
Jack Bridger:Yeah.
Chris Bell:And that part in the middle is where we see, like, a really interesting expansion opportunity to start powering more customer centric messaging that's not just transactional notifications, but it's much more like just customer messaging that's really native to your product and leverages all the really great developer experience that we've built already with, like, React components. You can just drop into your product, really good documentation, really great SDKs, like, really good logging and observability that feel native to, like, if you had built that service yourself. So that yeah. Like, we I think the world is like the the the dirty truth of the world that you're talking about with those marketing tools is, like, they're bought by marketers, but they're implemented by engineers most of the time. And engineers want the right tool, you know, and we're like, we're the ones in this in the journey now that are, like, have significant sway in the in the sales process, and we're, like, have budget and engineering teams have budget to purchase tools.
Chris Bell:You know? So that's, yeah, that's how we see the world.
Jack Bridger:Yeah. It sounds similar to how, Posthog seem to
Chris Bell:Yeah. On the on the, like, data and BI side and, like, how they're thinking about it there.
Jack Bridger:Yeah. In terms of, like, coming at it from I I mean, they do a lot of things, I guess, but, like, maybe, like, Mixpanel would be one of the comparisons whereas, like, Mixpanel is built for marketers whereas they're, like, realized that a lot of developers are spending a lot of time with Mixpanel and product teams that, you know, using Mixpanel a lot. Or maybe Mixpanel would be angled at products people. I don't know. But
Chris Bell:No. I think that that's right. It's a combination of product and marketers probably for Mixpanel. Yeah. Yeah.
Chris Bell:Yeah.
Jack Bridger:And and they were much more like, well, developers, you know, have been burned using these tools that don't aren't built for them. So let's build something that's, like, does what they do, but it's, like, much more tailored to developers.
Chris Bell:Yeah. Definitely. And I think then you can enable, like, the developer champion in that sale. Right? And that's the key thing for companies like that.
Chris Bell:And, like, I think that that's kinda what I was referring to before about, like, they have sway. They might not have like, I think the truth is, like, marketers have a lot of budget and, like, that is, like, also why a lot of tools are warranted around, like, marketers because, you know, there's a lot of money to be unlocked there. Like, but I think, like, enabling the developer to become a champion through great developer experience and everything that that means, I I think, like, that is really important to, you know, driving a future sale and and, like, really making a sticky product as well.
Jack Bridger:Yeah. This so it goes on a massive tangent. But, like, I remember, there being this, like, huge discussion of, like, I think I don't know if I told you that back in the day I worked in sales at Stack Overflow and, like, there was this whole thing of, like, do companies see developers as, like, a cost or, like, a I don't know what the word was. Like, a value center or something. You know, something corporate speak for, like and I feel like marketers get that extra budget because it's like, oh, we need to power the Valentine's promotion campaign that always brings us, like, $10,000,000.
Jack Bridger:So we're gonna spend a $100 on this tool. No problem. Whereas, like, if you're the dev team, you've gotta it's it's maybe in some companies harder to justify, like, how much money can we save by buying this thing unless you're able to show that you're like, okay. This this could also drive, like, you know, an extra million in sales or something.
Chris Bell:Definitely. And, yeah, I think what you're yeah. Absolutely. We see it, like, where marketing and sales tools coupled to revenue, they're, like, very easy to sign off money and budget for a lot of the time. And then, yeah, I think in product teams, like, you're part of the cost of goods of of the product being sold and you need to think about margins and, like, yeah, it's really I think in this market, especially, like, we're seeing companies clamp down on spend on in cloud tools and, like, budgets being scrutinized a lot more about, like, how much are we spending on that random tool over there that, you know, is driving this?
Chris Bell:And is that the right investment? Should we, you know, should we build that? Should we buy it? Should we bring that in house? Like and these are, like, really interesting conversations for engineering teams, and trying to make sure that they're getting the right kind of cost of value equation.
Chris Bell:You know? And I think a really thin way to sell that is just like, we're saving you 10 engineering hours. Like, that's kinda not enough. Like, you need to sell, like, the full package, like, how much infrastructure was, like, cost we're saving, how much, like, time you're saving on a regular basis of, like, keep the lights on work and maintenance and things like that. So yeah.
Chris Bell:But I don't know if that answers, then, like, yeah, vibes of what you're saying.
Jack Bridger:Yeah. No. No. But and and so do you do you ever, like, try and tie it to, like, the more like the the value side of things?
Chris Bell:Yeah. Definitely. And I I think that, like, that is about the capabilities. Right? It's like I know anyone could probably build a Slack integration, you know, but if you use Nock to do that, we just shipped a bunch of React components that you can drop into your product and have Slack up and running within an hour.
Chris Bell:And now, hey, guess what? That's one part of a much bigger story about multichannel notifications that you can now enable. You know? Mhmm. So I think, like, you're like, it's cost saving, but it's also like I like to say this phrase of, like, we're shipping your notification road map.
Chris Bell:Like, the road map that you your product managers, like, had. Right? And instead of them being like, ugh, we gotta deprioritize that again for, you know, this this big customer just has this feature that we need to ship. So therefore, all these things have gone off. Now you can say, well, actually, we get all of that, and and I'm saving engineering time.
Chris Bell:But it's more about the capabilities that you're enabling, right, than just the the the pure engineering time that you're saving. Yeah.
Jack Bridger:Yeah. I feel like this actually could have been the topic of the whole conversation of just, like, how do you, you know, how do you justify yourself?
Chris Bell:As a service?
Jack Bridger:As a service.
Chris Bell:Yeah. I think it's a I'm, I actually like talking at lead dev in September about, like, making build versus buy decisions as an edge team. And a lot of this is about those kind of decisions about, like, what capabilities do we wanna invest in as a team? What do we wanna outsource? Like, what's the cost of maintaining the service in house?
Chris Bell:Like, where are the hidden costs? Like, I think a lot of things, and, like, this is why things are being serviced. And it was like, it came into my head. I'm like, that is a dumb word. Let's just
Jack Bridger:go with it. Serviced.
Chris Bell:Yeah. Why things are being made services? I I think it's like it's definitely it's it's thinking about, like, what's core to our business. Obviously, what's not core and trying to outsource those. But it's also like things seem really easy on the surface to ship great software today because we've got so many packages and we can just, like, layer in, you know, capabilities kinda easily.
Chris Bell:But all code is a liability. Like, do you really wanna own that liability or do you want someone else to own it? You know? So I think yeah. That's kinda how I think about it a lot.
Jack Bridger:That's definitely how I say as well. Well, I think it's, like, that's one of the things that maybe divides some engineers, I think.
Chris Bell:Yeah. There's, like, a hubris of, like, the, you know, every new product that launches on hacking news and someone's like, I could've built that in a weekend. You know?
Jack Bridger:Yeah. Yeah. It's it's interesting. That that'll be we won't open that kind of worms because I think, like, this probably will be here for a long time. But We'd
Chris Bell:love to come back and talk about it tomorrow's time, Jack.
Jack Bridger:Okay. Chris, thanks so much for joining. Before you go, have you got one takeaway for, those listening?
Chris Bell:Yeah. First of all, thanks for having me, Jack. And I think my takeaway is APIs are immutable. Treat them as such, and do some design up front. And it's okay to be in the in a design phase for a while.
Chris Bell:You know?
Jack Bridger:That's actually an amazing takeaway. I'm gonna I'm taking that one to heart. Chris, thank you so much for joining. If you wanna learn more about Chris, Nok dot app.
Chris Bell:That's right.
Jack Bridger:And what's your Twitter handle?
Chris Bell:It's cjbell_, because couldn't get cjbell. So
Jack Bridger:Yeah. So if you are cjbell, really relinquish the handle. Otherwise, cjbell underscore. Thanks everyone for listening, and we'll be back again soon.
Listen to Scaling DevTools using one of many popular podcasting apps or directories.
