Some simple advice for Apple and app developers: It’s not about you

It’s been a rough few weeks for AgileBits, the company that makes password-manager 1Password. It announced that the new version of its Mac app would be built on a new, powerful and consistent code base, ensuring a consistency of product and a faster upgrade pace. Sounds good, right? It certainly did to AgileBits, which clearly saw its decisions as a win.

Of course, many Mac users reacted quite differently. What AgileBits actually did was throw its native Mac app in the garbage and replace it with an app built with the web-development system Electron, one that would be identical to the versions of 1Password on Linux and Windows. Good news, Mac users! We’re replacing your Mac app with a cross-platform, lowest-common-denominator version! Please clap.

Too often, when a company stumbles, it’s not because it made a fundamentally bad decision. It’s because it made a decision that benefited itself rather than its customers and lacked the perspective to understand that customers don’t applaud when you lower your costs or the quality of your product.

As someone who has been observing the tech industry for the last few decades, I can tell you that this sort of thinking is incredibly common. I’ve seen businesses of all sizes make the same mistakes, and it all comes down to getting caught up in your own business and forgetting that you’re there to make a product that serves a customer.

Invisible upgrades

Back in the days when software was sold in boxes and on CD-ROMs, every major version of a program was a paid update. And as you might expect, that led to a distortion of the way software was developed to focus on “marketing features”—namely, new features added to the software that would convince buyers to spend for an upgrade. Fixing bugs, especially bugs in the previous version’s marketing features, were never a high priority.

Say what you want about subscription-based software, but when a software developer has an incentive to keep its customers happy on an ongoing basis, it becomes a lot easier to soothe them with bug fixes rather than jamming through poorly thought-out marketing features to boost upgrade sales.

1Password 7 Mac icon
AgileBits has good technical reasons for abandoning its Mac native client, but the user experience will suffer.

AgileBits

Just as AgileBits made its decision for some sound technical reasons—there’s a whole blog post about it—sometimes developers make technical decisions and expect their users to go along with them.

I’m reminded of a Mac app that I reviewed for Macworld more than a decade ago. The app itself was excellent, and I’d reviewed it favorably several times. Then a new version came out, asking for a full upgrade price but the new version had very little that was new. I recommended that most users not bother upgrading until a new version arrived that added features worth the money.

Suffice it to say that the developer of the app was furious about my review. He explained to me the enormous amount of engineering effort that went into the update, requiring the wholesale rewriting of large portions of the app to better lay the groundwork for a bunch of exciting new features that would be coming in future versions.

I understood his point completely: From his perspective, this new version of his app required no less work than any of the previous versions they’d charged full upgrade price for. Why shouldn’t he get paid the same way? The problem is that from the perspective of the users, there was a big price tag… and nothing visibly better about the product. As admirable as the developer’s commitment to the future of his product was, he didn’t seem to consider that none of his labor was tangible or immediately relevant to his users.

This is why I’m generally in favor of subscriptions for apps that matter to you. When you pay for a year, and you use the app for a year, you can see the value. In the old system, things could get really weird and out of sync with reality.

Today’s marketing features

This all goes for Apple, too. Some of Apple’s biggest missteps come from making decisions about the company’s business direction rather than focusing on what is best for its users. Sticking to software for a moment, consider the annual release cadence of iOS and macOS. In a world where most major software projects have switched to subscription models and intermittent release schedules, Apple releases its operating systems every year and insists on showing them off at WWDC, marketing a bunch of high-profile features.

WWDC 21 Tim Cook

Apple WWDC keynote is more important as a marketing event for the general public than for developers.

Apple

It does feel like an old-school approach to software, translated to the present day. Last year’s marketing features ship with bugs that never get addressed because the next marketing feature takes priority. It feels like Apple’s decisions about how it prioritizes and rolls out OS releases say a lot more about the company’s product release and software development schedules than about what customers want.

I see a glimmer of this in Apple’s recent PR disaster regarding its roll-out of features designed to fight child sexual abuse media (CSAM). In designing a clever technical solution that used on-device scanning rather than content scanning on Apple’s servers, Apple chose a solution that fit its marketing message and showed off its technical prowess. Yet somehow, it seems to have deeply miscalculated the reaction to its decision—perhaps because it didn’t properly consider the perspective of its customers.

It’s so easy to lose perspective. Companies large and small have done it and will do it again. The trick to avoiding this mistake is deceptively simple: Realize that it’s not about you, and consider the needs of the customers who make your business what it is. If you try to sell your customers a product designed to make your business more successful without benefiting them, they won’t thank you for it.

Subscribe to Applenews247.Com Newsletter

Leave a Reply

Your email address will not be published. Required fields are marked *

*


*

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>