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

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

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

 Welcome to this episode of the builder circle today,  we're talking to Madhavi Gavini from droplet. 

Droplet is a company that has invented a misting tool that works to deliver active skincare ingredients into the skin . Better than just smearing it on your face. So they are a very interesting company that's working on,  relatively complex consumer electronics product and and Madhavi and I are going to be diving into,  the following questions that a lot of other founders might be facing today. So  Madhavi starts off by answering the question of how do you define the problem you choose to solve and how do you feel confident that it is a problem worth solving. It all starts from there. And then we go into discussion around how do you prove that  the solution or the approach you're taking is. Going to actually  solve the problem and it's the right solution. 

Madhavi then goes into talking about different pivots that she has had and her business.  Where I asked her, basically, have you had to make any pivots and how did you make that decision? What were the early onset writings on the wall that led you to consider a pivot? And what steps did you take to execute it successfully? Then she goes on to tell us about all of her.  Successful pivots and the reasoning behind them. Since this is a case study episode.  We'll dive into, , what make or buy decisions she's had and how she's strategically dealt with in sourcing and outsourcing. Then we'll break for a fun segment as we always do in these episodes. And she'll be talking about. 

Hardware horror stories where we go into some outrageous or bizarre hardware development stories that our guests have,  either heard or experienced themselves. Um, And then we'll  end the podcast on talking about failures. So what are the biggest failures?  Madhavi has learned the most from whether it's engineering, design, industrial design or production, and we'll end with the TL;DL segment, which is the too long didn't listen where  I will  📍 summarize all of the key takeaways and actionable items from the episode. So if you don't have time to listen to the full episode, 

 You can just scroll on to the end and get actionable advice from the TLDR. And when you have more time, you can come back and listen to the entire episode.  Without further ado. I leave you with Madhavi.    

Hello.  Welcome to the Builder Circle. Today I have Madhavi Gavini, with me, who is the founder and CEO of Droplet. 

So first to start off the podcast, thank you so much for being here. Madhavi. I'm so excited to have you.

My pleasure. I'm excited to be here.

So just so our listeners know who you are and your background and who they're listening to, could you give a rundown of your  background?

Yeah, absolutely. So I come from a technical background. My background's actually in mathematics and computational neuroscience. So before droplet I worked in drug design and drug development. So I was designing basically like computer algorithms to predict protein structures and then using that as a basis for designing therapeutics.

It's called like in silico drug design. And I worked really specifically on designing a class of drugs for a disease called pediatric cardiomyopathy, which is heart disease in children. It happens really commonly in children who have to undergo chemotherapeutics cuz they're hard on the heart. But it can also be congenital.

So really very classic like biotechnology, drug design and drug development.

Amazing. And could you also give us kind of a background around how you got into entrepreneurship and how you became a c e O of droplet?

Very organically. I can't say I ever thought I would like when I was in school. I never thought that I would be, starting a company and it definitely wasn't an aspiration of mine. And I found this is actually surprisingly common. A lot of the time you see a problem and then you wanna solve it and you realize the only way to do it or the most efficient way to do it is to just do it yourself.

And that's how I came to droplets. So, so as I mentioned, I worked in. Drug design. And several years ago we had designed a class of small molecule peptides that are efficient in treating fibrosis in the heart and vascular system. And we were really fortunate to get an orphan drug designation from the F D A.

And it was a big deal in the field because it was a first drug to get that designation for that disease since 1994. So the first one in like over 20 years. And , we were invited to give a talk on like new modalities of drug design and drug development at a conference. It was really intended to be like, Just a discussion around using computers to design drugs.

But the conference that year was around pediatric diseases and they chose to emphasize a type of rare skin disease called epidermal lysa. It's also called butterfly skin syndrome. And they wanted to bring awareness and like r and d to the field. So I had never heard of it before. And the paradigm in which I had existed up till then had been very much like, okay, you have a sick patient.

Somebody with my background designs a drug. We hand it off to the doctors, they treat the patient and they're cured. Problem solved Q E D. And that's not really how it works in a lot of fields in medicine. And dermatology's a really good example of it because even if we designed the drug that can cure, rare skin diseases like butterfly skin syndrome, you can't actually administer it to the patient and it's cause the delivery is a huge issue.

So in that particular disease case you have Patients who are missing a gene.  That codes for like a collagen protein basically connects your skin to the tissue below it. So if you're missing that gene, you're missing that protein and then your skin falls off.

And the DYS versions you have basically like a 90% mortality rate. And so it's just awful cuz it's pediatric, it's kids like, it's horrible. Even if it's a adult, like it's bad either way. Right? But it's especially like heartbreaking because you realize it's this genetic disease. It's kids, they don't really understand why they're in pain all the time and it has such a high mortality rate.

And the thing that was so shocking to me as a drug designer is like, we know exactly what drug will cure, right? It's just the gene. And we have the means obviously, in biotechnology to create. Large quantities of gene products, but in this particular disease case, it's delivery. That's the issue.

It's cuz your skin's a like a barrier. So there's no good way to deliver the gene back into skin. And that's what got me really interested in transdermal drug development. And my co-founder is a chemical engineer. So she worked in microfluidic devices and it really started off as a passion project.

So, we built early versions of it on my kitchen table at home. We were really lucky to get early funding. We were both working full-time, like when we, when we started building this. And it wasn't until we realized we had come across a design that was functional that we that we actually like, decided to jump, forward into making this a company.

And that was really the inspiration behind it.

That's awesome. And with that I'm gonna ask you to also describe what Droplet does right now. And we'll obviously get into the details of why it's slightly different now than it was in its original conception.

Yeah, so Droplet is really a platform technology. I have one on my desk. It's this little avocado shaped device. And like the way it really works is we take fluids, any fluid containing, small molecules or large molecules or genetic material, and it creates a high speed aerosol out of them that has a superior penetration profile into skin.

