Alex Bouchard from Hookdeck. Competition is a good sign

We just took how people were using the product, and we relabeled or, like, spelled out differently what that value was and kind of, like, the marketing associated with that and their documentation and so on. But the the actual product is is the same product. Right? So I don't really consider that a pivot. I think it's it's just a different way of explaining what you do to the market without really changing what you do.

Like, ultimately, the people we would, like, compare ourselves to are, like, all those, like, medium articles or blog posts you would see of, like, staff level engineers writing articles about how do you build reliable kind of, like, HTTP ingestion or webhook processing and so on. But, but over time, users have kind of been using the product in all those different ways that really had little to do with webhooks themselves. It took us kind of longer, I wanna admit, to really piece it together. But eventually, I wanna say last May, we kinda coined this term of, like, Odek really being an event gateway. And I think the thing that was important for us from a positioning perspective is to say, it's kinda twofold.

So the first part is you don't wanna necessarily put the emphasis on webhooks specifically. And the reason why we didn't wanna do that is, like, as we were talking to people, it's be it was becoming more and more clear that the webhook part of the problem is the part that, like, good engineers already understood well. It's like a HTTP endpoint. It's very obvious what you have to do to receive a webhook and so on. The part that they were struggling with is the event driven nature of that webhook.

So I think in that positioning, it was really important for us to say, like, okay, let's put the focus on the part that people are actually struggling with right around the part that everybody kind of, like, takes for granted. So last December, we kinda released this new website, new documentation, new use cases, new quick starts for those use cases, and so on that really put the focus on being this event gateway. And the way that we think about the event gateway, it's this, IO for basically all the events that come into your infrastructure leave your with your infrastructure. But the thing that's really important about a gateway is the fact that it lets you, interrupt or integrate with kind of like the outside world. So third parties that could be, still like the Shopify, the Twilio, and the get out of this world, but it could be your customers sending you events.

It could be IoT devices. It could be scanners, or it could be you sending events. Sending events to third parties, to your customers, publishing public events streams, and so on. So we really needed to, like, find a terminology that kind of, like, capture the breadth of use cases that people were actually building on top of the platform and the product that we had already.

Like, they haven't lived through a pain. They haven't had, like, a big event system related outage. They haven't, like, misunderstood 1,000,000 webhook over a weekend. Right? So they don't have as much to relate to.

And for those folks, I think it's still important to talk about the webhooks because the webhooks are very problem oriented. It's like or solution oriented, I should say, in the sense of, like, I'm trying to receive this webhook from Stripe. I wanna make sure our process is process it correctly. But when you talk to more and more, kind of, like, senior engineers, then the problems shift where it's like, well, okay. I've lived through this.

Right? Like, 2 years ago, or API went down because I did a bulk retry in Twilio or it was Black Friday and so on. And you have those things that you can current correlate to, and now you have experience working, excuse me, with some event driven architectures. You've implemented RabbitMQ or you're using SQS or Kafka and so on. And now the type of problems that you think about are very, very different.

Right? And I think in a repositioning, we're also trying to align ourselves more with the latter, kind of, like, more senior engineers, because, ultimately, we're trying to position our problem as being cloud infrastructure solution for those folks that are operating at scale that are receiving 100 of 1,000,000 of of Webex or events and so on. Right? And that would that was, like, really kind of, like, most important, I think, shift in in how we talk about it.

So if you're looking to cross the enterprise chasm and make yourself enterprise ready, check out WorkOS. We've also done an episode with Michael, the founder of WorkOS, where he shares a lot of tips around crossing the enterprise chasm, landing your first enterprise deals, and making sure that you're ready for them. Thanks, WorkOS, for sponsoring the podcast and back to the show. Yeah. And so when you've got these kind of people that are, you know, very experienced, they're already doing this stuff, but they're, you know, as you mentioned, like, running into challenges, but they're not using tools to do this right now.

How important is it to kind of that you're replacing a tool? Do you need to, or is it okay to just be, like, replacing a workflow?

Right? But I think that the thing that matters is, like, how much the thing that you're replacing is comparable to something else that they can kind of, like, refer to or have on top of their mind. So in the case of the event gateway, like, the very obvious proxy is the API gateway. So the API gateway came around, replaced our workflow as specific kind of value proposition associated with it. So there's, like, security, there's routing, there's rate limiting, and so on.

