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 enjoy the episode.   On today's episode of The Builder Circle, we have Tyler Mincey, general partner from Baukunst,  to talk about program management dos and don'ts for an innovation project where requirements are vague and ambiguous. Timelines are difficult to predict. Pockets of work are very difficult to scope, and unknown unknowns dominate your life. We're going to also dive into the future of modern hardware and how the process of development may change 

   We will also discuss how VCs look at product development and the product development roadmap and how it's evaluated in the investment process We'll break for a fun segment on hardware heroes, where Tyler will take a moment to recognize and celebrate   hardware developers who are doing amazing work in the industry.

Then we will close off the show with,  how AI will slot itself into physical product development. At the end of every episode, I do a segment called TL;DL where I summarize the key takeaways and tips and tricks that were mentioned in the podcast,  for those who didn't have enough time to listen to the entire episode.

So, If you are at that point right now,  feel free to scroll till the last about 10 minutes and you'll be able to experience  the extracted,  bits of knowledge from the episode and you can always come back and listen to the rest.

. Thank you so much and without further ado, I leave you with Tyler.  Hello, welcome to the Builder Circle. Today I have Tyler Mincey with me to talk about some program management and modern hardware and the process of development. Tyler, welcome, super excited to have you. And I'd love for the, yeah, thank you. And I would love for you to give a little bit of background and introduction to the listeners of who you are.

Yeah, so currently I'm one of the general partners at an early stage VC fund called Baukunst. We really describe ourselves as being a collective of creative technologists that are building companies at the frontiers of technology and design. We specialize in backing uh, Founders at the very beginning of their journey and being really highly engaged, collaborative company, building partners with them across their early teams that they're hiring product strategy and really debugging their business model to hopefully lay the foundation for something really great and impactful.

 Before being an investor I have served in a number of different engineering kind of product management design management roles in my career.  I'm a mechanical engineer by training. I did A mixture of product design embedded systems, some control systems design and really just love that interdisciplinary work of product development.

I was back at Apple in the mid two thousands. I was part of the core. Team for the first generation iPhone and was managing the full iPod product roadmap for a period of time. There. It was like the Shuffle Nano classic and the Touch at the time. It was still about a, it was about a 7 billion um, product line at the time.

And me and my team were mostly focused on defining the roadmap for the products and then we were the kind of system epms, the system engineering project managers that would shepherd those programs. Like through design, iterative engineering development and getting the supply chain stood up and ramping things up to mass production.

So very like full life cycle for all those products.  Really cool time to be at the company where we were basically operating like a startup inside the, inside, the larger company. The teams were like shockingly small, lots of responsibility with with relatively young teams too. So I really, benefited from that earlier on in my, earlier on in my career.

Done a number of things since then as well. I was a partner at a digital agency called Fictive Kin in New York for a bit. Mostly focused on software products, ui, ux we were basically a little kind of startup studio where we would spend off companies, help them raise money, loan out our teams.

And that was really how I started getting the startup bug. And it never really left me. I ended up moving back to the Bay Area to be part of the founding team and the VP of product of a venture back company in the automotive space called Pearl. We are building kind of AI driven driver assistance systems that people could add onto.

Posting vehicles. So had that whole journey of raising money, going through all the board meetings, growing the team really amazing experience.  And that's how I found my, my way into the venture world from there.

That's a amazing uh, career that you have. Truly it's very inspiring and I'm so happy that you're here and willing to talk to me about hardware development, because I can't think of anyone better. 

I do wanna give a little bit of a shout out to Baukunst

they are a absolutely wonderful VC firm.   They had a wonderful conference where it truly inspired a part of this podcast.  They support. Founding teams in a really incredible way. As you can see, Tyler has a really technical background and most of the partners actually have technical backgrounds in Baukunst

 they're truly a partner from the beginning until the end. For those that don't know it, they should definitely Google it and look up Tyler and get in contact with them because they're an excellent VC to work with.

Thank you. Yeah, it's never too early to talk to us. We spend a lot of time just talking to people about. Is helping them think about maybe if they should leave their day job to go do that now, and so always have to be a resource for people.

 Definitely. So Tyler, you mentioned that you were getting ready to launch the first iPhone, which was a huge milestone for humanity in a way, seeing how we use iPhones now. But when you took on that project, how did you go about understanding requirements or even just scoping it because it was such a novel technology and they, I'm sure there were a lot of unknown or unknown unknowns.

So what are your thoughts about that?

Yeah, for the phone, it was such a, it was a really, a whole company project that really came from the top down too. I think the, one of the most important things, I think the. Company and how the creative process there works. It's very demo focused and experienced focused.

It's really about capturing some magical experience, interaction being able to see that and feel that and then doing all the hard engineering work to make that possible. So it was less about there was like honestly no like product requirements document that had a bunch of numbers and speeds and feeds that was argued on.

It was really like, let's try this software experience. Do we love it? And then how do we make that a reality? And or can we hold these industrial design models? Do we love those? Do we think we can execute this functional experience in that package? Let's go figure that out.