So it works fairly agnostically in terms of therapeutics or whatever we want to deliver. So the company, as it stands today, we have one side of the business where we're doing r and d with academic partners. Like we work with Tufts Medical Center. They're funded by the DoD. And we do work around things like  slow healing wounds or non-healing wounds and every deliver everything from genetic material to antibiotics to growth factors and things to help expedite wound healing.

So that's like one. Aspect of the business. But coming from the drug world, it takes a very long time to get technology FDA approved and into the hands of consumers. In parallel, we realize that there is a major consumer need for this as well, which is around everything from what we consider these like subclinical dermal conditions like.

Dry skin, mild atopic dermatitis and so on. So that's like straddling that category. And we build out a consumer arm of droplet where we take basically the same core technology and then we deliver skincare ingredients through it. And that includes ingredients that you've probably heard of, like, that are pretty common, like collagen or retinol or transy acid.

And they're used both cosmetically, but then also to treat skin, I wouldn't call it skin diseases, but like skin conditions, right? Like, like dry skin people who have blemishes or acne. You just see superior results when the ingredient actually gets in. And that's what the company's probably known for, because that's our consumer arm.

That's how we've been growing and generating business into revenue and so on.

Awesome. Yeah it's a very cool idea and I feel like it's something that I hadn't really seen in the market at all before. There's a lot of, I mean, there's a lot of sprays and such that you can spray on your skin. It's supposed to help. But this is a very it it's a huge augment on top of that.

And I know that there's some pretty hefty technology that goes into I'm sure there's a lot of research that goes into what the proper speed of molecules is. In addition to actually building it, which is the hardware component. It's pretty sophisticated. It's a really cool product.

So, listeners should definitely check it out. And so with that comes when you're building a, even a small held device or any type of hardware comes a lot of responsibility and especially this is a very consumer facing product. It also interacts with the body. And that is also an additional responsibility That's I'm assuming, stressful in some capacity.

Because failure is less of an option with this. It's not like, oh, it broke and it's just needs replacement. It's like, oh, if it does something wrong, it could harm someone potentially. So I feel like it's really Interesting topic at hand and I really appreciate talking about consumer electronics because it has so many layers to discuss.

So going on it from the very technical side of building,  I would love to start from the very important conception of the problem that you saw and this as a solution. So, how did you go about defining the problem you were solving and how did, when and how did you feel confident that the problem was worth solving and that your solution was the correct solution for that problem?

Yeah, that's a really good question. So I'm one of those annoying people that believes that 90% of problem solving is accurately defining the problem. And

Not 

annoying. That is correct.

so, so for us it was very much starting with. I would call it design constraints. I think that was the biggest thing from day one. So those constraints to us were first and foremost, it has to be able to get things into the skin or it doesn't work. Like that's the whole point. So you have to achieve effective delivery and then it needs to be painless.

And lastly, it has to be consistent, like it has to be reproducible and something that you can do every single time. So those were our guiding constraints around around building out this hardware. And it took us quite a while to convince ourselves. So we built the very first prototype on my kitchen table at home.

And we actually tested it with a large molecular weight CH four, basically heavy food dye. It's a fancy way of saying that. And we tested it into basically into what we pitch to investors as a. Animal based skin eggplant, which is really just chicken that we bought from Whole Foods. 

That's awesome.

Scrappy.

yeah.

And so the first so we bought components off of Alibaba and and CVS and Amazon, and we built this like very early version of it. And I think that we got very lucky because quite early in the development process, we built a test module that was able to get effective delivery through that chicken skin.

And so we knew, okay, so we knew we had something, we're like, wow, we got it to work. And then we couldn't reproduce it. Like we just couldn't recreate it for a while. But because we had that early success, we knew that it was like theoretically viable and that's a big part of what kind of drove us to keep working on it.

Just trying to recapture that and recreate it. The other thing is, I think you hear a lot of stories about Like really brilliant founders who were like, I have this theory, and then they tested and it works. That was not us. We had a theory, we built an early module that worked that worked the one time, like I said, and then we were unable to reproduce it for quite some time after that, in large part because our initial theory of why it worked was completely wrong.

We had this model in our head of like the fluid physics that was driving it. And it took us a while to try to reproduce it and go down that, that theoretical path before we realized that we were just way off base and we course corrected and went back to like first principles.

So I think for us it was a ton of trial and error, but it was just this huge element of luck that we have to acknowledge, which was if we hadn't gotten it to work on a fluke that first time, we never would've continued to pursue that. And.

And eventually like cracked, like, okay, how is it working?

And then going from there to building it in a way that was reproducible and consistent and so on.

That's so interesting because  I feel like the story always is the opposite of that, where people have a problem, they have a solution, they build it, it doesn't work a million times, and then the one after them million, it works and Eureka it's a product. Whereas yours was, oh, it works.

Oh wait, hold on. We, what did we do last night? That it doesn't it's not happening right now.  But I guess it was I guess it was in the stars or the universe really wanted you to do this because I have a feeling that both of you being incredible scientists, you're very data driven.

So if you had seen that it didn't work, you'd be like, okay, the data's pointing that this is not gonna work and not pursued it. So I guess, When in, in terms of your situation is a little different, I guess, in terms of seeing the problem because you were so deeply familiar with the problem, right?

Because you were in drug development and you went to all of these conferences where people I mean, you said this in the beginning when you were introducing yourself.  The problem was so apparent and it came up over and over again. So it's also luck, I think, and obviously really hard work and education that got you to a point where that problem was so obvious and you had a lot of data and a lot of other really smart people backing it being a problem.

I guess the solution fit part was the actual huge strike of luck where you saw that there was potential of it working. You didn't understand the fundamentals of why, but you did see that it worked, so it was enough to continue that spark. Am I reading that right?

Yeah, I think that's exactly right. And I think I think what the thing is, the reason we thought it was initially working was a model we had built right, like a fluid physics model we'd built. And then once we realized that wasn't the case and we went back to first principles, it actually ended up being like a much more interesting thing that was happening.