They're a kind of value proposition for API gateway. And what we're saying is basically this value proposition is also needed for the event driven world, and it's resolved differently. So I think you need to have that proxy in a way that we didn't before. Like, before, the only thing that we could point to is those kind of, like, staff level engineers' articles that were, like, on Medium or Dev. 2 or, like, on the individual blog, and we could point to this.

But, like, it's it's it's really as far as we could go. Right? And, so so to answer your question, like, you can replace a workflow. I think you kinda have to if you're creating a category, and then we can talk about, like, whether or not you should be creating a new category afterwards. But, but you kinda have to.

But I think the point is, like, you wanna try to make the the the mental gymnastic that someone has to go through to understand, like, what the category you're you're creating as easy as possible. And the probably the best way of doing this is attaching yourself to, like, proxies or things that are already similar or, like, are conceptually similar to what you're doing, and then just, like, adding on your twist instead of trying to be the twist, you know, the the whole point. Right? So, so, yeah, at least that's how I'm thinking about it now.

So, you know, combat the at the at the cross section of those things, it's easier to understand.

So not only did they attach themselves to a category, they also name a competitor. And generally speaking, I think, like, not having a competitor is probably a bad sign. Right? There's kind of, like, the the founder in all of us that you start as the 1st 6 months. You probably don't even Google at all what you're doing because you're kind of complete denial of having, like, 50 other people doing the same thing as you. Right?

Right? Because the more people that are trying to hit that category or are operating adjacent to the category, that's the more more people that you can attach yourself to you. And then Ava is a proxy for understanding what you're doing, the value that you're bringing. So in many ways, like, we're trying to do the same thing now. Like, we just released this article comparing ourselves to, AWS EventBridge.

I think it's a great comparison. Right? And on some points, we do it very well. On some others, not as much. And now that's part of the road map. But I think it's important for us to be able to say, well, listen. Like, we're not the only event gateway. Event version event gateway, Azure Datagrid, I might be getting this wrong, is an event gateway. Event Google Cloud Eventarc is an event gateway, and so on. Right?

So now we're kind of taking inspiration from, Supabase and saying, like, well, our what Firebase was to Supabase, it it will also bend bridges to EdTech. Right? And, maybe from some naivete or something when you start, you're trying to do the exact opposite of that. So if you're creating a new category, you should probably be seeking those out.

Most kind of, like, big influential companies created their category in some way. Now there's, like, various degrees of how category creating they were, but there's always going to be something, like, fairly, kinda novel or, like, warrants, like, a new Gartner category at the end of the day. So so that's not to say, like, there's not great companies to be built in existing categories. There obviously are. But I think that challenge is, like, an important one to tackle, especially if you think you've, like, found something sufficiently relevant and valuable and that you have a strong vision around that it kind of warrants, you know, you kinda taking on that risk and that challenge.

On creating new categories, I think that 2 things have become, like, really interesting is that you're not really comparing yourself on kind of, like, quantitative facts of, like, what is your pricing or what is future x, y, and z doing versus, like, competitors and so on. It's very difficult to then, like, start drawing those comparison tables. Right? We're kinda trying to force a little bit with the EventBridge and so on, like I was saying. But so so I think it's a first set of challenge.

I think the second set of challenge has a lot to do with product. Because there's a set of expectations around how a product in a existing category is supposed to work, and now you're trying to, like, make those better. But the problem when you start from scratch is that there's an inherent risk that you get the design wrong from the get go. Right? Because there's no established way about what you're supposed to do this.

And, like, we we've definitely kind of been through those mistakes. Like, you need to be very careful about how you name things. Like, we're building the product for developers. Right? We have APIs that thousands of people use.

It's very important to think about, like, what the product semantics are going to be. How do you name things? How do you structure things? What are the core components of what you're building and so on? Because especially in DevOpra tools, it's very hard to, like, go back and change those things. Right? If you're building, like, a consumer kind of product or whatever, your v 2 could be nothing like your v 1. I'm like, it's fine. Right? There's no real kind of consequences, to that.

But for something like, for someone like codec, it's just like that. That's a no go. Like, that that's how you destroy your reputation. Right? You do a v two version that's completely backward compatible over everything else you've done before.

