Imagine coming back home after a short walk and discovering a frightening picture. Your belongings aren’t where you left them before going out. The kettle is in the bathtub now. The shoes and coats scattered across the room. It’s a mess. I bet you’d think you got robbed.

That’s exactly how your users feel whenever you change anything significant in the product.

“But if we stop shipping new things, people would leave!” you might say. “Feature requests keep piling up, and we got to make space for them.”. So here is a dilemma – people are always asking for new features, but they don’t want you to change anything. And it’s your job to deal with that.

Ship new without braking old

The reason change is so painful for users is because they have no control over it. It’s forced upon them. Reaching out to support after the fact is the only way to communicate the frustration. But the deed is done, and there is no coming back.

Eventually, it comes down to the choice. When people are in control of the change, they see it as a natural evolution, rather than a personal attack.

Ironically, the software is still developed in a factory-like way. When one-size is expected to fit all. And the manufacturer changes the product without considering diverse user’s circumstances.

Feature Flags:

With the rapid adoption of feature-flags, we come one step closer to tailoring experience per individual. The base concept¹ is that you, as a developer, have control over available features for the particular user(s).

Do you want a subset of customers to try a beta feature? Put it behind a feature-flag and flip it on the server whenever you please. Have an idea for the A/B test? Feature-flags will come in handy here as well.

Feature-flags technically enable developers to tailor the experience, but often users still don’t control the process. It’s mostly a one-way lane. The only difference is that developers now are more flexible in pushing changes across.

Moreover, let’s imagine the user can turn on/off every available feature-flags. Maintaining such a list would be insane. Changes to the product could be so dramatic that flags start overlapping and conflicting with each other. It would lead to disastrous outcomes.

Separate Major Releases:

Another approach to segment the experience is to separate product releases by major versions. It’s more common for desktop apps like Things or Clean My Mac.

But there are web apps that took the same route. The most notable is Basecamp. Not only do they separate major releases (Basecamp Classic, Basecamp 2, etc.), they also maintain all the previous versions. Which means customers aren’t required to upgrade. If the old version works fine, go for it. There is no need to break old habits and re-learn the tool again.

Sure, it isn’t free for the Basecamp team to maintain previous versions. And yes, customers are missing out on new features. But they at least have a choice. The software upgrade isn’t forced upon them. So whenever a new version comes out, they can choose to use it or not based on their circumstances, not the company’s release agenda

A reasonable question arises: “How to know when to separate major release?”. To paraphrase Jason Fried on Twitter: “When the product chassis is no longer capable of supporting radically new ideas, you have to change the chassis.”.

It means, within each major release, there are still some changes. They might not be as fundamental, but they are happening anyway. And each change can be significant for the user. So separating major release as the only strategy wouldn’t save you from people being upset that you moved this one specific button elsewhere.

Best of both worlds:

So if feature-flags or major releases alone aren’t a viable solution, why not try to combine them? With major versions separated, feature-flags collisions would be unlikely. So users would be able to determine their own local experience within the current version. And if they want a radical upgrade, they can switch to the next major version.

It’s not enough to put a bunch of toggles on the Settings page and hope people find them. If you want to give users control over their experience, you have to educate them first. They need to understand how the new change/feature is different.

As a developer, this also encourages you to design the system in a more modular way. Each new piece of functionality needs to be compatible with other pieces already in place.

For example, here is the concept of how I might set this up in CrossPatch, the product I’m currently working on:

• Let’s assume I released the feature that introduces new formatting options to the editor.
• Right inside the app, the user sees a small banner with a video introduction of the change.
• They can decide on the spot to enable it or do it later from the Settings page.

I think the video introduction is important because it visually shows the difference between experiences. It gives the user more context for the decision. Also, it educates them on how the new feature works. So when they turn it on, they already know how to use it².

Evaluate Feature Significance:

The fundamental decision that you, as a developer, have to make is to separate features that are significant and those that are not. So you can put them behind a user-controlled feature-flag, and let users decide.

As famously said in the UX community: “Don’t move the user’s cheese.”, in this case, you have to define what the “cheese” is for your users.

There is probably a no better way of doing it than using the Jobs-To-Be-Done framework. Without a clear understanding of the jobs your customers hired the product for, you can’t tell what’s important.

For example, this the core job people are “hiring” CrossPatch for:

As a PM, I want to keep internal stakeholders informed about the product-related changes and updates.

What parts of the product allow the user to achieve this goal? In my case, it’s:

• Editor – to write and format the updates.
• Integrations – to connect Slack, GitHub, etc., that would help PM write an update.
• Subscribers – for adding people who will be getting the specific updates.

So here is the approximation I use to determine whether a feature is significant or not: If the new feature changes how the user achieves an outcome of a frequently-used job – it needs to be behind a user-controlled feature flag.

Conclusion

Software products are more than capable of moving away from decades-old industrial practices. One-size doesn’t fit all anymore. We have to embrace the experience should be tailored by the user’s circumstances.

Building truly accessible products imply that people who do not want to change their habits should be allowed to use the experience they are familiar with. Instead of being forced to upgrade to whatever re-design your team comes up with.

After all, your product is your users’ house. You’ve been hired to build it. But it doesn’t permit you to put a kettle in the bathtub while the owner is away.

---