Breaking the Habit

In May 2019 I wrote a short piece on Medium about what changes when the software you build is someone else's job. It came out of one of the most ambitious projects I've been part of. At Quintype we had just finished reimagining our newsroom CMS end to end. We called it Bold, and it was. It changed how editors and content teams worked, with major quality-of-life upgrades and an information architecture where almost everything had moved somewhere new. So we took it on the road, visiting newsrooms across the country and walking the people who would live in it through the new way of working.
That roadshow shaped the original piece. Most of the apps we use every day are ones we chose and could replace tomorrow. Our users hadn't chosen the product themselves. Their newsroom had, and they spent most of their working day in it, so its workflows had become muscle memory. A slide-in panel that delights in a demo can grate on a journalist on deadline by the hundredth time it appears. Colours that look good in a two-hour review can be tiring over a full working week. And because people build habits around whatever they're given, even a change that simplifies things feels like a disruption to someone who has already learnt the old way.
Seven years on, I believe this more than when I wrote it. What's changed is that I now have a way to reason about it, and I've seen enough releases land, well and badly, to trust it. A B2B product team is in the habit business in both directions. Every workflow it ships becomes someone's routine, and every change it ships breaks one.

What Kaleyra added
When I moved to Kaleyra, we were building the first version of a new product, and Hiran, who had led design on Bold, joined me to lead its design. He's still there. We brought the lessons with us. The biggest was to make every change, and the reason behind it, visible. When users could see why something had moved, they were far more willing to move with it.
The second lesson was harder to accept as a product person. A better-looking experience doesn't automatically win. Sometimes a slightly less polished design is the right call, if the more elegant option would force people to change how they work in a major way. The user's working day is part of what's being designed, and a screen that looks a little worse but keeps that day intact can be the better product.

Product delta over change management delta.
The way I reason about it now is a ratio. The product delta is the improvement itself, the better flow, the cleaner screen, the faster path. The change management delta is everything it takes for people to absorb it. What a change is worth is roughly the first divided by the second.
In B2B the second number reaches much further than most teams account for. Internally there's support, sales, customer success and documentation. Externally, every client runs their own version of the release. A major client might write a new internal guide, rebuild its training material and set aside training days. Their trainers need retraining before they can teach anyone else, and onboarding for new hires changes.
Then there's the layer nobody sees, the shortcuts, workarounds and small hacks users have built around a product's quirks, some of which the team never knew were quirks. Engineers call this Hyrum's Law. With enough users, every observable behaviour of a system ends up depended on by somebody, and in B2B those dependencies live inside customers' own processes.
The ratio is why a small visual improvement that triggers a large behaviour change can cost customers more than it gives them, while a substantial improvement that fits how people already work can land almost free. Bold cleared the bar because its product delta was large, and we still took it on the road. Most changes don't clear it, and the hard part is admitting which ones don't.

A worked example
ZoomInfo gave me a clean case. When people use a product to do their job, muscle memory is a large part of what they're paying for, so I didn't take changing a familiar interaction lightly. Filters in one part of the product applied automatically as users selected them, so every intermediate selection ran a search. We broke from that and added an explicit Apply button, even though it went against the design norm and asked experienced users to change a habit. Design rightly raised the concern about consistency, and it was a real trade-off.
The product delta was substantial. Each search ran once instead of on every click, results came back faster, and users no longer waded through results for half-built filters they had no use for. The change management delta was one extra click, and we still treated it seriously. We watched support closely after release. A very small number of customers emailed about it, and once the team explained the Apply button, none of them followed up.
The person who buys isn't the person who lives in it
There's a structural reason the change management delta gets underestimated. In B2B, the person who buys the product is rarely the person who uses it all day. Products are often bought on the strength of a demo, and a thirty-minute walkthrough can't show what a change feels like in the fortieth hour of someone's week. The daily user, whose habits are about to be broken, usually isn't in the room when roadmap decisions are made.
Someone in the room has to carry the measure that matters most and is easiest to lose sight of, which is user trust and what the product does to someone's working day. That is the product manager's and the designer's job. Trust builds slowly, through a product that behaves predictably and changes considerately. One release that ignores the people on the other end can spend it very quickly.
What I'd ask of a team now
This matters more now than it did in 2019. AI has made shipping change dramatically cheaper, and the change management delta hasn't moved at all. A team that can rebuild a workflow in a fortnight has to be more deliberate than ever about what it's asking every customer to relearn.
So I'd ask a team to design the change as well as the feature. Before a workflow change goes out, estimate both deltas and be honest about the second. Make the reasoning visible to users and clients. Give customers control over timing through previews, opt-in periods and admin-controlled rollouts, so each client absorbs the change on its own schedule. Carry some of the cost with updated help content, in-app guidance and material client trainers can reuse. And after release, watch how long common tasks take for experienced users and what happens to support tickets, the way we did with the Apply button. That's where a team finds out whether it simplified a habit or just broke one.
I ended the original piece by saying that building habits is an amazing line of work. I still think so. Breaking them responsibly is the harder half of the job.