Building Enterprise Products on Platforms

What is an Enterprise Product:

An enterprise product is a software-based solution in the form of a web and/or mobile app designed to automate business processes, primarily for internal users (employees) within a company, though it may also interface with external users (customers or partners). Like any digital product, enterprise products are often continuously iterated, designed with a user-centric approach, and integrated into a company’s overall business strategy, requiring dedicated product management.

What is a Platform:

Platforms are low-code/no-code enterprise software solutions used to deliver business web and mobile apps designed to accelerate development. They provide pre-built functionality that can be easily set up and tailored through configuration, with the option for additional customization using code.

Unlike greenfield solutions, these platforms are fully managed in scalable cloud-based environments, offering native security and deployment features. This reduces the need for extensive internal IT operations to manage releases and provide technical support. Common platforms include the following:

• Appian
• Dynamics 365 (Microsoft)
• Pega (Pegasystems)
• Power Apps (Microsoft)
• Salesforce
• ServiceNow

Why use a Platform:

The decision to use a platform should result from collaboration among multiple stakeholders within the company—at a minimum, leaders from business, product, and technology. This process involves evaluating various factors and alternatives, though a detailed discussion of that is beyond the scope of this article. From a product manager’s perspective, the rationale for using a platform aligns with the rationale for building a product—it must be viable for the business and provide value to the user through an optimal experience. In short, a product manager’s role is to ensure that the platform offers the necessary capabilities to build enterprise products, whether through native features or customizations.

When I took on the role of a group product manager, some enterprise products had already been built on the Salesforce platform, and there were no capability gaps. As a result, there was no need to reconsider whether to use the platform. Salesforce continued to provide the required capabilities for those products while also enabling the development of many others—demonstrating that the platform was more than sufficient from the product management team’s perspective. Other key stakeholders across business and technology groups also supported the ongoing use of the Salesforce platform.

How to Evaluate Platforms and Features:

Whether you are considering using a new platform or using a new feature of an existing one, conducting due diligence is essential. Always be cautious about taking a software vendor’s claim at face value—just because they say a product can do something doesn’t mean it does it the way you need. Nothing is better at proving a solution’s capabilities than a working demo or prototype. This not only demonstrates what can be achieved with native (out-of-the-box) features and the level of customization required but also helps assess licensing needs and other key factors.

I learned this from my experience with not just Salesforce, but other platforms and other enterprise software as well. In most cases, the claims were true – the software could do what was advertised. However, some solutions required additional licensing fees, custom development, or were not to be the best fit for other reasons. I also found that partnering with the engineering team early in the vetting process provided valuable insights into the technology and key considerations for implementation. This collaboration paved the way for a more informed evaluation and stronger alignment on decisions about next steps.

Customization vs. Configuration:

One of the biggest advantages of platforms is the ability to build enterprise products through configuration changes, also referred to as “no code,” which doesn’t require technical knowledge of a programming language. Another advantage is the ability to customize the capabilities of a platform with code, which does require technical knowledge of a programming language and web application architecture, which can offer near limitless flexibility.

Customization as an Exception not a Rule:

Just because customization is possible, doesn’t mean that you should do it. The best way to reap the value from a platform is to leverage its out-of-the-box (OOTB) capabilities, which require only configuration and minimal, if any, customization. This should be a key factor in deciding to use the platform in the first place. Customizations also come with costs and risks—they almost always require additional effort to develop, test, and deploy.

In my experience with Salesforce, most enterprise products (also referred to as “apps” or “tools”) were highly customized. From a product perspective, these customizations allowed the platform to deliver all the necessary capabilities, including various tools and features. However, implementing these customizations required extensive work from the engineering team, following many of the same practices as greenfield software development—such as rigorous QA and release management aligned with agile methodologies. Due to the extent of these customizations, the engineering team also had to manage all configuration changes to prevent potential defects.

Stay Aware of Platform Licensing:

