📍   Have you ever had an idea for a physical product that you just knew had the potential to change the world? Maybe it was something you dreamt up in your garage or a solution to a problem you encountered in your daily life. Whatever it was, you knew it was a winner. If only you can turn that idea into something... Well, you are not  📍 alone!

Countless entrepreneurs and innovators have stood exactly where you stand filled with passion and drive, but unsure of where to begin, and that's where "The Builder Circle" comes in.  

My name is Sera Evcimen and I'm a mechanical engineer, hardware enthusiast, and hardware mentor.  I've had the privilege of working with numerous hardware companies that are passionate about solving some of the biggest challenges in the world.  And I will be your host as we explore the exciting and complex world of physical product development.  



Welcome to the builder circle today on this episode, we have William Burke from five flute joining us.

Today, we're going to start at the top and we're going to talk through. The design process and how you can set it up for success when building an innovation product. So starting from building the right thing, we're going to talk about design requirements and choosing your  choosing your users and doing user studies. We're also going to talk through accounting for manufacturability, repairability, lifecycle, and scalability. So in short DFX. 

And then we're going to. Dive into a little bit of the common pitfalls and failures that  most companies experience during their design processes. And then we're going to do a fun little segment in the middle where we do hardware hacks, where we'll, we'll kind of go through a bunch of hardware hacks that he's come across. 

He's going to go into some really cool, detailed. Manufacturing hacks as well as some design process hacks that he's. Done in the past in a machine shop and then we're going to start talking about a little bit about AI and the future of design, how AI could potentially influence or integrate itself and the design process. 

And then as per usual, at the end of the episode, I will have my TL;DL where it's called too long. Didn't listen. Where I will summarize all of the key takeaways from the episode, so that if you don't have time, but you really want to learn more about the  📍 design process and how to set up your requirements and strategize the way that you set up your, product design. You can get the key takeaways at the end. And when you have more time, you can come back and listen to the rest of the episode. And without further ado, I'll leave you with Will  

  welcome to the Builder Circle. Today I am in the presence of William Burke from Phi Flute. I am so incredibly excited about this podcast episode because we'll be talking about the design process and what goes into the first stages of product development. So Will, thank you so much for being here.

I'm so excited to have you.

Yeah. Thanks for having me. I'm stoked. I, we were just saying before you started recording that the community needs this kind of discussion and I just, I feel like there's nowhere on the internet for mechanical engineers to be honest, and I'm, and it, and like anyone that makes a place for them I'm usually happy about.

Yeah. And also will himself writes incredible articles to help mechanical engineers under five flute. So you should definitely go check that out. Okay. To start off will, could you give a little bit of background on yourself and then we'll dive into five flute afterwards, but just let the listeners know who you are, where you've been, what your experience has been, and so on and so forth.

Yeah, I'm first and foremost a pretty hardcore, nerdy mechanical engineer, I would say. My first grade teacher actually told my mother that I would be a mechanical engineer

and she was Right. Yeah. Crazy, right? I know cause I was like designing things. I was like making like little games and like I learned to sew my own baseball glove in third grade and all just yeah.

Kind of just always been making things. And then I found biking. I found bikes. I think this is like bikes are like a gateway drug for a lot of mechanical engineers.

And I found bikes in like middle school and high school and started like racing them and taking them apart and like rebuilding my shocks and like generally messing them up and just tinkering.

Like I had this big kind of a foundation of mechanical design without even knowing it before I even went to engineering school. 

That's cool.

which is a lucky thing. I kind of wanna circle back on this point because I think engineering education has some pretty severe faults. And you could see it in grads, recent grads.

But anyway, a, just a nerd's nerd, mechanical engineer spent the beginning part of my career doing kind of race car stuff, heavy truck suspensions designed boats for a while.

But they were weird boats. There were boats with suspension systems at a company called Marine Advanced Research now called ocean Power Technologies, actually, Marine Advanced Robotics Division.

And then had a a little stint in manufacturing and that was kinda my first taste of startups at a company called Plethora,

Which was in the Bay Area. We were putting the machinist brain and software and operating a factory to CNC machine parts and writing software to make that process easier.

And I ran the hardware team there and stumbled into managing the factory for a few years,

uh, Which was like super interesting. And then burn out on that. I like took a four month climbing trip and then retreated back to my first love, which was just pure engineering design.

That's when I joined a firm called Cooper Perkins that recently got bought by PA Consulting. But I was the engineering director there and was running really cool programs like teams of the lecture, mechanical engineers. Doing everything from like early technology development to pretty straightforward consumer product development work.

And that, that's where I incubated a lot of the ideas for five Flu. And I got interested in engineering tools. I was starting to think not just as a project manager or an ic, but as like an organizational leader and someone that's responsible for making sure that engineering teams work well.

And in that process I rolled out a bunch of software tools, tools like Asana. Typically things that were like designed for developing software and adapting them to hardware, which I feel like is a common pattern and just, it was just really frustrating. I feel like a lot of the mechanical engineering tools in particular are frozen in time.

Um, Like when I looked at my stack of tools from like 2007 it's basically identical to what it was in 2019. It's like SolidWorks in my spreadsheet, let's do this right? And, maybe Python or whatever, or MATLAB or something. But like realistically, it's like that was my tool set and let's make a Gantt chart and like model some stuff and get in a room and figure it out.

And it's just not, when you look over at the software world and you look at the way that they have built these incredibly powerful abstractions that they can build on top of,

Being a software engineer in 2007 is they wouldn't recognize what development looks like today. Uh, It's a totally, totally different game.

And so Five Flute is founded on that core frustration. It's like, well why isn't engineering, why isn't mechanical engineering the same way? ? So yeah. So then I met my co-founder, Carson got introduced through a mutual friend. Five Flute actually started as a kind of like a side project and we built the wrong product first and then.

Learned some things, and then Covid, like second wave was peaking, and it was, everyone was oh my God, we're not gonna be in the office ever again. How do we do hardware?

Right? And so we that's actually when we started taking a look at issue tracking and realized that there was a really big opportunity and then raised some money for the company.

What Five Flute is basically an issue tracking and design review platform for anyone making physical products. So that's ME's, EE's, industrial designers engineering technicians, and all the management layers around that. And I think the thing that really sets us apart, or philosophically sets us apart is that we want to bring as much capability inside CAD as we can.

So today that means that we're focused on issue tracking inside SolidWorks. I think CAD is like this incredible video game that mechanical engineers get really good at and they often want to. It's like your IDE as a software engineer. Like it's the place where you're doing your coding, right?

You don't really wanna leave that to do anything to 

Like context switching is not right.

yeah, exactly. So what we do is we make it really easy for engineers to create issues and share visual feedback with the team directly inside cad. Whether you're a CAD user or a non CAD user. And I think the CAD platforms are these incredible tools, but typically they're designed in the nineties.

They're not multiplayer products,

Mm-hmm.

, Safer, you know, on shape  really, but like the CAD market is just chock full of tools that are, for lack of a better word, kind of legacy tools that are incredibly good at CAD modeling. They're very complicated. There's a lot going on underneath hood there.

And they're not going any, any anywhere, anytime soon. NX has been around forever and like people, SolidWorks desktop is growing, right?

Yeah.

Which is crazy, right?

Yeah.

These tools don't talk to each other, right? So if I'm, if you're a typical stack, your product development stack is something like SolidWorks and Altium, and then maybe like you have an industrial designer using Rhino or something like that.

And then you have some people writing like firmware or software on top of that. None of these environments play well together. So when you bump into issues that cross discipline, it's extremely clumsy to solve those problems.

So like very simple design problems like making an electronics enclosure or something

you get, are integrated with the geometry of A P C B, right?

And maybe there's like a problem on that printed circuit board and it takes so long to trickle that information from the. EE to the mechanical engineer in the right format that they can actually do something about it. The change, the fix is great, I change and extrude in solid works. It's five minutes, but it's oh, you have to have a meeting about what's wrong.

Yeah. Yeah.

and so fundamentally, Five Flute is about reducing that cross-disciplinary friction by giving everybody a toolkit to do really have a really rich visual conversation in the design environment that they're used to living.

Yeah. And I've had the pleasure of being, a beta user in some capacity for Five Flute. And it's really re-imagining the way that engineering teams work together and trying to get rid of interdisciplinary silos in a  collaborative and asynchronous,

Which a lot of, specifically on the software and firmware side, people prefer, uh, working asynchronously and absolutely hate having meetings. I think it has a lot of potential and for people that are interested, definitely check it out. It's a really phenomenal idea that they're working really hard to. 