And that part of it, it's just a little bit of that geeky like math and fluid physics and like what's actually driving the delivery. I think that also helps keep you super motivated because you realize you've really stumbled on something that's just fundamentally exciting as well.

But I would agree, I think in biopharma especially, it's very much a case of the problems are so apparent and that's true for any disease, right? So you know that if you build something effective that people will use it because it's such a huge pain point, which is a little different than consumer products.

And I think now with a company that has, the majority of our presence in the consumer category like that's where we've evolved. It's very much a case of finding product market fits. So we've explored both sides of it.

Definitely. Well, actually, I that, that makes me want to talk about exactly what you said pivots where a lot of companies experienced this, hopefully early on, because later on the,  change management of that would get very sticky. But early on, when. Very early stage companies and very early stage products are being developed.

There is this constant battle especially if it's something completely novel to find that correct product market fit so that you are, your technology or whatever you're developing is cornering the market in a way that it becomes a market killer and it has a huge competitive edge. And oftentimes finding that is not a straightforward process.

It can be for some very edge cases, but most of the time that is what a lot of companies really struggle with. And the problem that I've seen, Overall is sometimes people over subscribe themselves where they have five products that they wanna produce early on. And I'll give a hint, that is not how you do it.

You need to pick a focus and then go forward. But sometimes that focus might not be the right one. So you with hopefully enough data and intuition you do a pivot. So I know that droplet has done pivots or a pivot so I would love to learn more about how did you make the decision?

What were the early onset writings on the wall that led you to consider a pivot, and what steps did you take to execute it successfully?

That's a good question. So we've done multiple pivots in different aspects of the business. I wouldn't say, I wouldn't say it's been like a full sort of 180 every time around the business case. But we've had things where we thought this was the way to go, and then we've had data that indicated otherwise and we've changed our mind.

So I'd say the first one for us is We, because we had approached this very much as a medical device consumer wasn't on our mind for the first like when we were first building the technology. And this was very much a case of listening to what other people said when we talked to 'em about it and then realizing that they're really odd to something.

Like if you hear something enough times, you're like, okay that's, that's what we should be doing. So for us it was we had thought about using droplet to treat. Rare skin diseases, whether it was like genetic where we're doing gene therapy or diabetic foot ulcers where we're delivering antibiotics.

And to be clear, we still very much believe in that and are interested in it, and are doing active r and d in that field. So it's not like that's gone away. But we realized that there is a huge consumer angle here. And that came from the fact that, we would talk to family or friends about it and they'd say okay, but can I use this to get Botox into my face?

That was this recurring thing. And the answer to that is, is no you should never aerosolize Botox. It's a neurotoxin. Please don't do that. But the point of like delivering ingredients like effectively into your skin, that, that actually makes a lot of sense. And then we also realized talking to dermatologists that this is a huge pain point.

Like you don't need to necessarily first solve or only solve the rare deadly disease like, Skin issues are like, they affect a huge swatch of people. They're painful. It's absolutely a pain point. And it's everything from like subclinical like dry skin to to actual, non-painful conditions like melasma to things like acne.

Like these are actual things that we could effectively solve and that have huge impacts on people's quality of life. So I think that was sort of the first pivot for us. And I think for us it was around focusing on something like trying to find a category that we could really build on. And I think what's exciting about having a platform is you have sort of infinite potential in a lot of ways.

And the hard part, the discipline part is like fix fixating on something and building that out. So that was the very first one we did. We had sort of a secondary pivot down the line where, We were trying to figure out where to launch our consumer products. So when we first thought about launching, we thought, we're gonna sell this to dermatologists.

Like we've talked to doctors, they worked with us to design the product, to test it. Like we had great relationships with them. And this was in 2020. And the way a lot of derm offices work in K C U or your audience are not familiar with it, is they will pre-order their products for the year in Q1 and then sell that through the year.

So you really want to get your orders in the first half of the year, like, maybe not q1, cuz it's experimental, but you wanna get it in the early part of the year. So for us, we were planning on launching in 2020. And around April of 2020, the world changed. And unfortunately, a lot of the clinics that we were talking to shut down.

They were not considered an essential business. Like if they were they were open for things like MO surgery, like skin cancer treatments, but not so much for anything else. So we were in a position where we had fully expected to sell through that channel, and we were getting calls from clinicians who we had worked with, and they were wonderful.

 I totally understand where they're coming from, but they're like, we just, we can't do it. Like, we can't, we're not open. We have all this inventory that we're sitting on, like, we can't this isn't gonna work for us this year. And as a business, you have to launch, you have to generate revenue, like you still have to operate.

And so we couldn't just shut down because of that. So we said, okay. We're gonna build a website and we're gonna just sell directly through our website and see what happens. And really because of that, we ended up becoming a direct to consumer business. And ultimately that ended up being a better business model for us.

So it's a pivot sort of from necessity. And it was definitely a really hard thing because, we're a company at the time of technologists, we didn't have marketing people really on the team, and it wasn't something we knew anything about. But you were forced to do it and we did it.

And then I think the third part, sorry, there's a lot of pivots here. On the hardware itself, we put we had this slightly over-engineered concept at the beginning when we first launched, and it was. As one does, right? Because you don't really know the realities of the world or hardware. So we had the device and just for context, the device comes with like, you purchased these capsules and there's just these little pods and they come with ingredients in them and you put 'em in the device and the device dispenses that we had built out this like slightly overly complex chip and chip reader system.

So each capsule was chipped. And it had a reader in the device that'd be able to tell you what, what was on there, and then you could transmit that data to an app. And it's a cool concept, right? Around compliance and all of those things. And we were really into it. And it ended up being just a disaster because shipping adds so much cost to your, to your capsules, it's like just not available.