So it really starts from this like demo place as opposed from a spec, a kinda a spec place. I think that was that's really important. So there was a long time where the whole project was living with these large, like non form factor PCBs, like tethered to a little like touchscreen in a box, basically, that people could do UI development and could experience some of the the product flows and iterate there while every while we were still trying to pack everything in the box.

 And so I think that was a really big kind of part of establishing the quote unquote requirements for the product itself. But but beyond that, a lot of it just comes from an intuitive feel for what are the fundamental building blocks of this product experience and how are we gonna develop develop them over time.

 It's shocking to remember that the first phone did not even have g p s, right? Like a smartphone that doesn't know its location is It's a little bit hard to imagine. But it was able to do some simple location triangulation based on wifi access points and things like that.

It was called a web hooks at the time. And so it had the m v p like baby step version of some of that functionality in a roadmap of how to do that with better accuracy, better power consumption, and better form factor over time. And so it was always a kinda a balancing act of the bar is very high.

Like the goal is excellence and a wonderful product. Like how do we do that this year? And then how we're gonna make it better again next year and not try to, not try to bite off more than, would hold back an entire program.

So it, it seems you didn't go down  the very prescriptive path of   systems engineering where you go out and do a bunch of  studies and then bring that back, turn it into a product requirement document, and then follow it to a t in   system development.

It was it more so there was this like vision of this crazy good user experience ?  And it was more afterwards, I'm assuming it was more like a spaghetti on a wall,  what does that look like? And just, let's just make a benchtop test that looks like grimy and gross.

And, but  this,  one part of it is something we c continuously iterate on. So you just went I, is that like how it, it started of just okay, we have this vision, let's just try something and let's just try it  30 times.

Yeah. And I think it's the most important point is push it beyond a vision to a demo.  Something you can really try and you wanna hold the thing in your hand to experiment with an interaction and say do we believe in this or not? But I think that was really that was the goal really.

But I wouldn't say that those were grimy and. Necessarily either. It was actually, we were trying to achieve those with a relatively, like high level of fidelity that was just representative of what you were building too. Because it's hard to say if it, if something is so rough around the edges that you can't say I believe in this.

We're gonna go do years of work across the whole company to make this a reality. Then you don't, you can't get to that level of commitment. So the demo and the prototype have to be like fairly refined and detail oriented. And you have to be smart about like how you actually do that.

But but because the like gate to moving past that stage, the bar's so high that you really, you end up having like fairly refined prototypes and it might be just some like little piece of the thing or a mockup of how an industrial design would feel. But those are usually like rendered with pretty, pretty high resolution.

Gotcha. And what steps did you take to get to those kind of demo?

 Very iterative, depending on what was being evaluated. So some things like some of the interaction paradigms around like multi-touch were thing that like had been, Being designed and experimented for quite some time. And so some of the things we take for, for granted now around like the inertial scrolling and like really being able to zip around a webpage to like pinch and zoom to to adjust scale.

Some of those things we knew were key gestures that needed to be supported, but there was lots of questions around like how to translate that to the specs of a touchscreen.  And that trickled down into the lines and spaces of the sensor design. And then how well. The colors of the LCD screen were were transmitted through the display.

And so that eventually those things got translated into these like very like nitty gritty tests where you had to demo that of like, how do the screens look under different designs? How how well was like finger accuracy and tracking matching under different designs. So you could evaluate some of those, but it was usually like in the context of of were we able to  hit those like high level like interaction paradigm.

Gesture, things like that, that we're trying to achieve.

Super interesting. And when when you were approaching the problem actually I'm gonna back up a little bit. How many of the designs that you did you end up throwing out?

A ton. Yeah. And some of that came out even in like the Samsung apple stuff that you can click back through some of the the early, the early designs and processes there.   But yeah there's just lots of moving parts. The very first.

Phone design looks literally something like an iPod Nano with a touch, with a click wheel that it was just really clear that wasn't gonna work. And more of the like multi-touch stuff crossed over from some other internal explorations that was just like really clear that was like a bundle of technologies that made sense.

But it was funny, I think there was even maybe I think it's Time Magazine that, that had the iPhone on the cover and it said invention of the year. Like it had just been. A light bulb moment like that, it like emerged from Steve Jobs  head that year or something. But really it was a confluence of so many technologies that had been, being developed for decades in some cases of wireless technologies of system miniaturization, of multi-touch.

And really it was all of those kind of components that are on these like evolutionary paths that all have this like kind of spark point where they're all coming together at the right place in time to make the product like that. 

makes sense. And when you were going through the product development part of it, what do you feel like you underestimated the most? That either took up way more time or wear way more cost  

Yeah. I don't know about underestimated the most. I'm cuz I'm, maybe, I'm like paranoid about everything. So I just like, as assumed like a lot, many things were gonna be, were gonna be harder than we expected.   It's very difference between being able to make one of a thing and millions of a thing too, and so you start just finding all these other like layers of problems once you truly get to that scale, like when you're a startup.

Like a 1% problem, like you maybe barely pay attention to. But when you're at like, at that scale of 1% problem is like a huge problem. Like you might stop the whole manufacturing line because of that. And so you really just have to zoom in on, on like incredible minutiae around things.

