Mike's Notes
Looks great. I must read this book and then write a review afterwards.
Resources
References
- Progressive Delivery: Build The Right Thing For The Right People At The Right Time (IT Revolution Press, November 2025), By James Governor, Kim Harrison, Heidi Waterhouse, and Adam Zimman.
Repository
-
Home > Ajabbi Research > Library > Subscriptions > IT Revolution
- Home > Ajabbi Research > Library > Publisher > IT Revolution Press
-
Home > Handbook >
Last Updated
12/06/2025
Technological Jerk: Why Users Resist Your New Features (And What to Do About It)
By: Leah Brown
IT Revolution: 03/06/2025
Leah Brown is Managing Editor at IT Revolution working on publishing books and guidance papers for the modern business leader. I also oversee the production of the IT Revolution blog, combining the best of responsible, human-centered content with the assistance of AI tools.
It’s Friday at 9:52 p.m. You open the app on your phone to adjust the alarm on your smart speakers. You need to ensure you’re up early to make a flight. When the app opens, it’s different. “Oh, cool, a new update,” you think at first. But after twenty minutes of fruitlessly tapping around the screen, you discover through Reddit that the new app update has completely removed the ability to control alarms.
You spend the next hour setting up physical alarm clocks while trying not to wake your family.
Sound familiar?
This scenario isn’t just frustrating—it represents a fundamental disconnect in delivering software. Software developers are often proud of their innovations, and businesses are eager to ship them. But users are increasingly exhausted by the constant technological churn disrupting daily lives and workflows.
In their upcoming book, Progressive Delivery: Build The Right Thing For The Right People At The Right Time (IT Revolution Press, November 2025), authors James Governor, Kim Harrison, Heidi Waterhouse, and Adam Zimman call this phenomenon technological jerk.
The Physics of Disruption
In physics, “jerk” isn’t just someone cutting you off in traffic—it’s the rate at which acceleration changes. It’s the feeling that makes you grab for the subway pole when the train lurches or brace yourself during an elevator’s sudden start.
As the authors explain in the book, “Just as physical jerk throws our bodies off balance, technological jerk throws our mental models and established workflows into disarray when software changes too abruptly or without proper preparation.”
This isn’t about resistance to change itself. It’s about our human capacity to absorb the rate of change. And in today’s software environment, that rate is accelerating far beyond what many users can comfortably process.
The Business Impact of Technological Jerk
When users experience technological jerk, they don’t typically blame themselves—they blame your product. This manifests in ways that directly impact your business:
- Decreased engagement: Users avoid using features they’re not confident navigating.
- Rising support costs: Every abrupt change creates a flood of inquiries and complaints.
- Negative reviews: More than ever, users vocalize their frustration publicly.
- Increased churn: At its worst, users switch to competitive products that feel more stable.
- Feature abandonment: New capabilities that cost thousands of development hours go unused.
In 2019, Slack faced significant backlash after releasing a major UI redesign that disrupted established workflows. Despite the company’s belief that the new interface would ultimately improve productivity, users revolted against the change. Some organizations even delayed upgrading to maintain productivity.
Even worse, in January 2025, Sonos CEO Patrick Spence was forced to resign after an app update broke core functionality. The cost of failing to manage technological jerk isn’t just customer dissatisfaction—it can be existential.
Why We Create Technological Jerk
If the effects are so damaging, why do we keep creating software experiences that jar our users? Several factors are at play:
1. The Curse of Knowledge
When you’ve spent months designing and building a feature, the change seems intuitive, even obvious. You can’t un-see what you know. This cognitive bias makes it nearly impossible to accurately predict how disruptive a change will feel to someone encountering it for the first time.
2. Deployment ≠ Release ≠ Adoption
Many organizations have embraced CI/CD to optimize their deployment pipelines, shipping code dozens or hundreds of times daily. But we haven’t created equivalent sophistication around how we release those changes to users and support their adoption journey.
The software industry conflates three distinct processes:
- Deployment: Getting code to production environments
- Release: Making features available to users
- Adoption: Users successfully incorporating features into workflows
While optimizing for deployment speed, we’ve neglected the human-centered processes of release and adoption.
3. The “User Knows Best” Fallacy
“But users asked for this!” is a common defense when pushback occurs. This ignores a crucial reality: users typically ask for outcomes, not specific implementations.
When a user says, “I want a faster search function,” what they’re really asking for is, “I need to find critical information during customer calls without losing the customer’s attention.” Your implementation of a “faster search” might actually disrupt the workflow they’ve optimized around the current search.
4. The False “Everyone” Narrative
Product teams often speak of “our users” as a monolithic entity. “Our users want this.” “Our users will love this.” This ignores the reality that your user base contains multiple personas with dramatically different needs, technical sophistication levels, and change tolerance thresholds.
What delights your early adopters may alienate your steady mainstream users. Assuming “everyone” will react similarly to change is a recipe for creating technological jerk.
Early Signs of a Better Approach
Some organizations have begun exploring solutions to this problem:
Feature Flagging Beyond A/B Testing
Companies like GitHub use sophisticated feature flagging not just for testing but as a fundamental control mechanism that separates deployment from release. Rather than abruptly pushing changes to all users simultaneously, they create control points that allow for gradual, deliberate exposure of new capabilities.
Ring Deployments
Microsoft has pioneered the concept of “ring deployments,” where changes progress through increasingly larger circles of users, starting with internal teams and expanding gradually to early adopters before reaching the general population. This creates a progressive exposure pattern that catches issues early while allowing most users to avoid the earliest, most disruptive moments of a new feature.
User-Controlled Release Cadence
Some products now offer explicit user choice in when and how they adopt new features. Google Workspace, for instance, allows administrators to choose between “Rapid Release” and “Scheduled Release” tracks, acknowledging that different organizations have different change absorption capacities.
The Rise of Product Operations
Just as DevOps emerged to bridge the gap between development and operations, a new discipline—Product Operations—is forming to manage the increasingly complex interface between product teams and users. This emerging function explicitly owns the user transition experience, much as DevOps owns the code transition experience.
Beyond Adhoc Solutions
These approaches represent important first steps, but they remain fragmented and inconsistent across the industry. What’s needed is a comprehensive framework that systematically addresses technological jerk by reconceptualizing how we deliver software.
Such a framework would need to:
- Recognize different user segments’ varying capacities for change absorption
- Provide mechanisms to measure and manage the rate of change
- Create feedback loops that detect when change is happening too rapidly
- Delegate control to those closest to the impact
- Balance the innovation needs of development teams with the stability needs of users
This isn’t about slowing innovation—it’s about enabling sustainable innovation that users can absorb and benefit from. It’s about finding the sweet spot between technological stagnation and technological whiplash.
What’s Next?
Progressive Delivery introduces a comprehensive framework to do just this—a systematic approach to managing technological jerk while maintaining innovation velocity.
Drawing on their extensive combined experience in the industry, as well as case studies from companies like GitHub, Disney, Adobe, and AWS, the authors demonstrate how organizations of various sizes and industries have addressed this challenge through a combination of cultural, procedural, and technical practices.
Until the book comes out, you can start by recognizing when you’re creating technological jerk in your own products:
- Are users complaining about the pace of change rather than the changes themselves?
- Do support tickets spike after every release?
- Do you have features with mysteriously low adoption despite obvious benefits?
- Have users created workarounds to avoid using your latest capabilities?
These are all signs that your delivery approach may be creating more friction than function. By recognizing the problem, you’ve taken the first step toward building better relationships with your users through more thoughtful software delivery.
Because at the end of the day, what matters isn’t just what we build—it’s how we deliver it, to whom, and at what pace. Get that right, and both your users and your business will thrive.
This post explores concepts from the upcoming book Progressive Delivery: Build The Right Thing For The Right People At The Right Time by James Governor, Kim Harrison, Heidi Waterhouse, and Adam Zimman (IT Revolution Press, November 2025), which introduces a comprehensive framework for delivering software in ways that respect both innovation needs and user adoption capacities.
