From Rockets to Roadmaps: An Engineer's Guide to Product Success | Sift Stack’s Austin Spiegel

0:00Something else that I got at SpaceX was really first-hand experience. In my case, that was building software, walking on the factory floor, watching technicians use their software to build rocket engines, going up to them, asking them questions about it, observing them. And that really helped, I think, build a better sense for how the product should act.

0:29Hey, everyone. I'm your host, Ben Moyd Pearson. and I'm happy to be joined today by Austin Spiegel, co-founder and CTO at CIFStack. Austin, thank you for joining us today. Ben, thanks so much for having me here. I'm really excited to be on. So you bring an impressive background. So before CIFStack, you spent about five years working as an engineer at SpaceX. And I want to start the conversation there because, you know, I think SpaceX is relatively unique in that they famously build almost everything in-house. like even systems like HR from what I've heard. And I imagine that really shaped your role that engineers play in product design.

1:09In fact, you wrote an article about this that I'm going to ask you a little bit about later. But first, let's just start with SpaceX. So can you tell us a bit about your experience at SpaceX and how it's shaped your entrepreneurial path? Yeah, definitely. And I kind of just want to start out and say too that I didn't really set out to be an entrepreneur. I've always been a builder. I loved playing with Legos as a kid. I've always liked watching How It's Made, the show about manufacturing. But coming out of college, I didn't really feel like I had a kind of unique perspective on a problem that needed to be solved.

1:46I was actually in an entrepreneurship organization in college. And of course, the problems that I was interested in building products for were fairly trivial, like a crowdsourced playlist, for example. So SpaceX really kind of opened my eyes to a whole class of problems that I don't think a lot of us get to experience every day. And specifically, that was manufacturing. So I think something that's really unique about SpaceX is it takes a kind of first principles approach to solving all these problems. And I think that gets to your point about SpaceX now building all of its own software rather than kind of rely on software that's already existing in the world.

2:22for example, maybe SAP, which is a robust ERP system, SpaceX thought, well, you know, we're the first company that's going to launch and land rockets. So what would an ERP and manufacturing execution system look like for a company that's going to do that? And I think that's really kind of what my big takeaway was from my experience at SpaceX is if you're going to go solve novel problems, you probably need novel tools to help you solve those problems. I can relate very heavily on the not having big enough problems to solve to actually like start a company for, you know, I think I think a lot of engineers relate on the idea of having like a lot of side projects and like other things that they love to build.

3:02And maybe that's why, you know, SpaceX engineering is so highly revered, because it does sort of encapsulate that type of mindset, you know. So I mean, you know, in order to land a rocket, we needed to also build an autonomous drone ship. So that's not a problem that you're kind of encountering pretty much at any other company. Yeah, exactly. So you emphasize the importance of engineers driving product vision. So not just being like responsive to needs of the product team or the demands of the product team, but actually helping to drive that vision forward. So explain how your time at SpaceX really influenced this belief.

3:40Yeah, definitely. So, I mean, I had the privilege of working with a lot of great product managers at SpaceX, but about midway through my time there, our organization actually eliminated all product management roles. Some product managers moved on or some product managers transitioned to engineering. And of course, this was a really difficult challenge for the remaining engineers because they needed to take on product management responsibility. and in some cases some of those engineers left and others you know stepped up to do that while we kind of ultimately probably swung the pendulum too far in the other direction of not having product managers when we did this restructuring we had product managers writing specs for projects that were probably never going to get built problem was it created this abstraction layer between engineering who was solving the problems and the people they were solving the problems for so we were kind of building features that maybe missed the mark or weren't actually solving the problem that we were trying to solve and they weren't really being used.

4:34My growth from there was as I took on more product responsibility, I realized that being much closer to the problem and more importantly, being much closer to the users really helped us build solutions that were addressing those problems and not waste time on things that weren't moving the needle for our customers. I love the idea of, you know, some engineering people being able to step up into this new like semi-product management role, were there any like commonalities between the people who you think both like were willing to step up, but also were successful in doing so? Oh man. Yeah. And that's a really interesting question.