Yep. So much software to build.

yeah. That's so excellent. And the essence of what led you to Five Flute is your experience in seeing the cycle and getting the frustration

The product development life cycle. And so  going, going to the like very first step. When you're starting the design process for an innovation product, whatever that may be, and

feel Off of any personal experience.

But when you're starting building, how do you make sure that you're building the right thing? Because writing requirements is one of the o like oftentimes in startups forgotten piece of the equation because people just assume that they know what the requirements are because the mission is so clear and the customer is clear.

So like, why not just start designing stuff and kind of go into the open terrain of design world? But h in, in your experience how do you go about uh, writing good design requirements and choosing users and anchoring off of that customer?

Yeah. Wow. Big question. 

Huge question.

I think people get people get lumped into sort of two camps. There's like the first camp that you just mentioned, which is forget requirements. I wanna start building now, right? I wanna make progress. Requirements are for the birds, right? They're boring, let's make stuff.

Um, and there's something to that for certain projects. Projects where discovery is really important. And I think I. Whether you're, you need to know whether you're doing technology development or product development, and we can put like a pin in that and come back to what the difference is.

But and then the second camp is the people that like fashion, very quickly fashion their own prison of requirements.

And they do it like right in the beginning of the project and they're like, we cannot make any progress until all of the requirements are perfectly defined and we have a path to meet them.

So so there's this gradient. I think every very few projects live on the extremes, but it is the gradient and all projects live somewhere in that space.

I've unfortunately seen many projects that live in those extremes

Yeah. I don't, that's interesting. Why is that, like, why do you think that is?

because what happens sometimes in startups is that, People, if it's a complicated enough product, people end up hiring folks from very big organizations where they're very used to see like the part of the spectrum where it's the requirement prison. I love that terminology. Where they have been systems engineers for government contract, big companies. So that's the only

world that they know. So

they try to apply that. A lot of people don't know that systems engineering is not a one size fits all.

I've seen that. And then the other way around is some startups hire very early career people,

uh, Who haven't had the experience and the pains of how much time gets lost  without the presence of requirements.

So what those teams end up doing is. They're super high energy. They have millions of ideals shooting out of their brains, and they just really wanna get it on a piece of paper and start brainstorming and

like doing stuff. And

They're like, I could  Rapid prototype this. And

then they go, and it's been months and there is no project manager usually early stage, so no one stops them.

I've seen both ends of that spectrum

Really strongly un unfortunately 

yeah. No, the being on the end of the spectrum where there's zero requirements and you have a product that like you're tooling is like the most horrifying thing.

Um, it's so scary. I've seen that a hand on a handful of projects I've been involved with, and it's really hard to reel that back in.

It takes a really strong amount of leadership, but okay, so how do I tackle this typically? So typically I like to start with I'm not a dogmatic person about requirements. I'm not like, you need to have like fully sussed out marketing requirements that inform product requirements, that inform engineering requirements.

I think that's typically like too much overhead.

I like to just you need to have a u some use cases, right? You need to have a shared conception of what the product is supposed to do at what le whatever level of depth you think suits the product. It's just like your judgment.

And then typically only make a PRD sketch off of that. A P R D is a product requirements document. It's just a way to write down what the thing should do.

It should not enumerate the solutions in an engineering sense.

It's just yeah, it's just I don't know, like you're making a watch for scuba divers or something, and it's it needs to work underwater at a certain depth for a certain amount of time.

So I like to make a P R D and then it's. You're gonna learn so much that you're gonna update and you're gonna fill in those requirements as you develop, but you need to have some like core subset that you know right up from the jump, 

non-negotiable. 

Yeah. I think, and I don't think it's hard, like I think you know what they are.

I think like you can just get in a room and talk with people and they'll just trickle out. Or or if it's like your company or someone's company that they're founding, like they have some pretty, they probably have pretty strong hypotheses about what the product needs to do to meet the needs of the market, right?

So that's just a conversation. Write that down, put it in whatever spreadsheet, air table yada. Like it doesn't really matter. And then don't put it away and forget about it. Keep it handy, right? Because you're going to learn a lot more and you're gonna add in requirements as you iterate.

And ultimately what you want to do is by the time that the thing is in the market, you have a really trustworthy set of requirements that you can actually know that you're meeting.

And so those requirements should in some sense also inform or represent risks that you need to de-risk throughout your development.

So that's how I think about it. I'm not a systems engineer, so you know, I'm not a super well qualified person to manage requirements on a rocket, for instance.

Yeah,

but I think it's, it is really important to have something at the beginning of a product development cycle. Obviously as you said, writing those requirements will likely be relatively easy if you are confident in the problem that you're solving and the solution that you are proposing will solve. So I completely agree and it should be a living document is basically Biggest advice here,

, which I've heard in other episodes I did and personally have ha have had experience with. So going through that, I know that Five Flute has a very good kind of hypothesis of what part of the market they're addressing.

So when you were going through kind of user studies and who you were anchoring off of, how did you go about that exercise?

Yeah, I think with Five Flute I have a pretty tremendous advantage in that I'm scratching my own itch.

Exactly.

So it's like I'm the customer in some sense at the highest level. That said one of the first things we've developed on the design review side is actually a drawing review platform.

So there's a module inside Five Flute that lets you do a collaborative drawing review in your browser, upload drawings, assign them to people designate reviewers, do all of your markup. In browser, upload different revisions, compare across those revisions, and then run in a custom approval process.

And for me it's been, I don't know, years since I've like really done drawings for a living. We just had to find people that had like capital P drawing problems, people that like were reviewing a hundred drawings a day or whatever and just talk to them. I don't know. I'm not, I think like people often over-index on user research at certain times.

It's pre, it's, it takes a while to do, right? Like it takes outreach, it takes user feedback in general I think is really noisy. So you need to like, it's this kind of like stochastic process. You need to get like a lot  of feedback and then you need to pull it all into your brain and be like, okay, what are the commonalities?

And tease that out. And that takes time. It takes a lot of time. And so when you compare it to the. Certain design decisions or development decisions many of them are reversible, those decisions. And so you don't necessarily need deep research if the decision can be rolled back very easily if you can.

The best research is like what customers actually do with your product. So there's a spectrum there, I'd say.

Definitely. One, one thing that five flu has done with me that I've really appreciated is just watch me work

through the, the software and and just and just see what my thoughts were on where I thought certain functionality would live in,

and Go from that, which I think is a perfect way to, to go about it. 

Yeah, it doesn't have to be hard, right? Like we, you can make a mock, you can make real software or you can make a mockup. I think with you, we might have even gone through Figma mockups. Did we go through click through mockups or was it Real Software?

I think we went through both.

Okay. Yeah. Like just doing wire frames or using Figma to make mockups and a lightweight prototype.

And then just don't say anything. See what people do. It's agony, right?

 

but don't lead the witness. Yeah.

Yeah. And I feel like this is like pretty, pretty special to software, but

It's also the it goes without saying that if you have a prototype and it is a consumer product, like having customers interact with it in real time and

Using it is also a very transferrable strategy of user feedback and,

uh, potentially make changes.

Yeah, I think the hardware products have an interface as well.

Yeah.

fundamentally it's, it's similar, right? You wanna see how people grok that interface, what they do with the product they have. Users always have amazing ways to just do something that you didn't expect them to do.

And you just need to be on the lookout for that. I think the depth and the importance of user research depends on the level of sort of human factors dependency of a product, right? If you're, if you're developing like an MP3 player or something, okay, like you, you want to pay attention to how people use it.

But there's lots of predicate designs out there. It's not super high risk if someone doesn't understand how something works at first discoverability probably won't. A lack of discoverability of certain features won't hurt people. But if you're designing a surgical tool,

Like you need to know the doctors understand it very quickly and they're not gonna make the wrong move with it.

If you're designing the. I don't know, like the control panel for the Apollo lunar module or something. It's okay, they need to understand exactly how this works so that when they're like not resourced in an emergency, like on the moon, they know how to take manual control of the thing and land it.

And then that happened, right?

Yes.

so I dunno, maybe this is why hardware stuff is fun. It's like there's such an enormous spectrum of different types of products and as a mechanical engineer you're like, you like get out and do your career and you're like, okay, I'm ready to design stuff, and it's okay, you're supposedly have been armed with the ability to design, everything from a toothbrush to a 7 87.

And that's wild. It's a super broad and super deep discipline that I find just infinitely fascinating. And I'm like constantly a beginner, like I.

yeah.

I know so little about engineering.

It's crazy.