And the reader had a copper basically it was like it had copper on the reader, like it was coded on that and it would corrode anytime it had liquid. And this is a liquid dispensing device. So that was like probably the third big one. And we were probably in the market for, I don't know, two months, or not even two months, month and a half.

And it was our beta launch. So it was a small number. And my co-founder was, I. She was like I just don't think this is a good idea. We have to take the chip reader out of it. And we made that decision really quickly and then just eliminated and scrapped that whole process.

And and that was definitely a big one cuz that had been such a fundamental part for us, of the concept of it. And in hindsight, two years later I'm like, oh, that was really stupid and over-engineered. But, it made perfect sense at the time. So we've definitely gone through our fair share of pivots and uh, hardware mistakes.

Yeah I feel like that happens very often because when you're looking at the same problem for a really long time nose deep, those. Those kinds of evaluations naturally come to a crashing halt. You stop evaluating certain subsystems and why they're there. So it, this is, I feel like a really good kind of advice point for listeners who are building something that always keep asking the why.

When you're looking at your subsystems, especially when you are at your minimum viable product stage and you have, you'll have an over-engineered, more expensive, complex product at first, that is totally normal. But I think it's always important to continuously evaluate so that you can catch these hopefully early on when not a lot of them have been produced.

Exactly.

that change order, I'm sure I'm good thing that it was beta. I'm sure that you didn't have a ton of units in your inventory, but still I'm sure that it was a big change order with your producers.

Yeah it definitely it definitely was the bigger thing was we had pre-ordered. So many, like, I wanna say half a million of those chips.

Oh, wow.

Yeah. And I think that's why it's a call, it's very much sunk cost. Like it's very easy to go down sunk cost fallacy with this stuff. Yeah. And so, so we had it paired with an app and the app's primary functionality at that point was to read the capsule so we could say, congratulations you used your retinol or used your collagen.

And so we basically were forced to go back once again to first principles and think, okay, what's the primary value to the consumer and what we had sort of. In on as a primary value is the ability to get an ingredient into your skin. Everything else is fundamentally like, it's nice to have, but in a way it's a little bit window dressing.

And it took us a year and a half after that and then we relaunched our app and it has so much more functionality right now. And we're able to, in, in many ways to get some of that usage data without beating a chip system. So it ended up being for the best. But it was a tough call because we had spent time and effort and just like, it was a hard problem to solve, to design a chip and chip reader.

And I think as an engineer, as a scientist, when you spend a lot of time solving a hard problem, it's very difficult to then just scrap it.

Definitely I think that is a huge lesson that not a lot of people talk about. And I feel like when you're writing your initial  system requirements, even if you're not sure categorizing in that very simple way of just is this a need, a want or a nice to have? And sometimes that's not obvious and that's okay.

And as you learn, going back to the drawing board and evaluating that will only save a lot of headache. 

So going into I guess like the whole design of the droplet module and everything, when you were deciding how to build this, I'm sure that you had to think about a lot of parts of it because it is a consumer product, so there's some industrial design involved.

It's a hardware product. So there's a lot of electrical work involved, mechanical design work involved, and then you have your production. When you were thinking through all of those things, how did you go about making decisions regarding insourcing or outsourcing?

It's a really, it's a good question, and I think the way we think about it is if something is either like a fundamental asset to the business, like at Droplette we are very good at, X thing, then  we bring  that particular skill in house. So it's a resource we can always rely on and improve.

And so for example we have a pretty robust engineering team that continues to do R&D and continues to like, build, the gen 2 when they're working on like a new, even a new version of droplet. So, so that's something that we bring in house. And then I think the other way we think about what we bring in house is  if it's something that we're. We're probably going to be producing like tens of millions of, and it doesn't already exist in the market. Like if there isn't an existing outsource solution, we'll bring it in-house. And for us, that was investing in automation to fill and seal our capsules, basically build with a partner. These robots that are able to at mass scale produce these and it's able to bring the labor costs down substantially for making capsules.

That's why we're able to offer them at the price we can to our customers. So those were two areas where it just made a lot of sense to do it. I think conversely where it makes sense for us at least to outsource is if somebody if it requires like a super unique skill that we will use to build a version, but it's not something that we're consistently iterating or building on, it makes sense to outsource.

So a really good example would be device production. We're not the experts in like precision tooling or or manufacturing an assembly for hardware. So we worked with a vendor who, who is and then similarly for certain things, like, especially in the early days, right, because you just don't wanna be top, too top heavy as an organization for certain things like firmware.

We had that outsourced with a consultant and and that made sense. And then obviously as we scaled, we started to do more and more with it. We eventually brought that capability in house.

Gotcha. And. When you were choosing to that makes a lot of sense. Having your kind of fundamental institutional knowledge, bits and pieces stay within the company. And then the parts that kind of come in and out where the level of effort is maybe 80% when you're doing a particular sprint, but then 0% when you're just focusing on other stuff makes sense to outsource.

Yeah. Industrial design's another good example of that, right? It's like a, it's very much a project, but then once you have the industrial design,

The majority of changes in iterations you're making aren't fundamentally changing the form factor or changing it in such, they're not changing it in such a substantive way that you need like a full-time industrial designer,

Right. Unless you're building maybe different. Different modules that look different, and you have 16 products that require different designs and their gens keep changing. And it's this ongoing effort to constantly design, which then definitely have it in-house so that you also build on your brand because there's you don't want a industrial company coming in, making something, and then another one coming in, which like, they have a completely different vision on your product.

Right, exactly.

That makes a lot of sense. When you decided to produce droplet out, when you decided to outsource the production of droplet, do you produce them in the US or are they done overseas?

So far everything's been produced domestically. And we actually found a manufacturer that was local to us in Boston. So we work with a company called East West, and they have sites in Boston and they have sites all over the world. They're in Vietnam, they're in China. And we chose to work with them for a couple of reasons.

One is they're just good, right? So that's like the first thing you look for, of course. But the second was they were actually located in a city of Boston building and we rented the floor above them and.

Wow.