As a product manager, you may not be directly responsible for platform licensing costs, but your decisions about enterprise products built on these platforms can have an impact. I found this to be especially true in my experience with Salesforce, where I sometimes worked directly with the engineering team and Salesforce representatives to assess changes that could affect licensing.

This was particularly relevant when considering native platform capabilities that hadn’t been used before or when planning to build new enterprise products on the platform—especially if they would require additional users. When new licensing was needed, business stakeholders were involved very early in the product development lifecycle, as they typically would cover the costs and secured the necessary funding.

Web and Mobile App Differences:

An enterprise product may function differently when accessed through a platform’s mobile app compared to a web browser on a desktop or laptop. In some cases, certain capabilities available in a web browser may not be accessible in the mobile app. This can be due to justifiable reasons, such as smaller screens or the absence of a physical keyboard on mobile devices. However, these differences must be accounted for when making product decisions. The following examples highlight the importance of thoroughly understanding a platform and why it is crucial to validate capabilities early in the product development lifecycle.

While working on a team responsible for enterprise products built on Salesforce, we developed a tool that needed to function on iPads using the Salesforce mobile app for sales employees in the field. At the time, some Salesforce capabilities available in a web browser on desktops or laptops were not accessible in the mobile app. By collaborating with the engineering team and a Salesforce solutions architect, we were able to confirm the technical feasibility of using the Salesforce mobile app to provide all necessary capabilities. This is an example of a mobile-first strategy, where design decisions prioritized essential features for the mobile experience. This approach also allows some additional (non-essential) features to remain available when using a web browser on laptops and desktops.

A similar strategy was used for another tool—an enterprise product that had all essential features available only in the web browser, with a limited set of features accessible in the mobile app. This allowed mobile users to use the tool for some features without always needing a laptop or desktop, which was effectively communicated and reinforced through user training.

There were some enterprise products that were built on the Salesforce platform that only required the use of a web browser on a laptop or desktop. Since using the mobile app wasn’t needed and would not have provided the needed capabilities, Salesforce was configured such that those products would not be available in the mobile app.

One enterprise product that was built for use on a tablet (iPad) had to be customized to provide an optimal user experience. The Salesforce mobile app would work on any mobile device and had a native feature that supported the rotation of the screen – to be either in portrait or landscape mode. A customization was added to only allow the product to be used in landscape mode and only on screen sizes found on tablets.

One enterprise product built for use on a tablet (iPad) required customization to provide an optimal user experience. The Salesforce mobile app worked on any mobile device and included a native feature that supported screen rotation between portrait and landscape modes. However, the user interface in the portrait orientation was found to be difficult to use, so a customization was added to restrict the product to landscape mode and limit its use to screen sizes found only on tablets.

Engineering and Deployment Process is Still Needed:

Product managers responsible for enterprise products on a platform need a partnership with engineering—specifically, those who are platform technology experts. Depending on the degree of customization and type of integrations, the level of engineering support can range from part-time resources to dedicated engineering teams, which may be part of internal groups or external technology partners.

One could argue that there are some cases where an engineering partner might not be needed, such as when a product manager is highly knowledgeable about making configuration changes (e.g., being certified on the platform) and is also responsible for implementing them. Even then, a business should not depend on a single person to make changes. There are numerous risks associated with this arrangement, so I would never recommend it, even if it is possible.

Even with just configuration changes (no customizations with code), having a deployment process is critical, especially for business-critical enterprise products (and the underlying data). Changes should be made in a lower environment where they can be thoroughly tested before being deployed to production. A lower environment is essentially a separate instance of a platform that mirrors production (usually with less data), allowing changes to be made and tested in a controlled setting. The deployment process, also known as release management, would be the responsibility of the engineering partner.

In my experience at a larger corporation, where there were many business-critical enterprise products used by thousands of employes all built on a single instance of Salesforce that were highly customized and integrated with many other enterprise systems, having a partnership with the engineering group was essential. The dedicated group consisted of a manager, architect and two engineering teams – each with engineers, QA testers and a scrum master. And the way in which changes were made to Salesforce was treated in a similar way to greenfield software with source control, release management, security audits and dev ops support.