Every day is a humbling experience, I think.

Yep.

I completely agree with you. The curiosity continues forever.

And, I personally ha share a lot of the feelings that you expressed about mechanical engineering, and it's the reason I chose it. It,

the opportunities are endless. It's amazing. But yeah. Okay going through the product lifecycle a little bit more. When when you're approaching Design cycle more for kind of manufacturability, repairability, lifecycle, scalability, all these things how do you go through thinking of those so the d the dfx others call is designed for x.

How do you think through those and what do you feel is the most important? Because you can't prioritize everything. So in your experience, what has been your approach?

Yeah, I mean, I think there's a, the very beginning of like the, the, the greenfield part of design should actually have sort of a, like a explicit concept development phase too. So even before like Dfx or whatever,

um, You need to know how to generate, how to evaluate, how to like, characterize and evaluate a solution space and generate ideas um, that you can evaluate in that solution space.

Um, Like lots of people do this by brainstorming, myself included. Um, At Cooper Perkins, we had a pretty cool uh, method of brainstorming um, that I've adapted. But, and it fundamentally it revolves around bringing some knowledgeable people and some ignorant people together. And then writing Think taking a lot of time to think about what the prompt actually should be.

What is the actual question that you're answering with the brainstorm,

And making sure that you frame that at the right level of specificity that you get a solution space that is populated fully like both broad and deep. Um,

An example that you could potentially give?

 Yeah, so I don't think it's particularly complicated.

Like I think yeah, I mean it's very hard for me to come up with a prompt offhand, but it w a, a typical prompt would be something that is like the major or the most risky sort of big bet in a product development effort. So like the core feature, the way to tackle the core technical problem.

And then what we would do is just get, we would. You as a person preparing that brainstorm, you wanna spend a lot of time writing down different prompts and doing your own personal brainstorm to make sure that you it's not too specific or it's not too general to be useless.

And then we present that prompt to a team of engineers, some of whom are familiar with the project, some of whom are not.

The role of nerd is very important in these spaces. You want people that aren't like previously biased to if you learn what a project is about, you very quickly start. You can't help your, you help yourself. You start coming up with solutions, right?

That know nothing about it, and you just present the prompt, the naked prompt without the rest of the baggage of the project come up with a very creative ideas.

And so you populate this entire space. And those should be low fidelity ideas. Sharpie sketches on a single piece of paper, given a name and a number. Pull that out, and then you cross pollinate all those ideas

And then come up with some ranking system. You do some voting or whatever.

You do a Pugh chart to. Weigh them against different criteria and that you care about. And then that sort of sets the stage for okay, these are like concept designs that are worth investing the engineering effort into.

So I would say the first thing is okay, how does D F X play into that process?

Is it a major contributor or is it a secondary concern? You should know that 

Mm-hmm. 

Right? If it's a sustainability focused product, then that should, maybe be in the prompt, right? Maybe be something that you're brainstorming around. I don't know. I didn't answer your question at all. I just, you're just rambling on about brainstorming, but I guess the way that I don't even know if I really think about D F X explicitly.

It's more of like a filter that I put a design through.

Yeah.

It's not something that I'm like primarily optimizing for at the start of many projects, unless it's really centered around that.

Definitely. I agree with that because what you said, actually, you did answer my question because I was more trying to understand like how it's prioritized and also in your mind, and then also how the process would go about. I completely agree with your assessment on brainstorming.

I follow a very similar. Kind of process. And it's, I think, important to note that very early on obviously you should have some level of requirements and the prompt that you were talking about and the prompt should involve metrics you care about. I usually call them metrics of just like dfx could be one of them.

And then time cost certain things can also be a part of it if you wanted to, but early on it's probably best to not cons over constrain

Yeah. Yeah. 

have a little bit more of an open terrain. Because what I've seen happen, which I find fascinating, is that someone could have an absolutely horrible idea.

Yeah. Yeah.

truly doesn't fall in the requirement in any capacity. But that idea triggers a good idea

Else being like, no, like that won't work. But what if we did this? And when you over constrain a problem, you cut those branches off without even

Yeah, completely. Like the people think that the value of the brainstorm is ha being in the room and like generating the ideas. Anybody can generate ideas. There's actually research that shows that p individuals generate better ideas

By themselves than Brainstormers do. Yeah. But I think it ignores the practical element, which is you gotta, people have busy lives and they're working on other projects and it's pretty, it's a pretty practical thing to get 10 people in a room for half an hour or one hour and be like, okay, ideas go right.

All of the value in my mind is on. The preparation for the brainstorm, making sure that you're answering the correct question, and then the post-processing of the brainstorm. Most projects do not need genius solutions.

They need practical solutions, right? So like brainstorming is not about winning some like innovation award, right?

it has to work. And there's not many better processes for quickly getting people aligned around a project, a problem. And then generating, like populating that solution space so that you can do the super valuable post-processing work. And it should be hair-brained ideas. It should be totally non-judgmental, right?

You can come up with totally wild things and that stupid idea might cross pollinate in some weird way with another idea that, gives a, the designer who's actually gonna do the work, the sort of courage to go in a direction that unlocks the problem.

I completely agree. And you used one of my favorite words, which is practical.

, That's what my company is called in Turkish. Pratik means  Practical.

Ah, nice. Okay, cool.

Yeah. So it's all about that truly. It's never the best. It's never the perfect solution.  It's the good enough. And you really. Need to provide space for your team to fly

a bit. and No ideas are discounted at first. And then you parrot down

It's very easy to say no to things, right? Everyone's used to saying no to things, right? 

Harder. Once the ideas get more fleshed out, it'll get harder to say no.

I was talking to another mechanical engineer and she called it killing your darlings

Of just there's gonna be a lot of emotion that's gets connected to

Yeah. Yeah. Ego too.

Yeah. As you go down the line. And I also loved that you mentioned pew charts. They're my. Absolute favorite decision making or other people would call it decision making

Yep.

Um, I use them religiously in my practice. And I actually fun, fun tip for everyone. This is I think I saw it somewhere, but I feel like it's a creation of my own.

So there's also risk matrices, right? And I actually cross pollinate those too, and use them with each other. Because sometimes when you're looking when you have a P chart, so a p chart, just so people can imagine it, it's basically starts with a column that has all of your metrics in mind.

So what you care about in the design, whether

it's like. How much time it's going to be, the complexity, the carryover potential, et cetera.

, and then on the following columns you have your different options that you're trying to select between. And then you weigh them. You compare them to each other and give a minus one or a plus one, depending

on,  performance.

And then it shoots out a mathematical result of one is better than the other. And

then you can, that can't, that doesn't have to be the end all be all, but it centers the conversation incredibly well.

That's the thing, is it's always wrong actually. The chart is always wrong and you, it spits out an answer and you're like, wait, that doesn't that doesn't match what I feel. 

then you 

that's where the conversation is. Yeah. And it's all about that conversation. So it's just a tool to get you talking about the right thing.

It's not necessarily like a, a perfect scoring rubric, 

No, it's not. And as you, you're totally right. The first time around it comes out and you're like, hold on a minute. That doesn't really go with the

logic that we've been Talking about.

And manipulate some of the things that you said of oh, maybe this isn't right. Oh, this isn't right.

And then it like, Starts to converge to something. But the reason I combine it with a risk matrix is because sometimes it doesn't take into account you can have a metric that's called risk, but I feel like that's not good

enough. 

I've done that before.

Where

clumsy. It's super clumsy cuz it's highly non-linear. The way you

Yeah. It's not a linear ranking at all.

no not at all.

And also, there's just you might have a set of lists of risks that of them are not super critical and then the

others are severely critical. So what I do is for each of the options, I also write down the risks. And even if one is a winner and the bottom, you see it's all red,

Like, this is like maybe a better option for my metrics, but it's a high risk, high reward situation, so I'm

gonna go with the less risk, but good enough solution.

And that

helps Center the decision. 

I've tried to do something similar where I like overlay like a range of performance where it's almost like a statistical, like in projects where it's like technology development and you don't know how the thing's gonna perform and you have different concepts and it's okay, there's, you're ranking it on some performance criteria and then you're like, oh, 

I don't know. I think it would be like I'll put a range actually

And then spit out a range as a score.

Oh,

but I played around with that ultimately. I think it was a little bit too clumsy. Like I made it and then I showed it at the rest of my team and they were like what?

But yeah, I, this, it just sounds interesting. This combining the risk overlay on the Pugh chart.

Yeah. It's how I've made decisions with really large engineering teams

As long as I can remember

since I started, Engineering.

