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

The episode features Chad Schneider, CEO and founder of Root3 Labs, discussing prototyping as a discipline focused on answering specific questions to reduce technical, schedule, and market risk. 

He explains that prototypes need not resemble the final product, citing examples like using a cardboard mockup to verify hand access for connectors and 3D-printed sizing models to understand surgical constraints. 

Chad describes managing complex, time-constrained projects by rigorously evaluating requirements as needs versus wants. He uses quick calculations and low-fidelity prototypes to resolve unknowns early — when changes are cheap — rather than waiting for expensive tooling decisions to reveal them. 

He also shares a hospital device concept that was canceled after observing nurses (who immediately removed the cable-concealing covers the team had designed) framing 'killing' the project as a win.  

Key takeaway: before you build, write down the question you're trying to answer, then find the lowest-resolution way to answer it. For more highlights, visit the blog post.

00:00 Start With The Question
01:22 Meet Chad Schneider
02:25 What Root Three Builds
04:46 Prototype Means Question
06:25 Why Skipping Costs More
07:17 Cardboard Box Prototype
09:27 Managing Deadlines And Needs
13:47 Risk Based Prototyping Culture
21:48 User Feedback Can Kill Projects
30:47 Final Takeaways And Challenge

If your team is still catching problems too late — let's talk.
→ Schedule a free discovery call: Dianna's calendar

Get the full framework.
→ Pierce the Design Fog 

ABOUT DIANNA
 Dianna Deeney is a product development process strategist with over 25 years of experience in regulated industries. She is president of Deeney Enterprises, LLC, where she helps product development teams make better decisions upstream — before costly design mistakes get built in. 

Transcript

Start With The Question

Dianna 0:01

Here's a question that might change how you think about your next project. 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? My guest today runs an 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. Stay tuned after this brief introduction.

Meet Chad Schneider

Dianna 1:24

Chad Schneider is the CEO and founder of Root Three 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. I've been looking through your Route 3 Labs website at the pictures of your team and the projects that you've been doing, and I gotta say, it looks like it's a lot of fun.

Chad 2:18

That's definitely true. Keeps me going for many years. It's a lot of fun.

What Root3 Builds

Dianna 2:25

so can you tell me a little bit more about the makeup of the engineering team that you lead there?

Chad 2:30

Yeah, we have mechanical, electrical, and computer engineers, and we're primarily working on multidisciplinary electromechanical type of devices for medical, aerospace, and defense industries.

Dianna 2:47

And what range of products-- Now, you mentioned aerospace, medical, and defense. Are these large projects? What's that like?

Chad 2:55

We work on all kinds of different projects at different stages. When you say large projects, we work on both projects that last for many months or years, but we also work on large projects, like physically large devices. Recently we built something that was for holding a 24-foot diameter part and, 10,000 pounds. And so really large things, but also we've worked on several projects over multiple years. And the other thing you asked about was the range of projects, and I think that's really the most interesting part about our work and our company is the range of projects that we work on. So a lot of them are early stage, taking an idea, turning it into a prototype, evaluating is it going to work the way we think it will. So our customers will come to us and they wanna know, is this gonna work? Is it feasible? And then once we've built some early stage prototypes, then- We'll figure out how to turn that into a manufacturable design, work with contract manufacturers, or even do the manufacturing ourselves, and build those manufactured parts, do some testing hopefully get it to the customer.

Dianna 4:21

So that's a lot that you're providing depending on what your customer needs. Now, you mentioned in there that you are doing the problem-solving, that you do prototyping, you contract out but you also manufacture in-house and you do testing. And it sounds like you're using prototypes to do a lot of that problem-solving and discovery. Is that right?

Prototype Means Question

Chad 4:46

Yeah. Let's define what a prototype is, because I think it's I think of it as anything that's answering a question. It's not necessarily, like if I wanted to make a prototype of a mouse, 'cause it's sitting here on my desk, and I had a bunch of plastic parts and some electronics and some embedded firmware, each prototype is not going to be an iteration of the mouse. It might be, are we gonna use a ball? Are we gonna use a laser? Are we gonna use something else? So the question might be, what's the best way to get better resolution on the mouse motion, i'm gonna test that thing specifically, and I don't need to build the actual entire prototype in order to do that. When I think of a prototype, there are lots of ways that we will build many prototypes that aren't necessarily representing the final product even remotely.

Dianna 5:51

I understand. So you're using iterative prototypes depending on the specific question that you have.

