Venture with Grace
00:30:29 · Austin Spiegel, Grace Gong
And then, fortunately, Sim was Ben's colleague at Applied Intuition, he ran what they call the Application Engineering Organization, but effectively applied for deployed engineering motion. And I think what I felt we really needed on for deployed engineering was a mix between being extremely technical, which is what we had actually. We had great engineers who were super passionate about solving customer problems, but what we were lacking, and I think what Sim bought, was also a commercial mindset, right? So, we can continue. We want to solve problems for our customers all the time. But, you know, when a relatively lean team, you have limited resources, you really need to pick the things that are going to provide the most ROI as well for us, right? And I think it's easy in this type of software to kind of go down rabbit holes and optimizing the software for various use cases. But we need to think broadly about how do we use our resources to build something that is going to benefit all of our customers and all of our future customers? And I think that's where Sim has brought that rigor to the Ford deployed engineering team. [00:31:45] S0: I guess one of the things that you mentioned about commercialization and I guess selling to aerospace or defense contractors is like, it's probably going to take forever. And then what does the go to market motion kind of look like? Would it be like, you you guys go after like the engineers or the procurement and like, what is it like of the average sales cycle kind of look like in the... In in this particular sector?
00:32:14 · Austin Spiegel
[00:32:14] S1: Yeah, yeah, it's a good question. I mean, so, you know, it's definitely there's a couple of motions, right? I mean, now that we've the product is much more established and the sales process is much more established for the kind of early to mid stage startups, the motion is much simpler. So it's typically either outbound, inbound, the first call is a demo. I think it's really important in this industry that you show your software, your product to the buyer almost immediately. A lot of these people are no nonsense, they know what they're looking for, and they just want to see if the tool does what it says on the box, right? And if you kind of have this open ended or very structured deck with the hardware engineers, it just doesn't really go well. Then you don't get a second call. So I think it's really important to show people the tool on the first call. Then typically, where we go from there is we do what we call a custom demo. So that's actually taking the customer's data and then crafting a demo around their use case. And then from there, it's typically... It could be maybe additional hands on sessions, typically that's where we kind of look to move to closing the deal. But that's for kind of early stage and mid stage startups. Would say, and then that's very much an bottoms up motion, right? Like, go and win the engineers because they're the ones who are going to be selecting the tool. For the larger companies like the primes that we work with, it's a two pronged motion, right? So, it is top down and bottoms up. Bottoms up, you really need to get... It's the same kind of principles apply, is you need the engineers who are using the tool to sign off on it. I think one of the other challenges with this type of software, especially at larger companies, is the person who's procuring the software is not the one using it. So typically we're selling to like a VP of software and they're looking at like a build versus buy analysis. So should they buy Sift or should they build their own application? And there's many, many motives involved in that decision, whether that's like, they believe they need to kind of own their destiny or have control of the tool long term. And then the other part of it is like whether they're trying to ensure that their team has kind of the work to do.
00:34:53 · Austin Spiegel, Grace Gong
So, that makes it more challenging, but I'd say like there it's still, you know, the top down motion is really like partnering with the executives and showing them that we have this ability to really transform the pace at which their team is moving and also solve some of the hardest problems that they're encountering. [00:35:16] S0: One of our LinkedIn user is having a question. He said, From a practical engineer doing test connections are often rooted because of many issue sensor actuators, RF contacts. Sadly, the subject doesn't come from service until it happens and doesn't work. It's the first indication, do you have a phase in your test plan that uses automated validation and verification of sensor and actuators so that we can at the drop of a hat if we have a suspicion of data stream test or, my god, what is happening? Sorry. I think
00:35:16 · Grace Gong, Austin Spiegel
[00:35:16] S0: One of our LinkedIn user is having a question. He said, From a practical engineer doing test connections are often rooted because of many issue sensor actuators, RF contacts. Sadly, the subject doesn't come from service until it happens and doesn't work. It's the first indication, do you have a phase in your test plan that uses automated validation and verification of sensor and actuators so that we can at the drop of a hat if we have a suspicion of data stream test or, my god, what is happening? Sorry. I think [00:35:56] S1: I can kind of answer this question and apologies to the asker if I butcher it, but I think there's two things here. One is how do we validate our software, right? So our Edge application has a lot of native hardware integrations. We have a hardware in the loop test rack here where we are validating the Edge applications connections with, for example, DACs or other hardware that you may be using to run your tests. And then the second part of that answer is we have an automated analysis solution. So you can author analysis either in a low code expression language or in Python and then that's executed automatically as the telemetry streams into Sift. And this is kind of how you can test out whether things are connected properly, if you're reading signals that you don't anticipate and then you can course abort the test in that case. But also happy to, if this person wants to reach out to me directly, happy to chat more about it.
00:35:56 · Austin Spiegel, Grace Gong
[00:35:56] S1: I can kind of answer this question and apologies to the asker if I butcher it, but I think there's two things here. One is how do we validate our software, right? So our Edge application has a lot of native hardware integrations. We have a hardware in the loop test rack here where we are validating the Edge applications connections with, for example, DACs or other hardware that you may be using to run your tests. And then the second part of that answer is we have an automated analysis solution. So you can author analysis either in a low code expression language or in Python and then that's executed automatically as the telemetry streams into Sift. And this is kind of how you can test out whether things are connected properly, if you're reading signals that you don't anticipate and then you can course abort the test in that case. But also happy to, if this person wants to reach out to me directly, happy to chat more about it. [00:37:05] S0: I guess one of the question I had was because you compare you guys to like Datadog for a minute. So like, are you guys... Do you consider yourself as kind of like a Datadog for a hardware industry? And I guess like we also tried about like the AI, your AE started building their own CRM. So what if everybody started building out their own internal teams to build the tooling themselves? So would you feel like it's the moat of your product to a sense as well? [00:37:40] S1: Yeah. Okay. Good question. So sorry, what was the first part of it? [00:37:45] S0: The Datadog for hardware.
00:37:47 · Austin Spiegel
[00:37:47] S1: Yeah. Mean, I think that's a decent comp, right? If you think about what Datadog is, the core part of it is this data platform for collecting telemetry, logs, traces from software. And then there's all of these different applications that different personas in a software business would want to use to understand, root cause analysis, uptime, costs, so on and so forth. So that's definitely very similar to what we do, right? Core data platform and then different ways for customers to interact with that data. To answer the second part of your question, I think the thing that you still have to ask yourself essentially is like, would you build CAD? Would you build a CRM? Ultimately, yes, one of our one of our AEs, like, built this kind of copilot CRM, but we ended up purchasing Salesforce, and it was honestly a good decision. I don't think... Don't know how many will say it was a good decision to purchase Salesforce, but the fact is is that Salesforce has the data model and the infrastructure that that, you know, it already exists. It's best in class. It's, like, best in class data model. Why why should we, like, go reinvent the wheel there? Also understanding that, like, maybe we want different ways to interact with that data, and that's what LLMs do for I think just the same thing applies here, which is we have built a platform for ingesting very high rate telemetry with minimal latency and storing it for incredibly long periods of time. Even with AI, that's not an easy problem to solve. Is that really going to make a difference to your business if someone else can already do it? And if you have the tools to customize the way in which you interact with that data, then is that solving the problems that you have? That's generally what my take on it is, and then I still think infrastructure is the mode. You know, do, like one thing that I've been telling the team recently is I think ultimately it's really the pace of execution and learning that will keep us ahead because LLMs can build anything and they're only getting better. So, this is why our Ford deployed engineering team is so important and this is why Mike's leadership is so important in engineering. It's really about how quickly can we go from insight at customer to deployed product that solves their problem, right?