, so yeah that, that's a really, I'm so happy that you mentioned it because it hasn't come up yet. So this the first time that it's

D dfx might be one of those criterion in this case too, right? So you might be post process, post-processing and looking at, sustainability or or whatever. Any other dfx parameter. I think in terms of the nitty gritty of design for manufacturability, designed for assembly, it's just a skillset that you need to learn as an engineer.

It's not mystical by any stretch. You, if you're designing for a particular process, you need to have a deep knowledge of that process or talk to people that do. And then that's how you bootstrap your own knowledge is you one of the first things I did when I was engineer at this robotic systems integration company right outta college.

I would just go out to the shop floor all the time and talk to the guy at the press break, cuz I just had no idea what I was doing with sheet metal parts, and, I would bring a printout and just show it to him and he'd be like, that's dumb. Here's why.

And you'd keep digging and then you get knowledge about the process. And that's how you bootstrap your d your sort of dfx knowledge. And it's super valuable. It's insanely valuable. Cause the more you bake it into your brain, the earlier you can fold it into your design process.

And the less it's not like a bandaid that you slap on at the end of the project, right? Projects have inertia, designs get deeply integrated, they get even harder to change. Con engineering gets concurrent. Like the deeper you get, the closer to manufacturing the like more handcuffed you are by your own designs and your requirements and your sort of requirements maturity at that point.

And the engineering work to unravel that or to go back, one iteration is super non-linear.

, so you wanna bake it in as early as possible.

Yeah, I feel like the actionable advice here is when you're doing design for manufacturability or repairability, specifically in the manufacturability sense,

Really knowing what  unit quantity that you're going to will help you say, okay, like we're in the prototype phase.

Now we're like 3D printing these, obviously that's not gonna be how we make them. Looking at, for example, options of just are we gonna injection mold this?  And then talking to those , to people to understand what the constraints of that.

Yep.

Um, early on, and if you can, incorporating those designs early into even your prototype, even if it's not going to be manufactured with that process 

yeah, exactly.

and being inquisitive about it is super important. And in terms of repairability, have your engineers. And even if you're a co-founder, you should definitely one, go through a cycle of producing whatever you're making by yourself.

And if you don't have the skillset with an engineer next to you so that you see what goes into it. And then secondly, if it's a repairability that you're looking into, build it. Build it and

repair it. Break something and try to repair it and see how that process goes and how much headache you get

early earliest you can.

Yeah. You said one, one thing in there that I think is super important, which is designing such that you can adapt the next iteration easily to the production process. So if it's a, even if it's a printed part or if it's a c and C machine part. If it's gonna be injection molded or cast or or sheet metal, like designing it with a geometry that is adaptable to that process easily super crucial.

Yeah. And usually the early prototyping versions can do anything. You can build anything with it.

Like with some, obviously some ca some edge cases where you probably can't, but that won't be your limiting,

uh, your limiter will come later, and if you already have entire system interfaces all flushed out, by the time

To that point, you're gonna be screwed.

yep. And I think ultimately too, like this is dfx down the stretch. When you have something that's like ready to be manufactured is very hard work. it, It's like it's super non-trivial. People don't even take the time to like actually map out what the processes look like for all of their parts.

And that's very val, that's a super informative process. If you can't actually develop a map of what manufacturing processes create a part, you don't really understand it. I see people Yolo entire designs, like over the fence to an O D M or a manufacturer.

 

and it just gets really messy.

Like you, they end up making things in ways that you didn't expect them to. And that has profound implications for performance

definitely.

that are hard to communicate sometimes. 

Definitely performance and also cost. 

Yeah. Yeah. Yep 

the OEMs are especially if you're outsourcing, which most small,



Hardware products will have to because there's all a lot of cost constraints there. If you don't put in the work ahead, it's going to bite you and your unit cost is going to go up significantly and also potentially break  your business model.

So there's Like this crazy domino effect into the business that comes through not being able to think of this early on.

Yep. Yeah. And if you get, if you, if the factory is doing your, some subset of design for manufacturability   they're not often doing that with the same level of engineering rigor that you

That your product demands necessarily. And I don't mean that like disparagingly, I think these factories like have lots of expertise, particularly in specific processes.

But if you hand them a design that doesn't at all comport with the way they make things

And then you give them agency to change it, to match the way they make things. It's, it gets really ugly really quickly. I've seen that happen on so many products and it's just a nightmare cuz you get a prototype back and you're like, oh my God.

Like I can't believe they they made it this way. Yeah. I cannot believe they made it this way. This is why you need to go, to your, get boots on the ground, have people in the factory.

, which is why Covid was so crazy for a lot of people. There's a podcast with my old formula s ae classmate, a j AJ Cooper, who runs I think he's like head of engineering at Lyft Transportation, like doing the bikes.

And he was talking about this very thing about if you don't see it getting made, you have no idea how it's made. Like boots on the ground in the factory is the only way to do that.

Yeah, that level of accountability is crucial,

, For OEMs and also a another less important. But still, I think important point there too is if you're outsourcing that part, the dfx part on your product to an oem, you're also losing a lot of institutional knowledge

there, That needs to exist for the company to sustain itself,

, for next gen products.

Yeah. Also

That happens in-house

Yeah completely agree. And then I think there's sort of two levels of D F M. There's designed for a particular process,

Which is necessary and somewhat valuable. But I think like the real value is in eliminating parts.

Yes.

This is where you win. Like engineers love to optimize parts  that shouldn't exist.

It's just like this fun game that people get super obsessed doing. And they lose sight of the fact that like the entire part or the entire module could be eliminated or could be combined into one monolithic part. And like those things, you're not really good. You're not gonna get that level of D F A designed for assembly or whatever from an oem, really.

Um, you're gonna get the, like, how do I run this design through a filter that matches my processes? Versus that holistic thinking is something that like your engineering team needs to own. And that's where all of the value In D F M A is, in my opinion.

Absolutely. OEMs should be used for their strength, which is building.

Um, and if it goes beyond that, you're going to suffer in, I feel many facets of product design.

So,  moving towards, common pitfalls and failures you've seen in the design process. Could you talk to some of those? I'm sure that you've seen trends after working through all of this 

Yeah, I think not knowing what the thing needs to do, right? So not having like a cogent acknowledgement of requirements or imprisoning yourself with your requirements. We already talked about abandoning your requirements, like thinking about it as a static document that you write one time and then you just forget about,

And this is gonna sound like I'm some, like requirements driven lunatic.

Like I'm really not I don't think it has to take up that much burden. but I, like it's important to know what the thing you're designing is supposed to do and have a shared conception of that across the team. I think the, one of the biggest mistakes I see is not prioritizing. Not de-risking the product in the right, the design in the right order,

Totally.

And like kicking the can down the road on certain fundamental technological problems or product development problems is a super big and common risk.

I think people often like to integrate the product, like into something that looks like the final product way too soon when they should be staying modular. You should be because it gives you the illusion of progress,

right? Like you make a thing that is product like and you're like, , we're so close to getting this to the market.

But that can really trick you into thinking that you've made more progress than you actually have. So I'm always trying to get teams to slice and dice the key, like key risks into modules. Like at Cooper Perkins, we call them like breadboards, like even it's not, not an electronic spread board, but like a hardware breadboard.

And like roadkill prototypes basically. So don't pull stuff together until you absolutely have to at the end. And when you're doing that, it shouldn't be a risky process,

Yeah.

right? It shouldn't, you should not, you should have zero technical, fundamental technical hurdles left when you're like making the looks, like works, like made like prototype.

You shouldn't be de-risking things at that are that fundamental. At that stage. You should be de-risking manufacturing process and assembly order and

Like problems of integration but not problems of technology. I see that as a big mistake. I think oftentimes that sort of rhymes also with people not understanding that they're doing technology development versus product development.

So technology development in my opinion is and this is again informed by Cooper Perkin's work for me, but I think So the founder of the, of Cooper, Perkins Gearhard used to say, I don't remember how you put it, but it's basically like technology development is everything that happens before you know your requirements.

And there's, there's, in some sense, there's always a top level requirement. It's like for, the Apollo program, it's get to the moon. Like you want to do the thing, but it's  how do we do this? We need like an engine, we need figure out that whole thing.

We need like a launch vehicle and like a lander and there's, you're trying to figure out if something is possible or not.

That's fundamentally different than product development. Product development is Hey, I have a list of things I need to do. And it's about executing on that list.

And that list, for lack of a better one is your p r d.

Yeah.

