I still remember the smell of burnt plastic.
It was 2013, and my co-founder and I were in a cramped workshop in Mountain View, surrounded by a tangle of wires, actuators, and 3D-printed parts. For six months, we had poured every waking hour and every dollar we had into building a prototype for a new kind of surgical robot. This wasn’t just another project for me. This was going to change the world. Or so I thought.
The idea was simple, even elegant. We wanted to create a low-cost, highly precise robotic arm that could assist surgeons in minimally invasive procedures. We believed we could democratize surgical robotics, bringing it to hospitals and clinics that couldn’t afford the multi-million dollar systems that dominated the market. Our prototype, which we nicknamed “Dexter,” was our first shot at making that dream a reality.
The demo was for a small group of angel investors, including a retired surgeon I deeply respected. We had practiced the sequence a hundred times. A simple task: the robot would pick up a tiny rubber ring and place it over a peg, simulating a delicate surgical maneuver. In our lab, Dexter performed flawlessly. But that day, in front of the people who held our future in their hands, it was a different story.
Dexter’s arm twitched. It hesitated. Then, with a sudden, violent jerk, it slammed the ring down, missing the peg entirely and smashing a small plastic component on the board. A wisp of smoke curled up from one of the servos. The smell of burnt plastic filled the room. Silence. The retired surgeon just looked at me, a flicker of pity in his eyes. We didn’t get the funding.
That failure was crushing. It felt like a public humiliation. But looking back, that disaster was the most valuable experience of my career. It taught me more than any of my successes. It laid the foundation for how I evaluate and invest in companies today, especially in the complex world of robotics and physical AI.
The Seduction of the Simulation
One of our biggest mistakes was falling in love with our simulations. In the controlled, predictable world of a computer model, Dexter was a star. We could run thousands of iterations, and the physics were always perfect. The virtual robot never had to deal with the friction of a real-world joint, the slight sag of a 3D-printed part, or the micro-second delays in a real-world data connection.
We spent too much time in that clean, digital space and not enough time in the messy, unpredictable physical world. The real world is a chaotic place. It has dust, vibrations, temperature fluctuations, and a million other variables that you can’t easily model. Our failure taught me a brutal lesson: a demo in a simulator is not a demo.
This is something I see all the time now as an investor. Startups come to me with beautiful simulations of their autonomous vehicles navigating a perfect digital city, or a warehouse robot flawlessly sorting packages in a virtual environment. I’m always skeptical. I ask them: “Show me the hardware. Show me the mess. Show me it working in the real world, with all its imperfections.”
That’s why I have so much respect for companies like Figure AI and Tesla with their Optimus robot. They are tackling the problem head-on, in the physical world. They understand that building a bipedal robot that can walk and interact with its environment is not a software problem alone. It’s a hardware problem. It’s a systems integration problem. It’s a problem of dealing with the messy, analog reality of our world. They are building for the real world, not for a simulation.
The Arrogance of the Engineer
Another hard lesson was about humility. We were engineers. We thought we knew best. We had read the research papers, we understood the kinematics, we could write the code. We spent very little time talking to our actual target users: surgeons.
We designed the robot’s controls based on what we, as engineers, thought would be intuitive. We made assumptions about the workflow in an operating room. We were so focused on the technical challenges that we forgot about the human element. The retired surgeon at our demo later told me that even if the robot had worked perfectly, the user interface was all wrong. It didn’t fit the way a surgeon thinks and works under pressure.
That experience fundamentally changed how I approach product development. Now, the first thing I ask a founder is: “How many customers have you talked to? Not just pitched to, but actually listened to?” The most successful companies are the ones that are built on a foundation of deep customer empathy. They aren’t just building technology for the sake of technology. They are solving a real, painful problem for a real person.
This is true for all the companies I’ve invested in, from RemoteTeam (acquired by Gusto) to Scale AI. They all started with a deep understanding of a user’s pain. For RemoteTeam, it was the headache of managing a global workforce. For Scale AI, it was the bottleneck of data labeling for machine learning. They didn’t start with a solution. They started with a problem.
The Myth of the Lone Genius
Silicon Valley loves the myth of the lone genius, the visionary founder who single-handedly builds an empire. It’s a great story. It’s also a lie.
When Dexter failed, my first instinct was to blame myself. I was the CEO. It was my fault. But my co-founder, and the two interns who were working with us for free, didn’t see it that way. They didn’t point fingers. They didn’t quit. The day after the failed demo, they were back in the workshop, taking the robot apart, figuring out what went wrong.
Their resilience and commitment in the face of that failure was a powerful lesson. A startup is not about one person. It’s about a team. It’s about a group of people who believe in a mission so strongly that they are willing to stick together through the tough times. The failure of our prototype forged a bond between us that was stronger than any success could have.
When I evaluate a startup now, I spend as much time looking at the team dynamics as I do at the technology or the market size. Are they a real team? Do they trust each other? Have they faced adversity together? A great team with a mediocre idea is always a better bet than a mediocre team with a great idea. Ideas are cheap. Execution is everything. And execution is a team sport.
From Surgical Robots to a Broader Vision
We never did build that surgical robot. The failure knocked the wind out of us, and we eventually went our separate ways. But the lessons I learned from that experience have been the guiding principles for my entire career as an entrepreneur and investor.
I’m still fascinated by robotics and physical AI. But now, I’m looking at it through a different lens. I’m not just looking for cool technology. I’m looking for companies that are grounded in reality, that are obsessed with their users, and that are led by resilient, collaborative teams.
I see the echoes of my own surgical robot disaster in the challenges that companies building autonomous vehicles or warehouse robots are facing today. The gap between simulation and reality is still the biggest hurdle. The need for deep user understanding is still paramount. And the importance of a world-class team is still the deciding factor between success and failure.
My first prototype was a disaster. It was a pile of burnt plastic and broken dreams. But it was also the best education I ever received. It taught me that building something truly new is not a clean, linear process. It’s messy, it’s frustrating, and it’s filled with failures. And that’s what makes it so rewarding. The path to building the future is paved with prototypes that didn’t work. And I wouldn’t have it any other way.
Frequently Asked Questions
Do all experts agree with this view?
No, and that's fine. The best ideas in business are often contrarian. I share my perspective based on my experience and data, but I encourage you to seek out opposing viewpoints and form your own conclusions.
How can I apply this thinking to my own situation?
Start by identifying the core principle behind the opinion, not the specific example. Then ask yourself: does this principle apply to my context? If yes, test it in a small, low-risk way before going all in.
What's the most common pushback you get on this?
People often push back by citing exceptions or edge cases. And they're usually right that exceptions exist. But building a strategy around exceptions rather than patterns is a losing game for most founders.