Back in the 80s, news orgs developed a process of reviewing software products. It got pretty formal. They had reviewers who specialized, some reviewed databases, some did word processing programs, others did outliners and presentation software, which is what my company produced. 

The review process fed back into how we developed products. Since we knew what the reviewers were looking for, we could make sure our products covered all the bases. And we also clearly understood what made our product different and better than the competition. We highlighted those differences in the reviewer's guide. 

They were usually 10 to 20 pages, printed, with illustrations. Written in non-hyped, clear and simple prose. Bullet items. Creating the guide was a product marketing function. Part of the PR for the product, but also part of the development process. As I'd work on a product with a team, I'd always be thinking about what we'd say in the reviewer's guide.

Also it served as a checklist for sales people. These are the things you should highlight in your demos with resellers and at user conferences. As the CEO, I needed a script for talking with reporters. This isn't the kind of stuff you want to do by the seat of the pants. It also formed a checklist for the press release announcing the product and the packaging. The reviewer's guide is part of the process of coming up with a great demo of the product. 

Even though we don't have reviewers anymore, I still do reviewer's guides for my important product releases. So I've been working on the reviewer's guide for 1999.io. And asking some of the early users of the product and also friends who haven't yet used the product to have a look and tell me what they think. 

I recorded a ten minute podcast to explain what the concept means. I wanted to share that with everyone. Maybe at some point we will start reviewing products again, and when that happens, it will help to have a template for what a reviewer's guide is.

PS: We're using GitHub to talk about the RG.