It’s odd to think that it’s taken 15+ years of “running the show” at various teams to finally figure out what my perspective on my process is. But I think I finally have a label for it: “Inertialess Development”.

Which, sure, isn’t the most elegant phrase. But almost everything in my process has to do with minimizing the impact of change. Whether it’s stuff like describing your high level goals in a single sentence (EA’s “The X” + Simon Sinek’s “Start With Why”) or pushing as much decision-making authority down the hierarchy as possible (David Marquet’s “Turn This Ship Around” along with Daniel Pink’s “Drive”), to prototyping and testing with real users as quickly as possible (Eric Ries’ “The Lean Startup”), everything has to do with being able to adjust your course as you learn.

Most of what I’ve done over the last 15 years has been essentially exploring novel spaces. Medical VR, the early days of App Stores – in both those situations, no one really knew “what worked”, and a lot of elements of development were quite different from the logically adjacent things. App Stores and mobile gamers didn’t behave like console stores or console gamers. Medical VR required different things that traditional VR games.

In both those situations, the most important thing you could do was learn fast. And the best way to learn fast was to try a lot of things, and release as quickly as possible. The best way to do that was to engage everyone on the team – not just in their assigned roles, but to get everyone recruited to think about the product and the users.

We did a lot of testing and data collection. We worked directly with end-users. But we also exerted tremendous experience and judgment, based on those “adjacent” fields that we had expertise in. But I think the most critical thing was that we weren’t bound to a plan.

We had high-level goals. We had a fairly clear understanding of our operating circumstances ($$). But we didn’t have a Profit & Loss to manage. We didn’t have a strict development budget. We didn’t have a timeline to adhere to. Our only goal was to make progress as quickly as possible.

If anyone asked me for a plan, or a prediction, I was clear that I couldn’t and *wouldn’t* provide one. That doing so would be a significant drag on our process, and would create expectations that we explicitly *would not* work to fulfill, because doing so would be explicitly counterproductive to the development process.

My job was to make sure we understood the high level goals. That we pushed our tests to users as fast and cheaply as possible. That we threw away minimal work to minimize negative morale impact.

For building things in novel spaces, I’m totally convinced that if the only skill you & your team has is that you learn faster than anyone else, you will be utterly unbeatable. And the best way to do that is to minimize inertia. Everywhere in the process.