What working in Mission Control taught me about product development
I had the coolest job in the world for a while. I helped assemble the International Space Station from one of the consoles in NASA’s Mission Control Center as a senior member of the ISS electrical power flight controller team. A lot of my most meaningful experiences happened in that incredible intellectual environment. Many of my best — and most painful — professional lessons were learned there.
Steve Cantley at NASA's Misson Control Center, circa 2000.
Over several years, I’ve developed a presentation about what engineers and managers need to learn from the loss of the space shuttle Columbia in 2003. It’s part of the “most painful” list mentioned in that first paragraph. I had the opportunity a few weeks ago to present it to seniors in mechanical engineering at UW–Madison.
After I’d finished, one student came up to me seeking advice before starting a co-op tour this summer in Mission Operations. I offered a couple of off-the-cuff thoughts. “What group are you joining?” I asked. The answer blew my mind. This student would be in my old group — or, at least, what it has morphed into. Sometimes, the world really is quite small!
Later, I emailed a more complete list of ideas for how to be successful as a NASA co-op. Here are the ones most relevant to product development:
1. Ideas are complex, but communication doesn’t need to be.
Work on your ability to communicate complex ideas clearly. In Mission Control, there is no currency more valuable than clear communication. Discussion within Mission Control frequently takes place without being able to see the person you’re speaking with. Visual cues for good communication aren’t available. Written communication — like procedures — needs to be tight and unambiguous. This is less about product development in general than it is about success in any profession, but in this day of frequent phone calls and constant email, clear and simple communication is valuable.
2. Understanding history makes your results stronger.
I wrote of the need to immerse in NASA’s spaceflight history — the Apollo 1 fire, the Challenger and Columbia accidents, STS-51F, and a few even more obscure examples. Why is this relevant? When I’m working on a project for a client, it’s important to understand the rest of the market around that new product idea. What similar things has the market seen before? How did previous products perform? Where were the strengths? Weaknesses? Understanding history helps our team be better developers.
3. Search for failure modes in creative ways.
I described a mentoring tool I used when working with junior flight controllers. We’d think aloud at one another about unique ways to turn off the ISS’s power system — fresh series of commands to accomplish the task in creative ways. This was useful because each of the novel sequences could be replicated through a series of system failures. Walking through them led to a deeper understanding of our system. As product developers, we all love to think about features, forms, interfaces — all the positive attributes that users will love. However, things fail. Understanding the myriad ways in which this can happen, and especially trying to be creative about how failures might manifest, helps us make products less prone to fail, and fail gracefully if they do.
4. Make your users real.
Mission Control fills many roles in manned spaceflight. Most critically, they’re a last line of defense against losing astronauts when things start to go south. Crew safety, vehicle health, mission success — in that priority order. Challenger and Columbia are the failures. My very first NASA group lead demonstrated on STS-51F that sometimes Mission Control does save the day (see point No. 2 above)! I also advised getting to know astronauts on a personal level. Encounter astronauts as real people, not just as names. Real people in space make Mission Control’s role tangibly immediate. Likewise, a critical part of creating amazing products is making truly compelling user personas to help us understand use cases. Know what they care about, what need they’ll satisfy as users of the product you’re developing, and why it’s important to do the job right. I never wanted to let the crew down. I never want to let the user of a product I help develop down either.
5. Observe, listen, learn — soak it up!
There’s no better way to prepare for the role of a flight controller than sitting inside Mission Control at your console, experiencing someone doing the job. It’s how the culture is passed along. Another bit of my advice was to find any excuse, even if it means sacrificing some nights and weekends, to spend time immersed with people managing the ISS for real. In product development, the equivalent is ethnography, and it rests alongside point No. 4 about understanding your user. Observe users trying to do the task that you hope your new product makes easier. Absorb their pain. Understand their joy when things go right and they’re successful. Get inside their heads, learn their culture, their motivations, and anything else that might help you design a better next product. Then apply what you’ve learned.
There was plenty of other advice in my note to the student, but these five points do a pretty decent job of highlighting the surprising ways that Mission Control — surely the best job in the world — prepared me to help my current colleagues create kick-ass products that I hope make the world a little better. No spaceships, no headsets, but I still get to love what I do.
I hope the student has a great co-op tour, learns a lot, makes lifelong friends, and then eventually gets a chance to certify and do the best job in the world — for real.
Steve Cantley is director of innovation and advanced research for bb7, a Madison-based comprehensive design and product development firm.
Click here to sign up for the free IB ezine — your twice-weekly resource for local business news, analysis, voices, and the names you need to know. If you are not already a subscriber to In Business magazine, be sure to sign up for our monthly print edition here.