This post was originally featured on First Mode’s blog.

It's 2015. I'm in Washington, DC sitting in a dark auditorium at the beginning of the 34th Science Team Meeting of the NASA mission MESSENGER (MErcury Surface, Space ENvironment, GEochemistry, and Ranging). MESSENGER is currently orbiting the planet Mercury, relaying transformative scientific data about the innermost planet. A month later, the spacecraft will run out of fuel and "lithobrake" (read: crash) on Mercury's surface, but for now, raw spectra from its X-Ray Spectrometer continue to download to my computer every day. X-ray spectra, these squiggly lines from space, provide clues to Mercury's geochemical and geological history.

As I listen to an engineer provide a spacecraft status update, unfamiliar acronyms and terminology wash over me in a flood of esoteric jargon. I've been a science team member for 6 months, but some people in the room have been involved for close to 20 years. MESSENGER was selected in 1999, when I was in middle school. The spacecraft launched in 2004 (high school) and finally entered orbit around Mercury in 2011 (graduate school). Having joined so late in the mission, I hadn't been around for the early stages of development. To me, the MESSENGER spacecraft was a magic black box that got me data.

Four years later, I now have experience working side-by-side with engineers on a daily basis. Collaborating with them on technical projects (including space missions) has given me insight into how complex systems that start as back-of-the-envelope sketches can be turned into real-life tools—products—that help us understand the nature of the world(s) around us. At First Mode, one of my responsibilities is to serve as an interface between our science-driven clients and our engineers in order to define, design, and/or develop tools that enable scientists to explore the Earth and beyond. Those tools include, but are not limited to, spacecraft (including rovers), instrumentation, and custom laboratory equipment. No matter the product, our approach includes the following steps:

1. Define the problem.

Rigorous identification of the problem—specifically, the scientific questions being addressed—minimizes costs, risks, and re-work, long before a solution exists in a physical form. We invest time with our clients, understanding their problem and developing product requirements that address their research objectives.

Requirements are the foundation of systems engineering. They are clear, concise statements that describe what a product must do without saying how it must do it. Constraints related to cost, risk, regulation, or other factors are also identified during this phase.

2. Identify the solution set, then select one.

Once the product requirements and constraints are defined, our focus turns to developing a concept of operations and solution architecture. These topics answer questions such as: How will the product be used? How will it interface with other systems? What environment(s) must it operate in?

We use the answers to these questions to survey the full suite of potential solutions (no idea is too crazy at first!) and then perform comprehensive trade studies to down-select to the most promising options. This is followed by interface definition between systems and sub-systems, leading to fully developed architectures.

With a well-defined solution set, we work with the client to select the option that best balances their requirements and constraints.

3. Design the product.

Now the hard work begins. To ensure that the product will ultimately address the scientist's research objectives, we must revisit and interrogate requirements throughout the entire project life cycle. This is most critical during design, when conflicting requirements are found, physics is discovered to be accidentally violated, and compromises must be made. Concurrently, scope, cost, and schedule creep must be mitigated.

Design involves both revisiting Steps #1 and #2 and looking forward to #4 and #5: a valid design must not only meet requirements and constraints but also be buildable and testable. It is an iterative process that requires open communication with the client.

4. Build and assemble it.

Often, the most difficult part of designing a new solution or product is having all the pieces work together the first time the “on” button is pushed. With a 7,500-sqft facility, a trusted network of manufacturing partners around the globe, and a history of successful delivery, we have everything we need to turn a drawing into a prototype. After parts are purchased or fabricated, we assemble the components into subsystems that are then integrated into the fully assembled product.

5. Test it.

Once the product is assembled, the processes of validation and verification ensure that the product is performing as expected. Both involve testing but they answer different questions. While verification answers “Did I do the thing right?” or “Am I done doing the thing?”, validation addresses “Am I currently doing the right thing?” Both are critical to ensuring the scientific validity of any quantitative results returned by the product.

After testing is complete and the results are satisfactory, we deliver the product to the scientist for real-world (or off-world) use.

Conclusion

Four years after sitting in that dark auditorium, I now look back on my MESSENGER experience with a fresh perspective and an appreciation for the engineers I never met who created and operated the spacecraft. It turns out that spacecraft are not magic but rather the product of smart people, good communication, and a shared common vision to explore our solar system. At First Mode, I carry that experience with me every time I interact with a scientist who needs help creating a tool to answer the burning questions that keep them up at night.