Yeah we had just got very deep in, in that regard with quality control, things like,

And you were talking about building demos and doing different types of tests. One of the things that I see a lot in. Engineering teams is um, engineers are very precise. They like accuracy, they like having numbers and they uh, like to do things and they wanna usually do it perfectly.

How did you get around that and how did you, like, how did the team get inspired to. Just try stuff and try the good enough. And is it, was it just built into the culture that the team was like risk averse? Because I've just seen so many engineers where they really wanna get the prototype even to be , almost as perfect as possible.

But then that takes away from the learning that could happen if they just made something and tried it and tested it and broke it. How, what what was your experience with.

Yeah. There's a lot of complexity around that. I think one of the big things like there, the expectation was that things were pretty close to perfect all the time too. So it was, there was a lot of execute or shut up, like like that was the kind of, you really just have to, had to be.

Extremely detail-oriented and everything you did. And so most people, I think, understood the expectations or had shared expectations and would really kinda like polish and iterate like within their own like purview. And I think they, they understood when they were dealing with a complex interrelated problem where they needed to pull on other teams, but otherwise you just had get your shit right and you wouldn't show it to you wouldn't waste someone else's time unless it was right.

And you really had something polished to show them. And so I think that was. You just had to do that and move fast. I guess really? There the line didn't really move like much towards let's just show each other unfinished things. I think there was a a pretty high bar.

Do you feel like people, because the bar was so high, people would take longer in doing things or not share because they didn't want it to be criticized.

Sometimes Yes, absolutely. But but I think that was, it wasn't like too long. It was like, if that's how long it was gonna take to get it right, we're have to take that. We have to take that long. Shorter amount of time, but not getting it right is not really an option. So it's like you have to, you have to do what you have to do.

I think as far as like the ability to take risks that was very structural. Because everything was coming from this this design perspective first. It was like the design teams like wielded god power. It was like, this is what we want. This is how our, this is how the product should look.

This is how the product should feel like everybody else. Just make it happen, or you gotta tell me like why? It's literally like against the laws of physics to make that happen. Otherwise just telling me it's hard is like not a good answer because we're trying to do hard things. We're trying to, we're trying to do this new product.

And I think that was just a permission to take risks or being actually like forced into taking risks. And everyone I think was pushing to move mountains and to work magic for the most.

I think that's actually not as bad as it might sound for some people. Because I feel like that level of almost  stability and grit of like, I know this is going to be what the final product looks like and trying to do that is much better than not exactly knowing what it's going to look like and doing a bunch of trials that just fail.

So that's interesting. Do you feel like, what, how do you feel like they knew that? How do you feel like they, they had such a clear vision of the.

Um, I don't know. That's that is a little bit of the secret sauce. I think at the end of the day, if you get really talented people and then give them the the like authority to. Make something that they can really stand behind. I think you, you start to get some of those start to get some of the, that clarity of vision and I think good product definition that comes out of it.

I think you have to have, you have to have really talented visionary people that are good at that. But if you put those people in, in, in like larger organizations where they're not empowered and you still are doing this lowest common denominator designed by a committee, like you don't get good work out of it either.

You have to take those really special people and really just support their singular vision. 

That, that's super interesting. But it's true. It's, once you get really good people, utilize them.

Yep. Yep. And people don't get it right all the time too. And so you do acknowledge that and you do have to try it and have the know, sometimes it's a little bit of a luxury to have the resources to try again, but but have to be really real about what the bar is to, ship something and then keep iterating if you're not being that bar.

Definitely. And you said something along the lines if it took people longer to get to a higher quality, like that's just gonna be the case. How did that in practice, Affect the schedule. I know that these things need to exist, but schedule is always a big constraint.

Uh, how, How did you work around that?  One way to work around it is just you work a crap ton.    Maybe that was what happened, but were there, like how did you deal with that?

For sure. I mean, Everything was hype is. Was very schedule driven, like Hyperschedule driven because everyone knew that you needed to go through iterations and you needed to organize those iterations. If there was no organization, then everything breaks down and you're of chasing your tail for each individual change.

You're trying to, you're trying to accomplish. So there was really a rhythm of. Of, design, build, test, design, build test that was happening. And those cycles like, were trains that ran on time basically. And you kn knew that you had to get testing done on a certain date.

You had to look at all the problems like figure out. Root cause figure out corrective action for all those, consider all the solution space as a whole, redesign something. And people knew like about how much time all of those things took so that we could run the iterations in a very scheduled way.

So there was a, I think a high level of rigor and process around that to make sure things are going as, as fast as possible. But you know exactly how many cycles it was gonna take. Was always a little bit unclear. But you did eventually have to establish like what was good.

For that year. And draw the line there too and and move other things to, to the future. So you do have to draw a line in the sand as long as it's, as long as it's meeting that high bar then you have, you do have to call it at some point.

So it's not necessarily like better forever.

I think that is like perfect as the enemy of the good. 

