Whenever the product expands to another platform, the question of feature parity bubbles up. Having an app with the same features across platforms is considered to be a good thing. The assumption is that your customer’s needs would be the same across all the platforms.
This assumption also means you don’t understand what the customer is trying to accomplish. The unique platform-dependent circumstances aren’t considered. And the phrase: “This is how we’ve done it historically.” is used to explain why.
There are two core circumstances you need to think about when expanding to another platform:
Platforms have unique pros and cons. And it’s your job to connect those with the users’ needs. You probably wouldn’t want to use code editor on the phone all the time. But answering on GitHub Issue comment via iOS or Android application would make more sense on the go.
Take the Notion mobile app, for example. I’ve been using Notion for a few years already. To plan the day, maintain notes, keep a reading list, you name it. It’s safe to assume I’m a loyal customer. But despite all of that, the Notion mobile experience is awful. I dare to say it’s unusable.
I attribute this partially to the unnecessary complexity of the app. It tries to give everything you already have in the Desktop version.
On one side, the app becomes much harder to use for people. On another side, it increases the maintenance complexity for the team at Notion. Imagine instead of doing everything, they would focus on a few specific use-cases for their mobile app:
For Individuals. As a Notion user, I want to capture information into Notion as fast as possible. So I can organize it later while on the Desktop. Covering just this specific case would automatically wipe out the complexity. And would already solve a huge problem for people.
For Teams. A big part of using the Notion mobile app with a team is about consuming and discussing information. Rarely you’d need to write the whole document. Not having a rich text editor in the app would allow the Notion team to optimize more valuable parts of the experience.
Of course, there is more to it than just shaving off the scope. You have to consider Business Circumstances in which the product operates.
Understanding People’s Circumstances maximizes value for the customer. Being aware of Business Circumstances does the same for the company. What is the reason for the product to expand on another platform? Without a clear business goal, you probably shouldn’t do it.
I like to think about this question with those four categories. The product on a new platform can either be The Driver, The Accessory, The Utility, or The Replica.1
The goal of a Driver is to bring more people to use the product. It usually means optimizing for value. The faster people discover how valuable the Driver version of the product is, the more likely they stick with it.
The Driver might not even provide the same value as the original product. But in this case, it should be convincing enough for people to give the original product a try.
Accessories supplement the original product by leveraging the platform’s advantages. The user can’t get the full value just with the Accessory. Instead, they can enhance the existing experience because of the new platform.
It’s probably the simplest platform expansion. All the features are already in place. You only need to figure out which of the existing experience can be enhanced by a different platform.
An example would be the Notion opportunity on mobile I mentioned earlier. Or take the early iterations of the GitHub mobile app. Notifications and comments were the focus. You couldn’t use GitHub at 100% with the mobile app. But being able to comment on the go amplifies the existing experience.
The product for another platform is considered a Utility when the original product can’t operate without it. It’s not just an addition. It’s the core part of the workflow.
For example, for Abstract to keep versions of your design files, there should be a way to track local file changes. Those changes have to be synchronized with the server as well. Abstract has web and macOS versions. And in this case, the macOS app plays a utility role. If you’re a designer, you can’t use the product without it.
Another example would be Loom. There is no way to use their web-version without the Loom Desktop app for video recording. It’s a kind of product-platform symbiote.
The Replica provides full or partial functionality of the original product on a different platform. The current Notion iOS application is a Replica.
This category isn’t related to the underlying technology. Most cross-platform products can be considered Replica. Not by the codebase. But because of the jobs, they enable the user to do with the product.
It’s also not uncommon for products to start as Driver, Accessory, or Utility and slowly evolve to the full or partial Replica.
The strive for feature parity without questioning the substance is just another form of excuse. Just like when you say: “This is how we’ve done it historically” to avoid re-considering the “Why” of the decision.
I’m not saying it doesn’t make sense to replicate the product on a different platform. Sometimes it does. But I want to stress that it shouldn’t be a default option. The decision to build on another platform should come from unique circumstances and clear goals. If you’re making a mobile version of the product just because “we have to have one!” I doubt it will go far.
A single application for another platform can be a union of any of the categories I mentioned. The difference between them isn’t rigid. But no matter the category, you need to understand the original purpose of going to another platform. ↩