Home
← Back

What is an Ecosystem?

An ecosystem is a dynamic, functional unit composed of elements that interact with their environment.

NOTE: This is a "Reader's Digest" Condensed version of a longer TCPE Proof of Concept document about how the overall environment, not just the content, should be thought of, from a Technical Writer's perspective.

If you are interested in the full document, contact the Author.

Technical Content and Product Ecosystem (TCPE)

Purpose

This document outlines the Technical Content & Product Ecosystem. If you have any questions or feedback, don't hesitate to get in touch with the author.

Scope

Technical Content focuses on helping both technical and non-technical people understand the technology around the product or portfolio and how it will help them solve a problem.

There are several kinds of content that the company must produce to supplement its products and services.

Including, but not limited to:

  • Marketing Content
  • Technical Content

Technical Content, as opposed to Marketing Content, focuses on helping both technical and non-technical people understand the technology and use of the product, and how it will provide value.

Exceptions

This document focuses on Technical Content creation and management (Guides, Whitepapers, Use cases, etc.). It does not cover any other (Marketing / Business )content.

What is TCE?

An “Ecosystem” is a mix of Content, Infrastructure, and Strategy, focusing on enabling technical and non-technical people to understand the technology and use of the product and how it will provide value.

A well-defined Ecosystem ensures that everyone involved in product development and marketing is working towards the same goals, maximizing the product's chances of success.

Technical Content

Technical Content has expanded well beyond the physically published word from the legacy "Printed Manuals and Guides shipping in a physical box to the user community" era.

Today, a broad documentation ecosystem is required to deliver format options that provide the best user experience, and value , and ensure long-term success.

TECHNICAL Content is not only a Strategy, but an essential element of the Ecosystem as defined within this document.

The “P” in TCE

The “P” in TCE represents Product or Portfolio, but in this case, it is Product.

Product can reference a Department, Group, Team, or Portfolio. Product also references Product Strategy and the value Technical Content adds to the Product Value Stream.

Product (Team, Group, or Department)

A product department or group is responsible for the product lifecycle from concept to end of life.

The Product Team, Group, or Department is the liaison between the users, business owners, and technical resources, ensuring that the product delivers both customer and company value.

Product Strategy

Product Strategy defines the vision, target market, key features, and company and customer value. It isa blueprint that guides product development, marketing, and delivery efforts in alignment with overall business objectives.

Key components of Product Strategy

Vision

A clear statement of the scope of product features and its intended value

Target Market

Defines the specific demographic of customers the product is designed for.

Value Proposition

Explains how the product will benefit the target market and address customers’ needs.

Key Features

Identifies the essential functionalities and capabilities of the product.

Competitive Differentiation

Outlines how the product will stand out from its competitors (“How we solve your problem better than anyone else…”).

Business Goals

Aligns the product strategy with the overall business objectives, like achieving revenue targets or increasing market share.

Go-to-Market Strategy

Describes how the product will be launched, positioned, and marketed.

Metrics for Success

Defines how performance will be measured and evaluated (i.e., what worked, what didn’t, and what’s needed next).

What makes the Ecosystem?

The following components provide the foundation of the ecosystem.

Strategy (General)

As the saying goes, "...Plan your work; work your Plan..." that is what a Strategy is in a nutshell.

Without strategies associated with these Content types though, companies inject unnecessary "Toil" into the environment: wasting money and resources by creating and then being forced to maintain, correct, or replace content that’s not useful for the users and a profit drain for the company.

“Toil” also comes in the form of trying to use the wrong tools, not assigning adequate time, resources, etc. to create the right content or even product for the market.

A strategy should address the following, prior to creating anything:

- The point (what does the product do or what need for the user is addressed).

- Who "owns" handling the information (create, measure, and maintain the information).

- What does the user community need (what will best meet user needs).

- How will the content be displayed (tone, structure, format, platform)

- How will the content be offered (publish method, user type also drives delivery method)

A strategy plan (company-wide / all content (Technical and Marketing)) will if:

  1. Done correctly, the content strategy forms the foundation of the ecosystem.
  2. Done correctly, the content strategy will reduce the toil associated with identifying the audience, what the content needs to explain, and the goals of the documentation.
  3. one correctly, the content strategy will guide the content map, while aligning with company objectives and user and product requirements and maps.

