We recently developed and delivered a mobile app called RAPP360. Short for Residency Audit App 360, RAPP360 makes it very easy for people having multiple residences to respond to tax audits from different jurisdictions by providing a detailed log of their physical location over the previous years. The primary target audience for RAPP360 comprises of Wall Streeters living in New York City during the week and having a permanent residence in the neighboring New Jersey or Connecticut – or what Occupy WallStreet would call the 1/2% . RAPP360 is equally useful for people living in other tri-state areas of United States, Canary Wharf – Greater London in United Kingdom and Basel, which is situated at the intersection of Switzerland, Germany and France in Europe.
Even as the first version of RAPP360 was undergoing beta testing, a few more people contacted us expressing their interest in RAPP360 with a few more features. When we quoted for these as enhancements to RAPP360, our reseller urged us to instead treat them as a separate product. Citing his past experience and a recent article in ZDNet, he advised us not to overload our application with too many features.
While this article only pertains to mobile and tablet technologies, we’re quite sure that ‘more features in a single product’ versus ‘separate purpose-built apps’ debate is not new to product managers and outsourced product development (OPD) program managers, who might have come across it even in the context of traditional client-server and web technologies.
The key to settling this debate lies in the resolution of a certain conundrum that we’ve come across several times in our 15+ years of working with several B2B software product vendors.
Before making a purchase decision, many prospects tend to believe in the “more the merrier” theory as regards functionality. At that point, many of them seem to subscribe to the National Rifle Association’s slogan, “it’s better to have it and not need it than to need it and not have it”, when it comes to product features. Many prospects are quite optimistic about being able to put all features to use in their respective companies and some of them even issue RFPs containing a list of “100 Must-Have” features that are derived by aggregating the Top 20 features of the leading five vendors in that product category. In a nutshell, most prospects ascribe greater value to software with a lot of features during the pre-sales stage without too much consideration of the relevance or implementability of the features in their specific circumstance. By following a feature-light approach, a vendor risks losing out to its feature-rich competitors apart from attracting the “feature, not product” criticism from research analysts and other thought leaders.
However, after buying a software, the very same companies who have now turned into customers find that they can get their money’s worth by implementing a relatively small subset of the full list of features supported by the product. Their end users use these features day in and day out almost mechanically and start complaining when they get hidden underneath new functionality added by the vendor in the next version.
Going by the history of leading applications like Word, Excel and SAP, we’re inclined to conclude that vendors have responded to this conundrum with bloatware – not light apps. For close to two decades, we’ve been hearing that the average user doesn’t use more than 30-40% of the features supported by these packages. Yet, industry leaders like Microsoft and SAP have constantly been releasing newer and newer versions with more and more features. We attribute this tendency to vendors’ recognition that, in a real life situation where a company is a prospect before turning into a customer, it is important to first win over prospects with more features and only then worry about post-go live considerations of customers.
We realize that this conundrum is only applicable for traditional B2B software that is deployed at customers’ premises. With Software-as-a-Service (SaaS), or what is popularly called CLOUD software, we anticipate a different buying behavior.
With almost all cloud software being sold as monthly subscriptions without any long term contracts, the buyer constantly shifts between the role of prospect and customer. To being with, the buyer company is a prospect. Once it signs up for the software, it becomes a customer. At the end of the month, when the time comes for it to decide whether or not to renew the subscription for the following month, the company becomes a prospect again. But, unlike ON-PREMISE software, it will now take its ‘purchase’ decision based on its actual experience with the software during the preceding month and not as an aspirational user. We think this important distinction between onpremise and cloud software will change the outcome of the debate between bloatware and light apps. Since SaaS customers are likely to behave more like actual users rather than first time ones, we expect them to show a distinct preference for lighter and purpose-built apps that are easy to use. If and when that happens, SaaS will settle the debate in favor of lighter apps.
By the way, we assumed that buyers of mobile apps and B2C software might not display a similar buying behavior as B2B onpremise customers, and delivered the RAPP360 enhancements as separate products as per our reseller’s advice.