So I see people like forgetting to do technology development first and then letting it, like starting this deep product development process that like leads to integrated products. That are made, like production processes or or are close to the final design and then not de-risking some fundamental technology,

Until it's too late and that just goes horribly wrong.

It like sinks companies. It's, it demotivates the hell out of engineering teams. It like completely bricks your progress.

Um, so that's the most common things that I see. Maybe some finer points would be like not being intentional with why you're prototyping,

And like what your prototype is intended to do for you.

You're trying to learn from it.

yeah, every project is gonna have a lot of issues

Yeah.

and so what you want to do is you want to discover and resolve those issues in the right, in the most efficient path.

And so my contention typically is okay, de-risk the riskiest and highest impact things first.

Sure. Yeah.

It's not complicated.

So make a prototype to do that

And do it at a level of fidelity that only does that, it does nothing else,

Yep.

right? And so naturally as you do that, you will start hitting the longer tail of risks. And the longer tail of risks is those things that are involved in integration. It's does it fit together?

Is it manufacturable in these ways? And then you get into like cosmetic stuff. It's are there knit lines on this injection molded part? Is it, do we cover them with a sticker?  But that's not really like the major thing that the product is doing.

Like most products are not just looking beautiful, they're doing a job. And you need to be super intentional with how you like as a pm or a leader, a hardware leader, like running these programs, how you like slice and dice the milestones

Yeah.

to de-risk in the correct order and do it in such a way that you always maximize for design flexibility throughout that process.

You have this again, we've talked about this, but like this highly non-linear thing, projects build up this inertia.

And the, your ability to roll back designs and solve seemingly simple problems when everything is deeply integrated, it, you can really handcuff yourself in a heartbeat.

Look, you look at, I think the biggest and best example of this is military programs like defense acquisition programs, right? So if you look at like the F 35 for instance, they were like, we're gonna be like, we're gonna get this developed super fast by doing concurrent engineering. That's a feature and not a bug.

And it's basically like everyone's gonna go off and design completely side by side with no thought for what's the most important thing to de-risk first.

And like the F 35 is a I don't know, a 1.2 trillion program.

Yeah.

It's like g d P level stuff and it's a plane. That can go horrifically wrong.

So there's a book that I just read I think, I can't remember the author's name, but I think it's called How Big Things Get Done.

And it's essentially like a, an analysis of projects and the ways in which they go wrong effectively.

And what what he's developed a database of projects.

And you see this highly non-linear long tail of cost overages

Depending on the types of projects. And one of the things that he talks about is think slow act fast,

Which I really love. And the, what we were talking about earlier with like people ignoring requirements and just starting to make stuff that is acting,

Fast

That is, yeah.

Like it's just not thinking at all.

like thinking fast and also acting

fast, 

Yeah. Exactly. And his point is like the duration of that, the, that the doing part of the execution part of the project that window is open is the duration during which mistakes happen. So what you really wanna do is minimize that time.

And, but the problem is planning doesn't feel like progress.

Correct. Especially for engineers.

Yeah, totally. And nobody wants to do it. So I think, he's he's has a handful of typically infrastructure programs that he's looking at that it, demonstrate this like the California High-Speed Rail project. And many other things. But I think the same.

Guidance applies to smaller projects, to hardware projects too.

Yeah. I really love the journey that you just take,, took us on with this, because I completely agree. I wanna make a particular comment on one thing you said which is regarding de-risking. It, when I think of common pitfalls I really think about very similar stuff, which is the requirements part and then the

risk Part. And I think another way to describe what you're saying is  when you don't do your proper risk mitigation early on and with your subsystems or sub-components, what you run the risk of, you actually add risk to the pro program. Um, is what happens is when you have a fully integrated system and you're testing for the first time for a specific risk,

Might have risk coupling that's happening

Oh yeah. 

you don't know. You don't know what is causing the failure. And one of the most important things in risk of mitigation is the identification of the failure.

That kind of root cause analysis that you completely cripple yourself in by not being able to perfectly compartmentalize what risks you're trying to de-risk on a subsystem or sub-component

Yeah. And it's all I completely agree. There's complex systems are difficult to debug.

Um, and they're almost, they almost follow like a diagnosis of exclusion,

Yes.

pathway where you, it's very easy to rule things out, but it's hard to get directly at what the core of the problem is 

And that's

you're, that's the main purpose. You would be doing testing in the first place, so you

Cut your legs off before you

can start running. So it's super important to be able to de-risk. And I do agree that most, the most common pitfall is the,  lack of planning that comes with that.



Yeah, no, thank you for bringing that up. I feel like I've been involved in so many programs where we're like, things are going wrong and we don't know why.

and and, I guess maybe the val, just, I'm just processing this now, but the value of proving out things at a subsystem level or in a more modular architecture is that you have preempted that diagnosis of exclusion.

What does work and what doesn't work before things are integrated. So your subset of root causes or you've trimmed, you've bounded the space of root causes in some sense. 

And it, it it helps with the failure mode analysis too. If you have all of those tests, you can add it to your failure mode analysis being like, this lip is too long and it might get caught in this other system, which could

cause the motor to fail,

say, and then when it happens, you're like, it's probably that lip.

Let's

make a little less, or get rid of it entirely. And then you do it again and it works or it still doesn't work, and you're like, okay what the hell? but yeah, it's I think that, that is a key component of all of the things that you mentioned. So I appreciate you, you bringing it up and talking through that.



You can eat so much time not knowing what's going on. 

Yeah. Oh, yeah. And, oh, everyone will have a different opinion and it's circular, circular conversations and it just, it

becomes a not fun time to have

I think this is fundamentally different about hardware as well too, versus software. And this is not my original thinking here. My buddy Jake actually talks about this. He frames software as being all about testing. Edge cases and like your failures are in like this, like tree of edge cases.

And then hardware is it's the core use case. That's where you see the failures, right?

true.

But the failure modes are opaque many times. Like we were, I was working on a boat it was a prototype boat years ago, and we were using, we were like hacking together. We were using a jet ski propulsion system

Drive this catamaran, and we were making some modifications to that jet ski propulsion system.

And there was this engine pod, and we were having cavitation at this inlet on this jet, and we couldn't figure out why the boat wouldn't go over, I don't know, whatever, 25 knots or something like that. And it took us like months to figure it out. Months. It was infuriating.

It's and I, in hindsight, I wish they'd be broken down that design problem into more.

Bite size chunks where we de-risk the performance of different elements. And there was this gigantic technical risk, which is, Hey, can we hack a jet ski into being the propulsion system on this prototype boat? Does that work or not? And we didn't do that first. We made the whole boat.

 It was a prototype. It was a one-off prototype. And, but still, I've made these mistakes way too many times.

Yeah it's quite common. And for like very well funded or big companies, this is not as big of an issue. It's not a life or death situation.

You're a nimble startup and you just raised a new fund and your investors are waiting for you to de deliver on

certain outputs That you promised through that this could truly be a company killer,

You haven't met your mark, you're probably gonna have to fundraise again.

And they're gonna come back with the question of, why didn't you do this? How can we trust you to actually deliver now?

So, Definitely super  📍 important. Okay. 

This podcast is presented to you by Pratik, a startup advising and coaching company that is geared to help hardware entrepreneurs get their ideas from a napkin sketch into a lab and out into the world. 

Podcast Break: Hardware hacks

With that, I wanna go into a quick podcast break where we do a segment on hardware hacks. So basically we're gonna take a take a quick break and share some fun or interesting hardware hacks that. Either listeners can try it home, or if they're building products, they can try it out or involve it in their product design cycle. Will, do you have any hardware hacks that you'd like to share with our listeners?

I think some of them are hacks and some of them are probably just frustrating advice. 

We,

we welcome both.

yeah, the first I'll lead with the frustrating advice if you're a mechanical engineer, you should learn how to code in MATLAB or Python. Python,

Just full stop. It's super powerful. I see a lot of people that like, forget the math.

The math is a hack. The math is the ultimate hack. It's like the thing that lets you represent the system without building it and see how it behaves. It's like insanely powerful and lots of engineers get outta school and they just put down linear algebra. They're like, woo, good thing I got through that  and I'll never have to use that again.

And then they get to a project where it's okay, there's a kinematic system they need to design. And it's okay you can do this with math. It's actually not that hard. I'm not good at Python, but I know it well enough to solve mechanical engineering issues and it looks like magic to people that don't know how to do that.

So number one, first PR, first principles and the math to back it up is the ultimate mechanical engineering hack. And if you lose that you've put away, you've just abandoned a gigantic portion of your toolkit as an engineer.

