diff --git a/modules/olm-operator-framework.adoc b/modules/olm-operator-framework.adoc
index fe1056291d..a3a2d3e68b 100644
--- a/modules/olm-operator-framework.adoc
+++ b/modules/olm-operator-framework.adoc
@@ -21,8 +21,8 @@ role-based access control (RBAC) of Operators in a cluster. Deployed by default
 in {product-title} {product-version}.
 
 Operator Registry::
-The Operator Registry stores ClusterServiceVersions (CSVs) and Custom Resource
-Definitions (CRDs) for creation in a cluster and stores Operator metadata about
+The Operator Registry stores ClusterServiceVersions (CSVs) and custom resource
+definitions (CRDs) for creation in a cluster and stores Operator metadata about
 packages and channels. It runs in a Kubernetes or OpenShift cluster to provide
 this Operator catalog data to OLM.
 
diff --git a/modules/olm-why-use-operators.adoc b/modules/olm-why-use-operators.adoc
index 02520ce8ed..c2a311c5b6 100644
--- a/modules/olm-why-use-operators.adoc
+++ b/modules/olm-why-use-operators.adoc
@@ -24,7 +24,7 @@ providers.
 Why manage your app with Kubernetes APIs and `kubectl` tooling?::
 These APIs are feature rich, have clients for all platforms and plug into the
 cluster’s access control/auditing. An Operator uses the Kubernetes' extension
-mechanism, Custom Resource Definitions (CRDs), so your custom object,
+mechanism, custom resource definitions (CRDs), so your custom object,
 link:https://marketplace.redhat.com/en-us/products/mongodb-enterprise-advanced-from-ibm[for
 example `MongoDB`], looks and acts just like the built-in, native Kubernetes
 objects.