Definitely. And I feel like with a lot of designs, you get to a point where every single iteration is only adding maybe like 2%, 3% of just improvement. And I feel like when you hit that zone and it's oh, like it, it would be better if we change this tiny feature and again, this many pennies back or something along the lines.

It's it's. It's important to think about how many people are working on it, what the schedule costs actually is. It's like always opportunity, cost and being able to uh, evaluate that. 

This is a very like academic thought, but like  Design to some degree for me, is really just making a set of arbitrary choices with some desired outcome, like within constraints like you, and if the. Constraints are the same. You end up with the same outcome no matter like what path you take or how hard you iterate.

And so you have to call it quits at some point. And what the really important thing is for the next generation, you actually have to move the constraints so that you can like land at a different place afterwards. And so those, that's like really the sort of the meta cycle of, of okay, we've made this like product this year as good as we can.

and We're calling it done for the next product. You don't just try again. You like try to move the constraints. And so you start to ask yourself like, what new battery technologies are available to us? Are we gonna add a new a new feature? How do we make space for that? What is the new, what is the new software thing we're trying to accommodate what new display technologies are available?

What new? Silicon that is available, that, that will help us save size or cost or things like that. And you really have to change some of those, like big chunks to have a new like product hub, even design around

That's such a, that was beautifully said and such a good point. And I think actually, While the product development is happening, identifying those constraints as pieces of innovation that can happen. That could be your R&D team. That could be something that is like actively worked on while the product development team is working on the, first gen of something.

And then so that in parallel you have your R&D coming up with ways to decrease the, the constraints that you're putting on the problem. And you totally hit the, and nail on the head. I feel like one of the things that I always see in, in startup land is that people know that designs need to be made.

But one of the things that's actually so helpful, and I find it so helpful is writing down the key decisions that need to be made.  Related to the design because that sparks so many conversations and it actually makes you operate quicker.  If you have the list of key decisions that you need to make and your constraints, and then you go for it, and you go system by system or component by component, and you evaluate the trade offs and then you're somewhere and then you say design build, test and repeat, rinse and repeat.

Great. Exactly.

That's awesome that, that was such a a concise and simple way to explain the biggest part of product development. That's so cool.  Do you feel so, um, right now obviously hardware is changing every day. There's more software that's being implemented into. Hardware solutions. And now the trade-off space is even larger because when you have a problem that you're trying to solve, when you're designing a product you're now thinking is this a problem that I wanna solve with software?

Is this a problem I wanna star solve with hardware? Is it the firmware? Like it, it just, it keeps, it's keeps going in many folds. And as the. Modern hardware, realm develops. Do you feel like the process of development will ever change, or do you feel like it'll still follow the same principles?

I think a lot of the same principles at a high level. Will be true, but definitely like how we work is changing. And I think the, how you're building and what you're building are always interrelated too. And so I think as our products evolve it, it will change how we're developing those products as well too.

Like for sure. The things you mentioned I like. I think of even like, when I think of modern hardware development, like how is it maybe different than we've done stuff historically? I think teams are definitely working in in a more like remote fashion than they ever have been before. Some of that is, is from different parts of the supply chain or collaborators around the world working together.

Some of that are just. People like working from home or hybrid work environments that happened before. And so that's requiring tools and processes that help people in different geographies work together in different time zones, working asynchronously sometimes. That's, I think really transforming how people are working.

I think the products themselves designed for sustainability or circularity are playing, is playing a larger. Role in how products are being developed. And so I think there's like a whole other metrics and constraints around the product design and goals and around the user experience that are showing up.

Some of those are being driven from like a regulatory perspective or or because of internal guidelines that that brands and companies are setting for themselves. But I think. That's been happening for decades already too. I think the most important thing is we're truly seeing a sea change in consumer demand and focus on those things as well.

So it really is being more market driven than it ever has been before. But I think the other big thing is just that we're s I think we're seeing the rise of more kind of opinionated, personalized products that are either being manufactured in a decentralized way or.

High value products, focused at smaller customer segments or demographics than have been in the past. Some of that's I think driven by some new advanced manufacturing processes that kind of make highly personalized products, like more feasible or actually lower cost to make.

But again, some of that is also opportunity market driven as well, where people are designing things. For under historically underserved markets but are doing that in a very high value way for people. And so that's really, that's just very interesting to, to see like how you test those products.

Like you're able to build relatively successful large scale businesses with almost a larger in, or, sorry, a smaller install base than you have the past. And that's, I think that's really. Changing some of the economics and process of how you do product development.

But the competing in the land of like, how are we gonna make one, black slab of glass that works for billions of people in the co the, of the world. That's, there's only a few people that could do that, that are doing that right now. And then but there's this really whole other kind of Cambridge explosion of slightly more like opinionated hardware.

I think that we're starting to see right now. And those things are a little bit more software driven. And most importantly, they have kinda services related business models as well too. So the companies are doing things and offering product experiences or services that offer ongoing value to customers and that they're paying for an ongoing basis, not just a one-time purchase of the widget upfront.

