Designing in the Wild: The Industrial Design Podcast
Designing in the Wild is the podcast where industrial designers, inventors, and changemakers reveal how they turn messy, real-world constraints into market-ready solutions. Each episode unpacks the mindsets, methods, and aha-moments behind sustainable innovation—whether it’s re-thinking plastics, hacking circular supply chains, or simply sketching faster under pressure. If you’re passionate about design’s role in a resilient future (and can’t resist a good behind-the-scenes story), this is your campfire.
“Real-world design stories for a world that needs better ones.”
Designing in the Wild: The Industrial Design Podcast
#009 - Unleashing Creativity Through User-Driven Storytelling - Sam Feller - Human-Centered Engineering, Team Management, Tracking Deliverables, Tactics for Problem Solving
Engineers are smart people. They're doing those technical things for a reason, but they haven't communicated necessarily why. If you talk to them, you can start to peel back what they had in mind and what the benefit was from it. Then you can start shifting the team to looking at user stories and becoming more user-focused and value-focused.
SPEAKER_03:What is up? Rob Irwin here with Designing in the Wild. I'm your host, as always, and we are back with another episode. I am super excited for our guest today, Sam Feller. He is a mechanical engineer and has risen the ranks all the way up through Amazon and beyond. Right now, he is working with Tulip Interfaces, and we'll get into a little bit about that later. So, Sam, welcome to the show. Appreciate your time. to chat with us.
SPEAKER_01:Hey, dude. I'm very excited to be here. I've been looking forward to this all week.
SPEAKER_03:Awesome. Awesome. Well, me too. Me too. So, okay. So you're a mechanical engineer. You've dabbled in web development, electrical engineering, embedded C, a little graphic design. Sounds like you've got some current passions right now around systems design. And of course, we'll get into that. Did I miss anything? No.
SPEAKER_01:Uh, maybe some marketing, general entrepreneurship, uh, bad industrial designer. Uh, yeah. I
SPEAKER_03:mean, just kidding.
SPEAKER_01:Mechanical. Yeah, it's true. Mechanical engineer by schooling, but I've done a lot since then. So.
SPEAKER_03:Yeah, yeah, absolutely.
SPEAKER_01:There's still an engineer on the inside. If you peel back the layers of the onion, there's an engineer on the inside. I love it.
SPEAKER_03:So, okay, so let's peel back those layers for a minute, Sam. Can you take us back for a minute, drop us a bio on you and a brief background?
SPEAKER_01:Yeah, and let's come back to this, but I want to tell you about the time that the engineer inside of me, I don't want to say died, but when I realized I wasn't an engineer anymore, but we'll get back to that.
SPEAKER_03:Excellent. I love it.
SPEAKER_01:Yeah, so I started off at MIT Lincoln Laboratory doing aerospace defense stuff. And I was there for several years. I went to private industry doing consulting, mechanical work. And the consulting was a weird experience because I was being paid full time. And I wasn't responsible for pulling clients in. But I was billing to overhead for 85% of my time over three years. It was just totally bizarre. And I used all that time to just dabble. And I just got into all sorts of stuff. So that led to the electrical work, PCB work. I launched some Kickstarters. I don't know, a whole host of stuff. And I was around a lot of smart people and tried to pick their brains and learn from them. And so eventually I ended up getting into some entrepreneurship and launching a company that made solar-powered cell phone charging kiosks. And when you do that, you end up doing a little bit of everything when you start a company. And so that was kind of a growth opportunity, led a small team, and the company went under, which is okay. It happens. And I freelanced for a while, and I ended up at Amazon as a mechanical engineer. And as you know, our group was very, very quickly growing, and I did very little mechanical work. I did mostly electrical work, and then I grew into systems work, and then I became a program manager as our team grew. I think we quadrupled in size. And from there, I went to Alexa, where I was a program manager for a software team. And then I left Amazon to start another venture, which very, very quickly failed, which is okay. I learned from the experience. And now I'm a product manager at Tulip. So that's my career arc in like three minutes there.
UNKNOWN:Yeah.
SPEAKER_03:I love it. It's quite the span, I must say. Can we dive in just for a minute on the Kickstarter? I'm curious to hear about your experience on that project. By the way, you didn't mention Awkward Engineer, I don't think. Did this have anything to do with the beginning of that as
SPEAKER_01:well? That was through Awkward Engineer. It wasn't the first Awkward Engineer product, but it was my most successful Kickstarter. I also had a kickstarter for a product called the cookie dunk cup and people called it someone on the internet called it the first worldist of first world solutions that sometimes you're drinking a glass of milk and then you drink some of the milk out of it and then it's hard to reach to the bottom to to dunk the cookie and it's terribly difficult it's painful yeah so i i launched a kickstarter for it and the the kickstarter failed uh But as a result of the campaign, someone had this, he called it like the dunker spoon. It was like this wand that fit inside the groove of the Oreo. And you could lower your Oreo into your glass of milk, like completely submerge it without getting your fingers wet. And he wanted to like expand his cookie dunking empire. And so he licensed the rights to the cookie dunk cup for me. And I think you can still buy it. I think it's called the dunker cup. Like D-U-N-K-R. The
SPEAKER_03:dynamic duo product package.
SPEAKER_01:Yeah. So that was the first Kickstarter. And I don't know, it... I think I raised like$7,000 out of a much larger goal than I needed to pay for injection molded tooling. And I think a lot of that came from my family. And I was like, mom will donate to my Kickstarter campaign. Like, okay, that's
SPEAKER_03:good.
SPEAKER_01:You
SPEAKER_03:branch out to the friends and family in the ring one of the many rings of your friendship and community.
SPEAKER_01:Yeah. But I had... I'd started awkwardengineer.com to pursue some product ideas. And I think my first one was called the Panic Button Light Switch Kit. And I just thought it was fun pressing big red e-stop buttons. And I ended up selling a whole bunch to thinkgeek.com, which was awesome.
SPEAKER_04:Oh,
SPEAKER_01:really? Yeah. Yeah. And... ThinkGeek is entirely online so the packaging was just this like simple like brown craft paper box like there's nothing special but then I was like why not try retail and so I got into like retail package design and I sold like I got like test runs in like Urban Outfitters and a couple other places which was like cool to walk into a store and see my stuff like on the wall but it didn't really
SPEAKER_03:so how did you well that's crazy you got that's some insane exposure by the way for to get uh you know shelving space at an urban outfitters can how like okay so now i'm thinking like i'm maybe a listener or something and i'm a product designer and i want to get this thing on a urban outfitters shelf how the heck did you go about that was it just like serendipitous interactions or networking
SPEAKER_01:it was it was it was cult calling product buyers it was ah it was it was brutal uh
SPEAKER_03:okay
SPEAKER_01:Yeah, I don't think that's a normal industry trend. But that was one of the fun things about ThinkGeek was that they were so different than other places and they were a younger, much faster company. And so I got a hold of a product buyer and I was like, here's this thing. And he was like, well, there's a story about an independent entrepreneurial designer who made this on their own. Packaging is done in the U.S., doing as much in the U.S. as possible. And for whatever reason that like caught his eye and he sold it. And I was like, okay, this is awesome. Uh, but I don't know. I don't think that's a typical channel. I think people often go through like trade shows and then the licensing industry around toys is a whole nother thing. And then I actually met a guy who did really well, uh, He stopped doing individual products, and he would come with full planograms. He'd be like, this is the section of the aisle in the store, and here's the full product line. And he would design things that way, and he was really successful with it.
SPEAKER_03:Interesting. Yeah.
UNKNOWN:Yeah.
SPEAKER_03:Fitting it into the whole planogram thing creates not only thematic elements, but you can position things in certain ways that make them pop a little more, I guess.
SPEAKER_01:Individual products can be hit or miss, but When he was looking at market needs and market trends, and he was designing full planogram sections that would address a full market segment, maybe within that planogram layout, individual products would do well or not so well, but overall, it was successful. It worked out very well for him. I think he had a licensing model where he would essentially pitch these companies, and he was like, I'll develop the whole thing turnkey. I just want like a 2% royalty for life and enough 2% royalties for life. Like they add up over a 20 year career and he did really well.
SPEAKER_03:For sure.
SPEAKER_01:But I think he did a bunch of work for... I think he did a bunch of work for Fiskars, like doing cutting stuff. Or maybe he was a competitor to Fiskars. I'm not sure. And then he did a bunch of things that you might have seen at like Jo-Ann Fabrics, like little craft things for kids, stuff like that.
SPEAKER_03:Got it. So when... When we were at Amazon, you came in as a mechanical engineer and quickly rose the ranks. I know we had a lot of need for a lot of people all at once, and I think we wore a lot of hats and jumped, you said, on the electrical engineering train for a bit, and then rose
SPEAKER_01:to... Do we tell the audience? Yeah, sure.
SPEAKER_03:of all the spaces where we worked, the building, because it created a really serendipitous interactivity between us to kind of help us move fast, think big together.
SPEAKER_01:Was that your
SPEAKER_03:take, too?
SPEAKER_01:Yeah. I mean, it was nice being able to, like, see everybody there. Like, we had no cube walls. You could literally see across the room.
SPEAKER_03:Yep. Yeah. Yeah, and no one to come, you know, jump over and pop over and say hi or bother you or... drop you with some weird question or something. And no, it was good. And so you went through and you got the senior TPM status. And I think this is where, from where I'm sitting, and correct me if I'm wrong, you really started thinking about the nuances of product development across the team. And you were developing kind of some I don't know if the planograms, but developing a schedule and timeline. Can you elaborate on kind of that process that you
SPEAKER_01:started to work on? Yeah, I can talk a bit about that. I think I had some things that sort of clicked for me towards the end of the experience. Like when I started, there were 15 people in the group and there were only five mechanical engineers. And by the time I left, like maybe a year and a half later, I think we were at, 30 plus on the hardware half. So between mechanical, electrical, firmware, optics, industrial design, God, did I forget any engineering disciplines that were connected to hardware? I think there were like 30 plus people. I'd driven products to the finish line before. I don't know if you call it instincts or nose for the goal line, but it took me a little while to figure out how to leverage some of those skills and build things and design systems for larger groups of people to work. I think what i settled on was as as fast as we were moving it was impossible to plan like individual little tasks but you still needed to coordinate across people and and get things done and i guess what i'd been taught earlier in my career and hadn't like really learned how to like click and leverage across those larger groups is is an expression is how late do you want to find out that you're late like you're You're looking for usually binary, inarguable physical things that say it's done or it's not. People love saying, what percentage complete are you? And I find that's relatively useless. You're looking for end deliverables. And so I ended up asking, what do I get and when do I get it? And it gets you a clear answer. And so what you might need... is like a physical... Say you have a physical module and the module has a PCB inside it and it's got a wire harnessing and all sorts of stuff like that. Then you say like... Are we on track to have the module? And this is where you need to start talking about deliverables and things. The thing is, I need a demonstration of the module that it works on this date. I need you to power it on, light it up, show me that the inputs go in and out on this date. Are we going to have that? And then people say, no, we're not going to have that. And then you start saying why. And so you can kind of peel back the... I love product breakdown structures. What are the components of the thing? Because when you start looking for things and deliverables, you start getting to those inarguable binary, it's done or not. And so if you have housings as part of that module, then you can start saying, when is the 3D print file, when is the CAD file released to the vendor? It's either released to the vendor or it's not released to the vendor. And so starting to look for those things as part of my practice. And it was never taught to me formally at school, and I picked it up along the way. I never took the formal training for the project manager certification. Think of the name. Project management professional, PMP. But I did read... uh like some class material and books and prep classes for it and the the The Program Management Body of Knowledge, or the PMBOK, which is, I do not recommend that book at all. It's a good bedtime
SPEAKER_03:book, right? Puts you right to sleep.
SPEAKER_01:Yeah. I don't know. It doesn't talk about getting people to work in that way or that practice.
SPEAKER_03:So are you bringing up, correct me if I'm wrong here, so I know you were starting to get big into scrum work and scrum teams and scrum... kind of cycles. Can you talk a little bit about that?
SPEAKER_01:Yeah. So after I was a program manager at... Well, actually, the firmware team at Amazon Go with you, we implemented a Scrum process. And it was really cool watching us transition from technical tasks. And then one day... I'll think of his name... Ryan, it doesn't matter what his name is, but he was like, I want to write stories for users. Like I want to know why I'm writing code. And so then we started talking about like things we were doing with the circuit board and different end users of the circuit board. And we talked about like the manufacturing engineer, Joe, and this poor guy had to like flash the circuit board with a test program, go through all the tests. And then he had to flash all the circuit boards again with like the final program that was actually going to run on the PCB when it was installed at the device and we're like why why do we need to do that that should be one one program that happens to have a test mode and so then we'd start writing then we'd start writing stories that said like as a manufacturing engineer i want like one image to install so i don't have to shoot myself in the head because it's not like you're doing one of
SPEAKER_03:these right it's like yeah it's going to be a very repetitive task over and over
SPEAKER_01:yeah And so, I mean, that firmware team, I think engineers, when you let them run free, just tend to focus on the technical problems right in front of them. And they're not wrong for focusing on the technical problems. And often, like, engineers are smart people. Like, they're doing those technical things for a reason, but they haven't communicated necessarily why. And if you talk to them, you can start to peel back, like, what they had in mind and what the benefit was from it. And then you can start shifting the team to looking at user stories and becoming more user-focused and value-focused. So I absolutely saw the same thing at Alexa when I worked on software teams over there. And it was definitely tough because they were back-end teams. back-end developers, like very little front-end programming there. And it's easy to write stories when you say, like, as a user, I want to be able to click a button to do, I don't know, buy tickets. Like, that's very feature-focused. And we started to look. I really love user story mapping.
SPEAKER_03:Yes.
SPEAKER_01:And mapping out, like, the user journey.
UNKNOWN:Absolutely.
SPEAKER_01:Yeah, mapping out the journey, like from one, you know, when a user first begins with the product to like achieving the goal or the outcome that they want. And with a lot of the backend software systems, you could start looking at your backend service as this pipeline of like messages or things that come in and then get transformed into whatever else you need. And then learn to start writing user stories that would say things like when situation need this outcome so that you can or need this feature so you can achieve this outcome and what's cool is that works for like super technical back end user stories so like when I receive an ACH wire transfer like that comes in over Ethernet and I'm just making up stuff now to try and keep it non-technical but when I get this when I get this message then I need to use this encoding scheme to maintain security. And it's hard to find a good user story that says, as a back-end computer system, they're not. But when you start writing stories like, when in this situation, I want this to happen. And so I I'm now at Tulip and started working with the engineering teams there. Real quick, Sam, sorry
SPEAKER_03:to interrupt. What you're saying is you're essentially drafting up a user benefit statement, a value proposition on the storytelling aspect of the backend technical stuff. I think that's awesome. Totally rad.
SPEAKER_01:It works. It works. What's awesome is that usually you can end up with a story that's readable in plain English, which helps me as a product manager. I'm product managing. At Alexa, I was a program manager for 30 engineers. It's just so much technical detail. There's no way I can be that deep on that many things. Death by documentation. But when you put it in plain English, it makes it way easier for me to come up to speed quickly, help bring context, have a reasonable discussion about it, talk about how we're achieving value and why we're doing things. And so, yeah, I lost my steam there. But I think I was saying I got to Tulip. Because we
SPEAKER_03:started out talking about Scrum work, and then we started to dive into the user journey there.
SPEAKER_01:So Tulip... engineering-heavy culture. A lot of MIT engineers who were there very early on. Similar situation where you see a lot of very engineering-heavy stories that are very task or activity or technically focused. It takes some training and teaching and coaching, but I'm now shaping up these teams to focus on user value, and it's awesome. What I love is I've seen engineers unleash their creativity because we had a different discussion about context. An example problem, I remember... I was helping an engineer refine a story, and he had this super technical task about multiple runtime environments conflicting with each other when running on this Linux device, and it was super confusing. And in plain English, what happens is that there are different systems that could potentially conflict with each other. So when a new user... is booting up the system for the first time and setting it up for their use case, we need a way to guide them to choose the right runtimes. I hope that was pretty plain English and you followed me there. And so the engineers shifted from trying to figure out how to de-conflict these multiple runtimes, which is insanely complicated technical solution, to realizing that they could solve the problem with just a guided splash screen that would say, hey, if you're trying to make machine measurements, click this button. And if you're trying to record operator clicks, press this button instead. And that was a solution that we could implement in like two days, as opposed to the runtime de-conflicting technical thing, which could have been like a five-week project.
SPEAKER_03:That's awesome. Yeah. So like actually engaging with the user to make the decision for us, as opposed to running some sort of like savant coding in the background to just do it. Yeah. Try
SPEAKER_01:to figure it out at least. But it also took... But it wasn't me that came up with that. It was like talking with the engineer to be like, what's the problem you're really trying to solve? And then backing that out and then being like, this is the problem space. And then the engineers went nuts on it, which was like, that's just a win-win for everybody in my book. Like, I'm pumped.
SPEAKER_03:I love it. No, that's just a great example of, you know, I think as industrial designers, we naturally start with the user, consumer, end user, whatnot. And I I think the big takeaway from an industrial design perspective for me is when I started with Amazon, it took a long time for me to ramp up to have a conversation that was beneficial for both of us me and the engineers because i'm coming from the user right i've got i've got all these all this uh provenance and historical knowledge of how people want to interface with this thing and they're coming from the internal functional aspects of how this thing needs to work and yep you know have being able to have a conversation about the through line between those two is super beneficial within an organization. And I could just say as just a side note for any listeners out there as an industrial designer, it takes time to develop these relationships. Don't get frustrated. And also, always ask questions with these guys because like as Sam, as you said, they're super intelligent, super smart people. And, you know, you guys are actually going to end up benefiting each other, working, being able to work faster, produce products faster, more efficiently together as these conversations about the user and the problems to be solved together as they unfold. So, yep. I mean, has that been your takeaway as well? I mean, I know we work together a little bit and you already have a background in the user side?
SPEAKER_01:I'm working with a lot more web designers these days and especially because I have a design sensibility and I'm like a bad web designer. In a pinch, I can do web design-ish. You can hear my confidence in my own web design abilities. But when I work with the web designers and talking to them, like they'll come with a mock-up and we'll talk very much about like user outcomes and how I expect like users to, to use, like to use a certain feature. And so there, there might be like a problem with the designer and an interaction that doesn't make sense or something has been emphasized and like, I have tulip examples that I think I can talk about. I'm mentally checking in my head what's okay. So we're... We're going through a situation where people are adding machines. They're monitoring milling machines or lathes or whatever it is. We're looking at the design and some of the features that were emphasized and it didn't make sense to me. I went back to the designer and I was like, let's think about how a user is actually going to go through this. They're going to be adding machines like a lot once when they first get set up but then in real life you don't have like milling machines arriving to your shop floor every day, and you're not shipping machines away from your shop floor every day. So the primary interaction is going to be the initial setup, and then the secondary and follow-on interactions are going to be revisiting this page to see what's there to understand what's happening. And then the tertiary interactions are going to be adding new machines and removing existing machines. It's going to happen, but it's going to be rare. I'm not designing it for them, but I'm giving them good feedback on how I expect this to be used, which helps them. It's not my job to solve the design problem. It frees the designer to use their design sensibilities and come up with their own solutions, but it's me clarifying to them what the problem actually is.
SPEAKER_03:Gosh,
SPEAKER_01:I think is I don't know. I think it's a good way of working. Yeah. Although I'm in a we're in some like early phase stuff right now. And when we're at this initial brainstorming kickoff phase, it's impossible for me to not design the solution at least a little bit, at least at a rough outline sketch. I don't know. I'll ask you for your hot take. I think it's part of brainstorming.
SPEAKER_03:It is. I think at brainstorming phases, of course, you're diverging as far as possible. And based on the temperament of the team, you can go as blue sky as you want. However... You know, it is kind of shunned on to kind of come to a solution of brainstorming phases. However, as long as you build in pressure test time, I think that you can, the benefit of doing that is obviously you can pump out a couple of concepts and test them and pressure test them and then do a cycle test or iteration. and come up with a better solution, right? You're never going to come up with the solution in a brainstorm, right? But I think building in that test time and cycle time. So what's your take on that?
SPEAKER_01:I feel like I have to sketch. Like I have to brainstorm to sketch to be able to articulate things Like sometimes it's hard for me to just go straight to like, these are the outcomes I'm trying to achieve with this page. Like I have to sketch to like flesh out some ideas to look at it, to be like, this is what I'm trying to do, to be able to articulate.
SPEAKER_04:I
SPEAKER_01:had to design it to articulate what I needed so I could go back to someone else to say, like, this is what I was really trying to do.
SPEAKER_03:Got it, yeah. Yeah, so that paints a better picture for me. So what you're really doing is, I mean, you're still developing concepts. It's not a convergence on a solution. It's just a... preponderance on an idea and so yeah, I want to get so you I want to pull out a nugget there that kind of struck me and that is brainstorming together and and at the same time sketching together as you brainstorm and talk through things and the power and like how how powerful that is because I can I can describe to you the physical form of a thing to 20 people. And if they drew my description, it would be 20 different things. Like if I just described a lamp, to 20 different people, same description, it's 20 different lamps. And so I think there is a monumental power and the tool of sketching with people to come up with solutions and highlight things. Also, one last thing I'll add is that sometimes problems like you're trying to solve, whether it's a web layout or a flow diagram, if you will, or navigation diagram, path through a website, you have to get these things out. You got to throw sticky notes up everywhere. You got to move things around. You got to talk about how this connects to this. Ultimately, to get them to that job to be done, that is the path that you are assessing. I'm curious to hear a little bit about something that struck me earlier. You were mentioning as a team leader now, as a manager and developing some of these tools, to use with teams. How, for instance, as a designer, as an engineer, as a creative person, are there tools that you've come across or developed that designers and engineers can leverage to kind of bring to the forefront at a faster pace the collaborative nature of a team or environment?
SPEAKER_01:I don't know if this... answers your question, but I'm a, I'm a big fan of like cadence and rhythm and regularity. Uh, and I've learned how to, I've learned how to drive status meetings in a different way that I like developed towards the very end of my time at go and really like honed at Alexa. Um, And so when you have a due date, like if you just ask someone for status, like, and just go around the room and just say like, like, Hey, what's your status? That's, that's basically the equivalent of asking, like, how do you feel today? How
SPEAKER_00:do you feel today? Which I
SPEAKER_01:don't know. It's not, it's not like
SPEAKER_00:efficient,
SPEAKER_01:but I think like one of the things that I described earlier, like, like what is your, when I said, like, when I started looking for deliverables. So if you start asking for status as, like, a deliverable that's due by a certain date, now you can have status meetings where you get the right information across really, really quickly. So you get really fast information flow across groups of people, which I think is huge. So, like, I wish, like, if I could go back in time, and I don't know if I would have had it, like, Maybe for the pace we were going, maybe two or three times a week, but just say like... are you on track to finish this CAD model by this date? Are you green, yellow, or red to do that? Because that's really the core of the issue. I'm not saying, Rob, how are things going? I'm not saying, how do you feel today? Is the work progressing smoothly? The real thing that mattered was, are we going to have this by this date? And then if the answer was no, then you'd say, why? You'd be like, well, this is taking longer. We're working at insane-o speed. We don't have enough time for anything. This just changed. The product manager came down and we moved four major subsystems and you have to redesign everything around it. Then you could be like, yeah, we are not on track to do that by that date. Then you'd be like, okay.
SPEAKER_03:That's where you can either course correct or...
SPEAKER_01:Now you can have a real discussion about it. When you're moving that fast, you can't you can't ask for the little steps along the way. You need to ask for like, when will the deliverables be complete? Yeah. And that's the thing that matters. Yeah. Can you also, it also, it also lets, I think some things are like really, really squishy and amorphous, uh, like CAD modeling. Like you, you might have like a master model and then you start, uh, getting into major features and then you start detailing out little pieces. I don't even know. We could probably have another discussion about CAD and CAD strategies. I've seen CAD training documents where they had they had like structured CAD models where they had a very formal, like you start with a top level master sketch and then you flesh out like big pieces and then you start coring stuff and then you save like fillets and small details for the very end. And so it's, it's, once you start getting into some of the end stages, you bump something somewhere, it bumps something somewhere else. And if you're really good at the top level layout, you avoid some of that stuff. But there's still a degree of how do you get all these pieces to fit in the puzzle? And it's very, very hard to say, here is the milestone where the top level sketch is done. because you might go back and have to tweak it. And so top-level sketch isn't a good deliverable. It's really the full CAD package. And when you ask about the final CAD package, it lets the industrial designer or the engineer who's responsible for that use some of their professional experience and judgment to make a call about whether they're on track to finish by a certain date, if that makes sense. It's one of the reasons why scrum and tickets can be really hard to make work for CAD stuff. It tends to not work that way.
SPEAKER_03:Yeah, we ended up using, because I remember I did use a... You use the ticketing system with just high-level feature work, I think, to your point. I mean, when you get down to the latter end of the project and you're already defining parting lines and there's like a gotcha at the 11th hour... I mean, I think...
SPEAKER_01:It blows up your model.
SPEAKER_03:Yeah, yeah. It'll blow up the model, right? And not only that, I mean, if it ends up being something where the parting line had a CMF break as well, so it could kind of drastically turn into like... a design intent uh like changed completely right yeah and so that's where you get into the the level of detail where you know in my experience a lot of times because there are deliverables and there are deadlines and not to mention well we just maybe we just ordered I'm just saying we in the obligatory we of a team, but maybe we just ordered a crap ton of raw material to produce the things, and the molds are getting in line to get cut. Unfortunately, sometimes the fact of the matter is on the design side, sometimes on the engineering side, you've got to give and take a little bit because you've got to drive through on those. Yeah. Yeah. Sometimes you've got to push the yellows through the green. Yep, yep, yep, yep. make the iteration later on you know when you make the new thing
SPEAKER_01:well yeah yeah sometimes sometimes the path to green is just working really really hard in the yellow the whole
SPEAKER_03:time
SPEAKER_01:yeah yeah
SPEAKER_03:uh yeah yeah 100 um yeah that's great so um Let's see, where do we want to go with this? All right, so, okay, so let's take a step back for a minute. I consider yourself a think big kind of person, you know, kind of always having your eye at 30,000 feet, but also three feet, you know, into the nuances. Do you have any, how do you, yeah, how do you go, how do you get to the 30,000 foot view when you're, coming up with ideas or trying to drive, uh, projects and concepts.
SPEAKER_01:The nicest thing that anybody said about me and like our internal reviews was like, Sam, Sam sees the forest and the trees.
SPEAKER_02:Yeah.
SPEAKER_01:That was, that was, that was really nice. That's
SPEAKER_02:sweet. That's sweet.
SPEAKER_03:No. And it's a skill that I think a lot of people yearn to have, and maybe they have some of that sometimes. Um, I personally try to do both as well. You know, Think Big is obviously one of the Amazon principles and, you know, across a number of other large organizations as well. How do you think big when you're moving fast?
SPEAKER_01:I've always thought in terms of systems and, like, that's very hard to articulate. Maybe early in my career, I worked as a med device. It was the consulting firm where I was unbillable 85% of the time. And they prided themselves on systems work. A lot of their companies, maybe they had done something mechanical or electrical in the past, but now... software was going to be involved, and now there was also a backend and a cloud as well. And now you're doing a full systems integration. You're not just designing a mechanical component as well. And they took a structured, rigorous approach to it. And I think it's partly because in MedDevice, you needed to have something called a design history file. And so you needed to you needed to show proof that you designed something on purpose and that there were design artifacts along the way. You had certain analysis tasks completed, testing tasks, review tasks. If you held a meeting about something, we would literally sign a sheet of paper that people attended the meeting and that became an artifact that you put in your design history file. And we would use our systems diagrams to organize the design. If you think about we're going to be having a meeting and generating these little pieces of paper every time we have a meeting, you start thinking about where those little pieces of paper are going to go. And so we would use our systems diagrams to drive the product breakdown structure and the organization of our design history file. And so at the top level, you might have your medical device, which would include all the testing that was done at the full device level. But then I remember working on a breathing therapy thing. It used a therapeutic gas. So then there would be control boards inside it, and there'd be tanks and various electromechanical valves, and those in turn would be subsystems. And so the test documents and test plans and requirements and meetings that existed for those subsystems would also go into their own folder inside that And then you could get down to like the component level and then, I don't know how you selected an oxygen sensor or CO2 sensor or nitrous gas or whatever the therapeutic gas was like that would also have its own folder. And so I don't know if that's like thinking big or at least thinking about the full system, but yeah. Like I came from a place where you had to think about that full system ahead of time, because if you didn't think of that full system, there was no way to get all the component pieces, not just to like literally fit together, but you needed the system to function and come together. And I think a lot of times when people don't have that systems mindset or systems approach, you end up with these like. integration hell at the end where you're trying to get stuff to work together and it doesn't. I'm thinking the Obamacare website that crashed on rollout is a classic example of this. I don't know. I've always had that big picture view and that's helped me Because I've dabbled in so many things, it makes it easier to understand the little details for me. I can get into the details of the industrial design or PCB trace width or PCB stack up or a gazillion different things.
SPEAKER_03:Sure. That's a great... That's a great kind of example. And it leads me to think about, think through all the times I've been, you know, maybe I've consulted or been with a company, whomever and whenever that was, where the leadership didn't care to or the client care to pay for the thinking on the front end. to save your ass on the back end ultimately. You know what I mean? So that whole integration hell is an effect from not thinking on the front end through kind of the techniques and processes you're going to use. And I think just taking that back just for a minute for the industrial design side of things, You know, okay, let's say I'm designing some headphones. Okay, there's, yes, a master headphone file. And then you drill down from the component to all the way to the component and part level. However, there's also other nuances of, okay, how many iterations do I want to do? How much testing do I want to do with users? How many possible concepts do I want to come out with? you know, how long is that going to take to do? Let alone modeling the form factors, getting the, you know, the space call outs for the actual componentry inside, working with the engineer. So thinking through that, that through line to the end result for the product is very, very important for an industrial designer, period. And definitely something you should be thinking about coming out of school if they didn't teach you about that. I mean, bill of materials is one thing when you design a product, but to understand the time that it takes to develop the whole product end to end is very, very, very powerful.
SPEAKER_01:Yeah. Yeah. Yeah. So if you knew... like the system isn't just like the headphones themselves but like the system also includes all like test plans, revisions, user tests, right? Like the, the user test, like talked a lot about like deliverables, the, the user test in a way, like, I don't like thinking of the user test as a series of tasks because you are going to have to test with a bunch of users. But at the end of the day, I want to report summarizing what you learned from those user tests. Like everything I just, I need to, it's going to, is it an email, a PowerPoint? I don't know, a piece of paper, like, or is it just you telling me what you learned? Cause That's okay, too. But the day I get a PowerPoint that says, this is what we learned from the user test, that's when user testing is done. That's what I need. Everything else up to them is just noise to me, which is mean, because I love participating in user testing and watching stuff happen. It's what gets you to focus on... That's the thing that you need as part of this system. Like if you're putting all these pieces together, that would be a box on my systems diagram.
SPEAKER_03:100%.
SPEAKER_01:That PowerPoint.
SPEAKER_03:100%. Well, that is– that's some fun conversations around system design. I think personally for me, there wasn't a ton of– conversation or classes or thinking around this in college. And it took me a long time because out of college, I went ahead and just started a consultancy or, you know, a company and had to start thinking through wearing all the hats, you know, for the running the business. And I'm sure you've been through the same thing, but that whole systems approach of how to bring everything to either deliverable for the client or customer or whomever. It's a very important skill.
SPEAKER_01:Even earlier in my career, I guess it was when I was at Lincoln Laboratory doing aerospace defense stuff. We were doing space flight systems, like satellite telescopes. And so NASA basically invented systems engineering. So that was maybe even earlier in my career. It was kind of baked into me.
SPEAKER_03:Wow. Yeah. So I want to shift gears a little bit, Sam, and maybe just talk a little bit more about... some random thoughts you might have been having around engineering, design. Do you have any non-related creative pursuits?
SPEAKER_01:So I do run awkwardengineer.com, which has a blog on it. Okay, so you write. Do you know about my typewriter? No. I've got it. Not that podcast listeners can see. I'll hoist it up. Well,
SPEAKER_03:we're videoing and hopefully at some point I'll get these up on YouTube. So we'll get there.
SPEAKER_01:Yeah. Hold on. It's on my desk over here. But yeah, I did a lot of writing on the typewriter, at least early in COVID. I called it my COVID journal. It was my stress management.
SPEAKER_03:Yeah. Yeah. Oh, wow. Nice. Dang. That's like what? Early turn of the century.
UNKNOWN:Yeah.
SPEAKER_01:so this was uh 1917 maybe yeah i uh so i i bought a typewriter uh is a royal i don't know it's the brand on it yep and like enjoyed it and then found from like my great grandfather there was like a typewriter in the attic and so it was it was the same model but it was just in terrible condition and there is one typewriter there's a typewriter repair shop in new england guys in arlington
SPEAKER_00:no way which
SPEAKER_01:is next town next town over from somerville and so i brought him this old unit and i was like i don't need two typewriters but But this old one that's in need of significant repair has sentimental value to me. And the guy was like, I'll repair it for the price of you giving me the other typewriter. I was like, that's totally cool. Hell of a deal. It's beautiful. I'm pretty sure he came out well on the deal, but that's fine with me. I'm going to have to get it.
SPEAKER_00:Well, speaking of writing... Yeah, yeah, go ahead. Sketch and doodle. Yep.
SPEAKER_01:Every now and then I sketch and doodle a little. I try and like brush up my industrial design skills. There's a note that says draw bigger. Nice. I'll hold it up to the camera where the listeners can't see. Perfect. Oh, yeah, yeah. You
SPEAKER_03:got all that room on that sheet. Just get the whole arm into it. That's kind of what.
SPEAKER_01:Yeah.
SPEAKER_03:Yeah.
SPEAKER_01:In pre-COVID times, I'd do some figure drawing, which I found really relaxing. There's a place down the street from my house that did figure drawing sessions that I'd go to on a semi-regular basis. I think that was a little easier to go to before kids as well. And then, I don't know, I rock climb, which is not necessarily a creative pursuit, but it's other stuff I do. And I cook.
SPEAKER_03:Cooking's creative. Oh, nice. So back on the writing side of things, from our just past conversation, any books, articles, websites that have excited you lately that maybe the listeners might want to check out?
SPEAKER_01:Oh, man. So I read Hacker News. Okay. That's one of the sites. I look at Core 77 regularly. Yeah, great site. Core. That's your audience. Yeah, for sure. The Swiss Miss design blog. It's like Swiss stat. One's the hot chocolate and the other is like a lady from Switzerland who lives in the US.
SPEAKER_03:Okay. What's the theme on that one? That sounds, I don't know, hilarious or quite intriguing.
SPEAKER_01:So the... The one that's the hot chocolate company, that's a hot chocolate corporate website. Totally get it. It's either with a dash or without. And then the lady from Switzerland, she's... I don't know. She's a designer, and she mostly just curates nice things that she finds around the internet, which I enjoy.
SPEAKER_03:Oh, cool. That's inspiring, yeah.
SPEAKER_01:I don't know. I have a rant in me about curation is key. I went through my photos for the past year. Oh, man. So we had this interior designer who put together a floor plan for what was going to go in the living room. I think 90% of her job was serving as a mediator between my wife and myself. We're going to have a neutral third party have creative control and we're just going to trust their judgment on this. If I was in charge, you'd end up with some weird stuff. She decided to put like her recommendation we had this wall she was like you're gonna put a picture grid put like eight photos up on that wall like we talked about how like family photos were important and so i went through i went through my kid is seven now my oldest one so i went through seven years of photos to find like the perfect eight that i will put on the wall that's right and so what an exercise you scroll you scroll through old photos on your phone and like takes a lot of pictures to get one good picture and so you have like 50 pictures of like the same thing on your phone it's just crap and so what i what i what i do i i i have like a backup folder in dropbox and i i go like month by month and i pull like the best pictures from that month and so curation Curation is key. And so the Swiss Miss blog, she curates, which matters to me. I love it. This is
SPEAKER_03:totally like, this is an app waiting to happen to download right now. It's like, use some AI behind that. Yeah, use some AI and then choose 15 of your 5,000 pictures that are really nice that you like, and then it just uses some algorithm of composition and just does it for you. All right, who's doing that out there, listeners? Let's make it happen.
SPEAKER_01:Picking those eight photos, like, it's emotional.
SPEAKER_03:Yeah, it is, I'm sure. It's a way back machine.
SPEAKER_01:I've got to get you this story about when I no longer was an engineer. This is important. Please, no, no rush, no rush. All right, so we were at Amazon. We were in the middle of a build, and someone needed to attach some side panels to some fairings. Some covers needed to be attached to something. And it had screws. I didn't know what screws to use or where they were or what the torque spec was or how to look it up or any of that. And in that moment, I realized I was like, I have become, useless it's like i and that's that's when i realized i wasn't a mechanical engineer anymore as i'd become a manager in that
SPEAKER_03:well i mean not to mention that like the information wasn't available regardless but you couldn't even turn a
SPEAKER_01:wrench anymore without a spec
SPEAKER_03:sheet
SPEAKER_01:that's that's when i knew i became useless i love it i don't know how to look i don't know how to look up this screw i don't know where it is i don't know the part number for it like I'm sorry.
SPEAKER_03:I'm sure that was still... Yeah, that's hilarious. And, you know, that's back in the days of the wild, wild west. I mean, we were doing cycle times on that dash cart. It was like six weeks each prototype.
SPEAKER_01:Oh, yeah. Yeah. That was wild. But it was... Earlier on, I still knew where Stu's stuff was. I was still the one putting it together. And at some point, something happened, and someone else had full responsibility for it, and I didn't know what it was anymore. And I tried to help, and I couldn't. And I was like, I am now a manager.
SPEAKER_03:Yeah, it's one of those things. We were moving so fast. You probably just spent a week up on your computer doing some CAD, and you came back down, and there was 30 new people, and everybody had their own toolbox. I wasn't even there. wasn't even doing
SPEAKER_01:cat
SPEAKER_03:but yeah yeah yeah something happened i don't know uh that's crazy well sam that's that's uh that is a great note to leave it on i do appreciate your time it's always a pleasure chatting with you and um yeah dude i hope you come back on sometime
SPEAKER_01:absolutely
SPEAKER_03:drop me some knowledge on uh on what you're up to here in a bit so Thanks again. Oh, by the way. Okay. So where can people find out about Tulip? Where can they check out some of your work? I know you mentioned Awkward Engineer, but go for it.
SPEAKER_01:Yeah, Tulip is online at tulip.co. Call it a meta tool. It's a tool for making tools for people that make stuff. So if you've ever been on a manufacturing floor and you said, I wish I had an app for that, like Tulip will let you low code, no code, et cetera, et cetera, build your own apps for manufacturing specific things. So that is Tulip. And then I also run awkwardengineer.com. Yeah. Awkwardengineer.com. It's A-W-K-W-A-R-D. Sometimes people have trouble with that word. It's awkward.
SPEAKER_03:yeah all right sam well this has not been an awkward conversation and i do appreciate it again thanks and this is rob your host designing in the wild thanks for tuning in and we'll check you later see ya hey guys rob again uh i hope you guys are enjoying these conversations i always learn a little bit every time i do these interviews so if you didn't catch the last episode with kip zoni doyle it's a great talk about how to protect your intellectual property as you develop new products. Also coming up after this episode next week, we will be talking with Andre Brown. He works at Amazon. He is a chief engineer for innovation over there in the transportation sector. He and I worked together a few years back when I was at Amazon, but he has some really awesome projects in the past to talk about. We also get into a little bit of Biomimicry Thank you for watching. through custom high-quality tiny housing solutions, as well as empowerment training programs. This group, Operation Tiny Home, is great. These tiny homes are the first link in a chain of services required to unlock a path back to dignity for the homeless, many of which are veterans. It's a real step in helping them get back on their feet and reintegrated into the fabric of community. Consider checking it out at theidpodcast.co. And with that, we'll see you next week.