5:12I mean, I think ultimately, like there's certainly no fault in being an engineer who just wants to go and solve a technical problem and spend more time in engineering. But what I noticed at SpaceX is the people that were successful in this role were people who saw engineering and building software as a meet to an end. So they really saw it as a tool to go and solve a business problem and not necessarily as something to build in and of itself. And I think that was kind of the greatest quality. And it's really people that have a lot of customer empathy and get really motivated when their users are kind of struggling.

5:47I guess the best example would be there's so many opportunities to save hours in the process of building a rocket. So the people that kind of look at that process and say, wow, if we go automate this process, we build this feature, we can now go and turn around Rocket in 10 less hours than before. Those were the types of people that really were successful in that organization. Yeah. So viewing software as like a means to an end. This is actually a very common trait that I hear in a lot of teams that we would view as like high performing engineering teams. And, you know, I really think that one of the surest sign that you have like a really strong engineering culture is that all of your engineers are considering like that end user impact going all the way through to the end to understand how it impacts that user.

6:33So, I mean, if you're a database engineer at Netflix, it's building backend database stuff. Like you're actually thinking about how do these queries impact the actual use cases that our developers are going to be or consumers will be like consuming this product. So, yeah, I really love hearing like more stories, you know, sort of related to that. I was thinking through like, you know, what specific examples could I draw upon here? And something that I found really interesting or I recall, and it's funny because my co-founder actually worked on this project. There's a manufacturing process where you basically take two different parts.

7:07So in this case, it was two parts of the trunk that go on the Dragon space capsule. And you basically take these two parts and you drill holes in them. And then you separate those parts and they go through separate processes. But you actually have to bring these two parts back together and those holes have to match. So that whole process is called match drilling. And it's a fairly complex process. and we actually wanted to build a feature into our manufacturing execution system so that we could ensure that when these two parts came back together, they came back together in the right formation.

7:37We spent a lot of time designing this solution and almost kind of trying to build software to solve a manufacturing problem. Ultimately, we went out, we spent a lot of resources, we built this feature, and then six months later, it was not being used by anybody. And I think that's kind of the perfect example of something where maybe six months, a year later, when we're in this world of software engineers, getting a deeper understanding of the problem and the project, they would realize this is actually going to add a lot of unnecessary complexity to our system. And it's probably not going to really solve the underlying problem, which at the end of the day is more of a manufacturing problem than it is a software problem.

8:13That's rough having six months of work, not going anywhere. Yeah. I imagine that doesn't feel great. You know, you've gone from SpaceX to go on and found your new company, SIFT. I imagine you're probably not building everything yourself anymore. But I am curious, how has that mindset sort of helped you or played a role in your transition to founding your own company? That's a great question. I mean, I think something that people typically forget is that SpaceX is nearly 25 years old. Elon Musk and SpaceX weren't household names less than a decade ago. So SpaceX actually wasn't building all of its own tools for the entire history of the company.

8:55And it wasn't fully vertically integrated for the entire history of its company. In fact, a lot of the software that SpaceX uses now wasn't built until after Falcon 1 successfully launched in 2008 and even later than that. Like once Falcon 9 was flying in 2012. So I think sometimes companies will look at SpaceX and try to apply the SpaceX mentality when there may be, you know, seed stage company. And that's probably the wrong lesson to take. I think ultimately, like the lesson you kind of want to take away is one, moving quickly, but also really don't build everything, but build your core competency, right?

9:30So what is going to be a competitive advantage for your company? The way that I look at it is we're building a time series data platform for hardware sensor observability. For us, ingesting story, analyzing time series data is a core competency. So of course, we're going to build a unique solution there. The real benefit of that is now we have total control over how it's implemented and how we grow it. We can really tailor it to address the problems that our customers are solving. But maybe as an example, compared to SpaceX, SpaceX is now at the point where it has built its own HR system. I don't think that's something SIFT would ever do, and certainly we're not going to be doing that at this point.