So so I think you have this extra challenge in in developer tools to be very mindful about, what are the right kind of foundations that you wanna you wanna build this on because you you don't really have anywhere to take inspiration from. And that's definitely been, like, something I've found, like, one of the most challenging as part of the journey.

So one of the place where we take inspiration from, in our case, is all the kind of ETL workflows. So we call it primitive source, connections, and destinations, which is like something you're gonna see in Fivetran or, like, Segment and so on. Right? But, obviously, the product is different. It's not a ETL tool.

So now you need to bridge the gap between the terminology of what you're gonna find and and and and those sorts of of services, what what you're gonna find, for instance, in a event bus. So in an event bus, you're going to have topics, you're going to have subscriptions, you're going to have consumers, and so on. Right? Which are all ultimately kind of, like, they they translate from one to another very well. So for instance, in a deck, a source is a topic, a consumer is a destination, a subscription is connection, and so on.

Right? But now suddenly, by the ways that you decide to name and label things, you're kind of, like, defining, or you're attaching yourself to one category or another closer. Right? Kind of, like, by by proxy. And for instance, like, the ETL tool is something we've had kinda, like, walked back a little bit because some people were just like, it's kind of like 5 trans.

Like, no. No. It's really isn't. So so I don't think we've kind of, like, fully figured this out, and there's changes that we've had to do. Still to this day on our API, there's endpoints that we've basically aliased now. But for instance, there's the slash webhook API, which in the context of what we do, it's, like, super unclear what a webhook even is. Like, is it an event? Is it a message? Is it a connection? It's, like, very difficult to, to put that together.

So we've renamed it to your connections. Right? But for backward compatibility and that kind of stuff, we now we've had to maintain those terminology. And obviously now in the documentation, there's this little block that's like, Hey, by the way, in 2020, we did the miss this mistake and this used to be called this and now it's called that. So just FYI.

Right? And it and it's nothing unfortunate to have to, like, carry those. Obviously, you can alias and so on. Like, it doesn't have to impact, like, a new user experience. But, Yeah. I guess that's what I have to say about, about the name. Yeah.

Right? Let's just write about webhooks. So now, we have this kind of, like, de facto webhook bible for all time purposes, where, you know, we have hundreds of articles, like, well researched, well written articles on every single possible problem you could find with a webhook. The problem, though, is now you talk to a more senior engineer. You know, they're very accustomed to webhooks and so on, like I was saying at the top of the show.

And now, really, the problem they're looking into is, like, dead letter queuing management with RabbitMQ. So it really has nothing to do with Webex. Right? At the end of the day, they're kinda, like, further down the the the problem stack. And I think that's the big learning that we're doing now, which is not only do you need the kind of, like, top level, content, but you need to get very specific about the problems that people are gonna run into that are, like, adjacent to the thing that we're you're really building.

Because we can't explicitly write about event gateways. I mean, we obviously we do to some extent because we're trying to establish it as a category, and we're trying to loop everyone else in kind of like that definition. Right?

So the rest of the content that's, like, the most relevant is dealing with those RabbitMQs issues or those SQS issues or the I cost of s 3 and Google Cloud Storage rights. And those type of problems that you're gonna run into as part of the process of building those, those workflow and those architectures that you would kind of, like, historically think as the de facto solution for for building this. So for us, at least, that's been working really well. Most of our user acquisition, most of the awareness that we build, most of the traffic, is coming from from those Google searches are not branded. Right?

So unbranded keywords on Webex and sign. I think there are anything too, which I don't know if you can generalize, but definitely applies in our case is attaching yourself to other companies or other tools, that you help kind of, like, build as part of that workflow. So for instance, if you're receiving Webex from Shopify well, obviously, Shopify is really irrelevant in that conversation. Right? Although Shopify kinda has nothing to do really with the problem that you're trying to solve.

They're just kind of, like, the producer of the of the event. Ultimately, you're still going to Google Shopify Webex because you need to know what their security, the sorry. The ASH verification is. You wanna know, what their retry policy is. You you wanna know what the supported topics that payload looks like and so on.

So then for us, it's kind of like a no brainer to say, well, okay. We'll buy a lot of content about Shopify Webex. Right? And now depending on kind of where you are in the world, if you try search Shopify and Webex, there's going to be a table that show up in Google that tells you what the retry logic is, what the timeout is, what the Ashing algorithm is, from our own documentation kind of above Shopify's own documentation. Right?