Yeah, that's a good point because a business model definitely plugs in very much so to what the product ends up being. And it is becoming more mainstream for hardware. Hardware companies or hardware products to have like a software component. And also I think in terms of just cash flow and being able to launch something quicker it's an interesting combination where I think it strategically works out really well for companies because oftentimes they can even start with the software part, launch it.

Get some level of reputation going and then potentially introduce hardware later or they launch it together. And it's easier to sustain it in a way because software costs a little bit less money than hardware does, and hardware has the lead time associated and everything with it.

It's interesting to see that morph together. So you have been on the like, product development side as an engineer where you design test and do all the kind of individual contributor work. And you've also been on the project management side and now you're on the VC side.

And um, hardware is notoriously hard to get fund do fundraising for because of the early onset expenditure that you have to do to get it to a certain point. So when you are looking into investments and looking into companies in terms of their product development roadmap, like what do you look for and do you feel like is more most important that teams focus on early and have a plan for.

Yeah, absolutely. I think because. Invest very early. Like we're often the first institutional investors in a company's lifetime. Oftentimes the company's like actually getting formed legally, like at the time we invest too. And so for us, we really focus very heavily on the team themselves.

And so I think we like to back founders that are deeply technical are planning on developing. IP that, that they're doing themselves inside the company, like maybe not out outsourcing much of their core development. And are gonna be able to like, while they're in that highly iterative, let's make a great product mode.

They can do that in a really capital efficient way where like they are a team of highly capable, scrappy builders. They understand. Quickly. And so I think that's really important for us. We also look for founders that have I think a depth and expertise in design too. And so that they have the technical chops, but they really know what they're building towards and can communicate that vision to other people on the team.

Can maybe inspire and recruit them in the first place. Hire hiring's a really big deal. We like to back founders that we often. Call creative technologists as a label. And those are people that, that bring that kinda, that Venn diagram of technology and design together.

That's a really big deal. So team is like the number one answer. The second one really is around business strategy and business model too. I think we, we want to look for something where, if the product works, there's a huge market opportunity there. And we're looking at like large addressable markets, like very high.

Long-term value per customer within those markets. And a really compelling story around why this opportunity exists today and has it in the past too. So really understanding competitive positioning and usually some macro trends either on the technology side, it's some emerging technology that.

That is a new tool that hasn't existed before, or there's something that's changed recently on the demand side of things. Maybe it's a demographic shift or or a change in consumer behavior or some externality like, like climate change, things like that too. So I think that's that kind of core what is the market opportunity is a big part of what we look forward to.

But as far as the hardware component itself, like we definitely We try to help people and what we specialize in, I think, is really helping people debug the business and show that they have a really good foundation there without  extremely high capital expenditures, like you have to spend some money.

That's also like why we're VCs like you,  it's hard to bootstrap these companies. Like you need to raise some capital and that's what we're trying to. We try to be there for people, but but we've also cultivated a lot  supply chain relationships with vendors that are very startup friendly and maybe can help get, get started without a lot of tooling expense or don't need like huge pos to get started with people.

And really help people understand like, what is success for your company? And usually like the people whose mindset is I have built a thing, now I'm going to go to. A CM and mass produce my thing. And it's one step is like a bat, a horrible plan. And usually a better plan is to think like year one, I need to make a hundred of this thing.

We're gonna let people use them for a few months, we're gonna prove out our business model, then we're gonna get a thousand people using the thing and show that we're, retaining people for long periods of time, that we have really healthy business model. And then like year three, we're gonna be building tens of thousands of a thing.

And it's really about having a business model. That, where that's actually, that makes sense. But then having very realistic expectations of what success is and growing in a in a capital efficient way.

That makes a lot of sense. And that's a super integrated approach, right? Like where you have e everyone when when they're  extremely technical and they're building a technical product there's this uh, it's just like life cycle testing or like validation testing that happens within the tech.

But there's also validation that needs to happen on the business side. And you don't wanna be investing tons of money and like spending up an entire contract manufacturer on piece of hardware that is consumer. The a consumer electronic that's for consumers and you haven't tested them with the consumers 

Exactly. Yeah, that's so you really have to get that right and if you haven't you shouldn't be scaling your product, you really want to really hold your own feet to the fire at that stage of the company.

And that's  a really good way to even like in, because a lot of startups with founding teams, they need to do some level of program management. In order to keep their keep it all together and that's why you have like phase gates or some type of like, milestone driven structure so that you have those moments of okay, we built a hundred of these, let's  have a hundred customers lined up in a wait list and we send it to them and we get feedback and we close that loop and then we implement the things that we learn because we might think something is great in our little team and we're nose deep into the tech.

But. When it actually goes into the world, it's a completely different story.

 📍 Absolutely. Absolutely.

 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 Segment

So we are going to go and do a different type of segment today with Tyler.

And it's called  Hardware Heroes, where we take a moment to recognize and celebrate hardware developers who are doing amazing work in the industry. And just talk about what's what some positive stuff. We've had a lot of a hardware horror story. So this is, this will be a nice little peppy moment, hopefully.

for sure. I'd like the take the opportunity to like actually call it a portfolio company.  We have a company called Five Flute in the portfolio that's actually making software for hardware developers.

