ISV Kaizen

Any macro- or microISV collects a pile of miscellaneous information while developing, promoting and supporting its software products. This includes:

• know-hows
• algorithms
• company policies
• programming, development or marketing techniques and tricks
• standard solutions and workarounds for certain issues
• collection of links to various resources
• how-tos
• use cases
• experience with third-party software, tools or services
• research and analytical reports
• white-papers and articles
• statistics
• industry news
• events
• to-do lists
• contacts
• … etc …

The list is theoretically infinite. In practice these odd bits of information are usually stored in different unrelated sources: e-mails, help files, document files, source code comments, browser favorites, or simply as sticky notes on your desktop.

This causes the following problems:

• Complicated access to important data. You can simply forget where they are stored.
• Risk to occasionally lose some significant files, e-mails or paper notes.
• Difficulties in collaborative use of the information. Nobody in your team knows where you store your sacred knowledge. In the same time, you have no idea where your colleagues keep their information.
• Ineffective re-use of information. You often have to re-invent something that you’ve already done or research something you know.

To overcome the problems you must accumulate all bits of your corporate information in a single knowledge base with collaborative access.

Large companies may setup custom knowledge base as a part of their corporate portal, e.g. with MS SharePoint server. But I speak for small ISV companies today …

Relatively small companies like ours may use Wiki engine. I’d personally recommend MediaWiki. It’s free and easy to install on any Apache/PHP/MySQL hosting though it’s very powerful and flexible. The famous Wikipedia uses MediaWiki engine.

Although there are many useful extensions and modifications for MediaWiki you may start with just a few of the most important ones:

• SimpleSecurity allows setting access privileges for users. So, you can limit access to certain pages for some members of your team.
• SyntaxHighlight_GeSHi allows to insert source code sections into articles and to highlight the syntax. It’s very useful for software development companies. This extension requires additional installation of GeSHi library that supports dozens of programming language syntaxes.
• CharInsert adds toolbar to the editor for quick insertion of Wiki codes.

Setup wiki today and start collecting your information there. Each time you or your colleagues have discovered something important for your business add it into your knowledge base. It requires just several minutes to add a new Wiki article. After several months you will be surprised at how valuable knowledge base you have. This will increase your team productivity and will become a kind of the company assets.

Just don’t forget to protect your knowledge with password. Your competitors want your knowledge too.

Upselling (or Up-selling, or Upsell) is a simple way to increase your average revenue per customer. It’s easy and effective. At the time of purchase simply offer your customers extra options or a more valuable deal.

This is just a short list of what you can offer to your customers besides your main software product:

1. Bundles with complementary software products
2. Add-ons and plug-ins
3. Visual themes and skins
4. Advanced versions of software (Professional, Deluxe, etc)
5. Multi-user discounted licenses
6. Source code
7. Delivery of files on CD or DVD
8. Boxed version
9. Printed manual
10. Express shipping
11. Extended download warranty
12. Access to private knowledge base or use-cases
13. Bulletin or a newsletter subscription
14. Professional community partnership
15. Priority support agreement
16. Long term or life-long support agreement
17. Long term or life-long update agreement
18. Setup and installation services
19. Customization services
20. T-shirts, cups, mouse pads and other stuff
21. User training
22. User certification

Nevertheless, try to choose upsell options wisely in order not to turn your order page into a pile of junk and scam-like offers.
Also don’t force your customers into up-selling options as it won’t be appreciated.

This is not my habit to copy posts from other sources but this time I couldn’t resist. The info below seems to be very useful for any ISV and everyone who deals with sales copy writing.

Here are 7 ways to use numbers to increase the selling power of your next promotion:

Original source: www.technicalcommunicationcenter.com
Author: Bob Bly

Numbers gain attention, arouse curiosity, and add credibility to product claims.

1 - Make percentages look larger.

Taking percentages out to the second decimal place makes them look bigger, because there are 2 extra digits.

Good: 230%
Better: 230.47%

2 - The magic of 2,000.

When you have 2,000 or more of something, you can legitimately say you have “thousands.”

Good: 2,100 subscribers.
Better: thousands of subscribers.
Thousands sounds better because it could be anything from 2,000
to 999,999.