Chad 5:57

Absolutely. Every prototype is An attempt to answer a specific question or multiple questions, and the goal is to reduce the risk of continuing forward with our product development or finding out something too late. So we're trying to avoid those things by looking ahead down the road, seeing what kind of issues might come up, and trying to head those off early.

Why Skipping Costs More

Dianna 6:25

Sometimes people skip prototyping because of the cost of it. In your projects or with some of your clients, have you seen some of the real consequences of skipping the prototype phase? Is it that your clients skip it, and then they come to you for help? Or what other instances have you seen of that?

Chad 6:47

It's funny you asked the question. It's not even comprehensible really to the idea of skipping prototypes. We've definitely had people who have said, if we're gonna do an alpha and a beta prototype in a proposal," they're like, "Can we just skip and go... 'cause it's gonna be expensive to do." But the way I think about it, it's way more expensive not to do it. And also, like I said before, the definition of a prototype.

Cardboard Box Prototype

Chad 7:17

For example, we built this sheet metal enclosure, it's a off-the-shelf enclosure that has a bunch of electronics in it, and we needed to make it waterproof. And the uh, mechanical engineer was putting together some modifications to the sheet metal so we could put these connectors sheltered from the rain and being inside the outer perimeter of the device so that it wouldn't get knocked or anything. There was a very tight amount of room in this recess, and we're wondering, are we gonna be able to get our hands in there to be able to put the connectors in and take them out because it's gonna get moved, and our customer was actually bigger, so he's got bigger hands. And so we built a prototype out of cardboard, literally cardboard, just cut up a box and put in some rough areas of where those connectors are gonna be, and then installed the actual connector in the cardboard so that we could see both how your hand fit into the recess, as well as how your hand fit in between the connectors so you could actually install all six or whatever there were. And so within the day, we had answered that question and spent no money on materials and a little bit of time. When we think about a question like that, it's so easy to answer it using simple tools and concepts.

Dianna 8:45

That's an interesting story, and you're bringing up something about, if you see a problem, mock up a prototype. Even in your story, you used cardboard to answer the question that you had. Sometimes there's difficulty in actually figuring out what question to ask or what potential problems there could be to even prototype them. So when you're given a big project when you get something that large, how do you break it down so you can understand what specific problems or questions you have so that you know what to prototype in the first place?

Managing Deadlines And Needs

Chad 9:27

So that was physically large, but- Actually relatively simple. There are certainly smaller devices. We have this bed in, that we built that has way more electronics and complexity to it. But the number one complexity the schedule. So it was 10 weeks from when we talked about the project to when we delivered it. And the reason was 'cause they were getting these 24-foot diameter, 10,000 pound pieces of equipment in, and they needed a way to hold it and store it and move it around and manipulate it in manufacturing. So this is a giant part for a rocket. And they needed us to build the ground support equipment to support that component. And so they had a very limited schedule. And the way we attack a project like that is by project management. And by that I mean we start at the end, at the deadline, and think what are the steps we think we're gonna need to do to get to that deadline, and how are we gonna accomplish that?" Then you don't fall behind and wait, and there's no rush at the end because you've seen this coming for nine weeks. So you have the complexity of the design, which in addition to schedule, there was very strict analysis on the welding and the material properties and the factor of safety because people will be working under it and around it. Anytime you have people working around something, you wanna really just make sure it's more than strong enough. And then there were all kinds of other constraints around the temperatures it had to support and the mechanisms and actuation and things like that. So there was some electronics complexity to it as well. But figuring out how to manage the project from the beginning and think about how you could make it in 10 weeks. And so the way we also think about it is the requirements. So we look at every requirement and we think- Is that actually a requirement? Like when you're talking to your child and you're like, "Do you really need that or do you just want it?" And so needs versus wants. If you have an impossible schedule and you don't need something, then what I think about is, we'll get you what you need, and the wants if there's time, we can start talking about adding that feature or improving it in some way. But often the schedules don't accommodate that, and I'd rather you met your schedule with something that is 80% of what you're looking for than aim to have 100% of what you're looking for by the deadline and totally miss it and you've whiffed and you have nothing. So for example, we had this big mechanism and long term it needed to be painted just for corrosion resistance in the long term, but they had this thing coming in 10 weeks, and corrosion resistance is not a critical requirement for being able to move this thing around the warehouse. And so we figured if it came down to it, one thing we could push off was the paint. So it was one of those things we were thinking about in a different way where the requirement is that it's painted, but was something that could move