And their whole point in life is to like, remove some horror stories from people, which is, which I think is great. And ultimately, like what I'm, what I'm a cheerleader for. They are building an issue tracking and kind of design review system for people doing hardware development.

Mostly kinda mechanical leaning engineers right now too. If you've ever worked through a hardware development project. There's some point where like your li your to-do list starts to break out of the notebook you have next to your computer. Like starts to maybe run into pages and pages of a text document.

Maybe you've tried to like eventually put those into a spreadsheet that just makes you want to stab your eyes out to manage, like with the team every week and you're like sitting through these. Bug scrubs or something horrible. Maybe you've even tried to use an issue tracking system like Jira that's really been designed for software and kind of r like totally breaks down when you're trying to like, describe a physical product.

Like you're trying to type out the description of please move that hole. The one I'm talking about, like that one, like a millimeter to the left or whatever. And it's, it slows things down, makes everybody's life a pain. And I think oftentimes like either people. Regimented about things and they have quality control problems or, the trains don't really run on time.

Or people like really bite the bullet and use some of these other more painful systems and everybody hates their life. And the Five Flute team I think is really making a smart system that's designed for hardware developers. And so they're building things like issues that are fundamentally more visual.

So you can mark up a drawing together, draw pictures of around them, they integrate back into your CAD system so you can like point to individual pro like parts you're working on. Can. Your your kind of to-do lists write it natively in the tools you're doing your work and are, I think, are being really smart about how that integrates with supply chain and overseas manufacturers.

And so I'm really excited about about where that company's going. I think I see a path where they can make the process of hardware development, especially with remote collaborators higher quality, much, much more seamless and ultimately make everybody happier too. I think there's a huge opportunity for software to be built around these workflows that have been done very painfully and manually in the past, but I think we know better ways to do that today.

Yes, absolutely. I share your bias. And actually,  William Burke from Five Flute, who is the CEO is going to be on my podcast to talk about the design. Process and how it can be made better. You're so right that a lot of tools exist in the software realm for software people and software development.

Which they're very useful for that because they were created for it. However, when you get into the hardware realm, hardware and manufacturing and all of those things, unfortunately did not get digitized as quickly as software did. And I think that caught. Specifically with this type of issue tracking, it actually never made it to issue tracking at all.

And program management in the kind of hardware development realm always remained with people through spreadsheets and JIRA, and then also just a bunch of different ones that just model Jira and make it slightly better and then worse in other ways.  

For any given, even any given thing you're developing in a hardware product, the. To the changes has such a long lifetime, right? There's like a, we found a problem. Has anyone figured taken to the lab and done root calls on that thing. Okay, what was actually the problem?

Now how are we gonna fix it? Did we agree that's how we're gonna fix it? Ha has it been designed have we even built one of them yet? Did somebody prototype it yet? Did we do a control run at the factory? What did the reliability results look like? Did those work? Do we believe them?

Do we need to do more? Do we need to do a, like a pilot batch? Like the sort of the build. Side of all of those ch changes, goes on much, much longer than in some software products as well too. And so the full, like really tracking each of those items in a full life cycle way is just a different beast.

Definitely, when you have issues on software the turnaround is usually potentially weeks of sprinting and then you get a result and it's the, there aren't external entities that are involved. No lead times associated. The lead time is just basically the software engineer's effort and time.

But when it comes to hardware, as you said, like when you change a minute even design future. If it's being produced that, that is a whole change order in itself. And if you find a problem, , just bunch of different cycles of root cause analysis, testing redesign design reviews around that, and then It just it's such a cumbersome process.

And it's high risk too when you don't do it properly and you release products that are not quite ha haven't gone through the ringer with this, then you run the risk of getting it into consumer hands. And then those problems coming about then, which is the potential worst thing that could happen.

Yep. Absolut.

Yeah I completely agree with you. Five flute is, are they are the heroes and I hope that they are heard more and used more in hardware development and Hopefully further along than that. So that, that's, that was an excellent example I think. And so actually it's, it's a very good lead on to the next topic I wanted to talk to you about.

Right now there's a huge can I, AI storm, I like to call it. That started with chat, G B T. There were many others that followed after that. Right now, the, even people are talking about some jobs not existing because AI can just completely replace them, like graphic designers and even like journalism and stuff like that which is crazy.

 AI is, Slotting into our lives in a pretty aggressive way, in my opinion right now. And I wanted to get your two thoughts of how it's going to potentially change the way we do physical product development and how modern hardware is gonna change with the advances in ai.

Yep. Absolutely. I would I think we're, we'd be kidding ourselves if we said that AI is not. Threatens some of that like low end of the market around, around a lot of those creative professions. I think there's a lot of applications where the quality bar is not so strict and people are really looking for faster, lower cost options.

And I think that's that'll be really. That will be really challenging. But like I'm almost like a little bit less interested in that. Let's just make the same old thing, but in a cheaper, slightly crappier way. I think the most interesting stuff are the people like the.

