diff --git a/design/release-notes/release-0.11/draft-release-notes.md b/design/release-notes/release-0.11/draft-release-notes.md
index 7535420f8..cf29cb00a 100644
--- a/design/release-notes/release-0.11/draft-release-notes.md
+++ b/design/release-notes/release-0.11/draft-release-notes.md
@@ -37,10 +37,11 @@ enable us to push ahead with many new features in the project.
 With all of these great changes, there is also work to do.
 
 The changes to our CRD resources mean that upgrading requires more manual
-intervention that in previous releases.
+intervention than in previous releases.
 
-It's recommended that you backup and completely uninstall cert-manager before
-re-installing the v0.11 release.
+It's recommended that you backup and completely [uninstall
+cert-manager](https://docs.cert-manager.io/en/release-0.11/tasks/uninstall/index.html)
+before re-installing the v0.11 release.
 
 You will also need to manually update all your backed up cert-manager resource
 types to use the new `apiVersion` setting.
@@ -85,12 +86,57 @@ users secure services running on Kubernetes.
 
 ### New CertificateRequest resource type
 
+With this release comes the graduation of the `CertificateRequest` resource from
+alpha to beta. This means that when requesting certificates using the
+`Certificate` resource the `CertificateRequest` resource will be used as the
+default and only way to honour the request. The addition of this resource
+introduces the ability for much greater extension points to cert-manager,
+notably out-of-tree issuers, istio integrations, and experimental tooling such
+as a CSI driver. You can read more about the motivation and design of this
+resource in the [enhancement
+document](https://github.com/jetstack/cert-manager/blob/master/design/20190708.certificate-request-crd.md).
+
+This change should cause no disruption to how end users interact with
+cert-manager, with the exception of debugging now requiring this resource to be
+inspected also.
+
 ### Support for out-of-tree issuer types
 
+With the graduation of the `CertificateRequest` resource, cert-manager now
+supports out-of-tree issuers by default and treats them the same as any other
+core issuer. This process is facilitated by the addition of the `group` field on
+issuer references inside your `Certificate` and `CertificateRequest` resources.
+
+If you're interested in implementing your own out-of-tree issuer, or if there
+is a provider you would like see implemented, feel free to reach out either
+through a [GitHub
+issue](https://github.com/jetstack/cert-manager/issues/new?template=feature-request.md)
+or send us a message in the #cert-mangager channel on [Kubernetes
+Slack](http://slack.kubernetes.io/)!
+
 ### New fields on Certificate resources
 
+This release includes a new field `URISANs` on the `Certificate` resource. With
+this, you can specify unique resource identifier URLs as subject alternative
+names on your certificates. This addition unblocks development for an istio
+integration where mTLS can be configured using cert-manager as the backend and
+in turn opens up its providers to be all that cert-manger supports.
+
 ### Improved ACME Order controller design
 
 ### No longer generating 'temporary certificates' by default
 
+Previously, we have issued a temporary certificate when a `Certificate` resource
+targeting an ACME issuer has been created. This would later be overridden once
+the real signed certificate has been issued. The reason for this behaviour was
+to facilitate compatibility with ingress-gce however many users have had trouble
+with in the past and has led to lots of confusion.
+
+In this release, no temporary certificate will be created unless explicitly
+requested. This can be done using the annotation
+`"cert-manager.io/issue-temporary-certificate": "true` on `Certifcate`
+resources, or using the `"acme.cert-manager.io/http01-edit-in-place"` annotation
+on ingress resources that will in turn write the temporary certificate
+annotation onto the generated `Certificate` resource.
+
 ## Changelog