Key Account Management software – native or not !

When I was starting up, the product roadmap then was a function of the requirements of our beta customers.

 

Thus, the key account management software then was a standalone application that would eventually connect with customer CRMs via an external connector. Our customers then were not on the major CRM platforms like Salesforce and MS Dynamics. In retrospect, our approach to building the suite of key account management technology tools basis customer requirements wasn’t entirely thought through well.

 

I recognized this problem and moved swiftly. Sometimes, being small is a big advantage. It still is.

 

I then quickly added a team to build the native application on Salesforce AppExchange. It just made sense. Salesforce, the CRM behemoth, was putting together this ecosystem of applications, to be built on top of their CRM software. We just went to the wind.

 

If you have been following our blogs and updates, we recently also added our apps on Microsoft’s AppSource recently. For us building good products quickly is the strength. And we went with it.

 

In comparison, I don’t need to tell you how long it takes ISVs to deliver similar products. Did you say, ‘Forever’?

 

But, if I were to do this all over again today, I would do it differently, very differently. Any guesses how different?

 

Salesforce – The leader and the teacher

Salesforce pioneered the concept for the market place in enterprise applications. In fact, it is said that Marc Benioff gave the idea to Steve Jobs which led to the creation of the Apple App Store. Some other companies followed suit – Hubspot, Zoho and more recently Microsoft. HubSpot’s VP Platform, Scott Brinker had written a Medium post explaining why HubSpot was moving to building a centralised system of applications.

 

When building a product, especially dependent on data exchange between big Platforms like Salesforce or Microsoft, a decision has to be made. Should the product be native to these platforms or an independent app? This is a huge strategic decision that needs to be made early in the product life cycle.

 

There are successful products both native (Docusign) and nonnative (Sales Loft). The decision is based off,

• Dependency on data from Platforms – If the dependency is expected to be high, a native app approach seems best for the entire ecosystem.
• Resident Users – If app users are already platform users, a native app isn’t just a good user experience, it is also a strong Go-To market approach.

 

For the record, let’s get the definition of native apps out of the way. Native apps are built using the technology provided by the respective platforms. Force.com by Salesforce is one prime example. Apps built on force.com are deeply embedded inside the salesforce platform.

 

Native – To or Not To

This is a very important decision for product companies considering a number of go-to-market strategies. I am listing down the advantages and disadvantages basis of my experience.

 

Advantages of going Native

1. The user need not log in to another app. They can use your app from inside the logged in the platform.
2. The security of data and access control is the same as that of the platform and managed by the Platform.
3. There is no need for integration with the Platform. The data, objects, and modules of the Platform can be the foundation on which you build functionalities of your App.
4. The deployment, installation and license management is easy.
5. The support from Platforms for sales and marketing your app is great.

 

The downsides to a native app could be

1. Reduced flexibility and dependence on Platform’s tech stack.
2. Restrictions on UI/UX since you would want to maintain this same as Platform’s UI/UX.
3. You have to keep up with Platform’s own product releases and tech upgrades.
4. Increased cost due to revenue share and other platform fees.

 

In the space of Key Account Management software, the approach by main players is as follows

• Altify – Native to Salesforce.
• Revegy – Independent non-native app
• Kapta – Independent non-native app
• DemandFarm – native to Salesforce & Microsoft Dynamics. Also independent app with API connectors. How cool is that?

 

The DemandFarm View

If the dependency and user base criteria for a native app are met, it is always advisable to build a native app on the most relevant Platform, to begin with. Once the product and its most important features are validated you can extend to other Platforms and/or build an independent app. This approach also helps in establishing product-market fit quickly.

 

I invite your views on this subject.