I remember when taking 247B design for behavior change, we touched on the idea that when shipping something new, the biggest obstacle isn’t the code or the feature list, but the psychology of the change. Gourville’s article helped me name what I’ve felt in launches, which is often buyers overweigh what they already have, while we overweigh what we’ve built. It is very much characterized by the 9* effect mentioned in the article (Gourville, 6).
When thinking about balancing the innovation with buyer resistance, I can think of a few strategies. First, I’d force myself to frame every new capability as a behavior change the user must make. If a feature asks people to switch tools, relearn a flow, or tolerate a new object on their desk, those can be seen as more of a loss than an equivalent gain. In practice, I’d have a two-column spec: “What users gain” vs. “What they give up.” If cons are longer or emotionally heavier than pros, I would either redesign or slow down the launch. My goal would be to migrate the feature toward the “smash hit” quadrant, delivering significant product value with minimal behavioral change, rather than the “long haul” (Gourville, 7).
Second, I’d try to wrap the new in the familiar to reduce perceived losses. Toyota’s Prius, as the article noted, didn’t ask drivers to rethink driving; it hid complexity and preserved rituals (Gourville, 9). I would try to do the same. For instance, when introducing an AI-assisted workflow, I’d keep the same shortcuts, same pane layout, and same “Save/Share” semantics. The feature is discoverable as an enhancement instead of a complete replacement. That compatibility can lower the psychological switching costs without dulling the value.
Third, I would make the adoption process slow. Suppose the idea intrinsically requires new mental models (a true “long haul,” for instance). In that case, I’d give it extra time, launch with enthusiastic early users, and guide everyone through gradual lessons (Gourville, 7). This aligns with the article’s advice to be patient and “cross the chasm” deliberately rather than burning capital trying to force mainstream adoption too soon (Gourville, 7).
Furthermore, I’d actively seek the unendowed, those who aren’t deeply invested in the incumbent habit. New users, new markets, or adjacent use cases judge my feature on absolute value, not on the sunk comfort of the old. Their enthusiasm provides me with usage examples and language that can later help persuade the entrenched base.
Last but not least, when resistance remains high, I’d ask myself if this feature is truly 10× better for a core job-to-be-done? If not, I’d narrow the scope until one critical path is 10× better, and I make that improvement legible with clear benchmarks and side-by-side flows. If yes, I would then consider whether we can eliminate the old path in specific contexts so users aren’t constantly re-endowing what we currently have.
I deeply believe that innovation wins when I design not just for utility deltas, but for psychological compatibility, so that the user can keep their habits while I quietly swap the things inside and start feeling relieved.
