Why It Pays to Use an Expert Salesforce PDO

By Matt Baker

A strong presence on Salesforce AppExchange is critical to success these days — after all, more than 90% of Salesforce customers shop at this global cloud marketplace. But making the cut can be difficult. There are some technical considerations that should be top of mind when designing commercial products for AppExchange; we cover seven of them here.

These seven services are unique to Customertimes’ product development offering and are an extension of the traditional development services known as PXO. An experienced PDO partner should cover each of these issues with you in detail before the first line of code is written.

The Top Seven

Do you have an “architecture of necessity” or a business-goals oriented architecture?

As the adage goes, failing to plan is planning to fail. If you take a reactive, ad hoc approach to product architecture – devising fixes to deal with issues as they arise – rather than a proactive approach, you will limit — even undermine —the long-term success of your product.

Instead, approach your product with business goals in mind from the outset. These PDO deliverables should be defined as part of the architectural design before any work begins:

• ROI
• Market Differentiation
• Go-to-Market Strategy
• Projected Features
• Growth Vectors

This is a keystone service Customertimes provided Solarisbank. Solaris wanted to develop and deploy Salesforce apps to enrich customer journeys, but it was unsure how to proceed. They needed help in integrating their platform with Salesforce, of course — but their requirements were more fundamental than that. They also needed to know just what their customers expected from them, and the specific steps necessary for creating an MVP suite of products.

Through CT’s Discovery & Ideation Lab, we researched and defined Solaris’ target customers; investigated options for integrating their existing platform with Salesforce; determined MVP baselines; and created a detailed project roadmap, including implementation costs and timeline.

We conducted our work in close consultation with Solaris principles, ensuring they were fully briefed on what we were doing and why we were doing it.  Likewise, we coordinated our efforts with Salesforce, confirming all corporate objectives were met on both sides of the project.

At this juncture, Solaris’ goals have been precisely defined and approved, and we’ve established the optimal path for reaching them. Next steps: building and implementing the products — and turning a profit.

How will you reach and onboard your target audience?

Since you will not have direct access to your end customers, robust self-service features must be built. These include:

• User guides
• Landing page
• Interactive help/chatbots

For example: once package installation is complete, an interactive landing page should be provided to walk admins through configuration items using a setup wizard. This is always preferable to a word document that explains any custom metadata that should be changed manually.

Do you need assistance to get the product working?

Fully automated installation should require no assistance or DevOps service to get the product working. As part of your agreement, your PDO partner should provide:

• Post installation scripts to populate all config and main entity values with default data
• Programmed auto-registration and key exchange for new tenants. If integration is required, this should be provided without requiring a support team or an admin to access the environment.

ETL is inappropriate outside enterprise systems with “owned environments.” For commercial products, integration mediums should be tailored for specific access context. Security separation should be enforced physically, and instances should be created as needed at the time of tenant auto-registration. From the outset, integration endpoints should scale easily to handle high customer volume.

Is the target environment flexible?

AppExchange products need to work with any combination of other platforms and local customizations to existing orgs. If the target environment is inflexible, a cascade of problems can develop, including:

• Errors and validations on objects can break other packages
• A chain of events may be triggered that cannot be controlled outside the package
• Future jobs can cause side effects on extra-package code

Additionally, third parties should be able to extend product functionality outside the control of the package producer.

As an example, local custom validation for sObjects should be automatically visible on custom screens that invoke the DML. Lightning pages are needed to catch DML-level errors and add them to the correct page validation screens. From project initiation, custom screens should be designed to handle the dynamic addition of custom fields if/when necessary.

These deliverables should also be included to ensure the flexibility and agility of your target environment:

• Graceful uninstall and clean-up scripts
• Dynamic hooks to existing custom sObjects via Partner Apex tooling API
• Hierarchical probability configuration testing to identify local configurations that may interfere

Your PDO should also expose extension mechanisms to third parties – global methods, plugin support with inversion of control, custom events fired, etc. – to test functionality and performance.

Can your product adapt to specific customer- and segment-specific behavior?

Often, products need alternative behaviors for specific customers or customer segments. These behaviors must be anticipated and planned for well in advance, or you will risk turning your product into a digital Swiss Army knife that is too difficult for novice customer admis to configure.

To avoid this, alternative extension packages, forked versions of the code base, and configurability must be considered ahead of time. Your PDO should establish:

• How the product will work in a multi-org set up
• Data segmentation and residency of external systems
• Modularity to install/enable specific functionality for different licenses and customer types

For the data segmentation, your PDO should make it possible to choose the corresponding external service clone from the installation page to avoid outages.

What support is offered?

Traditional outstaffing development services build your product and hand it back to you, leaving your team to grapple with any bugs or pressing customer support issues. Customertimes offers ongoing Managed Services to ensure your product succeeds, establishing permanent teams as needed to maintain your product and build new features/versions.

At a minimum, your PDO should provide the following support offerings:

• Anonymized debugging
• Troubleshooting without org access
• Self-service support centers
• Self-service training

How do you handle product/feature releases and upgrades?

For many (make that most) customers, downtime is unacceptable. To help you meet SLAs and keep customers happy, your PDO should have established plans to:

• Support multiple versions simultaneously. Not everyone will upgrade at the same time; most AppExchange products have long-term support for all versions.
• Manage:
  • Feature releases
  • Main version releases
  • Patch releases
  • Canary releases
  • Destructive releases
  • Rolling releases
  • Skip-version upgrades
  • Downgrades
  • Reversals
• Release integrated external systems, with a focus on supporting multiple API versions simultaneously for a seamless switch

Typically, a release versioning plan is created with specific SA for the life-expectancy of every version. The installation and upgrade process itself should be QA’d against multiple environment setups, and should be accomplished as normal functional flow rather than a technical job.

Conclusion

If you have a forward-thinking PDO – or PXO, in the case of Customertimes – your commercial products will have a much greater chance of success on Salesforce AppExchange.

Customertimes is the world’s largest independently funded Salesforce product development organization, and we’ve built hundreds of products that are currently on AppExchange. We’ve also built several of our own products for AppExchange, with a global user base of nearly 40,000.

If you’re determined to achieve long-term success for your own product on AppExchange, we’re ready, willing and able to help!