Experiments in writing, by Marjolein Hoekstra @OneNoteC

Archive for November, 2006

Launching in Beta? Here’s a Vendor’s Checklist

without comments

I remember well that a couple of years ago it took me several days to finish off a review (for the curious: it was Note-Taking, Attach Digital Sticky Notes…, which I wrote for Robin Good’s MasterNewMedia). In the mean time I’ve become a bit more experienced in doing write-ups such as these, but it still takes considerable time to get all the facts together, to create meaningful screenshots and most of all: to structure all the information so that my visitors can quickly grab the essence of my post.

It would make my job and that of many of my fellow IT journalists a lot easier if vendors would provide easy access to the following details when launching a new product or service:

  • core focus and purpose of the product (30-second elevator pitch)
  • feature list
  • supported platforms and system requirements
  • date launched and development stage
  • vendor contact details
  • screenshots, virtual tours, FAQ, user forums
  • links to team blog, release notes and feeds
  • other reviews and product radars
  • pricing plans and trial limitations
  • download link

General remarks
If you need to use geekspeak, then be sure to explain or simplify these words. If it’s not obvious from the hyperlink text, consider adding tooltips to your hyperlinks telling site visitors where the link is taking them. Ask someone outside of your direct circle of friends and co-workers to go through your pages and listen to their feedback. Simplify where necessary. Added note: I recommend running a spell checker on anything your publish. If you can afford it hire a professional copy editor to proofread your material and to check your facts.

Core focus
Imagine I have about 50 words to describe your product—what problem does your product or service aim to solve? Who would benefit from what you have to offer?

Feature list
If your product or service has a broad range of features, then categorize them in logical groups, or group them in the order that people are likely to use them: from simple features to more advanced ones. This allows people to gradually build up a clear understanding of what your product is about.  If you have unique features compared to what your competitors offer, then don’t hesitate to point these out. Just trust that I’ll investigate to see if you speak the truth.If your service offers RSS-related functionality, then point this out explicitly. It’s among the first features I’m likely to look for.

Platforms and requirements
Be clear on the platforms that you support, preferably mention also if you intend to extend support onto other platforms in the near future. Mac owners hate it if I rave about a product of which the developers do not even consider porting it to OS X. If specific browsers or layers need to be present (e.g. a toolbar that only works on IE, or a service that requires Macromedia Flash), then say so. Don’t publish a service that will only work in version 1.5 of Firefox, knowing that 2.0 is around the corner. What else does it require to start using your product or service? Do I need to sign up first to use your service? Will I get an immediate, automated approval or is human intervention required before I can use your product? What unsolicited newsletters are you intending to sign me up for?

Date launched and development stage
Is this a new launch or an improved version you are selling? Is the product in preview release, private alpha, closed beta? What is the planned roadmap from here?

Vendor contact details and feedback management
Can’t stress this enough. Provide e-mail, instant messaging and Skype details. If your product is in beta, it’s likely that early testers and reviewers run into ’undocumented features’. The quicker I can forward those to you, the sooner you can attend to them. If you can’t respond immediately, for example due to limited availability of human resources, then say so up-front. It’s frustrating to compile an error report and never receive a decent reply. If you ask for feedback, then be genuinely prepared to do something with it.

Screenshots, virtual tours, FAQ, user forums
Visual cues work wonders if you want to make sure people understand how unique your product or service is. You could provide static screenshots, animated GIFs (look at the new Gickr service, which actually inspired me to write this post in the first place) and screencasts that explain how to best use your product. Frequently Asked Questions pages are very helpful too, especially if I can see all the answers to all the questions in one glance—don’t make me click endlessly to scan them all. If you provide a user forum, then please accept my existing credentials to use it. Choose forum software that is protected against sploggers and please provide RSS feeds for the forum entries.

Team blog, release notes and feeds
Nothing informs me so well about a product as a team blog: I get a feel for the people behind the product, I taste their enthousiasm, their struggles and where they’re coming from. Please consider setting up a team blog if you haven’t done so already. Make sure your feeds are auto-discoverable. If you choose to write about other topics on your team blog also, then please provide a product-specific feed so that I can skip your off-topic rants if I want to. If you’re launching a .0.1.2 release, and choose to point me to it, then please make clear what’s new about this minor update and why I should care to have a look.

Other reviews and product radars
Do some ego searching and build a topic radar about your product. Start out with URL searches in blog search engines like Google Blog Search, Technorati and IceRocket. Add tag feeds from a couple of social bookmark engines ( and Reddit come to mind) and feeds from any other possibly relevant, RSS-enabled search engines and you should have a constantly updated monitor of what’s being said about your product around the blogosphere. This saves me from writing a review from the same angle as someone else has already done. If you want to take it one step further you could bundle the feeds into an OPML file and present it using Grazr, OPML browser or Bitty Browser, or even create a river-of-news feed using MySyndicaat or FeedDigest. In whatever way you choose to publish your product radar, please make it available on your site.

Pricing plans and trial limitations
Provide a feature comparison chart including pricing details. I’ve seen quite a few products that require me to put stuff in a shopping cart, sometimes even sign up for an account first only to find out how much it’s supposed to cost. Then, if there’s a trial version of your software, be clear what the limitations are compared to the full product.

Download links
I prefer direct download links. Don’t make me go through ZDNet or CNet or some other software archive’s pages to get to my file.

Of course this is only my own point of view. What things do you look for when you check out new software? Please feel free to use the comment form.

Written by CleverClogs

November 2nd, 2006 at 8:19 pm

links for 2006-11-02

without comments

Written by CleverClogs

November 2nd, 2006 at 6:18 pm

Posted in Uncategorized

links for 2006-11-01

without comments

Written by CleverClogs

November 1st, 2006 at 6:19 pm

Posted in Uncategorized