Advantage of that is we had the ability, and they were so flexible, but we had the ability to pop in and out and really have our engineering team like be on the floor during the first parts of production.

Anytime we made a change to the production plan or documentation or even componentry in there, we had people who could oversee that process. We could get. Product from them to us to test and vice versa. Like send things back. And it was super efficient. And so it was, I mean, they're absolutely their own company, but in some ways it felt a little bit like having it in house just because of the physical proximity to them and their willingness to work collaboratively with us on it.

So that was, that's exactly why we chose to work with them. For this process. They do have facilities outside of the US and so we are like, we are moving some of the production there, but it was after a couple of years of really honing in on the design, working with their team to take as much labor out of the process as possible.

And then the thing that they bring to the table outside of their US location is the ability to do like really precision tooling and they just have certain types of. Like when you're building to a certain scale, you can't support that locally, but you can support that internationally. So that's how we think about it.

And then as we release new versions of droplet down the line, it's probably going to be a mix. Some of it will be done domestically, some of it will be done internationally.

Gotcha. That makes sense. And I feel like that is a strength of subcontract manufacturers that's becoming pretty mainstream these days where they have US shops, which the press per unit is probably pretty high. But then they have secondary facilities that are either in Mexico or it other places.

And. You go into them with almost like a prototype in mind. You do some design optimization, some process optimization, which is huge on red, reduction of labor cost. And then from there you can scale up and seeing with the same partner is also really nice because they start to build institutional knowledge and they're usually also bought into the mission at that point.

If it's working out well, that is, some don't, and it's good to figure that out early on and potentially have some contingencies. But that's excellent. I don't think I've ever heard such a good situation when it comes to contract manufacturing. That sounds like an excellent deal you guys got.

Yeah, no we definitely have been really fortunate with them. And I think the other thing, and I think you alluded to this, is around institutional knowledge. Like they build up institutional knowledge on your product, but they also have seen so many products. They've seen so many things work and fail.

And so the ability to work with somebody with that kind of pattern recognition and institutional knowledge is absolutely incredible. And that's just something that you have to outsource. Like it's not affordable as a company to bring to hire that type of institutional knowledge in-house.

It's just so many people across so many verticals.

Definitely, I feel like mostly I the pattern that I see and feel free to disagree, but most of the time when you are insourcing production, it's for very large equipment or systems that truly no one else has the bandwidth nor the knowledge to be able to make. But when it's I guess smaller and there's some transferrable skillsets, it is usually in the best interest to outsource and remain, continue to have your team be good at what they are good at and continue providing.

Providing value there and then having the experts externally take care of the rest.

Yeah, I think that's a, I think that's a really fair paradigm and  📍 I agree with that.

Podcast Break

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. 

Now let's do a little fun segment on hardware. So going through the development process, I'm sure that you've had a bunch of this happen. So I like to call this segment hardware horror stories. I usually have my speakers pick one of three segments, and this one is by far the most popular, not surprising, because hardware is hard.

Sure, we have a couple. I shared obviously, and I think everyone has a few of these. We shared obviously the thing with the chip with the capsule chips where we were manually chipping them which was a complete disaster and never doing that again, lesson learned. But we had a second one, which was also during our beta, the beta launches rough.

It was during our beta and we we basically had a firmware bug that did not become apparent until like several weeks or days in use. And what would happen is it was basically an issue with the real time clock. On the circuit, like within the, within our Bluetooth module. And it would basically take the device and turn it, put it into this stationary, like stasis kind of position where it would not turn on.

You could not, and there was no manual reset. And the only thing that we could do was flash new firmware onto it through the app. But our app was not enabled at the time for a new firm. Like we just, we didn't have the ability to do that. So this was during the beta, it was over Christmas in New Years, and it was before we had anyone in customer service.

So it was me and my co-founder, Rathi, customer service for that for that period of time with our beta customers who were also just like incredibly understanding, like they were absolutely fantastic. But they would contact us and they'd be like, my device isn't working. And we would We were manning it basically 24 7, like we were sleeping in shifts doing this.

So we'd be able to respond a couple of minutes and we would like manually have them connect to the app, manually, connect their app, like to the firmware on the back end and push the new update. And this was maybe 500 or so devices in the field.

goodness.

Wow.

yeah, so we've learned a lot from that. We now as you can imagine, that's like one way to get a point across.

And so we we currently do very long field tests. As a result of that we make sure all of our field tests exceed several weeks. And do pretty extensive like testing to destruction as a result of that. And we're very sensitive to any, cuz the thing that happened is it would have these little mini freezes on the firmware side that we realized were like indicative of the problem starting.

But then you could press the on off button a couple times and it would restart no problem until it went into that mode. So now if there's anything even slightly off with any of the functionality we have, we put it into tests until destruction.

Interesting. I mean, that makes a lot of sense. It's so th this is great because I love having this horror story segment because patterns emerge and one of the patterns seems to be lifecycle testing. People don't think of this in the forefront because it's all about getting the minimum viable product out there into consumer hands so that you learn as much, which is definitely a kind of l a fail fast, learn fast method.

I, I'm not completely against it, but this could, I, would you say that this could have been easily prevented if there was like some level of like life cycle test that was done beforehand?

I think it's around how long does the lifecycle testing have to actually be. And I think that for us, that was the learning, right? Like your lifecycle testing has we do what we call extended lifetime testing now, where we run it for the equivalent of two years before, before we ever approve a design release.

And and that's on the Yeah, and that's because we presume if nothing happens after two to three years of like functional use it's probably good to go. But I think that was the big learning here cuz we had run it for a couple of weeks and it was fine and this just wasn't even on our radar as a potential fail point.

So in a lot of ways you have to you have to experience it firsthand to understand it. I think.

Oh, definitely. That is super interesting. And I'm sure that you had a lot it's very unfortunate that happened during Christmas and New Year's. Not the best way to spend family time, I'm assuming.