10:06Let's transition into a conversation about some of the thought leadership content that you've published that's out there. Not too long ago, you wrote this article. The title is The Secret to Better Products, Let Engineers Drive Vision. So let's talk about that. Like what inspired this article? Yeah, definitely. I mean, ultimately what inspired it was we've managed to hire a really amazing team of engineers who are product oriented. But of course, I think that's a difficult skill set to look for. And we wanted to kind of publish this thesis to attract more like-minded talent. So that's the primary reason for publishing the article.

10:43I think the other thing too is our customers really value working with people and vendors who understand their problems. We want to kind of build a culture here of customer empathy and of engineers who understand our customer problems. So that's why we published the piece. You know, ultimately, I think like building a product management organization where product managers are expected to make all the product decisions just doesn't scale for an early stage company. We have a team of 12 engineers right now. If we wanted to have a product management organization that was making all the product decisions, it would have to be like maybe a quarter of that or half of that size.

11:18And that just would be something that's feasible for us. Yeah. And I imagine that's a massive competitive advantage too, right? If you're able to dedicate a lot more resources into building new value, enhancing existing features. This culture that puts the engineers in the the position to drive vision so like what is like how would you describe what that actually looks like in the day-to-day like a developer like ideally you want all of your developers to raise their hand and say yes we do believe that we're following this so the ones who say that like what would you expect them to be doing in their day-to-day the first thing that's really important is is to have a lot of customer empathy and really think like put the customer at the center of everything we do.

11:58Ideally, that means having people on staff who are your customers or would be your customers. We're really fortunate. We have a team of forward deployed engineers who work on our core product and help extend our product for our customers. And all of those people are former flight software engineers that worked on the Dragon Space capsule. They have a really deep understanding of how these tools are used by customers, how these tools integrate with the customer application ecosystem. And then they can also really help inform our internal engineering team on how we want to build the product. That's number one, really important.

12:31The second, I think, is like including engineers in strategic decisions, which empowers them to make decisions about the product. So don't just create a roadmap and then throw that roadmap over the fence and expect your engineers to implement it. And of course, there are certain situations where you need to do top-down decision-making, but in those cases that really ensure that the engineering team is brought on the journey and they understand why they're building what they're building. Because ultimately, what culture we want to foster is a culture where the engineers see a customer problem and then feel empowered to go and address it.

13:03Finally, I think it's really emphasizing outcome over output. So it doesn't really matter how much time is spent in front of the computer. It doesn't matter even if we deployed a feature. What really matters is whether or not the customer is actually deriving value from the feature. So does it solve their problem? And ultimately, in order to figure out if it solved their problem, you need to go and look at the analytics, talk to the customer and ensure that that feature is actually doing what we expect it to do. Yeah, I think that, you know, including engineers in your strategic decision making, I think that's such a critical component.

13:34A lot of organizations either don't do it or they think they're doing it and they don't do it completely. We often hear about this dual mandate that engineering leaders face. You want to maintain the highest levels of operational excellence, but you always have this business demanding things from your organization. So how do you have conversations where you illustrate that the business wants certain things, but the engineering organization has to do other things to make sure that we can be sustainable and we can actually support scalability and we don't get overwhelmed with tech debt and quality issues.

14:06Of those things that you mentioned, I think that's, in my mind, tends to be the one that really is the most important, but those are all great insights. Yeah, definitely. I mean, I think that's pretty challenging. And something that I always say is like, we really want to align kind of individuals goals with overall company goals, with the type of engineer that's product oriented, when you expose them to the customer directly, the customer problems, they tend to get motivated to solve those problems anyway. And then it ultimately just comes down to working in the things that maybe don't seem like they impact the customer, like technical debt, scalability.

