Weekly Musings 136

Welcome to this edition of Weekly Musings, where each Wednesday I share some thoughts about what’s caught my interest in the last seven days.

You might have noticed that there wasn’t a letter last week. The good, the bad, and the ugly (and there’s been a lot of each) of 2021 finally caught up with me last week. And, to be honest, I needed to take a break.

This delayed edition of the letter branches off from Musing 134. How? You’ll have to read on to find out. I can’t make it easy for you, can I?

Just so you know, what you’re about to read started life in my personal notebook and appears here via a CC-BY-NC-SA 4.0 license.

With that out of the way, let’s get to this week’s musing.

On Feature Parity

Back in 2015, I briefly chatted with John O’Nolan, founder of the blogging platform Ghost. You’re probably wondering why the web needs another blogging platform, when WordPress powers millions of blogs and runs about 25% of all websites.

Prior to creating Ghost, O’Nolan worked for Automattic (the company behind WordPress). But he found that WordPress had:

too much stuff everywhere, too much clutter, too many (so many) options getting in the way of what I really want to do: publish content

Instead, O’Nolan wanted to take blogging back to basics. And Ghost was born.

During our chat, O’Nolan mentioned that he didn’t intend for Ghost to reach feature parity with WordPress. Ever. That’s not the niche the Ghost inhabits.

I wholeheartedly agree with O’Nolan. Not everyone is a power user, regardless of what many software developers seem to think. Regardless of what far too many user think. Not everyone needs their software and tools to do the same things. Not everyone needs their software and tools to do everything.

But the feature parity argument persists. I generally hear it from people who are thinking of switching to something that doesn’t pack all functions that they know from what they currently use. It doesn’t matter if they use those additional features or not. And it’s usually not.

I find the feature parity argument comes from two distinct directions. First, from people who use it as a crutch. A crutch that gives them an excuse not to try something new or to make a change, even if that something new or that change will simplify and streamline their digital lives.

Second, from people who whine about missing features and only do so because they can. They aren’t the application’s the target audience. Even if the tool did have the features they want (or think they need), I doubt they’d use it. I doubt the tool would be suited to their needs.

If feel you can’t adopt a tool because it lacks feature x or feature y, or because it can’t perform a certain task, ask yourself these three questions:

From my experience in a number of areas — technical communicator, writer, reviewer, and (former) technology coach — I’ve found that many people rarely (if ever) use the features that are supposedly deal breakers. They just need to take a little time to adapt and adjust to something new.

Feature parity isn’t something that’s important to everyone. More features, especially if you don’t use them, aren’t always better. It’s too easy to fall into the contingency mindset when it comes to features — thinking that maybe one day you’ll need feature x, even though that day rarely comes.

Don’t buy into the hype of feature parity. Instead of thinking in terms of features, think about what you need to do. Not at some point in the distant future, but right now. Then, think of what you need to do it. Chances are, you’ll discover that you don’t need something big and powerful to get your work done. You probably just need something simple, light, and streamlined.

I’m a strong believer in the 80/20 rule, that 80% of people really only need 20% of the features and functions of just about any tool they use. You can even argue that the ratio is 90/10.

Think about it for a moment. Unless you’re a specialist, you don’t need expert-level tools. You need tools that are small, fast, and lean. Tools that focus on the features you use regularly, if not daily. Tools that aren’t cluttered with functions and menus and toolbars and a lot of cruft.

Take, for example, image editing. Over the years, I used a powerful open source application called The GIMP. It was installed on all of my laptops. But I rarely used it. My needs when it comes to editing images are simple: resizing them, straightening them, adjusting their colour, and cropping them. For those tasks, The GIMP was just too much.

Instead, I use a lighter application called Pinta. Why? It does what I need, and just a little bit more. Not too much more, though.

That goes for a majority of the tools that I use. They let me do my work, quickly and efficiently. I’m not burdened with what I don’t need.

As I was writing those last few paragraphs, I could hear the plaintive cries But I need …, I can’t do without …, and What if I need …*

Admittedly, there are people who actually do need more advanced and complex features. But they’re not the majority. Not even close. It’s easy for them to fall into what I call the power user fallacy: everyone uses a tool or technology in the way that you do. That’s not the case. Everyone has different needs, everyone has different goals. Everyone tackles tasks in slightly different ways.

As for not being able to do without feature x or function y, how do they know that they can’t? They’ll never know until they try. And those bells and whistles that some people proclaim, often in tones of outrage, that they can’t do without? More often than not, the missing bells and whistles are sound and fury that signify very little. Folks might think they miss them, but that bit of FOMO disappears when they realize that they never used those features or functions in the first place.

Finally, it’s easy to fall into the contingency mindset. Again, you need to ask yourself a question: when was the last time I used that feature or tool? If you can’t remember, or it was months ago, chance are you won’t miss it.

Let’s end this musing with this thought:

Focus on what your tiny, tiny pond of early adopters wants and needs, rather than fighting a feature war for mass market opportunities. Delight your tiny pond of early adopters, and you can grow from there.

Something to ponder.

— Scott Nesbitt