No. No, but it was it definitely left an impression,

Oh, good. Yeah. That's why you now do destructive testing. I, that, that makes a ton of sense. And I mean, oftentimes it really depends on your product too, sometimes. Okay. Their life cycle might be two years, and there's a terminology called safety factor where you wanna maybe double that. 

Planes usually have a safety factor of like 10. Where if they one of the coolest little facts I know is that each plane has, if they have like one set of wires going from one part of the plane to the next, they have 10 others that circulate around the plane. So if the plane experiences some type of perturbation on one side, all of the others would survive, and you would still have communication with your rudder and your wings and stuff. Anyway, I digress. But

it makes perfect sense.

Safety factor is

For planes, that's especially important.

right?

And yeah. Or elevators and such. But even in in consumer electronics, depending on how much risk you wanna take, you can crank that up, maybe not to 10, because then that becomes an over-engineered product. But two, three, that's oftentimes reasonable.

Right. Well, I think that actually leads to a slightly interesting, perhaps digression, but it's around where you want your hardware to fail on a consumer product. So for us, like the safety measures we have in place mean that where we, like where you will have a hardware failure is the failure modality will be the device doesn't turn on right.

Which is bad, like, don't get me wrong, but it is much better than your device will overheat or your device will shock you. So it's, there's definitely Some element of like, where do you put that risk into your hardware? And I think for us, the choice we've made very early on, and in part because of some of the engineers who we work with, who've had their own set of historical horror stories at previous companies.

It's been, well, if this fails and the failure mode is gonna be, it doesn't turn on.

Yeah. Yeah. It's the fundamental of failure mode I guess trade off in a way, because you will have failure modes and w certain ones will be more They will have more likelihood than others, but when you're building a product and you're trying to move fast, you're always gonna have those trade offs.

Right. And with hardware, inherently you will, because some percentage of PCBs just will fail, right? Like

Of course.

inherent in the production the best companies in the world have like a certain. Break rate when it comes to electronics, and that's true component by component.

So it's I think that's I think that's equally important, to get that, to make sure your failure is one that is annoying, but not detrimental to your end user.

That actually makes me wanna talk about risks. So when you were first designing this, did you think about risks? Did you track risks at all? I mean, that might sound like a potentially silly question, but I've seen so many people that don't, so I'm just curious.

Yeah. Risk is definite, well, once again, I think this is a holdover coming from the pharma world, right? Because if you create a drug and you add an impurity to it, you can kill somebody. So your concept of risk or equally badly, you may not effectively treat the illness, which could result in a really adverse impact on your patient.

So, So I think coming from that, our sensitivity to risk and like harm to the end user was sort of, once again like a guiding principle. Like what can we do to prevent that? And so for us we added things like, like they're misters in there so that if you ever had overheating, the whole system just turns off.

So, so a lot of the engineering that's gone into it has been around. We know there's inherent, we know that there's inherent hardware risk. And so, once again, making sure that we can plan for all of those contingencies and making sure that we can dictate the failure mode.

I think that was very much the way we thought about it.

Of course, you want to hit a certain quality level and there's, that's but to us that's that's almost secondary to like the failure and secondary to engineering the failure mode into a way you want it to be.

Yeah, I mean, that's a good point because risks are they come in multiple categories depending on what product you're doing. But in, in what you were saying, there are certain risks that are just accepted because like PCBs for example, when they have a certain yield and if you get bad ones, they're gonna turn out bad and there's nothing you can do about it.

But then there are risks that. Require some level of quality assurance or some level of testing, or some level of supply chain management where it truly is on the business to notice and have a mitigation plan in place. And oftentimes that mitigation plan can look like a r and d project where they're trying to technically risk mitigate or it could look something like having a supply chain team working on long lead items and so on and so forth.

It's really important to categorize that early on. Oftentimes you, you don't know what you don't know, so it's hard to do that. Do you have any comments on that?

No, I think that's right. And I think the way we handle it is when we do have, like, when you go from. When you change components, you change manufac, like not manufacturers, but suppliers. You sometimes have changes in functionality that can result in a bad batch. And the way we've handled it is a little bit from a customer care side as well, which is we have a two year warranty right on the product.

We understand if you were a super early adopter that we wouldn't be here without you and there's a lot of gratitude obviously, that we have for our customers. And so if you bought into to our product or a platform and it's not like something went wrong, like your device failed or something didn't work out we will replace it.

No questions asked. And we've extended our warranty the two years to support that because ultimately for us we believe that this will be like the future of skin delivery or skincare. So we want you on our platform and we wanna make sure that your hardware's working. Cuz if it isn't you obviously.

Can't be using it. So that's so, so I think that it's a combination of treating it by obviously doing your engineering diligence and trying to make sure you build as high quality a product as possible, trying to track changes or track mistakes and address it as quickly as possible. And then of course, it's a huge customer care thing.

It's having policies that are as consumer friendly as possible.

Definitely that makes a lot of sense. So to, to wrap up I know that we've gone through horror stories. You've you've mentioned some pivots that you've made in in creating the droplet module. In, in your mind, what have been the biggest failures that you've learned from the most lessons from, whether it be engineering design or industrial design or production.

Also the biggest wins, right. I don't wanna just end constantly on the negative note. I feel like I'm constantly pounding people just like, what went wrong? Tell me. And but there's also things that I'm sure went really right. So, that ying and yang, if you could talk to that.

Yeah, I think that the way, so I think one thing we've seen is sometimes when. You do have a failure whether it was like with the firmware the firmware bug, and the chips and the chip reader and the first version of the app, we launched way back in 2020. The, you turn the failure, you can turn the failure into an asset over time.

So now, like fast forward two years later, right? We learned we learned a ton from the experience and we relaunched an app last year. That's completely different than what we had in 2020. And what the app does is it acts a little bit like a remote control for your device. So you can take your droplet device and you can turn it into you can put it into modes for targeted treatments.