3 - Almost/over.

When you want to make a number bigger than it is, compare it to the nearest round number using the words “almost” or “over/more than.”

Good: 17 years of experience.
Better: almost 20 years of experience.

Good: 21 years of experience.
Better: more than 20 years of experience.

4 - Use credible numbers.

The rule of thumb is to use the round number when you are talking theoretically, and the odd number when you are presenting hard data.

Theoretical: “Make $100,000 as a professional massage therapist.”
Hard data: “Last year Henry earned $100,287.45 in his massage therapy practice.”

5 - Do not write numbers as words. Use numerals.

Good: Seven ways to reduce PC down-time.
Better: 7 ways to reduce PC down-time.

6 - Write fractions as whole numbers rather than percentages.

Good: 30% of wine bottles have cork rot.
Better: 3 out of 10 wine bottles have cork rot.

7 - Use the largest unit of measure possible to make a number sound big.

Good: 25 years of service.
Better: A quarter of a century of service.

When we think about affiliates we usually consider them as webmasters or newsletter owners who put affiliate “Buy Now” links on their websites or plug them into e-mail newsletters.

The on-line affiliates can reach only a fraction of potential users of your software products. There are many prospects who cannot be reached by on-line marketers because they spend just a little time on the Web or don’t trust on-line sales copies.

In the same time, there are many people who could recommend your products offline: on conferences, presentations, user group meetings, etc.
But long affiliate links with personal code are useless in this case because they are hard to remember. The prospects will hardly follow the affiliate link. They will likely go to main product URL and will order from there. Thus the affiliate won’t receive the commission for that lead. This is bad.

If you use Plimus.com for managing your affiliate program then there is a way to help your affiliates to sell offline.

Setup a discount coupon and assign it to an affiliate. The affiliate may give that special coupon code to prospects and they will apply it on your website when ordering the product.

There are two obvious benefits:

• The prospects will be able to purchase product with discount. So, this coupon will make the affiliate’s recommendation more valuable.
• The affiliate won’t have to share an affiliate link. He\she can simply refer prospects to the product website and give them the discount coupon code. Every order with that coupon will be counted as affiliate’s lead and s\he will honestly receive the commission for that order.

Also, on Plimus you can setup the coupon to completely absorb the discount value and it won’t be deducted from affiliate commission. This will also inspire your affiliates.

I hope this idea will help you make you affiliate network more profitable.

If you’d like to sell our help authoring tool Dr.Explain offline by using this approach and to get paid then join our affiliate program and request for your personal coupon.

This is just a few facts from the history of our product, Dr.Explain. I feel a bit nostalgic for that time of big dreams and hopes. Now it’s just a business.
I think these facts could inspire the new rising startups.

Initial design specification for the first version of the Dr.Explain was made in two hours and fit in just two pages: several screen prototypes and a paragraph of text explaining the conception.
The pilot name of the Dr.Explain project was ‘Catch&Doc’, like ‘Cats-n-Dogs’ :-).
Development of the first version took 7 months in part-time mode (nights and weekends).
Most of code was taken from CodeProject.com. In the next years it was overwritten almost completely :-).
Development of the first version delayed my Ph.D. work defending for about a year.
The first version of the Dr.Explain was released July 23, 2005.
The price of the first version was $50 (US).
The first order arrived on 7′th day after official release.
Most of first users came from Clarion developers community.
I left my day job to start the company after 4 months since initial release of Dr.Explain.

Could you disclose something interesting from your product’s history?

If you have ever released an update of your software product then you likely faced the problem of notifying your existing customers about the update. In this post I’d like to give a simple yet very important advice how to notify your customers properly.

Releasing the upgrade is a very important task. After several months of development and testing you may get tired and miss some important details on the final stage - distribution and official announcement.

Here is a list of the most common issues that may happen during the release and reduce the effectiveness of your announcement:

• There is a bug in your software
• There is a bug in your setup utility
• The download link is broken
• Your server is unexpectedly down
• There are typos and mistakes in your announcement text
• … or else

You must detect the possible unexpected problems and fix them before all your customers have received the announcement message. The trick is easy - send your announcement by portions.