You're so right. First principles come back to the play every single time.

Yep. And it's just, and you don't really even, I hear people being like, I never use calculus. It's that's stupid, and it's of course you do. Like calculus is like the math of change. It's the language of change. And like every system is, many systems are dynamic.

And so whether or not you're like, you don't do I'm not like solving definite integrals as part of my project or whatever, right? That's silly. But even your mental models for how things should behave are based on calculus, right? Like motion, 

The entire intuition around how certain things behave when they're moving

is based on that.

position, velocity, acceleration, jerk, snap, crackle, pop.

Those are all time derivatives.

I love that. 

I want that to be, , a sweatshirt or something.

Um, 

Was the most poetic way to describe calculus. That was

oh, I think that's I think 

The math of change.

it's Steven str. That's language actually. I think he's I think he's like a mathematician out of, I don't remember where, Cornell or something.

Um, he has a really good book called, like the Joy of Calculus or something like that.

I love that.

That's, yeah, it's super powerful.

So that's my number one hardware hack. Don't forget the math. Let's see. All of that said CAD is an amazing calculator in a pinch,

you know, Especially for mechanism design. Maybe the humble CAD sketch

A nice hack a good place to prove out the motion of a dynamic system.

A really lightweight playground. I think brainstorming is a hack. I think there's lots and lots of manufacturing hacks, like in the shop. Little things that I like to do that are maybe just you develop your own style for prototyping. But I think people underestimate what you can do with simple tools in a shop and a printer.

So like a printer is actually an amazing tool. Printing a one-to-one scale drawing of something and then gluing it to a piece of metal and then cutting that on the bandsaw. And then, using it as a drill press template. 

Oh

yeah. 

can do a ton in the shop if you have some like super 77 glue and a really good printer.

And paper can wrap around objects too. So like I used to do composites work

And we would be cutting these tubes in different geometries and I would scale a print. Just slightly such that the thickness of the paper itself was considered when you were doing bending and then you wrap it around a composite form and then do some cuts based off of that template.

So I dunno, it's pretty easy to get caught up into, everything has to have a crazy tolerance in order to be a useful part.

I just think that's not true. If you just get into a shop and you learn how to use a bridge port and you can make like paper templates. There's really good resources for this too.

If you there's a YouTube channel with a guy named Paul Brody, who's like a bike frame builder, and he just has, he's just like a master sort of home shop fabricator. He has a Bridgeport Mill and he has a lathe and he has a welder but but realistically, like compared to manufacturing facilities with C N C machines and LAIs and all this stuff, it's not actually high tech.

It's like really old school.

Yeah.

As long as you know how to use it.

Yeah, exactly. Use a rotary table on your bill, and he makes beautiful parts and they're complicated. They're, he makes brake levers. These are like non-trivial geometries. And if you can just use your math and be creative and use a printer, make templates, figure out how to measure things appropriately, that's infinitely valuable.

I don't know. There's probably many more hardware hacks that I've used over the years, but those are the 

Paper. Paper is coming about as a pretty, pretty decent hack. I in, in a in an episode with Bridget. She also uses paper for wire routing,

Oh, cool.

I think it's I think it's a a thread that I'm picking up on.

Interesting.

Yeah, it's a, it's an, it's a unique interface for certain types of problems.

Definitely 

you can overlay. I guess just scale one to one, scale drawing is really valuable. Like for, especially for people that get lost. I get lost in CAD sometimes and I 

Totally. 

you forget how big the thing is,

right?

And there's always this maybe this is what it is, paper steps outside of the constraint space,

Placed on designers by the by tools,

Right? So if you look at and you see this as particularly in automotive, right? Like the tools used to design a car

Had a heavy impact on the shape of the car.

So like you look at like a Jaguar in the 1930s and it's beautiful. It's like super swoopy and there's not a flat surface on it. It's all compound curves and it's made by these like master tool and dye guys, right? They're not in cad, they're like making wooden forms or whatever to like match sheet metal parts too.

And then you see CAD come in and everything becomes a box,

right? It's like we design in CAD now, okay, flat surfaces, planes, we can establish those pretty easy. Compound curves are really hard. So you get I mean I think you still get equally rad designs you, but you get things that look like a Volkswagen Chico or like an Audi Quattro.

They're awesome, but they're like angular.

Uh, and then you get like this proliferation of capability in CAD tools that lets you do sweeps and surface modeling grows and you get things like people who get obsessed with making curves because the tool makes it. Easy for them to do that. And you end up with horrible designs like a 1996 Ford Taurus.

It looks like a frog. It's all bubbly and it's all stupid. And then, and paper just has this ability to just step outside of that constraint space and be like, okay, you're just drawing. You can draw whatever.

So maybe it's uniquely valuable because it sidesteps that.

I, I love that perspective. I agree that I, I had never thought about it that way. Very

I think also  other, hi. Other hardware hacks are coming to me here as we're talking. 

It.

The water jet machine is maybe like my favorite, one of my favorite processes early in prototyping.

Um,

underdog of the machine shop.

Yeah, it just it just, it's insane. It it cuts everything and you don't really need to worry about it.

And it's super cheap and there's no setup cost basically. There's no tooling required. And if you design for, maybe the hack here is like designing for 2D processes only early on and being really creative with that. So if you're making a weldment or something like that, doing like tab and slot fixturing so that you can take like a bunch of 2D components and very quickly index them, self fixture them relative to each other and then tack weld it or whatever.

So the water genesis, that's like infinitely flexible prototyping tool. You can make flexures, you can make all kinds of different components  

 very cool. Okay. Uh,

so to move away from the segment and into a little bit more discussion. So I wanted to get your thoughts, and I'm sure that you get asked this quite a bit around the future of  design and management and progress management and how potentially AI can

influence the way We design in the future.

And how it'll get integrated cuz it's the new hype train right

Yeah, totally.

and then you have Elon Musk and others writing letters to say,

Yeah. Pause.

of this.

it's it's scary. So yeah, I'd love to get your thoughts on that.

I think we need to get the basics, at least as engineers in our particular field, we somehow have managed to not get the basics right first.

Um, so that's fundamental to me and that's really why Five Flute exists is we wanna make it easy to have a rich visual conversation about things that are hard to describe with words.

I see lots of people like writing Jira tickets that describe a hardware issue and it's move the bo, move the. Produce the length of the M three bolt so it doesn't clip the flange. And it's like, where, what are you talking about? Yeah, which flange which bolt, huh? And so that's the reason why we wanna bake this capability into CAD so everyone can see what you're talking about and you have a way to reference the design.

I think that's foundational  but I think the release process, like I'm a little bit torn. Like I hear people espousing agile for hardware and I'm a little bit, I think maybe you're one of these voices too, actually. So like you probably have a good perspective on this, but I think certain hardware development fundamentally is not software development.

The value of discovery in hardware is not the same as it is in software.

And so going whole hog, like full agile feels a little bit. Too much for me. I think there's, the, fundamentally, the way I see it is you wanna re, you wanna reduce the cost and complexity of iterating,

Right? That's the lens that I see it on.

And Five Fleet is built to help teams do that in a variety of like super practical ways. Primarily involving just communication about

common engineering issues and design reviews. So I think there's still tons of headroom to get that right? Give engineers better tools to iterate faster.

 There are many other problems. There's a lot of ac, a common iterative cycle is like conceived, design, build, test, deliver in some sense, right? And so it's not all just issue tracking, right? You have to make things, you have to design things. And so there's improvement probably at every phase.

I think AI is going to play some role. In all of those phases, it's hard to know what the most valuable part is. For us, like I would love to get to a place where, we can provide some level of intelligence in checking people's designs, right? If right now we have drawing review software and that's people manually reviewing each other's work, but like aspirationally it doesn't have to be that way in the future, right?

I think there's much more low hanging fruit in terms of just basic coordination, reducing coordination, communication cost that we're working on today.

So that, like auto checking and drawing doesn't feel like the highest value thing. When people are still like writing Adobe comments and emailing them different versions of the drawing back and forth, it's okay, maybe we should solve that first, right?

So that's what we're doing. But yeah, AI is the new hotness, I think. Where I see it, I think some people think that AI is already happening deeply in, in mechanical engineering. They conflate topology optimization on the design side with ai.

It's not really, it's not ai.

And so the, and I see AI working very well. Like obviously you see large lang language models like G B T four or whatever and they're super promising and people are using them for marketing and copywriting and all kinds of stuff, practical stuff today. And then you see things on the artistic side like the stable diffusions in the dollies of the world.