Strategy gives you direction and a repeatable, sustainable path for how to do things without "reinventing the wheel" every time.

Authoring Platform

Authoring, too many times, focuses strictly on the writing tools alone--be it a FrameMaker, Madcap Flare, ZenDesk, etc., that are currently in use in most content / documentation scenarios.

While they are, for the most part, robust at wordsmithing, other areas, such as storage, reviewing, even publication might be supported, but not the best method because those are not the roots of the application (i.e., Zendesk is a Service Desk application with "bolt-on" article and word smithing options)..

"...Pick the right tools; don't pick tools and try to make them work 'right'..."

What we need to do is expand the vision of what we work with and what is needed to support the production and sustainment of the content. We need to think in terms of environment. The "platform" needs to scale,

Choose an authoring environment that supports scalability, flexibility, while reducing writing resource toil:

Confirm that the platform enables easy creation, editing, reviewing, validation, and publishing while supporting either internally, or as seamlessly as possible, version control and access control.

Provide training and resources to help resources adhere to these standards effectively.

Authoring Tools

Invest in authoring tools that streamline the content creation (reduce toil) and promote scaling and flexibility. Look for tools that embrace structured authoring, content reuse, and (hopefully seamless) integration with other systems and platforms. Team members' collaboration, real-time feedback and review should be second nature to the tool. If there are other departments or groups generating content (i.e., Marketing), coordinate with them to try and minimize exporting toil:

Remember, "pick the right tool..."

Templates and Standards

Establish templates and standards (i.e., Style Guides, Version Control, Document ID system, etc.) to ensure consistency. A Style Guide should spell out clearly the styles, conventions, and terminology that support the user communities’ style, guidelines, and especially terminology (to avoid confusion or terms and definitions) and to produce a consistent message and professional appearance--making the product(s) and company appealing.

Feedback Mechanisms

Implement feedback to gather input from users and stakeholders, both internal and external, resulting in sustained content improvement. Encourage feedback, simplify methods to report issues, and offer easy to understand and use avenues to suggest enhancements through multiple channels. The resulting flow can then be repeatedly applied to the content every time something new is needed, features are added, etc.

Defining the Ecosystem Components

The following lists some examples of reference materials that could guide the company. It reflects the path taken to build out the infrastructure needed for the Ecosystem listed in the previous section.

  • Doc ID Number (DIN) tracking log
  • Technical Content & Product Ecosystem (TCE) 
  • Documentation Strategy Policy (DSP)
  • Master Documentation Roadmap (MDR) 
  • Documentation Life Cycle (DLC)
  • Documentation Request
  • Documentation Priority
  • Document ID Number (DIN) Assignment 
  • Documentation Estimate
  • Documentation Build Process
  • Content Review Process 
  • Content Stage & Deployment
  • Content Sustainment Process

Best Practices

The following Best Practices will be instituted in conjunction with TCE.

Apply Applicable Professional Bodies of Knowledge

Embrace standard Technical Document Templates/Outlines. Ensure Content is Fit-for-Purpose and audience focused.

Regular Updates

Regular scheduled Sustainment reviews and Release Notes

Accessibility

Enforce accessibility to ensure full functionality and ADA compliance.

Localization

Consider multiple language options where applicable. Adapt content to cultural and language preferences.

Continuous Feedback

Actively employ Feedback mechanisms with the owners, requestor(s), and user(s)—both internal and external to align content with the voice of the customer. For example trhe following questions are good starting points:

  1. Does this document appear to provide the information you require?
  2. Does the information appear to be presented in a logical manner?
  3. Does this document need more diagrams or illustrations?
  4. Is the format accessible and easy-to-use?
  5. Do you expect to use this document regularly?
  6. How would you rate the usability of this document on a scale of 1-5 (1=excellent)

Anaytics

Technical writers should use analytics, if possible (i.e., Google Analytics), to measure documentation performance, user behavior, and content effectiveness.

Key metrics to target should include:

  • Page views
  • Bounce rates
  • Session duration

and

  • Search queries
  • The search queries will help enable data-driven decisions to improve content usability. This helps identify popular topics, reduce support calls, and optimize user navigation.