Posted on

Why we’ve launched the Cherryleaf podcast on technical communication

Earlier this month, we started the Cherryleaf podcast, and we’re currently publishing a new episode each week. I thought it might be useful to explain why we’ve done this, instead of publishing videos.

For the audience members, they are able to do something else at the same time as listening to a podcast. For example, you can listen to it in the car, while walking the dog, or lying in bed. I’ve found them to be a godsend when I’ve been waiting around at airports. Video demands more attention from the audience. This means podcasts generally make it easier for people to listen for longer periods of time.

As a result, podcasts are very popular. Although there are some very good podcasts on technical communication (such as Ryan Weber’s “10-Minute Tech Comm”), we felt there was room for at least one more.

For us, it opens up the opportunity to record outside the office. We don’t need to worry about lighting, framing, and the other issues that can come with recording video. It’s also easier to interview guests (something we hope to do in future episodes), when you all you need is a decent audio connection. This means it requires less time and effort to produce the content.

The frequency and the topics we cover will partly depend on you, the audience. We’ll stick with the weekly schedule for the next month or so, and then probably move to a monthly release cycle. We’ll be able to look at which episodes have been downloaded more than others, and gain an idea of the most popular topics. It will, of course, also depend on whether we run out of things to say.

We’d love to interview documentation managers and technical communicators, and include their opinions in future podcasts. So if you like to discuss taking part in a future podcast, do please contact us.

Posted on

New training course – Writing skills for developers

Today, we’ve released our latest training course – Writing skills for developers. The course teaches developers the key skills of technical writing for software user documentation.

writing techniques web page

Although it would be better for a professional technical communicator to write the end user documentation, for some organisations, this isn’t always possible.

It is for developers who:

  • Need a solid understanding of the fundamentals of technical writing
  • Want to communicate more clearly and effectively
  • What to know how little, or how much, they should write
  • Want people to answer their own Support questions

The course comprises 14 modules in total, which delegates can complete at your own pace. The course modules are delivered over the Web in small, manageable video presentations. The course handouts and exercises are downloadable as Word or PDF files.

We can also deliver this course as a classroom course for development teams.

For more information, see: Writing skills for developers training course.

Posted on

Breaking down the marketing and techcomm content silos – not as simple as it seems

Over recent years, we have seen many presentation on how marketing and technical communications content shouldn’t sit in separate “silos”, never to be shared between each department. Unfortunately, it’s not simply a case of getting both to agree to share content.

In the book Selling the wheel, Jeff Cox and Howard Stevens tell the story of a fictional technology start-up company inventing and marketing the wheel. Through this parable, they look at the lifecycle of a business, and how selling changes over that lifecycle.

The early stage

In the early years of a organisation’s life, it needs to have a sales person who is able to close one-off deals with as many “early adopters” as possible. At this stage, marketing and selling teams focus on selling the opportunity associated with the product, and selling the power and practicality of the product itself. At this stage, the organisation typically does not focus on customer support or service. Early adopters are often left to solve problems themselves.

The growth stage

In the growth stage, the organisation begins growing and taking on larger clients. These new customers want expert assistance both before, and after, the sale is made. Marketing and selling needs to be technically expert enough to deliver a solution tailored (and possibly customised) to a buyer’s need. This often involves instructing the users on how to use the product. This means providing demonstrations and training, as well as an installation service.

The organisation also needs to offer support. It also needs to test the products fully prior to release.

The mature stage

When the majority of the market is using the technology in the product, the organisation focuses on existing customers. They want customers to buy more, and pick up new business from competitors messing up.

The focus is now on maintaining relationships with customers and prospects. The organisation needs to manage complexity, pay attention to the details, and make sure the customers’ needs are understood within the organisation.

The commodity stage

As the market matures, and the market becomes saturated, the product moves towards becoming a commodity. The goal is to become the market leader with the most efficient supply chain.

The focus is on differentiating the product, where possible. This is typically done by offering superior service and by creating a positive customer experience. There is less need for requirement for customisation, but perhaps more opportunities for offering value-added products and services.

Because of the high competition, there are often mergers and acquisitions between competitors. Their products may need to be incorporated into the product portfolio.

The changing role of technical communications content over the business lifecycle

These different lifecycle stages mean the importance and role of technical and marketing communications content will change over time:

  • 1st stage – The organisation needs content that demonstrates the power and practicality of the product/technology. It needs to be credible, and it needs to be consist with the marketing message.
  • 2nd stage – The organisation needs content that enables installation, customisation and customer training. It also needs content that enables it to fix mistakes.
  • 3rd stage – The organisation needs content that enables it to manage complexity – make things easy for existing customers. The technical content must help in avoiding the company from screwing up.
  • 4th stage – The organisation needs content that enables it to provide great service. This might be enabling customers to solve problems easily themselves, or enabling the Support team to provide great service.

This means it’s not a simple case of co-creating or sharing content between the Marketing and Techcomm departments. Different approaches will be needed, depending on where the organisation currently sits in the lifecycle we’ve described above.

Posted on

What is the minimal amount of user documentation you should write?

In researching what developers wanted to learn about writing documentation for users, the most common issue related to how much, or how little, they should write. One developer said:

“I would want to know what is the minimum I should write. If you can persuade me what is the necessity of each thing I’m capturing, and the voice I should use to make it most acceptable, I think I’d tune in.”

We’ll look at this question in the Writing Skills for Developers course, which we will be releasing soon. In general, you need to:

  1. Meet the legal requirements (which differ depending on the product, and the country).
  2. Provide enough information so that users don’t give up using your product, if they get stuck. For example, how to install the software, and how to get started.
  3. Consider the support calls, and whether you could avoid any of those by having good user documentation.

That might appear a bit too vague, so let me go back to one of the sentences above:

“If you can persuade me what is the necessity of each thing I’m capturing”

Before you start writing, you should define the purpose and audience for each deliverable you create. There should be a use case:

  • Without documentation, is it clear what the user should be doing? is it clear what the user should be doing first?
  • Is it clear how they should be doing the task?
  • When they have to choose between options, do they have enough information to make the right decision?
  • When they have completed a task, do they know what to do next?
  • Are there any concepts or terms the user might not understand?

You can assess what topics to cover by doing some basic usability analysis. However, if you think about the tasks, the process (workflow), and any unfamiliar concepts, you will be on the right track.