And they're incredible. But they're not, what I haven't seen is something that suits engineering deeply in terms of design. Ca CAD is a parametric space,

Yep.

 Is it is, generating an image

Is a different problem than generating a CAD file.

Yeah.

And I'm sure some of the major CAD companies have looked into this,

Probably non-trivial training data problems,

In order to get that work.

And also IP

issues, 

Get there's IP issues up and down all over the place for all of us, right? I 

it's, I feel like for 3D models though, it's a little bit more niche and it's more protected because it's niche under

Uh, but maybe that's a naive comment.

What's the difference between a designer, a mechanical designer gaining inspiration about a mechanism and an artist gaining inspiration about a piece? You might see some contemporaries painting in a particular way, and then you you develop your own style. Musicians all nothing is new,

right?

Sense, nothing is new, right? So people are these algorithms are doing something that rhymes with human creativity,

In a way. But it's, what's troubling is when they can output things that are more akin to blatant ripoffs than inspired design.

And they're so opaque that it's difficult to prevent that in a lot of circumstances.

If I was, a big famous artist, I would be pretty bummed if some algorithm ingested all of my work.

Uh, now I hold that feeling simultaneously also while being like, holy crap, look at what you can do with these incredibly capable tools. Look at how much knowledge is embodied in them.

and so that's a super tough one 

can't have a kind of, mono opinion about it.

yeah.

it con constantly a pull and push of just what is right? This is cool, but it's scary

and unfair, but. Super innovative and can truly change the way that humanity progresses And

Yeah. Now all of that said, I think there maybe is some low hanging fruit. I think we've talked about this in the past, but like the amount of ti, CAD is a very capable tool, but the amount of time to realize an idea is pretty long in cad, particularly for complicated parts. And that's not necessarily super fun work.

Um, like that's not, when I think about like the joy of mechanical engineering, I'm not, it's not Making sure the sweep functionality works in solid works. And like I have the correct 3D guide path sketch. It's ugh, gag me with a spoon. That's awful. Like I just want the part to be, the fun is like the thing is in your hand and you're putting it together, right?

Like you go from the conception to like the engineering work to make it work, the math, the analysis, and then like you do a design. And in some sense the CAD work can be fun up to a point.

So, I think it was an, was it an Nvidia team that put out a tool that like would let you go text to point cloud model?

Oh, I'm unsure,

but 

think,

yeah, I think this exists. I think you can describe I want a green tree frog with extra big toes and it would like make an s STL file for you. Now that's cool, but like how good is an STL to a mechanical engineer?

Not great, right? What You need to know exactly what size it is.

You need to be able to modify the design. Maybe there's a pathway there where somebody figures out a translation from sort of raw STLs or point clouds or OBJs or some, yeah. Some non-parametric format to something that becomes parameterized where you can have a model tree or a structure to actually,

like it is closer than we think. Honestly.

I don't know, it's, that strikes me as a different problem than these large language models. And I'm not sure how many people are actually working on it and who's incentivized to work on it. So in some sense, the dynamics of the CAD market change this a little bit.

It's not Text is so universal. It's if you're a copywriter, if you're a marketer, if you're like a blogger, right? Like a largest language model becomes useful to you immediately.

Uh, I mean it's a also, it's a search engine in some sense, right? It's an embodiment of human knowledge. So it, so the user base is whatever, like everybody, right?

But the amount of people that like deal with 3D files on their day-to-day basis is just like a vastly reduced subset of those people.

So, I, that said, I have talked to some up and coming entrepreneurs that are looking at the sort of auto complete for CAD

I think is really cool.

 Like many parts are not particularly difficult to describe.

And so text to a model strikes me as a reasonable next step.

Like I want a 90 degree angle bracket with four hole, four quarter inch holes drilled on each side 

Specifically standard hardware.

That's a good point. Yeah.

Yep. I think that's coming soon-ish. All that said I don't know who's doing it, do you?

I don't know about auto complete. I know that Xometry like for quoting purposes, I think will be employing some AI tools to generate what,

how a thing would be made.

So it's It's tangentially related, not quite what we, we are talking about.

I think a lot of these developments are in stealth right now, just because I think there's an apprehension because the hype train is getting very very hyped and it's

this kind of  growing industry that people

don't know how to deal with and ethically regulate



So it, it's a tough space to I feel like there's a good amount of risk right now. But I feel like in terms of AI implementing itself into the process of modern hardware development, it could be a tool to really speed it up,

uh, rather than be a replacement or I think it will augment on top of it

Yeah. I don't see a direct path to it being the designer in the way that you would see for something like stable diffusion. But I do see a direct path to analysis type work and programming work, obviously. I use Python and like I've used Simulink and other tools in the past simulation tools, and realistically, like lots of times what you want is not that hard.

You wanna give me a model of a. Spring mass damper system with a subcritical damping coefficient. Or gimme a model, gimme a quarter car model for a vehicle. And these things are modular, like they're not that hard. So they've been done before. 

Out

there, and it, if someone's doing it for the first time, it's a long process for them to potentially get there. If

they, Just describe it and get it, that's a huge

win, I think. 

Yeah. And then tweak it, right? You still need to know how to, how these things work. You can tweak the model. But I would love to see that. I think there's probably also a room for a kind of like a d linter for CAD or something that auto checks your cad. But again, you need a CAD data set.

And getting a CAD data set is getting a u sorry, getting a big CAD dataset is not harsh. Like we could scrape McMaster.

Yeah,

But getting a useful CAD data set might be hard. I don't know. I haven't thought deeply enough about it.

Yeah. Like maybe grab cad and just like download that entire library.

yeah. But part of it is like,

it's noise.

There's the signal to noise ratio is tough.

there's a billion different ways to design a bracket in a ton of different processes. So what's a useful 

And  like that layer of what is the application of this

even What are the environmental conditions that it's working against?

What are the force profile? It's working.

There's so much to it. So I really appreciated your on all of this will and in terms of, I always I tried to ask my speakers at the end of just, do you have any advice for,  hardware builders, hardware entrepreneurs, people who are trying to build a physical product? Just any advice that you'd give as parting words.

man. I think the first thing I'd like to give advice on is maybe not to the builders, like building something novel, but to individual engineers, like early in their career or even mid-career. I think that one thing that's really helped me is almost being. Like deviously selfish in a way where if you see a problem that you want to tackle and you want to use that problem as an opportunity to stretch your legs, figure out how to do that.

And so this works really well when you have a good project manager. But like I wanted to learn Python and I was horrible at it, right? And so I think I was learning it on a particular project and I was like, oh, I found a juicy problem that I wanted to solve in Python. And I knew I could have done it in a day, in a spreadsheet basically.

And instead I think I talked to the PM on that project at the time and I was like, listen, like I'm learning Python. I want to try this. Can you gimme some like extra leeway and some space here

To try to solve it with this new tool? And I think if you can do that on every project you're ever involved in through your entire career, you, it's this growth mindset, right?

So you get 3% increase in capability like every quarter or whatever, and then seven years later you have all these engineering superpowers and it's totally rad. That's just an approach that I would advise younger engineers to take. And it doesn't necessarily have to be devious. You can ask for permission, but sometimes maybe don't ask for permission, just solve it how you wanna solve it, so that leads to growth and leads to excitement. And it's such a big field and if you do that, it stays interesting. It stays fun, it stays beautiful. So I would say that's, Honestly, that's what I care about the most is 

Yeah, 

helping. Yeah. It's just helping engineers. This is the reason I do all the writing.

This is like

the The brand of Five Flute is about educating engineers, right? Like our product is not just our software. Our product is our engineering guide. It's our online calculators. It's our perspective about how things should be done. It's these conversations with people like you.

And so that's maybe the thing that I care the most about.

Like I think we should, I would love to have another episode with you at some point where we talk about engineering education and depth. Cause I think there's so much room for 

I would love to do that because it's it come. So even though this is geared towards builders and it is geared towards engineers as well, it's also geared to entrepreneurs that are,

Building companies alongside their product. It's a different problem set.

And when building a company, I think providing, knowing that your engineers are your greatest asset and providing them space and time and resources to build on their capabilities

alongside Building your product is very critical.

And I think coming out of that, like I would give the advice to entrepreneurs and co-founders who are hiring engineers, whether they're mid-career, whether they're early career, the learning never ends.

If you're a mid-career engineer and you feel like, oh crap, like I haven't done that in the past decade, it's never too late to start.

Yeah. Yeah.

There's just one more thing too, which is like a, I guess a flip side of this coin. Having been a peer engineer for a lot of my career and now being an entrepreneur and being a founder I just have profound respect for people that build new things, build companies.