And, like, the goal to do that is not to say that Shopify's documentation is not relevant. It's more to say, we'll surface that information to you right away in a form that Google likes. It's going to put it right up there. You're going to have your answer. In the process, we're tying we're building a tiny bit of awareness for for Odek.

Right? So those are the things where you don't need, like, an explicit partnership, but then there's the other part of this where those people now have an incentive to make their users successful with their with their with their their run times or their platform and so on. So they wanna collaborate with you. Right? So now we're putting out content on, Vonage documentation, on GitHub's documentation, on Okta's documentation, and so on, because they see a vested interest interest in their user adopting Webex as well.

Right? And we make that easier. But the same is true with the runtimes. So the Vercel, this word, like Next. Js, we're in the process of building a Next. Js malware. I guess this this is the first. Right. And,

So in the case of GitHub, for instance, they were referring to some tools in their documentation, that was down. Like, it it now is, like, 12 hours or something. So I opened a PR. Their, documentation is open source. I opened a PR, and proposed adding a deck in there because the alternative was down.

And they they basically approved it. But from there, their, own team working on that documentation thought the tool was real cool and just started writing new content, with Odek in it where we weren't involved in it anyway. Right? Actually, we we found out about it because of just website referral. We're like what's this? Like, what is this referring URL? Right? So so I think I think it's a mix of both. Right? Like, good things don't happen, don't offend just by themselves.

Like, I think there's kinda creating your own luck that happens there. And some of that is just, you know, getting more brand awareness and having a good product and so on. But I think the other the other part of it too is, like, making a compelling pitch to the people that are working there. Right? Like, the DevRel teams or the engineering managers and so on that are working on, those part of the product.

Like, especially with Okta, we built strong relationship with the engineering manager on their, their web of product. Right? So, so I think it's a missing vote.

Like, the Yeah. Platforms are similarly influential and so on. I think there's just kind of a I think it's very difficult to say, like, oh, we're gonna do 1 or 2 partnership, and then we'll be able to clearly tell whether or not that is a good return on investment. Yeah. Chances are you won't be able to do this unless you're, like, Twilio or, like, big established companies with huge numbers and strong patterns to to to recognize and so on.

There's a big new project that the VP is pushing for. There's something going on that specific point in time that makes it relevant. Right? And most of the potential, I think, comes from there. But that being said, I think that's something very dangerous to edge yourself on because, obviously, you kinda lose some of the agency if you're now you're dependent on someone else having that problem at very specific point in time.

Right? So our kind of, like, solution to this is to say, well, okay. We have this cloud infrastructure product. We have this platform that you can use for, you know, your production use cases that's ready for your scale and your volume and so on. But we also have those developer tools that you can use at any point in time, have absolutely no consequences, that you can do unbeknownst to anyone else in your organization.

Right? And that helps you, first of all, get some of the value, get built some of the trust into the brand and the company and the quality of the product, but also be top of mind for when that inflection point is going to happen. So if you're an engineer at one of those big companies and it's like, like, that looks cool, but, like, I don't have anything right now that I would be willing to kind of, like, fight for this for because there's there's no, like, specific problem that we're trying to solve, but we are already, like, overly invested in this and so on. Well, I can still, like, download the CLI and receive my Webex locally where I can use the that console to, like, preview the payloads, from the different platforms and forward it to different HTTP destination or, like, my local host. And suddenly, it's like, you can still derive some of the value from what we have to offer for free, right, ultimately, until that inflection point comes.

I think that's an important part of the strategy if you're depend depending on timing. You basically want to try to alleviate that as much as possible. What other reasons can you or, like, what other value can you provide to people that isn't dependent on it and maybe has way lower friction, right, to get some of that value? So that's definitely something that we've been investing on, and we're we're we're just kinda seeing pan out as part of the strategy.

I'm thinking of, for instance, like, I mean, I guess, dev tool dev tool adjacent, but I'm thinking of, like, Raycast and Arc and, like, products like Diaz. Right? Or was it Zed, like, the new coding editor? Like, there's things like that where you can you can just kinda try out any point of time. But but I think the bar there is extremely extremely high.