At Highway1 we believe there’s no substitute for lived experience, which is why we like to put people who’ve seen and done as much as possible in front of our cohorts to share their knowledge. One person we’re always happy to welcome back is Ryan Vinyard. As former Director of Engineering at Highway1, Vinyard saw a lot of startups go from scratch-built prototypes to Demo Day, and in his current position as VP of Manufacturing at Molekule (a Highway1 alum), he’s shepherded a highly technical product from Demo Day to mass production. After his illuminating talk for Cohort Nine on that post-Demo Day life, we caught up with him for some more in-depth follow-up.
HWY1: Your main slide in this talk is a pretty comprehensive timeline of events from Demo Day to manufacturing; what’s the most standout thing on it?
RV: The biggest thing was getting a good partner to help us scale. That’s a hard one, because:
- A factory of that size isn’t going to talk to every startup
- Not every startup needs the kind of scale we were looking for immediately
But having a partner that we understood could scale, and was developing things in order to get to scale — not just to get us that first 1000 units — gave us confidence in everything we were doing while developing. I think that was pretty important.
There was also some early integration work. The manufacturer had made some mockup units, but we also had internal demo prototypes. We had to make some new ones that looked like the final industrial design; [founders Dilip Goswami and Jaya Rao] were trying to sell a product that didn’t exist yet without a final version of said product. The box beta was helpful for our user trials, and the mockup was great for showing people what it looked like, but investors looked at them and said “If you have these two separate things, that means you don’t have them merged yet.” Doing that engineering work to realize a prototype that incorporated all of the design elements, which was in some ways extra overhead, was key to enable the business to move faster.
HWY1: What was the most stressful thing that happened?
RV: Anything that happens while you’re in China can be really stressful. There are moments like “Whoa, there’s a key tool that’s not on the floor yet, so the schedule I’ve been seeing digitally doesn’t actually hold up,” or “This thing they told me they were making is being made in a different way, and I don’t know if it’s actually going to work or not until we get the final one, but I can’t change it mid-flow.”
I highlight China because it’s so remote, but it could happen at any time. Jaya, Dilip, and I were at a key vendor here in the States when Dave, our VP Product who was back in San Francisco, called us. He said “I know you’ve been at the vendor all day, so you haven’t been checking email, but our other important vendor in the region just changed project managers on us.” The project manager was the one person that’d been running the whole project for us with that vendor, and we got an “I’m done tomorrow” email. Jaya and I changed our plane tickets, drove to another city, and met with that vendor the next day. If we hadn’t been communicating as well as a team — if Dave didn’t know where we were or hadn’t felt empowered to call us — we might’ve headed to the airport without knowing what had happened.
In hardware, you’re going to have to work with distributed teams. You’re going to have people in different countries, coasts, timezones, languages, etc; I think that’s what can become really stressful. If you don’t have that trust culturally, you can start to wonder: “Well, Dave’s in China this time and I stayed here; is Dave going to do everything in China that I would’ve done?” You know what: it doesn’t matter. Dave’s in China and he’s getting stuff done; we’ll work together as a team no matter where we are to each move things forward in our own way.
HWY1: Is there something all hardware startups should be doing as soon as possible that they’re not?
RV: I’ll beat this drum over and over: talk to users. In my Highway1 days, I saw startups that would drive me nuts, and finally they’d do it, and I felt like they were just checking a box to put something in front of Rafi, Jon, and me: “OK, I did user development — can you teach me about DFM now?” I’d always wonder: once you do this DFM, are you going to show that to users again? I don’t know that you are.
Wanting to be proven wrong is how I’d fundamentally put it. If no one’s told me my product sucks yet, that doesn’t mean it’s great; it means I haven’t shown it to enough people, so I haven’t found the person who’ll tell me what aspect of it needs to be better. You need that constant desire to be wrong. As an engineer, all you want to do is prove that you’re right, so I find this really hard for engineers from a cultural standpoint. There are a lot of designers in the Highway1 community who respect engineers and vice versa, but outside of here or even Silicon Valley in general, it’s just not there. You shouldn’t just want to talk to users — you should have a passion to be proven wrong by users.
HWY1: Molekule’s technology came from a hard science research environment. Do you have a sense of how much tech is sitting on a lab shelf waiting to be commercialized?
RV: [makes “mind blown” gesture] I believe the ratio of what’s on a shelf to what’s out there is something like 9:1.
To put it on a simplified spectrum, I look at it as a matter of technical depth vs human communication.
- On one side you’ve got the scientists who talk to the atoms. Instead of working at the user level, they’re deep into fundamental research: concentrating on experiments they’ve been working on — sometimes for years — that are being used to understand one particular problem and investigate a hypothesis for how to solve it. They might take fifty years to get to one perfect data point.
- In the middle are the engineers who say “OK, what does that data point mean for humans? How do I get that to be repeated millions of times in a factory in China instead of a lab in the US?”
- At the other end are the designers who say “Now that an engineer made it repeatable, how do humans actually use it?”
This is a generalization, of course; there’s overlap between those fields (scientists who do design, etc), but I would argue that on a spectrum from pure theory at one end to usability on the other, there’s nobody who can really do A to B — and if any of us think we can, we’re being too arrogant about the other areas. I’m in the middle: I’m the engineer who’s helping scientists talk to designers, and I would never think I could be better than those scientists. I’m strong technically, I did great at math in school — that’s why I’m an engineer. I’m still not a scientist, and I still can’t figure out how to get humans to use something as well as a designer would. I’ve talked about this a lot in the engineering spectrum: you’ve got software, firmware, electrical engineering, mechanical engineering, industrial design, and user experience. If you want a UX designer to talk to a firmware engineer, good luck. You can have a firmware engineer talk to an EE, who’ll talk to a MechE, who’ll talk to ID, but it’s hard to have firmware talk directly to UX unless you have the right people.
Being at Molekule has made me think more about actual science and the process of invention. I would believe there’s a 9:1 ratio of stuff that’s been invented and is just sitting on a shelf vs what’s actually been commercialized — but I’d also argue half of those could be run through the product development process only to find out they don’t actually help humans. It could be great data, but it’s just not something you can commercialize. A lot of it comes down to metrics. Everyone wants to be profitable and have money, but a scientist can’t license a patent and see enough revenue from that license to think “I should just try to commercialize patents all the time!” Their job is to get stuff to work in the lab. Design is something you can do rapidly; science is a lifetime.
