What Are You Really Trying to Learn? Chad Schneider on Prototyping with Purpose (A Chat with Cross-Functional Experts)

Before you build anything, before you open CAD, before you request a quote, before you sketch on a whiteboard: can you name the specific question you’re trying to answer?

Dianna talks with Chad Schneider who runs a successful engineering shop where a cardboard box became a prototype and where killing their own project was considered a win.

His team doesn’t think of prototyping as a phase. They think of it as a discipline, one that starts with knowing what you don’t know.

This interview is part of our series, “A Chat with Cross Functional Experts”. Our focus is speaking with people that are typically part of a cross-functional team within engineering projects.

About Chad

Chad Schneider is the CEO and founder of Root3 Labs, an engineering and device development company in Maryland. He’s a professional engineer with a background in mechanical engineering, haptics and medical robots. With over twenty-five years of experience across medical device and aerospace and defense, Chad and his team specialize in applied research, rapid prototyping, and design for manufacture. They help clients turn ideas into prototypes and prototypes into finished products. He’s named on sixteen patents and is a Goldman Sachs ten thousand Small Businesses alumnus.

What Chad and Dianna Talk About

They talk about why prototyping isn’t about building miniature versions of your final product. It’s about answering questions before they get expensive. We cover how Root3 Labs uses low-fidelity prototypes like cardboard mockups to test assumptions early, why Chad starts every project by separating needs from wants, how his team navigates the tension between what stakeholders ask for and what users actually need, and why killing a project can be the best outcome prototyping delivers.

Key takeaways

Every prototype should answer a specific question

Chad’s team doesn’t build prototypes to show progress or impress a client. They build them to resolve a specific unknown. Whether that’s “can someone with large hands reach this connector?” or “will nurses actually use this feature?” If you can’t name the question your prototype is answering, you’re not prototyping. You’re just building.

Low fidelity isn’t low value

A cardboard box with real connectors installed answered a fit-and-access question in hours that would have taken weeks and thousands of dollars in fabricated sheet metal. The prototype didn’t look like the product. It didn’t need to. It answered the question. Your prototype’s job is to learn, not to impress.

Separate needs from wants before you optimize

One of the most valuable exercises Chad describes is pushing clients to distinguish between what their product genuinely needs and what they want. “Does it need to weigh five pounds, or is ten pounds actually fine?” Cutting features that are wants rather than needs simplifies the design, reduces cost, and focuses the team’s energy on what actually matters to the end user.

The best prototype outcome might be killing the project

Chad’s team designed a hospital device concept with covers to conceal cables for a cleaner look. When they observed nurses using similar equipment, the nurses immediately removed those covers to access the cables faster. The team recommended canceling the feature and considered that a win. A prototype that saves you from building the wrong thing is more valuable than one that confirms what you hoped was true.

Watch for the rabbit hole

Even Chad (someone who lives and breathes prototyping) warns against going too deep. When a team gets excited about a technically interesting problem, they can spend weeks optimizing something that isn’t the highest-risk unknown. The discipline is matching the fidelity of your investigation to the importance of the question.

Insight to Action

Before you build anything, write down the question you’re trying to answer. Then ask yourself: what’s the cheapest, fastest, lowest-fidelity way to answer it? The point isn’t the prototype. The point is the question. If you skip that step and go straight to building, you’re not reducing risk, you’re just spending money to feel productive.