The first pilot portion of your mailing must be sent just to a few customers, about of 100-150 contacts. Those users must be as different as possible: from different countries, with different operating systems, corporate and home users, old clients and newbies, etc… Usually the first mailing to such small yet contrasting group of users allows detecting the possible issues in your release or notification. In the same time you won’t be overwhelmed with support request from thousands of disappointed people.

Wait for about a day for possible problem reports and initial feedback. If everything is OK then you may send another portion of mailings to about 5-10% of your customers. Wait for another day. If everything is OK this time then continue sending your announcement by portions of 15-20% with pauses of several hours between each session.

This simple approach will allow you to:

• quickly detect the possible problems in your release;
• keep the majority of your customers happy and properly informed;
• save your support team from the sudden hurricane of the bug reports;
• keep your mail server work load stable.

If you are serious about writing a good documentation for your software either with our help authoring tool - Dr.Explain, or with another one, then you definitely should subscribe to the following blogs on technical writing, software help and documentation authoring. To be honest I even included links to blogs of our direct competitors.

I say “Thank you!” to our fellow customer and partner Craig Prichard, a technical communicator, who gave me many new links for this list.

Cherryleaf Technical Authors’ Blog
A blog site from Cherryleaf, a technical communication UK company by Ellis Pratt. Ellis regularly gives comprehensive review of the industry news as well as practical articles on technical writing.

Harry Miller’s Technical Writing Blog
Harry’s blog contains not only written content about documentation, technical writing, and technical editing, but many podcasts as well.

HelpStuff Blog
A famous blog by Char James-Tanny (JTF Associates) about all aspects of helping software end-users.

I Came, I Saw, I Learned…
A blog by Kevin A. Siegel who has written more than 100 step-by-step computer training books and has been a software trainer for more than 15 years.

E-Learning, Moodle, Technical Writing, and Training
William Rice is an educator, trainer, and writer. Most of his posts are either articles or tutorials about his professional pursuits: e-learning, Moodle, technical writing, and training.

I’d Rather Be Writing
A blog about technical communication by Tom Johnson. Tom covers many topics from any kind of user guides and design documentation, to audiovisual tutorials and drawings, or other explanatory content that is of a technical nature.

Gryphon Mountain Journals
Ben Minson is a technical communicator. He creates documentation and training on applications that are produced in-house. Writing is what Ben does. He thinks that when he die, the mortician will have to pry the keyboard loose from his cold, dead clutches.

OneManWrites
That OneMan is Gordon McLean, a technical author with a passion for good communicative information products. Another Gordon’s passion is web design. In his posts Gordon keeps balance between practical issues and theory of technical writing.

Charles Jeter Blog
Charles writes mainly about technical communication aspects in Web 2.0 world, e.g. work-flow collaboration and e-learning.

User Assistance
An exploration of issues pertaining to online help by Michael Hughes, PhD. As you can see from the blog’s title Michael focuses mainly on embedded user assistance, usability issues and user behaviour.

Just Write Click
A blog by Anne Gentle, a senior technical writer who is blogging about technical writing, information architecture, topic authoring, social media, and other communication technologies.

Mike’s Web Log
In this blog Mike Pope, a technical writer, covers various topics from writing and editing, to teaching and movies, and to politics and musics.

monkeyPi
An interesting point of view on usability, visual & technical communication, and software design.

Great Documents
In this blog Keith Johnson, a technical writing & software documentation specialist, gives many useful tips not only about documentation writing but on successful blogging, SEO, and social networking.

Scott on Writing
Scott Mitchell is a freelance writer, trainer, and consultant. In his technology-related blog Scott talks about technical writing, technology, and ASP.NET

Sharon’s MadCap Blog and Mike’s MadCap Blog
The two blogs by Sharon Burton and Mike Hamilton from MadCap Software. It’s always interesting to know what your competitors do

Technically Speaking
Paul Pehrson is another technical writer who blogs about various aspects of his job: writing tools, software, grammar, technologies and other important topics.

The Content Wrangler
A great resource for everyone who deals with technical content writing, editing, publishing and delivering. There is a lot of practical articles and industry news.