The designers working with ai, I think like the AI replacing a designer is not quite as scary as who are the designers They're gonna work with AI like together. And so they are gonna be extremely competitive, I think. And so for some people just looking to keep up in a. Competitive professional market.

I think that's I really think it's an existential risk really, that the people need to be, like, trying these tools, think about it how it transformed their processes figuring out how to use them in an intelligent way. I think that's gonna be, yeah, a massive change for our, generation in the next couple years.

Some of the like specific areas we're like starting to see, I think as a concepting tool, some of these static image generation tools are fascinating. I've seen lots of people of incorporating them into their industrial design processes right now where you can really quickly get some like creative aesthetic form, language, directions and iterate on them really quickly.

And none of those are really like us. Renderings or models at the end of the day. But but you can really get through a lot of cycles at a conceptual level, that would've taken a a lot longer in the past. I've seen some people really produce some some interesting work there.

The, as far as like actual, geometry and things like that too. I think that'll be there's a lot of experimentation that's happening there. The, like AI is such a broad term too, right? Like in some cases it is used as a generative tool. Sometimes it's really pattern matching, doing kind of classification or anomaly detection on designs.

And there's a lot of companies that. Building rich software interfaces on top of traditional manufacturing processes that maybe can do like real-time quoting or real-time D F M or actually like suggesting design changes that maybe you would've had to talk to a salesperson and then talk to an engineer.

That might may have been like a multi-week process that you can start to do a, yeah, you can start to do a a first pass really quickly. So that's totally interesting. And I think there's like lots of applications and and I think really transformative things that'll, that will affect how we design things, how we manufacture things.

I think that's totally cool. Lots of stuff happening on, just on like generative  geometry as well too. I think people that are working at high level engineering constraints and letting some of the, like the AI systems actually like generate. Part geometry from those high level constraints is a a totally interesting area.

I think there's been lots of g great examples of people designing things that are much lower weight lower cost, but still meeting high level parameters that, that maybe wouldn't have it wouldn't have emerged from a more manual design process. And then there's also all of the crazy stuff too.

Like once, AI can actually integrate into the the human machine interface where you can start talking to things more than needing touch screens. Like where audio interfaces maybe can be richer. Where like, how frequently you're interacting with something can change things like that.

That's gonna, that's just gonna change product requirements, interactions in a really core way too. We'll have to kinda wait and see how like soon some of that stuff will really land, we all probably thought like voice assistance that would get better than they have been so far.

But we're definitely seeing an, a kinda exponential growth in the capabilities of some of those systems now. So that'll be really, important.

So your hypothesis is that  AI will be a very strong tool for nearly like collaboration on an individual level. So that rather than if you're coming up with ideas or you're doing designs, like AI will slot itself in in your personal kind of brainstorming 

we're definitely gonna see like more generative 3D stuff. Like people are rapidly working on that right now and it'll probably show up in the game industry a little bit first because I think like ever, programmatically expanding worlds and things like that, like maybe match some of the user experience there most directly, but they're gonna, I think start, start taking the baby steps towards really generating.

3D forms and shapes in a more generative way as well. And that's I think that'll be really interesting to do. There's lots of work around in a more traditional like engineering sense of doing not just generative parts, but generative assemblies of standard parts.

That I think is, there's lots of technical complexity, but if they all get worked out are super interesting. And yeah, so I. Lots of interesting stuff to see there. I think another interesting nuance is most of the news making AI stuff that we're seeing now are we're trained on mostly publicly available data sources.

And there's lots of ethical questions around are those training sources being like acknowledged or compensated appropriately and did they opt in, et cetera, et cetera. But I think there's gonna be more and more power in the future of letting people contribute their own kind of proprietary data sets to private models.

And you can imagine companies like uploading all of their mechanical designs to a private model where all designs in the future can make recommendations based on what parts have looked like in the past and maybe following, following some design rules that, that people have developed internally or have some like historic.

Like legacy weight too and things like that. And that, that gets really powerful as well too, where now you're starting to really like, develop more institutional knowledge about how things are designed by using some of these tools that maybe just existed more kind of word of mouth or culturally in the past.

 I feel like that's something that a lot of companies lose out on when they have retention issues. Is that kind of legacy and background and history around what different. Designs have been tried out and failed and all of that stuff. And AI goes off of data.

So if there's any type of documentation or model, it could just take it in. And give any type of A person that's starting on the project, ideas on what has been done and what can't be done and what the constraints were, and know what they are now it's super interesting.

  So do you feel like AI will ever make its way into production and manufac.

  There's lots of data that is required for manufacturing. Lots of data comes off of production lines all the time now too.

There are machines, like there, there's something more, more atom based than based there. But but yeah, I think there's a huge opportunity there. And there's, a lot that's existed in statistical process control and tuning that like is.

Applied statistics under a different name that like maybe could have been called AI in the past that like pe like manufacturing engineers have been doing for a long time too. So I, I think that there's, that, like a lot of that is already there too, where you're you're trying to tune massively complex numbers of parameters in a manufacturing process to achieve outcomes too that that I think a lot of that is has been happening.

And, but some of the more like modern approaches to AI machine learning I think can totally apply. In a manufacturing context certainly for things like predictive maintenance and like yield optimization things like.