Dianna 13:05

You're talking a lot about project management, requirements versus needs evaluating risk. Like that paint job is a perfect example. Yes, it needs to be painted, but when versus budget. So I would imagine setting all that up would start to tease out some of the potential problems or questions with a project that might lead you to say, we should do a prototype here." So how far in advance do you think you identify the need for a prototype? Or is it more as you're doing the project, you're noticing, "Hey, we have this question, let's just do a prototype and figure out the problem"?

Risk Based Prototyping Culture

Chad 13:47

It's both. When we look at the beginning of a project, of a phase, we'll look at what's known and what's unknown, and even when we're doing concept generation as the beginning of a big project. So that is where we are sitting down and sketching basically the different solutions we could possibly have. So for that big ground support equipment, we had multiple ways we could address the major requirements. But if we don't know something about it, like how big the tubes need to be, we might do a calculation. If we can't do a calculation, we might build a prototype. So if the unknowns at the beginning of the concept generation require building a prototype or figuring out what the bill of materials might be so that you can figure out how big does that power supply need to be, what's the power budget, how big does the display need to be or the other components. Because you can do all the sketches and it's a nice little handheld thing, but if you need a car battery in it to make it work, it's not gonna be very handheld. So even though you can imagine what this could potentially be, I'm trying to be practical about various way... Like, how are you going to minimize this, or what's a reasonable size for that? And so we'll build prototypes early sometimes just to figure out those sort of things, like a power budget, and then we'll build prototypes all along the way. So it's very integral. That's, that's something that I think we prioritize by having a giant shop in the office. And I don't know if you can hear it, but we've got the CNC router running right now, which has a really loud vacuum associated with it. And it's ways we can build prototypes quickly when we may not even do the CNC router for a prototype because you can get really good resolution and materials, but it may be on the laser or it may be 3D printed or it may be just like a cardboard part. So it just depends what we need, and that's why we like having those tools because we can go build a prototype really quickly and answer a question and it could be anywhere along the product development process.

Dianna 16:17

I see. So you're using a lot of risk management. You said identifying the unknowns of a project and really using a lot of risk-based thinking to determine what kind of prototype you need, when you need it, to answer what important question. So do you talk this out with your team or just one of the engineers in your team just say, "Hey, you know, I think we should do a prototype," and everybody's on board? How does that get flushed out?

Chad 16:46

Yeah I don't do as much engineering as I used to 'cause I am running the company. But the engineers and they're all running their projects and they're using their own discretion on what needs to be prototyped. They're working together on multidisciplinary teams. They're talking to each other, figuring out what they need to understand in order to move forward. So it's everyone's responsibility to understand what the questions are that they're trying to figure out which is a challenge. Going to school for engineering, you're always given these problems, and then you come up with a solution. But in the real world, you're coming up with the problem too. The team, We see a lot of that, just they're figuring out what they need to build, and they'll be working on a prototype. One of our senior engineers is going to watch a surgery, and it is on an animal. So we're building a medical device, and she's gonna go watch an animal study surgery. And so she 3D printed this conceptual size of what she's been working on so that she can take it and just put it near the part of the animal that she's gonna be building the device for and understand the size, and is this reasonable? Does it have to be half the size? Is it twice the size? Like, she's got, she's got no concept of... And there's not really good measurements on different animals, like what does the spine look like or something. And that's what the product is. It's around spinal surgery. And so she's just gonna take it and, and try it out, so she needed a little 3D-printed part. So she decided that herself, that she's gonna go explore this surgery and... Which is great because you get the opportunity, she gets the opportunity to go and see for herself what this surgery looks like. Because when you ask a doctor, "Tell me about this surgery," they're not gonna remember every step. So you get to observe every step and see what they did, and so she's gonna get the experience of both the seeing where the device will go as well as what the procedure is like and how the doctor interacts with the animal, and this'll eventually get applied to humans someday. And so that's the idea. So they're figuring it out on their own.

Dianna 19:11

And it sounds like they have a lot of capability to prototype in many different ways at your lab. Some engineers don't have the availability of those prototyping mechanisms like the 3D printer or the CNC machine. If an engineer wants to adopt your philosophy, about prototyping, identify your problem, find out your risk, prototype to answer the questions that you need to have answered, what is one of the first steps that they should do when they're faced with that impossible deadline and they know that a prototype would help, but they need to get budgetary approval for it?

Chad 19:59