And some of them are fun, like there's a lip plumping mode, which is really popular. Some of them are more functional, like, there's a blemish mode to treat acne. There's like modes for under eyes. So there's sort of these and then there's modes for specific capsules. And so what I realized is the vision we had for the app, which was really just a tracker, it was almost like Strava for your device usage, if you will.

It's not like that's what we had launched with way back in 20, in 2020. And that if we had not had that failure, like if that system had worked perfectly today, we would have a product with a much higher and possibly like unaffordable production price point for the capsules, which means we would've had to charge more to our customers in order to like basically support it.

And we would have an app whose only functional feature was tracking. And now because of that failure and because we were able to pivot from that, we're able to. Sort of pay those cost savings forward to our customers on the capsule side, which is great. And we're able to create, to take this single piece of hardware and actually give it, half a dozen.

And obviously as we grow, it'll be a lot more sort of targeted modalities of treatment. So our customers can get way more out of that one piece of hardware. And then for the formulations or the capsules they put into it, they can once again use it for a variety of things. Like, a simple example is collagen is our most popular product.

We have people who use it across their whole face. We have people who use it to treat their under eyes. We have people who use it to treat their acne scars, people who use it to treat like dry skin or eczema patches, right? Like you see all these types of different treatment modes. And I think that entire functionality wouldn't exist if we had been successful the first time.

And I think a lot of the time  You know, it's, it's learning from that failure and kind of using it to create something that's even better.

I love that is a perfect way to spin, I keep hearing this, right? Give yourself space to fail. Failing is not a bad thing because the learnings from that actually guide you to the path that you're supposed to be on, and oftentimes where your product is supposed to be on.

Right, right. And I think there's also we hear this from investors, which is like, fail fast and fail cheaply.

Yeah.

 And I think that's also part of it, which is like being able to acknowledge when something's not working and then being able to pivot from that versus doggedly pursuing that initial path because you thought that's how something should be.

Yeah. And I feel like, the startup ecosystem and culture really doesn't do the, oh, this has always been the way we've done it, that does not quite exist here.

Right, right. I also think there's an element of ego to it as well, which is um, yeah. As a founder, like you might have a few good ideas, but you're gonna have a lot of bad ones. And so it's important to weed out the bad ones as quickly as possible.

Yeah. And have the humility and vulnerability to one, put those I ideas out there and be open to criticism from whether it is your team, your co-founder, your investors, your advisors, and then evaluate. And if the advice is consistent and it has some level of data that's backing it, move on.

It make moves on it, it is, I think, much more respectable to change your mind than to have a very poorly failed product.

Right. I think I have a pet peeve, which is around, and he sees this in media all the time, like in movies or TV, around the idea of like the lone Wolf brilliant founder who is like creating something and everyone tells 'em it's a bad idea, but they're ultimately right at the end.

Like that's just not reality. That's fiction. So yeah, I would say they don't model your life on that.

That, that's awesome. I mean, I usually end the podcast with asking my my, my speakers to say like, what would you recommend to hardware leaders? But I feel like that's a advice. But if there's any other advice you'd wanna give the stage, the the, there is no stage here, but the microphone is yours.

I think it would be very much that, and to an extent building on that, which is find find people who will challenge you and in, in a productive way. Not people who are just out to get you, but people who will constructively and productively challenge you and we'll work with you to make things to make, to come up with an even better solution.

And I think I've been really fortunate in that my co-founder, Rathi, is, comes from a different, like a different academic background, right? She's a chemical engineer, so we come from slightly different angles when we approach things. And I think as consumers we're also two very different consumer types.

And so what will often happen is, She will have an idea or I will have an idea and the other person will be like not sure if I would end up buying that. And when we hash it out and we get something that we both are equally bought into, it ends up being a much better product. And I think that's the sort of healthy like conflict and challenge that you need to, you, you wanna have in your company and what you wanna create.

I love that. It's so true because if you constantly have people that are saying yes to what you're saying, it's not a diverse pool of data. And oftentimes you need those tensions and you need that diversity so that you get to the right product and innovative solution.

Yeah, absolutely. And I think also one thing we've worked really hard on, on the product side, what at Droplet is we have pretty good representation across aged groups as well. We have we have our Gen Zs who represent us. Certain type of consumers. I'm a millennial, Rai's a millennial, and then we have people who are Gen X or baby boomers who certainly have like a really strong point of view on the types of products they would like.

And so once again, when you can find a product that hits at least two or three of those categories, that's when you know you have a winner.

I, I love that as well. Well, thank you so much Madhavi. It was so, so nice to have you. This is all incredibly important and useful information that I know that our hardware listeners and builders will greatly appreciate. So thank you so much.

Thank you so much for having me. This was a lot of fun. 

TL;DL

Hello, and welcome to the TLD L segment of this episode. Either you have listened to the entire episode and you're grabbing a notebook, grabbing your laptop, and you want to take down notes of what. We learned today in this episode, or you are in a rush, 

and accompany, you're building something and you really just want to get out, the most actionable pieces of this episode. And,  next time. I hope that you'll be able to, start from the beginning and listen to the entire episode because it's a really good one, Madhavi is a wonderful person and she is a very successful entrepreneur.  I'm here to boil it down to, uh, some key takeaways so that you can go on with your day, go on with your product and. Hopefully it will help you determine the next steps that you need to take. Okay, so starting off. Madhavi starts the episode with saying that 90% of problem solving is accurately defining the problem. 

And as you define the problem, it's really important to immediately go into tests to understand viability, so trial and error. If you see a spark follow it. And if it worked once it'll work again. But you really need to understand the root cause of this success. Madhavi goes into the,  story where her and her co-founder got really lucky. And when they first tried out there, 