Communications from DMN
Aaron Davis and Scott Nesbitt, two experienced technical communicators, post their ideas and opinions, as well as links to information that they find interesting and hope that you will too. As you will see from their posts, Aaron and Scott have a wide range of interests when it comes to technical communications.

HelpScribe
A pretty young but very interesting blog by Craig Haiss, a technical writer. Craig started his blog to share his professional knowledge with colleagues. That’s great!

Usable Help
A blog of Gordon Meyer, an interaction and instructional designer. Gordon is a professional author and speaker on the topics of help system design. His posts on software help, usability and testing are always very practical and focused.

Of course there are many other blogs on help authoring, technical writing, e-learning and technical communication. I listed only the most popular and active, i.e. with new posts in 2008. If you know other good blogs on these topics, please add them through comments. Thank you!

This post is a brief digest of most important events in our company for the past several weeks. In order to keep this blog mostly self-hype free I summarized all our news in a single short post.

Dr.Explain 3.1 release

We’ve recently released the new version of our software help-authoring tool, Dr.Explain 3.1.

This update is a great step in the product history. Until the version 3.1, many software developers and vendors have been using the Dr.Explain to document their Windows software, HTML pages, or Flash (SWF) applications.
Now, the Dr.Explain 3.1 enters the Java world. Java developers can benefit from the same technology, and automatically generate professional documentation for their Java applications made with Swing components.

Besides the support of Java applications, Dr.Explain 3.1 brings more new functions that will help software vendors produce astonishing documentation even faster. The customizable capturing scenarios allow to precisely specify which window element or HTML tag to analyze or to skip, how to handle its child elements, and how to name and to annotate it. Other gems of the new version are new graphical effects and image rendering technology. All screenshot images, callout lines, text label fonts, shadow and blending effects are drawn with high precision which leaves no chance for fuzzy edges, making documentation illustrations look clean, realistic and nice (beautifully clear).

More info: www.drexplain.com

New Dr.Explain forum

If you have questions, concerns or ideas regarding the Dr.Explain software and if you want to discuss it with other users or with Dr.Explain team publicly then I invite you to join our forum at: http://www.drexplain.com/forum

ISDEF 2008

This week I, Dennis Zhuravlev (a.k.a. Dennis Crane), the CEO of Indigo Byte Systems, will attend the ISDEF 2008 conference in Moscow, Russia. If you attend this event also then I will be happy to meet you there.
There are lots of possible reasons to meet me there:

• To ask questions about our products (Dr.Explain and TBS Cover Editor (on behalf of TrueBox Shot software)), our company, or me.
• To receive a discount coupon
• To know what new projects we’re going to launch shortly
• To tell about your products or services
• To discuss a possible venture or partnership
• To offer a topic for this blog
• To trade something
• To give or to take an interview
• To chat about software, business, sport, politics, or large hadron collider
• To take a shot of beer, brandy, vodka, rum, whiskey, tequila, juice, tea or coffee
• … or just to say: ‘Hello, Dennis!’

If you’re going to ISDEF, please let me know via e-mail or comment. I’m looking forward to meet you on ISDEF 2008.

If you decide to split your software product into several editions with different settings then you will likely wonder how to name them. Naming software editions depends upon what do you offer and what do you limit in each edition. There are several common approaches in building editions:

• Functional limitation (F)
• Environmental or purpose usage limitation (U)
• Limitation of number of installations (N)

Here is a list of common edition names. The hints in parenthesis designate which of the approaches each name suits better.

Level 1
Junior (F)
Beginner (F)
Student (U)
Educational (U)
Light (F)
Lite (F)
Bronze (F,U,N)
Empower (F,U,N)
Starter (F)

Level 2
Standard (F,U,N)
Regular (F,U,N)
Intermediate (F,U,N)
Personal (U,N)
Home (U,N)
Silver (F,U,N)

Level 3
Advanced (F,U)
Professional (F,U)
Business (F,U,N)
Commercial (F,U)
SOHO /Small Office or Home Office/ (F,U,N)
Company (F,U,N)
Gold (F,U,N)
Mega (F,U,N)