I wouldn't just make the argument that the product development process is an investment The concept, the idea that you're going to make an investment but then short-circuit the process of the investment to save a, sometimes a small amount of money, but potentially it could be a large amount of money. When you can do it ahead of time and save a ton of money downstream, I just don't understand it. So a number of examples come to mind not the least of which is you're at some point going to spend money on hard tooling or hard materials, sheet metal, machined metal, plastic parts that are injection molded, which requires thousands or tens of thousands of dollars in aluminum and steel tooling. You could maybe thermoform it and make it out of wood or soft materials that are cheaper. But you're still gonna make these parts out of what are called NRE, non-recurring engineering. And so they're, like, tools that you have to go through the process of making that can take weeks or months to build. So I'd rather figure those things out early in the process when they're cheap. And I think about it like an exponential graph, that the farther down the process you're going, the cost of change becomes exponentially more expensive. And one of the purposes of prototyping is to mitigate risk. So if there's a risk and you're not sure about something, then figuring out how to prototype and mitigate that risk early on rather than later is, seems like a excellent investment.

User Feedback Can Kill Projects

Chad 21:48

But the other aspect of it is what prototypes are really good for is minimizing the risk in the marketplace. So I talk about risk a lot, and I talk about speed a lot, and how to accomplish speed, but I also talk a lot about the importance of understanding the user and the marketplace and the problem that you're solving and trying to aim for problems that... or solutions that really are fundamentally what a customer needs and wants to spend money on, and isn't just a nice to have sort of thing. So the idea of mitigating risk because you're studying the customer, you're putting prototypes in their hands, you're seeing what they like, even if it's just, how does this feel? But the idea was we had a customer that wanted to build this device that was gonna be used in a hospital, and nurses are extremely busy and have a million things going on, and can't be thinking about all the different ways that your device is cool. They just wanna be able to use the stuff that they need to be able to use. This was a device that was gonna sort of clean up all the cables and the appearance and make it look really nice in the hospital. But then we were concerned that no one wanted it, and... Not no one, but the nurses particularly. And so we showed it to a bunch of nurses and got their input, and it was basically unanimous that they were like, can I take these features that hide all the cables and the display and everything, can I take those off? Because I just wanna be able to reach in and, and see what's going on with the display, make sure that the fluid from the saline drip i- that the bag is not disconnected or stopped flowing or something. I wanna be able to look at it without having to-" Move things out of the way first. And so it was a really tough conversation to, where the customer kind of thought they knew what they, what their customers wanted or what they wanted to build, and the customer that we, the customers we talked to didn't want it. And so we had preliminary data. I wouldn't kill a project based on just some preliminary data like that. But it's certainly something that you wanna talk to customers and understand you're going in the right direction, they like it it's something that w- they will, it'll improve their workflow or their day or whatever, make things easier, make things take less time, something. The other complexity in medical devices is that they're not the only ones being considered. So you have nurse, you have the patient, you have the person in purchasing who's looking at the cost of this. So there's so many people that are involved. You're trying to figure out what each person wants and try to fit it all into a Venn diagram, and it can be pretty complicated.

Dianna 24:48

Yeah. And so that's where prototypes can help add some of that clarity.

Chad 24:53

Yeah we built a prototype using some wood and aluminum and it was, eventually it would've been thermoformed plastic and custom aluminum frame, and it would've looked beautiful and it would've been built really nicely and sturdily. But the early prototype didn't need to have that capability. It just needed to convey the idea, the essence of what this thing was gonna do.

Dianna 25:20

Now, can you tell us with the nurse project, they thought they had an idea, but you took it to nurses and they didn't really like it. Can you tell us what happened with that project?

Chad 25:33

We lost the project. The project ended up getting canceled. So we basically killed our own project, which I didn't feel... On the one hand, I didn't feel great about because we lost a project and we were busy on it. But on the other hand, I would not wanna know this and build a product that nobody wanted. So I was also really excited about learning that. Like, I don't wanna spend time working on a project that doesn't go anywhere. It's so much nicer to work on a project that- people love. We have other projects that people are raving about, and that just feels so much better to be associated with projects that we know we did a great job, but we also know that the customer loves it.

Dianna 26:20

I love that mentality with your company too. It's about making products to help other people and useful products, right?

Chad 26:29

Yeah.

Dianna 26:30

Engineers listening today they're nodding along with "Yes, I like to do," more prototyping. They like the risk-based thinking. What's one thing that they can do today to improve recognizing when a prototype would be the best course of action or getting more into prototyping?