14:41But ultimately, I think all these things actually do impact the customer in our case we have to scale our platform to ingest you know petabytes of data technical debt impacts how quickly you can ship code so i think all of these things can be spun in a way that you know their customer impacting and can be prioritized as such yeah yeah from what we've seen is if all you do is focus on new value feature enhancements and you're never focusing on like maintenance and keeping the lights on And eventually your entire product roadmap just becomes like unexpected work, essentially. And so, you know, having a framework to, you know, I think having engineers directly involved in that is a great way to just tighten that individual to executive connection or strategic connection, as you're explaining.

15:27Is your engineering team ready to improve performance in 2025? Linear B's 2025 Engineering Benchmarks Report analyzed over 6 million pull requests from 3 ,000 organizations worldwide. And the insights are game-changing. From Dora metrics to pull request workflows and team predictability, this report is packed with strategies to level up your team. Did you miss the November webinar with DevEx leaders from CircleCI and MongoDB? No problem. The recording is ready for you on demand. Don't wait. Access the report and webinar now. Check out the link in the show notes. So I'm going to take a little bit of a segue here and talk about some of the current trends in software development, including LLMs and automation and AI.

16:14How do you think that these types of things are going to impact the role of engineers moving forward? prior to to founding sift i was looking for a new role and i was interviewing as an engineering manager at a company that had used a low code tool to build some internal software this this software they were building had a lot of complicated business logic but was technically quite simple and i kind of came to this realization that you know there's a lot of software that's very in that you know never sees especially a lot of software that never is used by anybody outside of a company. And a lot of that software is very tactically simple, right?

16:50So it's probably just a form sitting on top of a database. And I realized that because tools to build software are getting easier and easier to use. So low-code tools, LLMs are obviously making it really simple to build apps. In fact, we just interviewed a product manager who was building their own mobile app using Cursor. It kind of made me realize that the people who will write the best software will probably have a better understanding of the business domain. So of course, there's always going to be technically complex software that needs to be written by great engineers. I mean, after all, somebody has to go and build the LOMs or build these low-code tools, but I think those roles will either maintain their current availability or even become more scarce.

17:35So really having this kind of product-oriented mindset is how you can continue to thrive as an engineer. If you have generative AI tooling, like both making it easier to adopt new technologies because you can rapidly onboard new skills and knowledge a lot faster. But then also, you know, we're seeing it sort of remove a lot of the toil and like nitty gritty details of like having to produce software. You know, given that this is happening or this, you think this trend is happening, how can engineers like bridge that gap and become more business savvy? Like if they want to start being more focused on end users, how can they start that journey?

18:16Yeah, yeah, this is a really great question. I mean, I think, you know, to start, it really helps to work with great product managers. For example, when I was at SpaceX, I worked with a group of folks who had previously worked in the manufacturing sector. So they had basically built software for automotive manufacturing, aerospace manufacturing. And through them, I was kind of able to learn a lot of the intricacies of the processes in that business. Also, something else that I got at SpaceX was firsthand experience. Walking on the factory floor, watching technicians use our software to build rocket engines, going up to them, asking them questions about it, observing them.

18:52And that really helped build a better sense for how the product should act. Here at SIFT, we have a forward-deployed engineering team that previously used tools like these. So that's another way that our team can get, you know, firsthand knowledge of how the tool should be used. So that's kind of number one, which is trying to get, you know, hands-on or firsthand experience. But secondary, it's like spending as much time with customers as you can. Now, of course, this is a little dangerous. You know, you need to still go back to your desk and be able to get some work done. But ultimately, like getting in front of customers, whether that's visiting customers on site, sitting in on meetings with customers.

19:26In our case, it's kind of showing our projects to customers before we get on them and then getting feedback as we're implementing them and then having direct lines of communication with customers. So Slack is actually a great tool for this. Slack Connect, being connected to all of your customers and being able to reach out to them directly. And I think the final thing I'll mention here too, because I kind of have gone back and forth on this a lot, but specializing in a business domain helps because you can just get deeper and deeper. So when I was at SpaceX, I worked on manufacturing problems and then I left briefly to work in the game industry and that was a great experience.

