The do’s and don’ts of Salesforce product ownership

I’ve been working in the CRM and related domains in the Financial Services sector for close on two decades.  I spent most of this time implementing and managing Salesforce instances or, in parlance, organisations. These are my reflections on implementing and embedding Salesforce in large enterprises.

Democratisation of software

The original attraction of remains compelling. From a technology-employment perspective, this has  two dimensions.  The first is delivering software via cloud computing, and accessing the application in a browser. The second is the focus on configuration rather than coding. This is  especially attractive to a business or power user.

It is now readily accepted that software can be accessed via the cloud in a browser. Ten years ago, this was considered a light option. The on-premise client server model still reigned supreme. As web-friendly frameworks have developed, the cloud to browser model is now standard. It has freed us from on-premise servers and burdensome patches and upgrades, as well client-side application installations.

Salesforce has continued developing its clicks-not-code model, also known as declarative programming.. Power users or Salesforce administrators without coding knowledge can develop applications without heavy IT development. But there is still a need for analysis and design, especially relating to the data model and process flows. The generic business super user is usually disinclined to do this or is not aware of its importance.

Without this forethought, the result can be an Excel-esque environment of disconnected apps with misaligned data models.

As apps and features on the Salesforce platform increase in scope, IT governance and deeper technical skills become critical.  All the more so when the estate crosses functional and business areas. Even if apps for different areas are built in the same Salesforce organisation, siloed apps may result if there is a lack of alignment, coordination, and collaboration. This must be managed at the business level, followed by the solution architecture level. However, the original value of having no-code or low-code application development remains.

On the downside, there are times when great effort is put into configuration, only to later realise that coding is required, because the feature doesn’t work in the most user-friendly or optimal way with configuration only. This is the so-called declarative cliff. This would have been prevented with comprehensive analysis up-front.

Sometimes the requirement evolves past the point where configuration only is good enough. Sometimes business needs change beyond what reasonably could have been anticipated. Then we need to code. Many initiatives, especially as business and process complexity increases, will follow this path.

Salesforce continues to push the cliff out with continual no-code and low-code extensions to the Lightning Platform. In theory, this means that more and more can be done with minimal coding. Be sure to check the scalability and robustness of the newly added features.

User Adoption

Read any paper on enterprise software adoption, and you’ll see that executive sponsorship always features. But  players are also critical. In the case of B2B sales force automation, these include sales and account team heads, influencers such as finance directors / managers, and business champions and ambassadors.

Executive sponsors are critical for vision, funding, and maintaining momentum after implementation. For day-to-day usage and adoption, motivation by team heads and success stories narrated by respected influencers are far more effective. The initial drive is by the executive sponsor, but team management must instil the discipline. Adoption will lag if your manager lets you get away with not updating your pipeline forecasts in the CRM application.

Ongoing adoption discipline greatly benefits from success stories, which provide social proof of success. Social proof is a powerful motivator. Nobody enjoys being outshone by their peers.

The final piece of the puzzle is a regular review of user adoption metric, and changes in adoption strategies, where necessary.

Data, data, data

The credibility of any CRM application and the decision support value it generates relies heavily on data quality. This important aspect is often under-weighted. The result is incorrect data mapping or duplicate data ingestion, which damages credibility and takes a long time to recover from. The key to prevent this is to consider all points of entry, including direct user input, spreadsheet imports, and source system integration. All of these streams can pollute data.

For each of these streams, anticipate the likely sources of dirty data. Put strategies in place to eliminate or reduce the flow of dirty data. For example, if you have validation rules in place when users capture data, be sure to execute them, even when importing data or integrating with other data sources.

This is important especially when importing data. There is usually a need to import data to prevent recapturing the data. Depending on project pressures and timelines, it may be tempting to import the data as it is from the source system. Don’t do this unless you have done at least some level of clean-up and field mapping, especially when matching records to static reference source data such as client or customer names, where unique identifiers play such a critical role.

Manage the change

Organisations have varying levels of complexity and maturity. Maturity, in this context, refers to the level of the discipline of logging business data, as well as the level at which processes which support data capture and required data are embedded in the organisation. It’s part of the culture of the organisation. For instance, do all end users capture their client interactions or do some users “get away” with non-compliance?

Your change management strategy must be based on a realistic assessment of the complexity and maturity of these processes.

Another way to view adoption is to look at it through the lenses of data quality, improved process management, and usability. The first two relate to overall value add, also known as the “what’s in it for me” question. Are the  data reliable so that I can make business decisions? Does the CRM help me to do my job? Usability is the oil which reduces the friction of adoption friction. It’s the  key to process improvement. You can have the best features, but if they’re not easy to use, adoption suffers.

Focus on key outcomes

It’s tempting to build out every feature request in the service of maximising the value of the Salesforce investment. Especially considering Salesforce is a customer platform and not just a CRM tool. Unless you have adequate budget, resources, and a solid plan, don’t. Even then, it’s not advisable. It’s best to avoid the problems of “change fatigue” and “all things to everyone”. Pick three to five problems to fix, or opportunities to develop. Focus on these and do them well.

Tie these back to the business rationale and measurable benefits to show the value added in the form of making a difference in the lives of end-users. Answer the “what’s in it for me” question, and the value to the sponsor and management will automatically fall into place. It’s important not to do it the other way around. Don’t make it about reporting on metrics. Start with the benefit to individual users.

Focusing on key outcomes also means being process-first rather than data-first. Far too often, the reflex is to add more fields to support new reporting requirements, usually for the sake of expediency,  when it should start with the business process and what it means to the end-user, followed by the impact on data model and user interface design.

Focusing on a prioritised set of initiatives does not preclude you from extending functionality over time. It does, however, give you the time and space to do a few things well and to build credibility as you continue to show the increasing value of the Salesforce investment.

Know your platform from your framework

Salesforce is a platform, and not a framework. The platform’s utility and power comes from a set of related tools which can be used to extend an existing scaffolding. If your requirements call for a very high level of front-end and UI control, the greater flexibility of a framework might be a better option.

One of the benefits of a platform — and part of the SaaS value proposition — is the continual delivery of new features and tools. For example, Salesforce enhanced its global search function significantly by introducing natural language search and personalised search results. This feature set, branded Einstein Search, was made available at no cost to most licence subscription types, without the client organisation having to do any coding.

While a framework such as the various Javascript options will give you a greater level of control and flexibility, many features and toolsets will have to be coded, even though there may be libraries to tap into.

A key trade-off, then, is the platform’s greater speed of delivery versus the framework’s greater flexibility in delivery.


The return on a CRM software application investment depends on a lot more than delivering the required features. Just as critical to success are decisions made and actions taken to manage how the application is built and which features to focus on, along with user adoption and data quality.

Zaheer Ismail