Building a Product Release Engine with CogniDox

In this blog I want to start a new theme - projects that can change the way your company works.

All companies are unique to a degree, but there are many common issues that the majority are trying to solve. In the technology world we talk so much about features that it can be difficult to relate these back to the problems they are meant to address. I want to approach it from the other direction: what is the problem and how can software (CogniDox in particular) address that problem?

In the first of this series I'm going to consider a biggie: how do we make an efficient process for actually releasing a product? We read scholarly articles about innovation and the overall process / development methodologies that might help, but what about the mechanics of actually making a product release in the leanest manner possible?

If we succeed in this, we can say we have an efficient Product Release Engine.

Most high-tech companies have multiple products. Most products combine multiple project deliverables; from different hardware and software teams as well as technical writers and training. Most product releases are complex and require a specific configuration of elements to work reliably and properly.

You can have great teams using the best tools, but still suffer from information silos in your product development. The hardware team may have files created in AutoCAD or SolidWorks for CAD design. The software team may use Git or Perforce for the version control of software programs. The technical authors may use a DITA-compliant XML tool for the user guides. And so it continues across Training, Technical Support, and other groups.

There are two other common problems.

The first is the task of making a product release can be hard to pin on any one job role. It could be the Product Manager, but they may think their job is about managing user requirements, prioritising product features and building roadmaps. Project Managers may only be concerned about milestones and finishing on-time, rather than what happens after. It could be the Software team - after all they'll likely have a software configuration tool in place and will be familiar with the language of branches, builds, and releases. But software is only one stream in the overall product, so this is necessary but not sufficient. The solution to this is to make this an explicit job title - the Release Manager. It doesn't always have to be a full-time role or person, but it should be clear who is responsible. Their responsibility is to validate that all release components have been approved for release by the technical, product, and executive teams.

The second problem is that there is often a gap between the product deliverables and the entitlements of the customers receiving the product. Even if someone is responsible for the release, they lack the tools to help them manage a matrix of products and customers. Even if it’s managed using the ubiquitous spreadsheet, it still requires a manual step to decide before a customer receives anything.

So what can be done to link together the different teams that contribute to a product development and prevent 'silos of information' forming in the company?

CogniDox is a ‘silo-linker’ that solves this problem and gives the Release Manager a useful set of tools. Here’s how:

• It provides a common repository for all the individual specialist tool outputs. Infeeds from mechanical drawing, software development and technical authoring (to name a few) all end up in the same place

• It enables a common review and approval workflow across teams and job functions. This is augmented by dashboard tools to instantly see the 'health' of a product category; to judge whether it is ready for a Gate Review meeting, for example

• Document Holder files can be used to describe what components make up the product. A document holder is a special CogniDox document type (DH) that is used to link  documents. DH document types are XML files that are then automatically formatted into a web page with links and information

• The Product Manager user role in CogniDox includes features useful for Release Managers. For example, they can build a release configuration where content is tagged with a license and customers are assigned licenses for access entitlement. Licenses can be linked to anything that binds a set of customers: product type, geography, service level agreement, generation of product, early adopters, and so on

• At product release time, content is automatically copied to an extranet web portal where it is available for customer download. No more panics at 6pm Friday (always the designated release day) to "get everything out the door". Not to mention the work on Saturday and Sunday to correct the errors

• Download activity by customers is automatically tracked on an individual document level. Analytics like this can give insights into the way individual content (such as a new release of software drivers or a quick start guide) are actually been consumed

If you'd like to know more about the tools that CogniDox provides for Product Managers, feel free to contact us for more information or a demo https://www.cognidox.com/contact-cognidox-document-management-system