Yeah. 

Thank you so much Tyler, for your time. This was incredibly helpful and awesome to think through with you.  If you have any last minute advice for hardware startups 

yeah, definitely. No, thank you so much for having me on. I think the. Biggest thing is just to acknowledge how long of a road it can be if you're developing a product, and especially if you're developing a company around the product at the same time too. And so like my general advice is just to make sure that there's a real, genuine passion from what you're working on to, and to set the bar really high for what you're doing.

And you want to be something you want to be. Like working on a problem that you're gonna be proud to tell your friends and family about. That if it takes five years, 10 years, that's gonna feel like a good use of time.  📍 And so I think that requires like a high level of ambition and a high level of like just personal motivation of what you're working on too.

And just don't settle for less than that, I think for yourself. If that's really what you're trying to do.

Awesome. Thank you so much. 

TL;DL

  All right. Welcome to our Too Long Didn't Listen segment. If you didn't have time to go through the entire episode, I am here to give you all of the key takeaways, actionable pieces, and tips that were covered in this episode. 

So in the Tyler Mincy episode, these are the following key takeaways. A program management strategy is unable to fit the needs of every type of product. So you need to be able to come up with a strategy,  for each,  You don't have to reinvent the wheel.

However, not all parts of program management strategy will be applicable, uh, to an innovation product. So for an innovation product, it is really important to have a demo based strategy so that you can test fast and learn fast. Other people call it fail fast, learn fast, whatever you want to call it. 

If the user experience is the most important part of the product, like it was for Apple, it is really important to have bench top tests and demos to get as close to the user experience as possible so that the engineering team  bought into the trajectory of the product. You want beautiful demos. However, if there are fundamental technological pieces that need to be de-risked or learned about a minimum viable  prototype so an ugly demo is a good strategy to deploy first, as well. 

Your tests. A k a demos should be structured to be as iterative as possible. A lot of designs get thrown out or get ne they are never used. This is normal in a part of the process. So, , make sure that the engineering teams, uh, remain in high morale and that that is an expected outcome. 



Making one of something is very different from making a million of that same thing. So when designing, if something causes a small problem, it's always important to multiply that, that problem with a million and see if the issue scales linearly. If so, fix it then and there. Don't let it go to a manufacturing line with the same issue.

Having high expectations and standards for design, fidelity is a good strategy. However, it can co, it can sometimes cause people to wait until they are too far along in the cycle to actually share work. So finding a good balance between high standards and collaboration and just, uh, , understanding and judgment free design team is very important.

Determining what metric you care about the most, whether it's form, fit or function. Obviously these can be deciphered into multiple sub metrics, , but understanding and determining what metrics you care about the most early on can help determine the hierarchy of decision making. This will speed up the overall team.

I e I. Apple had,  their design as their fundamental strategy. So the design team had primary authority. Usually teams struggle with making decisions, , fast. Either. There is a lack of clarity of autonomy and authority. So  making sure that your authority structure doesn't come about from just, a team's,  Actual character, but through, , the design requirements and what the company actually cares about.

Apple operated in a design build, test, sprint mentality, and those buckets of work were the ones that were set to run on time, no matter what, ,  which kept them on schedule. 

Design to some degree is really just making a set of arbitrary choices with some desired outcome within constraints that's quoting Tyler.

I think he said it very beautifully and very concisely.  If the constraints are the same, you end up, , with the same outcome no matter. What path you take or how hard you iterate, and every next iteration of the product should start by moving those constraints. Moving the constraints could be the role of an R&D team while the engineering team is working with the constraints in hand on the first generation, the R&D team could work on moving the needle on the constraints to set the second gen or the third gen up for success.

This could be a corporate strategy that, startups take. In the early stages of the company, specifically when raising rounds, it's important to have both technology and business viability validation in the forefront of the business strategy. So on the tech side,  what that means is a lot of prototypes and testing.

And on the business side, it's a lot of conversations with customers and the feedback loop that you achieve from them regarding the tech. So making sure that you're, , what you're building is working, but also making sure that you're building the right thing. . 

So this is where the episode kind of takes a shift into talking about the future of modern hardware development and machine learning in  ai.

And, , the key TA takeaways there,  to be summarized,  very shortly is the ability to work with AI is a skill that every working professional should utilize and embody as it will change the way you interact with the market. AI has the ability to speed up businesses and founders should not only utilize it, but also hire people that do.

And there's a lot of AI that is entering the engineering world from design and dfx to generative 3d. To FEA so looking out for technologies that can be implemented into your hardware company is always a really good strategy so that you can get ahead and work more efficiently. So hopefully those key takeaways were really, , valuable and spark some thought and I hope that they help you with your general strategy.

 The music for this podcast was brought to you by my friend and incredible musician, Joel, Caffey. 

 The Builder Circle is actively looking for people in the hardware industry and serving hardware entrepreneurs.

Please reach out to sponsorships@pratikdev.com that is pratikdev.com to inquire about getting featured on this podcast. Thank you so much and I hope you enjoyed the episode.