Proposed audience strategy for website refresh

[tdcox]

Audience Personas

When writing content for cdevents.dev, it is important to understand who this site is intended to serve and to ensure that the needs of each group are being addressed with appropriate information.

We anticipate that the primary audiences for this site are:

• CI/CD Tool Maintainers (Vendors / FOSS project members)
• Decision-makers, evaluating CI/CD tooling
• End-Customer Engineers, implementing CI/CD instances
• Browsing audience, looking to understand more about best practice

Let's understand the needs of each group in more detail.

CI/CD Tool Maintainers

As a CI/CD Tool Maintainer, I work for a commercial CI/CD Tool Vendor, or am a contributor to a FOSS project that maintains a CI/CD tool.

I am highly technical and understand the benefits of standardization and interoperability.

My primary interest is in understanding the specification so that I can implement functionality in my product correctly.

I may be a producer of events who is maintaining a CI/CD platform tool, or I may be a consumer of events who maintains an associated CI/CD product such as a metrics collection system or visualizer.

Decision-makers

I work at an End-Customer organization and am currently evaluating CI/CD tooling options in order to support our transition to Continuous Delivery.

I may come from a technical or a commercial background and am at an early stage of familiarity with the challenges associated with Continuous Delivery.

I need help to understand how best to differentiate between all the tooling options available to me.

End-Customer Engineers

I work at an End-Customer organization and am responsible for implementing our internal CI/CD instances.

I am technical and understand some of the challenges in the Continuous Delivery space but want to learn more about how CDEvents make my life easier.

Browsing audience

I am interested in CI/CD and Continuous Delivery and am looking to understand more about best practice in this space.

I have been reading the CDF Best Practices Guide and was referred here from there. I may be more or less technical in background and would like to understand where the value in CDEvents lies for me.

Audience Strategy

By looking at our personas, we can see that we have two basic narrative tracks that we must cater for:

• There is a highly technical audience that needs very detailed and accurate specifications
• The remainder of the audience remains to be convinced and will need a story that they can follow to their satisfaction

CI/CD Tool Maintainers and a large proportion of the End-Customer Engineers will want to approach the site as reference documentation. For this audience, we need clear links that take them immediately to the detail, structured in such a way that they can find what they need, but also have visibility of the full scope of the information available, to help them to size the effort facing them.

The intent is for this audience to have a pleasant experience, implementing CDEvents.

Decision-makers and the browsing audience are likely not bought into the content upon first arrival, so we have perhaps ten to twenty seconds to persuade them to invest more time in order to learn what is of value to them in the content. This requires a succinct and friendly landing page that pitches a clear message above the fold. This should then expand into a non-technical narrative providing the basic concepts before leading into the detail, with the expectation that few from this audience will consume all of the information themselves.

The intent is for this audience to take away key learnings that they will use to support future decisions, and to direct others to visit to access the details.

It is additionally expected that some CI/CD Tool Maintainers and End-Customer Engineers will benefit from the conceptual narrative that will enable them to easily become evangelists for the CDEvents approach. CI/CD Tool Maintainers may need help in communicating to their own customers the value-add of CDEvents support in their systems. End-Customer Engineers are often in a situation where they have to pitch a technology to their Decision-makers to get buy-in for a given approach, so simple explanations of commercial value can be very helpful to this audience.

This strategy must extend beyond the learning journey into the community space. Once we have explained the specification to the CI/CD Tool Maintainers, this must be reinforced with a call to action to implement the spec within their product and connection to appropriate additional support and community resources to help make this as easy as possible.

For all of our audience, we would additionally like to create a call to action to become contributors themselves and to add to the shared value.

[afrittoli]

(...)

CI/CD Tool Maintainers

As a CI/CD Tool Maintainer, I work for a commercial CI/CD Tool Vendor, or am a contributor to a FOSS project that maintains a CI/CD tool.

I am highly technical and understand the benefits of standardization and interoperability.

My primary interest is in understanding the specification so that I can implement functionality in my product correctly.

I may be a producer of events who is maintaining a CI/CD platform tool, or I may be a consumer of events who maintains an associated CI/CD product such as a metrics collection system or visualizer.

Decision-makers

I work at an End-Customer organization and am currently evaluating CI/CD tooling options in order to support our transition to Continuous Delivery.

I think we should limit ourselves here to the use case of transitioning to CD.
Many organisations are at different stages in their CD journey and they may be looking at how to advance further, how to improve on specific DevOps metrics, and how to fix existing bottlenecks and inefficiencies.

Is "End-Customer" different from "End-User"?
End-user is an organisation that adopts CI/CD tools but does not resell them.
What does end-customer refer to in this context?

I may come from a technical or a commercial background and am at an early stage of familiarity with the challenges associated with Continuous Delivery.

I need help to understand how best to differentiate between all the tooling options available to me.

End-Customer Engineers

I work at an End-Customer organization and am responsible for implementing our internal CI/CD instances.

I am technical and understand some of the challenges in the Continuous Delivery space but want to learn more about how CDEvents make my life easier.

It might be worth calling out platform engineers. Event-based architecture and flexible and resilient, but also have a higher degree of complexity, so I expect them to be more common in organisations that have a platform team managing that complexity for all the dev teams.

When a platform team exists, CI/CD engineers may still have to emit CDEvents to fit within the platform, and our documentation should be a good reference for them.

Browsing audience

I am interested in CI/CD and Continuous Delivery and am looking to understand more about best practice in this space.

I have been reading the CDF Best Practices Guide and was referred here from there. I may be more or less technical in background and would like to understand where the value in CDEvents lies for me.

(...)

[tdcox]

From a best practices perspective, we discourage the use of ‘CD’ abbreviations as too ambiguous. The focus should really be on Continuous Delivery as an overarching methodology because the majority of business value is realised only via that path, so the intermediate task of continuous deployment often causes confusion and ‘failure to take-off’.

[e-backmark-ericsson]

I like the way you describe the Audience Strategy, @tdcox !

And to expand on it event more, to me, the two main purposes of cdevents.dev site are:

1. "Storefront" - Present what CDEvents is in as simple and intuitive and convicing terms as possible, attracting potential users (CI/CD tool maintainers, decision makers and end-customer engineers) of CDEvents

• This would include some top use cases for CDEvents. Those include the obvious CI/CD tools interoperability on the orchestration level, but almost equally important is the added value of enabling any consumers of this data to digest it in a standardized way. Such consumers could be metrics collectors (DORA for example), visualization solutions, release decision processes, build/test avoidance systems, etc etc.
• The Storefront would be based on the latest released version of the CDEvents spec, if version specific information is mentioned

2. "Portal" - Serve as a portal for all CDEvents information needs, such as a link to the spec (preferrably links to all supported versions), information about existing SDKs, PoCs and other CDEvents supported tools/components (i.e. CDEvents landscape)

Of less importance is the need to include:

• Detailed technical details such as json schemas and a full catalog of event examples. Such could instead be assumed to be found in some of the referenced GitHub repos (the spec repo for example). This section should probably link to (or possibly include) information related to each supported version of the spec.

So regarding the narrative track "There is a highly technical audience that needs very detailed and accurate specifications" I believe that comes with lower priority than the above mentioned "Storefront" and "Portal" narratives.