Initial prototype that was super scrappy. It actually gave them really good results, but they were unable to reliably reproduce those results. Even though they weren't able to reliably reproduce it, the fact that they had done it once they knew that they could do again. Not all of us are that lucky at times, but it is really important, , to also celebrate your successes and go on that gut feeling but continue on testing so that you can prove reliability as well.  When building a product, listen to what people say. When you talk about your product, try to pick up on patterns.  one example is droplet. When they started, when they started off with this missing device, they really wanted to gear it to cure serious skin diseases and anchored on a medical application. 

But then when their friends and family and others kept asking about daily skincare they pivoted and continued to work on medical applications as their R and D. And they realized that they, their addressable market was much larger when you go into daily skincare, which was better for the business and the technology transferred really well. 

Always continue to ask why, especially during the early stages of the design process, , because there will be a lot of over-engineered features that should always be re-evaluated as time goes by. , one really important point that Madhavi made was the sunk cost fallacy. Where, , basically. You. 

Either buy or put in a lot of effort and time, or you don't have a team that's putting a lot of effort into time and time into a feature that really do you find out later that doesn't really have to exist, but because there's so much time. Money or other things that are invested in it, you continue down the path because you're , oh, it's just sunk cost. , I'm just going to continue it. 

But  It ends up hurting your product and your market and everything else in the long run. So it's important to not fall into the trap of that.  An example was the droplet had bought a half a million chips that they ended up scrapping because, there were a lot of integration issues and it was a feature that was not intended in their product. 

It would have caused them multi-millions and likely some very upset customers if they had pursued it in the feature. and it would have been a failure mode that kept coming up. So.  Instead, , they decided to get rid of the feature.  but, and they didn't fall into that sunk cost fallacy because they had  already bought so many. 

, this is a really important point.  Obviously ego gets attached to products that are built, whether it's a, an engineer or an entrepreneur. So making. Making sure that you check yourself out the door. And when. Pushing for a feature really reflect on why. 

And if it's, if it's \ user data, people really want it. It's it's a bright make it or break it for the product. Obviously keep it  that's a obvious. Yes, but if it's more so, oh, but we worked so much on it, like we've, we've. Say like we market it a lot.  There's a lot of trade-offs there, but it's important to really reflect on it. 

 So going into the insourcing and outsourcing. Um, conversation it's important to strategize what core competencies and institutional knowledge or company needs early on.  And this will enable you to make good decisions when it comes to insourcing or outsourcing. If your company needs. 

To be good and engineering a product it's important to insource your engineering capabilities. But if there is a need for a one-off or a knowledge base that doesn't have to exist in the company for a long period of time, that could be outsourced for droplet. For example, this was building the firmware early on, but then afterwards they had. 

 Firmware that,  they had more for my needs and they had different products that require different types of firmware. And  , Eventually, they were able to convert that into an in house capability. So there could also be  a roadmap to starting outsourced, but then,  converting into in-house. 

In terms of testing and validation,  conducting long horizon field tests. Uh, is incredibly important on firmware to ensure no problems arise after a period of usage one. Example that came up was Madhavi,  was talking through the time they had a firmware freeze.  that costs 500 units that were in user hands to enter a state. Where did they did not turn on? And there were not functional. 

And they had,  they had to get a little creative and they pushed up the updates through an app, a backend manually in order to enable customers to use their device.  But obviously this was a, this is a pretty difficult thing that they had to deal with and it was during Christmas and they were sleeping in shifts to be able to figure it out. 

This is the , this is the hardware horror story that a Madhavi mentioned.  So it's really important to run a life cycle test, according to your warranty of the products, if you feel like your product is made to last two years, make sure to test an equivalent. Timescale.  That's super important. And depending on your product, having some safety margin on top of that, 

It should also definitely be considered. And this will specifically be crucial in applications that involve health or safety.  And then. It's important to note that failure of products is inevitable. Every product will fail in some capacity. However, which of the failure modes ,  you mitigate will be incredibly important,  in terms of your technical strategy. 

, specifically in products or systems that are designed to be near humans, it's important to converge the failure modes into one that causes the least amount of damage.  So in the case of droplet the product,  Basically the failure mode. What is. Would be that it shut down. So by that, I mean, obviously we have, , an engineering practice. We have failure mode analysis and failure mode mitigation. 

And it's important to do you can't mitigate all fairly your modes. So being able to choose ones to mitigate that actually cause harm and then, or,  It doesn't necessarily have to just be harmed. Some, some are not designed to be near humans, but,  really understanding which ones are mission critical and, making sure that they. 

Most of your failure modes naturally converge into kind of a dormant stage  so that the worst thing that happens is it just shuts down. 

 Failure modes go hand in hand with risk management. It's important to make sure that you have a plan,  for all of the risks and contingencies and make sure that. The failure mode can be dictated. So having a robust risk mitigation plan is also really important. And some risks require some level of quality assurance or some level of testing, or even some level of, supply chain management, where it truly is on the business to notice, , and have a mitigation plan in place. And oftentimes. 

, mitigation plan could look like an R D project where they're trying to technically risk mitigate, or it could look something like having a supply chain team working on long lead items and so on and so forth. So there's obviously a lot of risks. There's technical risks, there's, budget risks, and there's,  program risks where that's  related to timeline. 

So making sure that you have, , mitigation. Plan in place.  Sometimes failures are not necessarily a bad thing because,  this was, this is very insightful about Madhavi says a failure could lead you. To a pivot that expands the potential of your product. Listen to your failures , because they might really dictate the feature of a feature success of your product. And , we go into the element of ego. , so as a founder, , you might have a few good ideas, but you're going to have a lot of bad ones. And so it's important to weed out the bad ones as quickly as possible. 

And then find people who will challenge you in a  , in a constructive and productive,  way. And we'll work with you to  📍 to come up with even better solutions. So picking your team and choosing 

to surround yourself.  With the right people for your product is going to be crucial and your product development journey. And with that, I wrap up the TLD L for this episode. I really hope you enjoyed it and feel free to leave comments and reviews. Wherever you get your podcasts. Thank you so much and happy building.   

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

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