Salesforce DevOps vendors will become a commodity if we keep our focus on features instead of outcomes

I speak to many people about their DevOps requirements, and I've been surprised by many of the requirements I've been given, such as:

• Being able to compare a Git branch against an org
• Being able to deploy a range of Git commit IDs to an org
• Being able to cherry-pick changes
• Create a feature branch per deployment
• Back promotion
• etc

What's wrong with these requirements? They are technical implementation details.

DevOps is a cultural move first and a technical implementation second. Ideally, I would want customers to think of their DevOps requirements as follows:

• Being able to deploy more frequently
• Reduce the number of failed deployments
• Not having to do rollbacks- Being able to shift quality left into the development lifecycle
• etc

Focusing on the features and not the outcomes has several drawbacks:

- You could have all the bells and whistles and still be deploying less often, with more bugs, etc. Features don't immediately translate to business value. Process and discipline around the features do.

- If the focus is on features, the community forces all vendors to have the same features.

In Michael Porter's strategy views, this is known as "pure competition" or "commoditization," where Salesforce DevOps vendors become interchangeable pieces of software because they all do the same in the same way (same implementation details).

This gives the community an unbalanced bargaining power, where users now force DevOps vendors to compete solely on price, which lowers the overall industry profitability.

If we focus on the outcomes, vendors can implement their preferred way to satisfy those outcomes, allowing for more differentiation, a healthier industry, and more successful DevOps implementations.