It's incredibly hard. It's super rewarding. The highs are extremely high, the lows are extremely low.

, and I think engineers would, engineers sometimes like to be the smartest person in the room,

They sometimes lack empathy for the ways in which other people's work can be extremely difficult too.

I

Yep.

I'm a pretty good mechanical engineer. I can do quite a lot. I feel very comfortable in that space. And then marketing for me has been a big learning curve. Super steep learning curve and hardened like very, like weird and opaque ways, and so as a founder, I have all these new jobs that are are really challenging and they're challenging in totally different ways than typical engineering problems are challenging.

And so I think empathy across

disciplines Is always a plus.

I really love that. That's, it's it is so true. And being able to understand that beyond the scope of your work, there's a lot of pieces and puzzle pieces that are moving around, that are trying to make the very complex technological thing that an engineer is working for

actually have a purpose and

Trying to bring something to life. It's not just making it right. It's like,

it, if it doesn't make it in the world and people aren't using it, or it's not generating something for people to use,

then it, it just goes to waste. So,

It's making change in the world, and that's, engineering is one small subset set of that, marketing 

It's important, 

having a viable 

of components. 

Yep. 

Definitely. And that's what we're trying to cover here at the Builder Circle. It's,

uh, like hardware products and all the pieces of the puzzle that lead up to that existing in the world.

Thank you so much, will, this was a

wonderful conversation and 

Thank you.

It's been a pleasure to have you.

No, thank you so much for having me. It's been really awesome. 



All right. You've made it to the too long. Didn't listen, T L D L section of this episode. So I'll just   be reading down a list of the key takeaways that I was able to extract from this episode. It was very content heavy and there was a lot of really good chunks related to product design. So hopefully these will be really helpful when you are embarking on your product design journey. 

 There are  two extremes when it comes to, , engineering design requirements, most, Most people either over, over constrained or under constrained there, 

Design space. And the right answer is likely in between. So you should know your use cases and generate a PRD, which is a product requirements document without a lot of prescribed numbers, you should, and you should start with a core subset of non-negotiable or known values to reflect the strong hypothesis of. 

 What people are working on. So you likely have a product that you feel is important. And there are certain parts of the product that are known, whether its dimensions or like what temperature it needs to operate in, or who needs to use it and what capacity. So there will be known values that you should definitely put down and categorize is non-negotiable and then you'll have a lot of other things that you will need to figure out throughout the design and iteration process. 

So writing all of those down will be important. And then,  most importantly, don't put away your requirements after you write them down and keep updating. As you learn more, it should be a living document. And as you learn, as you test as a prototype, you should always come back to it and reevaluate the values that you put in, or the statements that you made. 

 User studies have a,  a pretty bad signal to noise ratio, meaning that you get a lot of feedback that is not useful. So it's really important to have your. Company priorities and focus and mission pretty set so that you can parse through the data and utilize the ones that are the most important and will really contribute to. 

What. We'll make your product the most successful. Best research is what your customers do with your product. So basically,  when you're doing user studies, providing your customer with the product and not leading the witness. So not leading. 

 Not giving them any information, but basically telling them this is the problem that you have. This is supposed to solve it, go and use it. And then that itself will generate a lot of really useful data of what people struggle with, which, what part they thought was which, and so on and so forth. 

So watch how they interact with it. And then,  When it comes to DFX, it's an important consideration when going through your product design process, however, it should act more as a metric and filter rather than, being in the driver's seat. And obviously this is product dependent. If the product is obviously an improvement that centers around a DFX. 

 Problem, then the approach would differ. , but in general, that's not the case. So starting the design process without a lot of requirements and with an open terrain and open brainstorm can really help generate a lot of ideas.  I mentioned this in the episode, but basically I've had moments where someone really came up with a horrible idea, but it triggered someone else to come up with a really, really good at one. So it's really important to not stifle the team early on. 

And even the bad ones can lead to someone else thinking about a winner.  Utilize Pugh charts. When thinking about metrics you care about in your design process, also try to combine a risk matrix to ensure that you're aware of lower-level risks you're taking. When you select that one design over the other. 

Pugh charts are very valuable. They're very commonly used in the design decision-making  so highly recommend utilizing those when. And trying to make a design decisions that require a lot of thought and a lot of priorities that are going around. If you are trying to learn about  how your design will perform in terms of manufacturability. 

 Go to your crystal ball and predict what different manufacturing techniques could be used when scaling to higher volumes and be inquisitive around those manufacturing techniques. Ask experts and techs on how the current design won't work. So this is basically saying if you have a design and you want to scale it up and you know that you're going to scale it one day, thinking through what kinds of manufacturing.  Techniques could be used to actually scale it and then say, okay, say you're going to,  have to. 

Die cast it.  Learn about die-casting learn about the design considerations around that. Is it even able to be die-casting so on and so forth and be inquisitive so that you learn your constraints? You learn the constraints that your design is causing early on so that you can potentially make changes. 

Or at least know what you're getting into.  When it comes to repairability,  Have your engineers and even your co-founder.  Build and repair the product. As a co-founder you should definitely one go through a cycle of producing whatever you're making by yourself. And if you don't have the skillset, do it with an engineer next to you so that you know what goes into it. And then secondly, if it's, , repel ability. 

 Build it, break it, repair it, and, see how the process goes and how much headache.  You, you get as earliest as possible. , 

When designing  develop a map of what manufacturing processes for each component,  will require. And then what assembly will look like. This will be really eyeopening into what you may need to change. So never throw your design to an OEM or a contract manufacturer before doing this, because you will lose that battle in the end because you should be the expert in your product and you should at least have an idea of. 

What the manufacturing processes. Should look like, and even you should have an in-house process that, you know, very well and all of the, , time it takes for each process too, because those will all be negotiation, tokens that you can use with the OEM or the contract manufacturer. If you choose to outsource later on. 

 Big value in design is to reduce the number of parts and OEMs. Won't be able to make that decision on, they won't be able to make that decision correctly. And sometimes they might not be incentivized to because the more your park costs,  often,  it's better for them. Sometimes they make a better margin. 

, but overall. It's important to know what trade-offs are making. , the most common mistake is to kick key risks down the line, but it should be front, front and loaded. So don't start building until you have de-risked components. Otherwise you'll risk coupling those.  And what that means is if you have component level risks that you haven't de-risk earlier on in your program, and then you go on assemble and have an integrated system, you're going to go on test that, and what's going to happen is it could break and it could fail, which is very normal because you're taking on a lot of risks. 

But the problem is you won't be able to do root cause analysis on it because you don't know which component broke or which of the failure modes actually happen. So it's important to be able to decouple them and systematically de-risk. Early on. 

Technology development and product development are two very different things and technology development needs to happen before requirement development. So that's basically like if there are any fundamental research questions that need to be answered around the product that you're developing, that goes into technology development and even capability development, and those need to happen before you start generating product requirements. 

So that you are attacking the product design in a systematic way. Always have intentions with your prototyping. It can be for de-risking seeing the fit, observing user experience, et cetera, but all of your prototypes should have a reason of existing. When figuring out your milestones and leading product programs, always optimize for design flexibility, because as you learn more, more changes will have to come naturally

and you will need space to be able to do that. So it's important.  This one's really simple, but think slow act fast. , I really like that. That's really good way to go about,  creating an, a product. Uh, if you're a mechanical engineer, learn MATLAB or Python and use it to speed up and perfect your first pass at design. 

So starting from first principles, such as free body diagrams, a simple structural fat finger calculation, et cetera. These could be made much faster and better, , using code. , .  I just really like this quote from the episode that I'll just read quote here, the value of discovery and hardware is not the same as it is in software. 

 I'll just leave you with that to ponder. And then last two pieces are AI, could slot itself into design review cycles to help judge the design from different angles and parameters set by the team. That was an interesting insight into,  When we were talking about how the future of modern hardware development will look like. 

And then as an engineer scout out opportunities to set yourself up for learning.   📍 We'll give this example of solving a problem using Python instead of a spreadsheet, even though he knew that a spreadsheet would have taken him a day where Python took him a few weeks, , and this is something that. 

He recommended that most engineers do so that they always.  Have continuous improvement. Well with that, I will wrap up the too long didn't listen. I hope those key takeaways will help you when when you're attacking your product design.  

The opinions and information shared on this podcast are for informational purposes only. We always recommend that you seek professional advice before taking any action related to your business or personal ventures.

 Thank you for listening, and I hope that you enjoyed the episode