In this talk, Bob Moesta explains that successful innovators rely on mental models that reveal the underlying causal structures of how the world works, rather than just observing events and patterns. He emphasizes that customers have desired outcomes, which are distinct from the metrics or outputs they might express. Using his personal weight‑loss story, he shows that the true outcome (being able to ski safely) differs from the measurable metric (pounds lost). Moesta distinguishes between controllable factors (the span of control) and noise, urging designers to focus on what they can control and make systems robust to external variability. He advocates for lead measures that predict customer satisfaction and introduces “right‑to‑left” design thinking: start with the customer’s desired outcome, derive the necessary outputs, and then determine the system that can deliver them. He critiques the common product‑first approach that asks “who wants this?” and argues that over‑engineered, overly complex products often fail, whereas simplifying to the essential outcome creates competitive advantage.
Chapters
Causal structures. So this one was actually hard for me to figure out because it was like everybody has a certain way they see the world work, but it turns out that anybody who's really good at innovation has at least a mental model of how things work. And that this kind of like highlights the thing, and this is, to be honest, it almost highlights like my career, which is I was so worried about events and patterns that I didn't actually have a way to see underlying structures. But ultimately, the 4 mentors taught me all these mental models so I could see how the world worked, not from my perspective, but from multiple perspectives. Deming, again screaming, would say, you know, you— if you can't describe it as a process, you don't know what you're doing, right? And so part of this is that taking the time to understand— by the way, somebody buying is a process, and the way you want them to buy is not the way they buy. So be careful about the difference between the supply side and the demand side, but to understand the causation. So the interesting part is I learned very early on this frame, which is basically there's inputs and Right, there's a system, there's actions, they create an output to a customer. But the reality is, it's a little bigger than that. It's this fact that customers have outcomes that they want, and outcomes are not outputs. So for example, I've lost almost 60 pounds, right? And so you could say my metric was pounds. But the real reason why I lost the weight was the outcome is so I could go skiing with my family. Because I was at a weight where I would get hurt. I did get hurt and I wouldn't go. And so the outcome is very different than what the metric is. And we can't confuse what they, what they say they want or the metric with what the outcome is. The other part is to realize that there are control factors to the system and there are noise factors. This is where when we end up building a system is like, oh, it's their fault. You know, engineering didn't do this, so-and-so didn't do that. It's like They taught me to basically say, where is your span of control? Everything else is noise. You can't control it, so make yourself robust to it. We want to actually get to these lead measures to know that we're going to assure that we can actually satisfy the customer. Causation is at the core of this. Here's the challenge. When we build, we usually build what I say, we build from here's the inputs, here's the system, here's the output. But when we design, we design in the opposite way. We design in what I call right-to-left thinking. I gotta understand the customer, I gotta understand the outcomes, I gotta understand this aspect of it, and that gets me to the outputs, which then gets me to what different systems I can build. 9 times out of 10, when we start product, we start with the system and say, who wants it? It's backwards. It's why we're trying to force value the wrong way. 'Cause a lot of times, to be honest, my specialty is going in and building a product that's half as good as the leader and killing them because they've over-bloated the product because it's way too complicated. And so part of this is understanding when is enough and what do you really need?
