How to build a new rocket
A rocket builder is giving a tour of the manufacturing site for a new rocket. Once complete, this rocket will form the upper portion of the largest reusable heavy launch vehicle ever constructed. It is, by any measure, an ambitious project. The visitor is an avid and well-informed super-fan of space rockets. As they enter the assembly hanger, the visitor marvels at the sight of several pre-fabricated steel nose cones laid out in a row. The conversation turns to how this revision of the nose cones have been manufactured...
ROCKET-BUILDER: It doesn't have indentations ... basically you can do a one-sided die. You can just stretch-form it over a big mandrel.
VISITOR: This isn't the cargo [version]? It had that opening on the one side... you were working on the door?
ROCKET-BUILDER: I actually stopped working on the door. We're gonna focus on getting to orbit. We don't need a door. We need to be super focused on getting to orbit, then super focused on getting the ship back. Then we can worry about doors.
VISITOR: Okay...
ROCKET-BUILDER: It's just unnecessary complexity. Is the door necessary to solve the problem? No. Will we use this on the first ten or more that get back from orbit? [No.] We probably won't fly them again.
VISITOR: They're not going to be putting any payload up. You don't even need to worry about it yet!
ROCKET-BUILDER: Yeah. Why have a door on a thing that's never gonna fly satellites anyway?
Satellite doors don't get a rocket into orbit
Having functional satellite doors is a requirement that is relevant if, and only if, the rocket is able to get into orbit with a payload. When it comes to reusable heavy launch vehicles, this is not a solved problem. The team is innovating to find a solution that will succeed in this task. Some amount of extra engineering time and effort will be required to produce a rocket with those satellite doors. Not building them yet means they have been able to simplify how they form the metal for the rocket nose cone. By deleting the requirement temporarily the team is able to focus on only the critical path that will determine the rocket's success, and even better, they have been able to speed up their iteration cycle time with a simpler process.
If you've gotten this far you are probably seeing the parallels with software startups. It is common for software startup engineering teams to build features that will only be required in the successful version of the product. There are many reasons for this, some of which I'll cover in more detail in a future post, but the simplest mistake is where the team is building something that is an at-scale only requirement, when they currently have zero or single-digit users. These are fairly easy to spot and I'd hope that most startup CTOs have already worked out that they shouldn't be building those in the early versions of the product. However, the satellite doors problem is actually more subtle than this because the doors are part of the product MVP.
Critical path to liftoff
Haven't we all been taught to build 'skateboard' MVPs by years of lean startup methodology?1 If so, surely we never find ourselves building things that aren't required because, by definition, they aren't part of the minimum viable product? But a rocket that is designed to take cargo into space, is at some point, going to need to have satellite doors to load and unload the satellites right? Otherwise, what's the point of the rocket?
Sometimes a requirement is part of the product MVP, but isn't on the critical path for liftoff. What will absolutely have to be true for the product to even get 1 metre off the launchpad? What about 100 metres? What about the Kármán Line2? In rocket terms, it is much more likely that you will fail to get off the launchpad than it is that your satellite doors won't work.
Software startups often make the mistake of thinking that the largest opposing force they have to overcome is merely the existence of a minimal set of software features. Lots of software startups fail because they never get any significant users even when all those features do exist. Worse, the 'minimal set' of features starts to change, as initially traction isn't achieved.
If you think deeply about your problem space, there is usually a much smaller subset of forces that are directly opposing your success. Often times these are related to distribution, or getting the market's attention. Fixating on overcoming those is the critical path for achieving liftoff for your startup. Startup CTOs need to overcome a tendency that most technical teams have to want to build proper solutions. If it isn't directly solving the goal of liftoff then there's a reasonable chance you're never going to need it - even if it is part of the MVP.
Avoiding the trap
As a startup CTO your job is to make sure your whole team is aligned on building to achieve liftoff. I'm not talking about getting tons of users, or revenue, or hockey stick growth, or any of those traction metrics normally associated with startups and rocket ship metaphors. You're a technical person so when it comes to rocket ships you get to have your own technical rocket ship metaphor.
Focus relentlessly on building whatever is going to get your rocket ship off the launchpad. Consider whether features you are building are in support of that. Strip back your time and effort to focus on the critical path. Explain to your team what liftoff will look like and what you need to be building to achieve it and get their buy-in. Engaged teams that understand how to focus on overcoming their biggest obstacle are the ones that get into orbit.
Everything else is building satellite doors.
- https://blog.crisp.se/2016/01/25/henrikkniberg/making-sense-of-mvp↩
- According to some, in order to truly achieve spaceflight, a craft must reach an altitude higher than the Kármán Line, 100 kilometers above sea level↩