Supporting smaller audiences for maximum profit

by Jack Tarantino

or "How I learned to stop worrying and love all browsers the same as long as they came out kinda recently"

Time and time again I've seen companies ignore smaller audiences that use their product because those audiences are not the main/target/primary audience. At a recent job they ignored users on small desktop computers and on tablets saying that the company "doesn't support" those devices. At a recent consulting gig someone asked "why would we support a web app when our target market is mobile?".

There’s a concept in software design where browsers and environments are not just "supported" or "not supported" but they receive gradations of support. This system is referred to as a "browser support matrix" and is generally broken down into 4 categories:

  • A level - this browser is fully supported and the tiniest bug will be fixed.
  • B level - this browser is supported and any large problems will be dealt with but we're not worried about cosmetic issues or fringe cases.
  • C level - this browser is supported functionally only. if there's a bug, we're only fixing it if the app completely stops working.
  • Unsupported - this browser will not get any of our dev time, sorry.

Other systems can engage more levels of support and some very daring engineers actually support platforms on the feature-level instead of whole-platform. Going by feature and trying to "progressively enhance" experiences is very difficult to do right though. It generally takes a very strong engineering team or a great deal of time.

This system and the effort that we put into sorting different browsers and environments into different categories helps us to determine how much effort we want to put into supporting a given platform. the mistake that I see all too often is that people think that there's no gray area between full and nothing and that hurts them. The business loses customers. The business loses prospective hires. And consumers miss out on a good product.

Take, for example, this social app that doesn't have a web version. The company is missing out on people who don't have smart phones. They're missing out on people who don't want to download the app onto their phone (which could be for security reasons or maybe they just can't afford the 200mb download on their plan). They're missing out on people who want to be logged in but don't want to have more than once device out in front of them. They're missing out on people who were going to send one last message but then their phone's battery died and they don't have a charger and they just missed out on messaging their would-be soul mate (it could happen!). Now, these people are clearly not in company's priority audience. The priority audience is people who have a working smartphone, who use it constantly, and who are easily conned into buying upgrades and subscriptions. But just because that one audience is the most profitable doesn't mean you have to cater to only that one audience at the expense of all the others you could be profiting off of. Even if those other audiences only constitute 1% of your demographic each, that's 4% all together. and that's 4% more money that the company could be making with a minimum of effort. In many cases just putting smaller audiences in your B or C support levels can dramatically increase profits. The company doesn't have to fully support and cater to every single platform but if they just put in a small effort they could be making a lot more money and have many happier users.

In this particular case, there's also a technical upside: reducing the amount of code maintained and the amount of effort that goes into developing and deploying new features. The company currently supports native applications written for iOS and Android. They do not support Windows phone or anything on the web. If they wrote a web-based application and layered in support for mobile features like push notifications (which you can also do on the web now!) they would have a lot less code to maintain. One codebase for 4 platforms instead of 2 codebases for only 2 platforms. Half the code and double the platform support equals like 16 times the fun! The business would also save a lot of money on developers because they'd only need to hire people to program in and debug one platform instead of many.

Now, not every single business is going to want or need to support every single platform out there. But when you're considering your audiences and whether or not you "support" them, keep in mind that you are allowed to only partially support an audience. You don't need to have every single pixel in place but just having a barebones version of your service on a platform gives you a whole new audience to capitalize on. You don't have to give A-level support to tablets if they only make up 3% of your audience but if you just make sure that tablet experience is not broken(C-level support) then that 3% of your audience will still keep giving you money and you don't have to put much effort in.