This content was created by Bobby Moesta. This content was uploaded by Bobby Moesta. This is a YouTube talk titled "Prototyping to Learn - The Five Skills" by Bob Moesta (published 2023-01-07). The excerpt is a single-speaker presentation in which Moesta discusses using prototyping and the design of experiments to learn early, contrasts Toyota’s iterative, failure-seeking development approach with Ford’s, critiques A/B testing, and describes how his dyslexia shaped a test-first, learn-by-doing mindset for product development and innovation.
Chapters
Prototyping to learn. Oh, I think this is gonna be a book in its own because I learned something called design of experiments when I was 18. And I applied it to— I've applied it to everything I can imagine, which is seeing things as a system, understanding that when I change things, I don't know what's going to happen, and ultimately using design experiments to help me learn what I don't know. We actually test to prove what we know. Hypothesis testing. And in Japan, they would say, like, we test because we don't know. And so a lot of the work that I think is important is actually understanding what are the unknowns that we have in front of us, and that if you're really innovating, you have a lot of unknowns. So building better product isn't about knowns, it's actually about unknowns. And this is what I will tell you, is as a dyslexic, I have a unique advantage. For all you people who got A's, you actually usually can't start till you know what to do. But somebody like me who got D's and realized that I had to work really hard to get a D to a C and then C to a B, all I know is I gotta start and I know I don't know. And so I literally start testing right away. Most people wait to test to prove what they think. And I would always say, I'm not smart enough to even know. 18 years old, I was told A/B testing is the worst way to test anything. And the only thing it does is create job security for engineers. Right? It creates a house of cards because you don't understand. And so learning how to experiment, learning how to test, learning how to actually let the experiment unfold as opposed to test so you know what the data is going to say. And so part of this is really taking the time to prototype to learn. The product development cycle time for building the Taurus. And one of my first assignments when I went to Japan was to actually look at the differences between how Ford developed the car and how Toyota developed the car. And if you look at this as the number of changes to the product, as you get closer and closer to scale up and development, right, it starts very small and then it just escalates. And as it got closer and closer to basically launching the product, they'd say, we gotta stop. They wouldn't really stop, but they'd say they'd stop and it'd go down and then they'd launch it and then they'd do— I think of this as the backlog of all the stuff we had to do afterwards to fix all the stuff we didn't do. And when you looked at the, the Toyota, right, it was actually very different. They actually had almost 10 times more changes way earlier. And what they're doing is they're actually trying to make it break. They're trying to understand where are the boundaries. Most of the time we're just trying to make it work and move on. They're actually trying to push it to know how can I make it faster, cheaper, better. All the time. And when they got to launch, to be honest, they ended up developing a car in 36 months. So for every one car we could launch, they could actually do 2 iterations. That's how Ford lost its entire position in the '70s and the '80s. And so part of it is this whole notion of how do we learn as early as possible, and how do we actually figure out how to prototype to learn? What are some of the things that you've learned