In my experience at a larger corporation, many business-critical enterprise products were used by thousands of employees, all built on a single instance of Salesforce that was highly customized and integrated with many other enterprise systems. So having a partnership with the engineering group was essential. The dedicated group consisted of a manager, an architect, and two engineering teams—each comprising engineers, QA testers, and a Scrum Master. Changes to Salesforce were managed similarly to greenfield software development, with source control, release management, security audits, and DevOps support.

Your Product Roadmap vs. Platform Roadmap:

Platforms are updated periodically to add or modify capabilities. As a product manager, it is important to stay informed about the platform’s roadmap and planned changes while simultaneously managing the roadmap and tracking changes to the enterprise products built on it. You should pay the most attention to changes that affect capabilities in enterprise products but also remain aware of other updates that could present opportunities to add value. In the case of the latter, any promising ideas should be incorporated into the discovery process.

Salesforce publishes details about upcoming updates months in advance. My team would allocate time to review the release notes as soon as they became available. Because we were a large strategic account with Salesforce, we had the support of a Salesforce Success Manager, who assisted in identifying relevant or potentially valuable changes.

The Risk with Platform Customizations and Platform Updates:

Salesforce releases major updates three times a year (spring, summer, and winter), and these updates are mandatory. The risk of defects in an update affecting the platform’s native capabilities or configured changes is minimal, as Salesforce thoroughly tests these areas. However, Salesforce cannot account for every possible way in which customizations (involving code) are implemented, which, in my experience, posed a risk for the many customized enterprise products built on the platform.

To mitigate this risk, Salesforce provides a release preview that can be applied to a lower environment, referred to as a “sandbox.” Our engineering team conducted extensive testing of enterprise products in this preview environment, with a particular focus on customizations. On more than one occasion, defects were discovered and resolved in partnership with Salesforce before the update was applied to the production environment—either as a change in Salesforce’s release or an adjustment to customizations made by the engineering team.

One Platform with Many Products and Many Stakeholders:

Businesses may build multiple enterprise products on the same platform, given how it can be leveraged to provide more value. This is especially true when using the same instance of the platform. For example, a business might use a single instance of Salesforce for CRM (customer relationship management, using a Sales Cloud license), IT support ticketing (using a Service Cloud license), and a custom application (using a Platform license). Note that while multiple instances could be used for different capabilities and accessed by the same users, that setup typically comes with disadvantages, such as higher licensing costs and a fragmented user experience. It is also common for each enterprise tool to have a different business stakeholder, while a single engineering partner is responsible for the platform and everything built on it.

This reflects my experience as a group manager at a large corporation with many enterprise products built on the Salesforce. While there were many benefits to this platform implementation, it also presented challenges. The most notable was the fixed “supply” of development capacity, which was significantly lower than the “demand” for ongoing customizations and other changes. With so many enterprise products built on Salesforce, each with different stakeholders, there were always competing priorities within and between products.

The solution was to establish a governance model to collectively decide how to allocate shared development capacity and allow stakeholders to fund additional capacity for specific changes. Without getting into the finer details, Product Managers managed their respective roadmaps for assigned enterprise products and obtained point estimates for top priorities ahead of a monthly governance meeting:

• Required Attendees: A Project Manager (who facilitated the meeting and tracked decisions), all Stakeholders (leadership level), all Product Managers, and Scrum Masters (from the engineering group to confirm capacity and assess the feasibility of decisions).
• Objective: Develop tentative plans (commitments) for shared development capacity a month in advance—essentially advanced sprint planning or pre-planning. Identify any need for supplemental development capacity, define the scope, and determine which stakeholder would be responsible for funding. Additionally, the status of any currently funded development capacity would be reviewed.

This approach worked well most of the time and was a necessary compromise to the best practices of the product operating model. In rare cases where stakeholders could not align on how to allocate shared development capacity, higher-level leadership would step in to make the final decision if necessary.

Managing Configuration Changes:

