4 steps for improvement

This is a riff of something that Everyday Astronaut got from a SpaceX interview with you-know-who. Yes, I deleted a step. Mostly posting this here so that I can refer to this tweaked version.

Step 1. Challenge ALL assumptions

Another way of saying this is to make your “requirements” less dumb. So, treat all of your “requirements” as if they are definitely dumb, and make each one justify itself, based on logic and the end-user or customer’s need. It doesn’t matter where you got your requirements, or who gave them to you, they’re still dumb. It’s particularly dangerous if a smart person, or someone more senior than you gave them to you. You have to be able to question the requirements with impunity.

I’ve written before about how “requirements” is a particularly dangerous word in product development. It suggests that the thing being stated is DEFINITELY needed. But the reality is that so often that’s not true at all. So let’s call them what they are: “assumptions”. Or at the very least, experiments.

Worth pointing out: this is why psychological safety is so important in product development. You really need to have a team who is empowered to test assumptions, no matter who’s asking. This is an essential first step.

Step 2. Make it Small

You need to be radical here and experiment with deleting stuff. Deleting parts/steps needs to be experimental, where you’re expecting failure. Keep going until it fails. If you’re not adding steps or parts back in having tried to remove them, you’re not deleting enough. So, strip it right back until it doesn’t work, and only then add the bits you really, really need back in.

Be careful with the “just in case” justification. This is a recipe for overloading and bloating that can kill a product. In many cases, YAGNI (You Ain’t Gonna Need It). Think iPhone, which went from a single home button, to no button. Then no headphone jack. They’re constantly trying to delete parts.

There’s a bit of an “MVP” feel to deleting stuff. For products where you can iterate, you always have the option to add stuff later, so sharpen your cutting implement and slice away.

Step 3: Make it Fast

Now that you’re more sure of the thing that you’re doing, speed it all up, accelerate cycle times. Set a target to halve the cycle time, and/or double the frequency. But don’t do this using automation just yet, just see if you can speed it up manually.

Definitely don’t attempt to make it faster until you’ve done Step 1 and 2. There’s no point running twice as fast in the wrong direction. 1 and 2 are about making sure you’re on roughly the right heading first. Then and only then should you try to speed it up.

Step 4: Make it Smooth

This is where the automation comes in, which also tends to make it faster as well. There’s a saying in the military: “Slow is smooth and smooth is fast”, a paradoxical aphorism along the same lines as “Less is more”. This is the step where you employ automation to handle the variability, speed up the process and make the quality of the outcome much higher.

Be careful not to start at Step 4, and leap straight into the automation. You’ll likely be automating the wrong thing, creating a lot of work that doesn’t need to be done and end up with a much more complex and brittle solution than is possible if you diligently start at Step 1 and patiently work your way through the steps.