Level 4
Deluxe (F,U,N)
Architect (F,U,N)
Site (F,U,N)
Enterprise (F,U,N)
Platinum (F,U,N)
Premium (F,U,N)
Exclusive (F,U,N)
Ultimate (F,U,N)

This list gives you an idea how to get started with your own software editions. Combine names from different levels to build your own successful product line.

If you know more naming examples then post them as comments please.

[Editor’s Note: This post comes from Craig Prichard, a Technical Communicator. He has provided beta and usability testing for Dr.Explain, wrote the sample project (GUI) that is distributed with the latest version, and is the “voice” of this video.]

Dennis has generously provided me enough rope to hang myself. I hope to make a hammock and just hang out a little instead. We’ll see.

This post comes from the perspective of a Technical Communicator. 25+ years of software development, business analysis, beta and usability testing, and technical communication in its many forms have confirmed to me that these principles are universal to anyone faced with creative problem solving.

Technical Communication (TC) has many facets but at the core of every effort, deliverable, meeting or other task is the challenge to solve a problem. Whether the task is to write or otherwise communicate an explanation of how to do or use something, convince a client to use your services, resolve an interpersonal conflict between yourself and someone else or between others, or determine the best content delivery medium for a specific scenario, you will always have two challenges: clearly identifying the problem and producing a satisfactory solution to it. Sometimes the problem is cognitive, e.g. learning and explaining. Sometimes the problem is emotional, e.g. conflict resolution. Sometimes the problem is spiritual, e.g. conflict of interest. Sometimes the problem is physical, e.g. constrained by available resources. And most of the time the problem is a lovely blending of components that taxes body, soul, and spirit. The remainder of this article will be based on two (1) assumptions (I know what they say about “assume”, thank you):

1. You have identified the problem. This would make a good topic for another post.
2. You believe a satisfactory solution can be achieved. I believe there is an achievable satisfactory solution to every problem, which would make good topic for another post.

How do I get from point #1 to the end of point #2? I don’t have any idea how to solve the problem. Or, more likely, I have some idea of how to solve the problem but there are pieces missing that need to be filled in.

First, let’s modify our taxonomy. Do not refer to this as a “problem” any longer. It may seem trite or contrived to call it a “challenge” or “opportunity” when the terms are synonymous. But actually they are not. Would you refer to training for a 10 KM run as a “problem” or a “challenge”? It’s a matter of choice. You choose to participate in a 10 KM run and know that without training first, your results will likely be less than satisfactory. You refer to the effort with a term that, in your mind, is less negative than “problem”. For motivation sake you choose a term that encourages rather than discourages. For motivation sake you need to think of the TC effort now facing you in terms that do not discourage. One reason you might be having difficulty crafting a solution to the challenge is that your mindset regarding it is unnecessarily negative. Turning the corner from “Woe is me” to “I shall overcome” (thank you Martin Luther King Jr.) can help the creative juices to flow again.

Challenge Types and Suggestions:

• Cognitive: I have the problem of learning a new program and writing a Getting Started Guide for it. No, I have the opportunity to expand my repertoire of computer programs AND demonstrate my excellent communication skills in producing a quality Getting Started Guide.
• Emotional: For the next project I’m paired with the most obnoxious team member in the group. No, I have the opportunity to combine my expertise with another team member who, while challenging to work with, still have valuable contributions to make. That which does not kill me makes me stronger.
• Spiritual: The changes to this policy manual are going to make people around here upset and might cost some their jobs if they don’t change before it goes into effect. The problem is I can’t talk about it. No, the challenge is I need to honor my professional commitment to non-disclosure and confidentiality, remember that I don’t make the policies, and hope the example I set will help others by exemplifying corporate policy.
• Physical: The problem is the video is too large for web-based distribution. No, the challenge is to either reduce the video file size or modify the distribution mechanism in some way.
• Blended: The boss wants another chapter in the Training Manual ready for review Monday and I promised my wife we would take the kids camping this weekend. No, the challenge is to manage my time and resources as efficiently as possible and insure my boss understands what reasonable expectations are.

