Most systems become irritating long before anyone seriously considers replacing them. An approval that takes a day longer than it should can remain part of normal life for years. People allow for the delay when they make plans, and new employees learn to do the same. We learn the strange sequence of clicks or add ten minutes to a task because ten minutes is easier than rebuilding whatever created the problem. Once we’ve adjusted, we may stop mentioning the inconvenience even though we still spend time dealing with it.
Occasionally, someone decides they’ve had enough and tries to change it. An employee writes a script to avoid doing the same manual work every afternoon. It may only work for her, but a similar effort elsewhere in the company suggests that other people are running into the same limitation. When those attempts keep appearing independently, we have more to investigate than one person’s frustration with a tool.
People start changing a system before the system officially changes
The employee automating part of her work probably isn’t trying to redesign the company. She needs to get through the task in front of her, and her solution will reflect that. A team elsewhere may deal with the same problem by abandoning part of the official process. They’ve responded differently, but both have decided that continuing as instructed costs them too much time.
Customers make similar decisions. A company may direct them to an online service, while customers learn that calling gets the job done faster. The company can keep promoting the online route without understanding why people avoid it, or examine the calls to find out what the website still doesn’t let them do.
One unusual request gives you little basis for changing a service. Repeated requests for the same exception deserve a closer look, particularly when people have begun finding their own ways to get it. What was treated as an edge case may now account for enough work that the original process needs to be reconsidered.
The old way can survive by demanding more from everyone around it
A process can become increasingly difficult to maintain while continuing to produce acceptable results. Customers expect an answer faster than the existing operation can provide it, so staff make up the difference manually. The customer gets an answer, and there may be no immediate reason for anyone outside the team to ask how it happened.
Handling exceptions this way can be sensible. Rebuilding a platform because one field is missing would be absurd, and redesigning an entire process because of a handful of unusual cases could create more work than it removes. A manual check may be a perfectly adequate solution for years.
The difficulty comes when those accommodations accumulate without anyone reviewing their combined cost. Five extra minutes becomes part of the task, then someone spends Friday reconciling two sources. Eventually an experienced employee is doing an impressive amount of work to produce the result everyone assumes the system already produces.
The business can still look healthy. Its dashboard may show that orders are being completed on time without showing how often employees intervene to make that happen. As that work increases, a redesign that once seemed too expensive may become worth doing. You need to know how much effort the current arrangement requires to make a useful comparison.
The years before a breakthrough are usually messy
Innovation stories get much cleaner after somebody succeeds. Once the replacement works, the old system looks obviously outdated and it becomes easy to explain what customers wanted all along. Earlier attempts tend to receive less attention, particularly when they were awkward to use or failed commercially.
There can be a long period when everyone agrees something is annoying and nobody has found a sufficiently good way to stop doing it. Customers complain about the old system and then refuse to switch because the alternative fixes one irritation while introducing three new ones. They may like the new feature enough to try it and still need something the old service does better.
A failed attempt can still teach the next team something useful. People who tried a new service may be able to explain precisely what made them return to the old one. That is more useful than knowing they disliked the old service, because it tells you what a replacement has to preserve as well as what it needs to improve.
The surrounding conditions can change between attempts, too. A product that required expensive computing capacity several years ago may become affordable to operate. Another company may build something similar to the version that failed, but offer it at a price customers will pay. Several businesses can spend years trying to remove the same constraint before one finds a way to make the service viable.
Adoption can eventually move quickly enough that the change feels sudden. An organization may have absorbed years of increasing friction through extra work before a viable alternative becomes available. The speed of the eventual switch tells us little about how long people have been trying to make it possible.
Friction can also mean something is simply bad
It would be dangerous to treat every difficult experience as evidence that a larger change is coming. Plenty of founders have convinced themselves that customer resistance proves they’re visionaries when customers were accurately telling them the product was unpleasant to use. Difficulty using something is a reason to investigate it, with no guarantee that the investigation will reveal anything beyond poor design.
There are also systems people hate that survive for generations. The people experiencing the problem may have very little power to change it. An arrangement can remain profitable for the people controlling it even when using it is miserable, and frustration alone won’t change their incentive to keep it.
I care more about what people start doing in response and whether their attempts are changing. Several departments independently building versions of the same missing capability give us a reason to examine that capability. They don’t tell us whether a shared version would work, or whether anyone would use it once it existed. A workaround that people continue using despite its limitations offers different evidence from one they tried and abandoned. Both can help explain what they need, including why an apparently reasonable replacement hasn’t been enough to persuade them to switch.
Tension changes as alternatives become easier
Friction that has existed for decades can become much harder to justify once the cost of avoiding it falls. A manual process people tolerated when automation required a six-month software project looks different when an employee can build a useful tool in an afternoon. That tool may still need substantial work before other people can safely depend on it, but the employee has demonstrated that at least part of the task can be done another way.
Customers reconsider familiar inconveniences for similar reasons. They may have accepted a long wait because every available provider took roughly the same time. A competitor offering a faster service gives them a choice they didn’t previously have. The existing provider hasn’t become slower, yet customers have a new reason to leave.
That changes the decision for the company, too. Improving the service may previously have seemed too expensive to justify. Losing customers to someone who has made the improvement changes the cost of leaving things as they are. Work that kept being postponed can become urgent without the underlying complaint having changed at all.
The eventual change may still take years. There’s no reliable way to measure the frustration and declare that a breakthrough is six months away. We can, however, examine whether successive attempts are resolving the problems that defeated earlier ones, and whether more people can now afford to try them.
This is part of what we mean by Anticipate
At ShanVic, Anticipate includes examining changes like these before a company has settled on a response. We want to understand what people are trying to do and why the existing arrangement makes it difficult. Complaints help identify where to look; the efforts people make to get around a problem give us more detail about what they need.
We also need to understand how the organization keeps the current arrangement working. A process that looks stable may require much more intervention than it did a year ago. Knowing where that extra work goes helps establish whether an ordinary repair would be enough, or whether the company is repeatedly compensating for a limitation it has never addressed.
Often, a repair will be enough. Changing an approval process may resolve the delay people were working around, with no need for a larger project. There’s no benefit in treating every irritating procedure as the beginning of an industry transformation.
Where attempts keep recurring, we want to know what each one has achieved and why it hasn’t been sufficient. An alternative that was too expensive last year may now be practical. One that saves employees time may still create problems for customers. Those details help a company decide what to try and what would have to improve before it could depend on the result.
We don’t have to wait until a replacement is widely accepted to take part in developing it. An incomplete approach may be worth a trial when we can explain what has changed since earlier attempts failed. The trial gives us a way to find out whether that change is enough.