Best practice: Developing products and services with a wiki

Pinakothek der Moderne
More orientation in the product management with wikis. Image: Pinakothek der Moderne, München 2004, by: Reinhard Jahn (CC BY-SA 3.0) via Wikimedia Commons.

A wiki is the central tool for sharing information about changing products and services centrally, efficiently and systematically. Are there best practises? We have compiled the most important questions.

When companies develop their services and products, there are many questions that need to be answered quickly and communicated to the relevant departments and teams:

  • What is included in the product?
  • How is the product calculated?
  • How does the product differ from competing products?
  • Is there a need to observe certain procedures and requirements at the time of delivery?
  • Where is there additional information about quality features or about similar products in the product range?
  • What are the experiences with this product and how should it be further developed?

Sales, development, project management and support depend on up-to-date information in order to carry out their tasks efficiently and efficiently.


When is the use of a wiki recommended?

In general, every company can use a wiki to centrally document and further develop services and products. The attraction of using a wiki is, on the one hand, the fact that the employees can quickly look up and get information about the status of the product. On the other hand, suggestions for changes and experiences can also be collected directly. In this way, the requirements of different departments can be quickly and systematically integrated into the ongoing product development. Wikis are therefore interesting when dynamic, agile, highly efficient and collaborative documentation is required. So always.


How does a wiki support product planning?

With an enterprise wiki such as BlueSpice, you can document a product from planning to sales start to archiving. The wiki is the ideal documentation tool for every step in the product lifetime.

  • New or planned products and services are created as a new page. Page templates support the authors in structuring the articles. Forms can also be used – to store metadata (product owner, publication date, product category, predecessor product, etc.)
  • The product can be sorted with categories and with help of portal pages.
  • Depending on your needs, you can publish products in a draft mode that is only visible to certain employees.
  • Workflow tools support quality control: experts and stakeholders are systematically asked to evaluate the product or the new service and to add missing information.
  • At the end of this review process employees can release the product and release the design mode.

However, the use of workflow and release functions is not compulsory. Often, for smaller organizations – for example consultancy firms – the standard functions of a wiki are already sufficient.

BlueSpice is ideal for the further development of products. For this each article has its own “discussion page”. There, new ideas and requirements for the successor product can be collected. In planning meetings they are then coordinated. The decisions can also be documented in the wiki on the discussion page or in a log.

Quality assurance is assisted by placing articles on “remind” and assigning the articles to an editor or groups which will be informed of all changes.


How to prevent all employees from seeing products that are still under development?

Wikis like BlueSpice have different mechanisms to manage rights. In order to be able to discuss new product developments with a small group, one can set up a so-called namespace, a protected space in which articles are located, which are only viewed and edited by a particular group. The publication of the product page is easily done by moving the article from the protected namespace into the public namespace.

By the way: It is worthwhile to announce new products or changes in the wiki-internal blog, in order to keep as many employees as possible informed.

There is also the possibility to outsource confidential information about products and services to another wiki. With a separate wiki you can perfectly split permission groups and ensure the protection of the content. It also offers the advantage that employees can already see at the first glance what is internally and confidential and what already has been made known to partners and customers.


Can I protect single pages?

A protection of single pages is basically possible. But BlueSpice MediaWiki is not designed for single page protection for many reasons. Among others: too many protected pages demotivate authors and coworkers. Wikis are powerful when knowledge is to be quickly shared, collected and sorted. So it is recommended to keep the hurdles as low as possible.


Does this also apply to products with high safety requirements? For example, in innovative tech companies?

There are use cases, which, for good reasons, also have high security requirements and require good access protection. These use cases can be realized with a wiki. In the last ten years, we had almost no use case that could not be realized with a more or less adapted wiki.

However, we are observing that many companies are discussing what information needs to be protected and which information should be available more freely. Under the enormous innovation and competition pressure employees have to be informed and involved in order to prevent bad planning and redundant communication. Innovative industries need agile methods and tools. The encapsulation of knowledge in protected knowledge silos is increasingly becoming an economic issue.

BlueSpice MediaWiki supports the integration of employees by changing the viewing angle. The question “What can we publish?” will be changed to “What do we really have to protect?” This change in the angle of vision creates the basis for an extremely productive collaboration within the companies.


How to deal with product variants?

The wiki offers here several ways, that depend on the specific content and structures in the company. The cleanest way is to create a separate article for each product. Product variants can be put onto so-called subpages. For example, there is an article for the service “maintenance contract” and the variants of this service (e.g. “self-support”, “standard”, “premium”) can be described separately on the subpages. Then the articles will have these title structure:

  • Maintenance Contract
  • Maintenance Contract / Self-support
  • Maintenance contract / Standard
  • Maintenance contract / Premium

The main article “Maintenance contract” contains the regulations which apply to all maintenance contracts and on the subpages the employee finds the description of the variants.

The advantage of subpages is, that all related articles are bundled and can be found quickly.

However, these subpages are not protectable and the readability of titles can suffer when the subpages are nested. If a page protection is necessary, you can work with namespaces as above. Here it is worthwhile to plan the content and title conventions well in advance.


What is with descriptions that apply to multiple products?

MediaWiki has a brilliant template system. This allows you to copy the contents of an article or template into several articles, but you only have to maintain it in one place. This mechanism with the term “transclusion” is very useful within a wiki. Transclusions from one wiki to another are not recommended for safety reasons because the rights management is circumvented. Here you have to deploy a clean publishing process, which can be supported with some software customizations.


Are multiple languages ​​supported?

Product descriptions in other languages can be placed on subpages, if these are not reserved for product variants. Don’t mix that up. From a certain amount of articles, however, each language should have its own wiki – like we know that from Wikipedia. This has many advantages for the user guidance (search, navigation, categorization).

It is best to set up a WikiFarm and link the different language articles via language links.


Can customer-specific changes be documented?

This is of course possible. The question is, whether changes and documentation should also be visible to this customer. With such more complex requirements, software and architecture adaptations are unavoidable. In general, however, it can be said that MediaWiki in general and BlueSpice in particular provide already in the standard the basis for customizations. Hallo Welt! also provides comprehensive consulting on these issues.

You Might Also Like

Leave a Reply