20:01But ultimately, I realized that manufacturing hard tech was where I wanted to build my career. And that's what we're doing here at SIFT. And I think ultimately, that's probably where I'll end up spending most of my time. Yeah, I love the getting closer to your customers. But yeah, I think it is warranted to call out that it can be dangerous sometimes, right? Like engineers aren't like typically the person that is the most skilled at like going in front of a customer and trying to be persuasive or stuff like that. But, you know, I'm someone who also has to go into customer conversations quite frequently in like a technical role.

20:35There's other alternatives to that as well. Like, you know, you can use like data to sort of be a proxy for your users. Or I frequently love to watch calls that we have with our customers or with prospects just to see like when they're being exposed to like our platform or to new things that we're doing, like how do they respond to it? Like, do they actually like seem to want to engage with it? So yeah, I think even if you don't get directly involved with a customer conversation, maybe you're a developer, that just terrifies. I think there are a lot of new ways now to start, to at least get proxies for that.

21:12Yeah, absolutely. I mean, our forward-to-play engineering team is actually curating content from customer conversations to share with the engineering team. That's a really great way of getting exposure without going and sitting on a meeting. I think to your point too, it's really easy to over-index on maybe one customer, for example. Different companies have different ways of doing things. So if you're building a tool that is going to be used in their internal processes, you could pretty quickly build a tool that maybe overfits to that company. So, you know, it's important to both get a broad perspective, but then also cross-reference it up with what you mentioned, like analytics, screen recordings, various tools you can use now to kind of get a really better picture of the customer and the user.

21:55So you mentioned that you have this forward deployed engineering team. In your experience, like what are some of the traits or the qualities that you typically see in the people who do that type of role versus the other side of your engineering team? Yeah, that's actually a good question. I mean, to be honest with you, this is not a function that I've previously worked with. So it's still trying to feel out like where do you draw the line? and ultimately I actually had a lot of hesitation in building a forward-to-planage gearing team because it always felt like something that would turn into more of a crutch than it would be an accelerant because we would ultimately you know rely on these people to kind of fill in the gap between where the product is and where the customer is but what I realized was it has actually helped us learn more about our customers more quickly because we have like more touch points in a higher surface area with the customers.

22:49So, I mean, what makes those people different or kind of what are the traits that they have that our engineers don't? I mean, I would say generally it's really more of a domain experience type thing. So these people, as I mentioned, have all worked in this role. And actually the type of software engineering that they were doing in that role is very different from the type of engineering that we do in our core engineering team. So, you know, we're building big data and full stack web application. The skill sets you need for that are inherently different than if you're basically writing code that runs on a spacecraft.

23:22So the forward-to-play engineering team, they have that spacecraft coding experience. They also have the experience of testing spacecraft so they can deploy or employ that engineering knowledge. But then what they bring to the table is actually the experience doing that role. So if they were to come in, work in our core engineering team, they wouldn't necessarily have the skill set that's necessary to go and build a big data system, for example. Yeah. And on your point with having more touch points from this forward deployed team, there's some products out there that just have much longer adoption cycles than other products, often because there's some major technical challenges or customization, et cetera.

24:03having like that technical team more involved with the customer really gives them through if you have a more extended cycle it gives that customer a lot more confidence in your company's ability to actually like deliver the things that you're telling them that you're going to deliver absolutely yeah you know we have very technical customers and also we have very many user personas So we have people who are responsible for SIFT at their company and integrating their various tools with SIFT. And then we also have software engineers who use SIFT. We have hardware engineers who use SIFT, manufacturing technicians who use SIFT.

24:41So we kind of need to tailor our communication to each of them. And I think for many of those customers, they appreciate interacting with people that are highly technical. I'm interested, out of all those groups you just listed, are any of them the ones where they benefit in particular from having this forward deployed team? Or is it just sort of across the board? Typically, what we find is our customers have built some version of this tool in-house. So they have a small team that is building and maintaining that tool. And now that team can go and kind of work on other problems that are more core to the business of the company.