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

**Austin Spiegel** (0:00)
Something else that I got at SpaceX was really firsthand experience. In my case, that was building software, 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. And that really helped, I think, build a better sense for how the product should act.

**Ben Lloyd Pearson** (0:29)
Hey, everyone, I'm your host, Ben Lloyd Pearson, and I'm happy to be joined today by Austin Spiegel, co-founder and CTO at Sift Stack. Austin, thank you for joining us today.

**Austin Spiegel** (0:41)
Ben, thanks so much for having me here. I'm really excited to be on.

**Ben Lloyd Pearson** (0:45)
So you bring an impressive background. So before Sift Stack, you spent about five years working as an engineer at SpaceX. And I wanna start the conversation there because I think SpaceX is relatively unique in that they famously build almost everything in-house, even systems like HR from what I've heard. And I imagine that really shaped your role that engineers play in product design. In fact, you wrote an article about this that I'm gonna 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?

**Austin Spiegel** (1:24)
Yeah, definitely. And I kinda just wanna start out and say too that I didn't really set out to be an entrepreneur. I've always been a builder, 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. I 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 first-primitive 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. For example, maybe SAP, which is a robust ERP system, SpaceX thought, well, 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.

**Ben Lloyd Pearson** (2:48)
I can relate very heavily on the not having big enough problems to solve to actually start a company for it, you know? I think a lot of engineers relate on the idea of having a lot of side projects and other things that they love to build. And maybe that's why SpaceX engineering is so highly revered, because it does sort of encapsulate that type of mindset, you know?

**Austin Spiegel** (3:10)
I mean, 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.

**Ben Lloyd Pearson** (3:21)
Yeah, exactly. So you emphasize the importance of engineers driving product vision. So not just being responsive to the 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.

**Austin Spiegel** (3:40)
Yeah, 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. Of course, this was a really difficult challenge for the remaining engineers because they needed to take on product management responsibility. In some cases, some of those engineers left and others stepped up to do that. While we 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. The 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 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. My 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.