The “no code” feature of platforms means that anyone that is knowledgeable could make changes to enterprise products. It is strongly recommended that all changes be strictly controlled and managed, regardless of who makes them, with user permissions, processes and protocols set accordingly. When there are customizations (made with code), it is also important to consider how configuration (“no code”) changes could have an impact – to avoid unintended outcomes, including defects.

In my experience as a group product manager, some product managers that were well-qualified to make configuration changes to enterprise products build on the Salesforce platform (including those that had one or many certifications). Initially, an arrangement allowed some changes to be made by product managers working in collaboration with the engineering group. However, this approach proved too difficult and sometimes resulted in defects and other issues. We ultimately decided to have the engineering group handle all changes—both configuration and customization. This provided better change control, reducing the risk of defects. Additionally, this decision allowed product managers to focus on their core responsibilities.

Product Strategy for Enterprise Products on a Platform:

The strategy for enterprise products built on a platform should incorporate ways in which it can be leveraged to increase value and benefits—both from the standpoint of the business and the user. This aspect of product strategy, which relates to the return on investment (ROI) of making changes—adding, modifying, or removing capabilities—is shared with stakeholders and engineering for the following reasons:

• More Value from the Same Cost or Small Incremental Cost: Maximizing changes through configuration by using existing licensing and capabilities.
• Higher Productivity: The more capabilities built on the same platform for the same users, the easier it is to reduce the learning curve and provide a more unified experience, avoiding “swiveling” between apps.
• Faster Time to Market: Building and modifying enterprise products on platforms generally require less time and effort than developing them from scratch (greenfield).

In general, the strategy should be to maximize the capabilities of the platform through configuration and minimize the customizations, with use of the existing licensing. And as with any digital product, in addition to product strategy, other related strategies may come into play, including business strategies (e.g., sales, marketing, operations), technology strategy, and data strategy, among others.

This was incorporated into the product strategy in my experience with enterprise products built on Salesforce. Additionally, the product management team adopted a strategy for an enterprise product that was built to accommodate several different stakeholders (e.g. multiple sales channels). Some sales channels had slightly different capability needs, which could have led to significant customizations. However, our product strategy was to address such variations through configuration changes rather than customizations, which dramatically increased the ROI of changes to that enterprise product.

Avoiding Data Conflicts with Other Systems:

It is imperative that any enterprise software, including the platform, respects the system that serves as the “source of truth” for data. Platforms have its own database(s) that may contain vast amounts and types of data, some of which may be duplicative of information found in other enterprise systems. While this could be considered a non-functional requirement, as a product manager, you should be aware of the importance of data integrity and collaborate with those in relevant parts of the company that need to be involved in product decisions related to data.

In my experience, this was a challenge with user hierarchy. Salesforce has robust features for user account data, including managerial relationships. However, the HRIS (human resources information system) was the authoritative source for a user’s manager, so we had to take measures to ensure that user (employee) data remained consistent across both systems. Exceptions were allowed in some cases, which required guardrails to be put in place.

Data was also a challenge when building a lead management capability in Salesforce. Lead management was a new capability for sales employees, and there was a need to incorporate it into sales compensation models. The sales compensation system was originally designed only to accommodate sales transactions, so it required close collaboration across multiple teams to develop a solution and implement the necessary changes in Salesforce and other systems, including the sales compensation system and data reporting.

Qualifications for Product Managers for Products Built on Platforms:

In addition to the qualifications common to any Digital Product Manager, those responsible for enterprise products built on a platform need to have a comprehensive understanding of that platform—most importantly, its native capabilities and what can be changed through configuration versus customization.

When hiring product managers, I always considered aptitude and attitude to be the top priorities. For those assigned to an enterprise product built on Salesforce, I required them to have a comprehensive understanding of how enterprise products are built on the platform—whether through past experience, training, or obtaining a Salesforce admin certification. Industry or domain experience was desirable but not required.

The Rules of Product Management Still Apply to Enterprise Products:

It is worth mentioning that aside from the differences described in this article, all fundamental aspects of digital product management still apply to enterprise products built on platforms—including roles, processes, and tools.