Chad 26:50

I don't know if it's true for everyone, but I, I am wired to just look at the negatives, negative things that could happen. And so I will look ahead and see that something may go wrong, and so I'll build a prototype to figure that out. But I think what people could take away some actionable items what are, what could you eliminate from, a requirements document that isn't a need but it's more of a want? And then you can look at what are you doing that aligns with those requirements that still remain? But you also wanna think about, do I need 1,000 prototypes? Do I... Am I just making things more complicated? Am I spending time on something that isn't necessary? Is there a rabbit hole I'm going down? For example, if you wanted something to weigh 10 pounds, or it needed to weigh less than 10 pounds, but you'd really like it to weigh less than five 'cause you think it would be more impressive or,, less cumbersome or something like that. The way I think about that, I would eliminate the five pound, quote, unquote, "requirement" from my thought process, and I would only focus on the 10 pound one so there's just so many factors, and what could someone do right away that's very easy to think about, hard to do, is cut things out of the requirements. You might have to get into a few discussions heated discussions sometimes where you wanna get rid of something and somebody will push back and say it's needed, it's not wanted. And those are interesting discussions. I don't know how to advise on where that line is drawn 'cause it's different all the time. It's different with certain customers or different team members or something. It's just a matter of figuring it out for yourselves and getting agreement and then moving ahead so the team is fully aligned and things like that. But the idea of simplifying, I really like the idea of simplifying.

Dianna 29:03

And your story about going down a rabbit hole I was smiling when you were telling it because

Chad 29:09

Those rabbits

Dianna 29:10

well I recognize that in my early engineering career, and I've seen it in other projects too where it's an interesting problem, and it's a challenge, and we think we can. But to your point, is it really necessary, and do we really need to spend that kind of time on it?

Chad 29:27

It's so many things. It's design, it's paint it's like art or documentation. If you were gonna write a document on your project or a book, like, when is a document really done? It's done when you put down the pencil. That's when it's done. You could spend a ton of time getting every factor in a design and calculation and everything. There's rabbit holes to go down, and it's very tempting, so try to avoid them at all costs.

Dianna 29:56

And to your point about understanding requirements versus needs and what are you really aiming for here is part of defining what done means for that project which can take some time and discussions and sometimes heated discussions to get on the same page with everybody.

Chad 30:14

Yeah. Now that you've gotten it to five pounds, can you get it to three?

Dianna 30:18

Yeah. I've seen that too. It's been great talking with you. If people wanna reach out to you and have a conversation, what's the best way they can do

Chad 30:28

Oh, yeah. I spend a lot of time on LinkedIn, so I'd love to connect with people who are interested, and make sure in your message to connect, you mention this podcast and I'll definitely accept it.

Dianna 30:39

Thanks, Chad, for coming on the show. I appreciate it.

Chad 30:42

Yeah, my pleasure. Thanks for having me on.

Final Takeaways And Challenge

Chad 30:47

Here's what I want you to take away from the conversation. When Chad says prototype, he's not talking about a machined showpiece. He's not talking about a months-long validation test rig. He's talking about cutting up a cardboard box to see if someone's hands will fit and getting that answer before lunch. That distinction matters because in my experience, the word prototype is where a lot of teams go wrong. They hear it, and they jump straight to building. And once you've built something, you're anchored to it, and that's a cognitive bias called fixedness, and it's real. You've invested time, money, and ego into a physical thing, and now the team is defending what they built instead of exploring what they should build. What Chad is actually describing. It's question answering. It's the discipline of naming what you don't know and finding the cheapest, fastest, lowest fidelity way to learn it before you've committed to a direction. That's staying in the problem space long enough to ask good questions before you jump to the solution space. So here's your one thing. The next time you feel the urge to build something to prove your idea works, pause. Write down the question you're actually trying to answer. Then ask yourself, what's the lowest resolution way to answer it? Maybe it's cardboard. Maybe it's a conversation with a user. Maybe it's a sketch on a whiteboard. The point isn't the fidelity, the point is the question. If you skip that step and go straight to building, you're not prototyping. You're guessing with expensive materials. If this episode gave you something useful, share it with a colleague who's in the middle of a project right now. And if you're an engineer with a perspective you think other engineers need to hear, reach out. I'm always looking for guests who are willing to have frank conversations about how engineering actually works. Find me on LinkedIn or at qualityduringdesign.com. This has been a production of Deeney Enterprises. Thanks for listening.