Why Software Applications Need Product Blogs, and Why They Don't Get Them

by Tom Johnson on Apr 16, 2008
categories: blogging • technical-writing

Even though I'm an advocate of blogging and think it's critical to tech comm, I've always been assigned technical documentation projects for internally used, confidential, or classified software. Documenting products promoted on the web has never been an option for me.

However, I'm convinced that even internal software, which never sees the light of WWW, still needs a blog as much or more than products sold online. Even so, numerous corporate restrictions, standards, and culture will present seemingly insurmountable barriers to blogs.

I can think of six major ways product blogs can benefit users and project teams. Product blogs can

• Provide a venue for product announcements
• Allow users to submit product bugs
• Allow users to submit feature requests
• Provide a roadmap preview for the product
• Enable a point of connection between users and project teams
• Provide a way to teach advanced tips to users

The following sections expand on each point above.

Provide a venue for product announcements

If you have a new release, you want users to know what new features and fixes are available. With software that runs from a browser, users may not know an upgrade has taken place. Additionally, if you're offering training or new services, such as a training environment they can explore, you need to let users know.

A blog can be a perfect way to let people know what's new. For example, today I learned from the Visual Lounge blog what's new in Camtasia 5.1. I loved finding this announcement in my feedreader (rather than getting an email blast).

Allow users to submit product bugs

Sure your Quality Assurance (QA) team tries to find all the bugs in the software, but if you allow users to submit bugs, you multiple your QA team of 1-3 people by 100 or more. The QA team usually has set scripts they run over and over to test the software, but they can't know the hundreds of ways users are using and abusing the software. Your users can submit an enormous amount of bugs if you just let them.

For example, Madcap Software has an online bug submission form. I've submitted more than a dozen bugs through this online form. Through your blog, you can easily add a tab or button that enables users to submit bugs. Of course you don't need a blog to collect bugs, but at least with WordPress, a built-in contact form is easily available (see the Dagon Design Form Mailer plugin). Making bugs public allows other users to be aware of potential pitfalls. And you can provide workarounds or fixes that all users can benefit from.

Allow users to submit feature requests

How do you gather feature requests from a wide user base? Like most people, I often have suggestions to improve the usability and features of the software I use. Because of the interactive nature of blogs, it's a natural fit to provide a feature request form on your blog.

If the feature requests are public (such as a comment thread on a post), other users can comment on the requested features. In fact, you could incorporate a rating form that would allow users to quickly indicate how much they wanted such a feature. You could then make better informed decisions about the priority of enhancements. This method avoids the problem of polling software requirements from a narrow user base.

Provide a roadmap preview for the product

Especially with agile applications, users want to know what enhancements are coming. On your product blog, you can provide a roadmap of features in development. This would allow users not only to be less frustrated with current system limitations, but would also clue them into the fact that upgrades are coming. I find that many users have no idea when upcoming releases are scheduled nor when they're released. They don't know if they're in 2.1, 2.2, or 2.3. They're just "in the application."

But with a roadmap preview, users can see what's coming, when it's coming, and what the new release will include. They'll be more patient, knowing that developers are actively working on problems and enhancements, and they'll feel part of the excitement of a live, actively developed application.

One of the things people like most about WordPress is that its in active development. Releases come out four times a year. With every release, users get really excited. In fact, the release of 2.5 was announced as the kickoff for Matt Mullenweg's keynote at Wordcamp Dallas.

Enable a point of connection between users and project teams

Perhaps the most important benefit of the product blog is to enable a point of connection between users and project teams. Blogs provide a way for users to contact actual project members, to express their concerns or requests, and to otherwise interact.

Likewise, blogs allow project members to connect with users. Allowing people to connect and communicate is huge. It's the phrase Mark Zuckerberg kept repeating at his keynote at SXSW, attributing Facebook's success to the way it allows people to "connect and communicate" with their friends.

With large companies such as Microsoft, Adobe, or Apple, I don't feel like I have a connecting voice. I have no idea who to contact, and even if I did have a contact email, the person (usually in Marketing) is so removed from actual development that I doubt my communication ever has an impact. In contrast, blogs make everything transparent and interconnected.

Provide a way to teach advanced tips to users

Users often don't realize that even though they've learned the application, they may be using it inefficiently. Once the user gets past the novice stage, they rarely consult the help. They get trapped in inefficient practices without realizing it. Through the blog, you can deliver more advanced tips that users may never be aware of, even if the tips already exist in the help.

Additionally, because blogs give the instruction in short bursts, users won't be overwhelmed (such as with a 200 page user manual). They can quickly skim a blog post and get the gist of the instruction. You can hit them with some advanced tips every week, spoonfeeding them into power user status.

Corporate Challenges to Product Blogs

On the web, you can easily install a robust blog platform, such as WordPress, and modify it with all the features you need. In fact, if you get a hosting plan with a company like Bluehost, setting up your blog is a 2 minute process (see their Simple Scripts feature). However, installing a blog on corporate server space behind a firewall is beastly, for the reasons listed below.

Approved Technologies Only. Most interactive software runs on PHP, requires databases such as MySQL, and has other server requirements. Companies often have strict infrastructure guidelines that aren't very tolerant of open source software. If your company has chosen not to use PHP, or uses only Oracle or SQL Server, or restricts everything to Java, you're in for a battle. (By the way, an alternative blog platform that runs on Java is Roller. Looks complicated to set up, though.)

No Server Space for Help or Blogs. Even more problematic, many times your infrastructure team won't give you server space at all, much less space to install a blog. SharePoint possibilities may exist, but SharePoint blogs are usually primitive (for example, there's no "read more" tag), and SharePoint can require users to log in before they can read your blog.

False cultural beliefs about blogs. Cultural shifts are also a big hurdle. A blog in the mind of your CEO or CIO may conjure up images of MySpace and Facebook, or opinionated ranters, or videos of cats playing the piano. You'll have to sell the idea of a blog. Maybe ditch the word blog and call it a new media site where users can interact. I don't have much advice here other than to be persistent. The squeaky wheel often gets the grease. If you mention how your competition is using the software you need, it will boost your case.

Employees don't use RSS readers. Finally, employees at companies rarely use RSS feeds, so delivering your blog will be difficult. Sure they can download a feedreader, but if yours is the only feed to subscribe to, fat chance. Perhaps you can convince developers to add a link that says "blog" next to the help, but you'll really have to convert the project manager to Web 2.0. I've daydreamed about how to integrate an RSS feed into my online help, but the idea of people accessing help to click a link to a blog is unlikely.

Conclusion

While software products need blogs, getting server space for a blog, getting approval for the blog, finding a blog platform that runs on your company's approved technology, and integrating your blog into a space where users frequently visit all pose major challenges for blogs in the corporate scene. Still, if you can manage to break through these barriers, product blogs can provide tremendous benefits to both users and project members.