My first point is about perspective; having a perspective about the challenge that doesn’t drain you of confidence to overcome it. The next point is also about perspective; looking at the opportunity to see what it is and what it isn’t. When I need to produce a deliverable that similar to numerous deliverables I have produced in the past, there is little need for creativity beyond the content itself. It’s when the deliverable is different in some way that the need for creativity arises. Understanding what is different is key to focusing your creativity productively. This is “thinking outside the box” and critically important in sparking creativity:

• Do I have all the facts and understand the scope? If I don’t think so I should gather the information I need from wherever or whomever I can?
• Have I discussed the challenge with stakeholders, knowledge experts, subject matter experts, or any key personnel involved in providing input to my efforts? Have they offered suggestions, no matter how ridiculous, to include in my pool of possibilities?
• Have I done some brainstorming, alone or with others (preferable) to fill my pool of possibilities? Did we step far enough back to allow the ideas to fly well beyond reasonable and practical? If one (1) in a hundred ideas is good, then I should accumulate several hundred ideas so I have a couple of good ones to evaluate and pursue. Ask any of the companies I do regular beta and usability testing for and they will report that my enhancement suggestions list is usually massive and often borderline unachievable in the extreme. Why do I continue to pour in suggestions when most are ignored? Two (2) reasons: first, I leave it to them to decide what is good and what is stupid, and, second, sometimes even stupid can lead to good. A stupid suggestion might spark a discussion leading to something valuable.

Challenge Types and Suggestions:

• Cognitive: The Getting Started Guide needs to fit on a single sheet of paper. Has the content been edited to be clear, concise, and complete? Could sentences be turned into bullet points, paragraphs combined, smaller headings employed? Does it have to be 8.5×11? Could it be 17×11 folded? Could it be rendered in a smaller font size, with fewer images and smaller margins?
• Emotional: The team member will not listen to any of my suggestions. Can I learn to communicate my suggestions in a way that doesn’t cause a defensive reaction? Can I accept the team member taking credit for my suggestions?
• Spiritual: The boss wants to include a paragraph from an uncited source. Does my boss understand what plagiarism is and how strongly I oppose it? Do I understand why he does not want to cite the source?
• Physical: The video resolution must remain high, stream, and start playing within five (5) seconds. Do I know what the latest compression technologies are and how to utilize them? Could the videos be split into shorter segments?
• Blended: The deliverable must be produced using a product I am unfamiliar with. Am I constrained to create the deliverable using this product or am I constrained to generate a specific target output that this product produces? Possibly your tool-of-choice will be acceptable if it produces the required output type. Or maybe, for archive purposes, the content can be imported into the required product at the end of the development cycle.

Next, at a more practical level, am I as prepared as I can be to be creative right now?

• Am I getting enough regular rest?
• Am I eating healthy regularly?
• Am I distracted by challenges outside the professional context that are demanding attention?
• Would a brisk walk, some other exercise, or just some calisthenics around desk help get my heart rate up and blood flowing?
• How about snack to quiet my stomach and boost my energy?
• Does standing up, pacing around, squeezing a stress ball, chewing gum, playing ping pong or some other physical activity help my focus?
• Is there someone I can talk to right now to get a fresh perspective, brainstorm with, or engage for a few minutes?
• Is there some other creative activity I can do for a while to take my mind off this challenge, e.g. cooking, musical activity, other hobby activities? Often when you engage a different part of your brain it will be easier to return to the challenge with a fresh perspective.

Here is a recap of ways to help the creative juices flow:

• Power: Don’t give the challenge power over you by thinking of it in defeatist terms. Keep a positive perspective. A solution will be forthcoming.
• Perspective: Turn the challenge over, inside out, upside down, and sideways. Changing your perspective might reveal something previous hidden from view.
• Practical: Is this machine; my body, soul, and spirit, ready to face this challenge?
• Ask for help. Discussion sparks inspiration. You can quote me. And you can contact me if you want too. I love a challenge, an opportunity to kick a problem so hard its mother will cry out.

There is no new research or startling information here. You know all this. But I hope that by putting it together as I have done, you will have greater ease in diving into, uh-oh, what’s about to walk into your office…

As always, your feedback is appreciated.

Craig Prichard
Technical Communicator
craig dot prichard AT gmail dot com
http://members.shaw.ca/craig.prichard