In planning out a new feature, the Product Manager wrote out an issue card in GitHub for developers to reference. The card included the PM’s notes from visits on site with customers. I updated the card by: Removing extraneous verbiage Adding sections and rearranging content Updating references to existing product features Some portions of the issue make sense within the broader product portfolio. Those have been left without further explanation in the edited card, as such additional information is already known to the development team.
About this sample The information below is about a fictitious software product, “Assetly.” I based Assetly on a real product I documented, though many details have changed in this document. I wrote the original product document in Madcap Flare in consultation with a number of subject matter experts, including: Product Manager Developers Quality Assurance team Sales team members who championed the product Product Team Executives This sample reimagines the original document, now written in Markdown for use in this blog.
About this sample The information below is about a task a user would need to complete in a fictitious software product, “Assetly.” I based Assetly on a real product I documented, though many details have changed in this document. I wrote the original document in Madcap Flare based on my own use of the software. During my use of the real product, I occasionally uncovered bugs or more complicated problems. When discovered, I created issue cards in the development team’s issue tracking system.
About this sample For a job application process, I was asked to revise a sample business requirements document. The provided example was a template purporting to be notes from several different meetings. I left the headings from the template as they were, but edited and formatted the contents of each section. While the original sample was done in Word, I have recreated it here with Markdown, published by my SSG, Eleventy.
My first job at a software company landed me in a software training role. While I learned a great deal about adult learning and best practices for knowledge transfer, my proudest achievement while I was there involved project management. Our department had a catalog of 160 course manuals. These manuals varied in length from 20 pages to several hundred pages. These were course guides for the various training classes taught by everyone in our department.
I have spent the last year at my current job working on transitioning our docs from Madcap Flare to Antora. First things, Madcap Flare is a great tool. This is the third place I have worked that has used Flare for some form of documentation, and it does its job well. However, there are several factors that impacted the decision to move away from Flare to another tool. Flare is proprietary software that requires a not-insubstantial subscription license to use.
Image credit: Photo by Vojtech Okenka from Pexels TL;DR Here’s what I did to create this site and give myself a (well, almost) free site to build out a portfolio. Create an account with a Git service provider. I used GitLab I already had, but GitHub also works. Select a starter template from Forestry.io for the desired SSG (static site generator) and create it on Forestry. Forestry.io automatically adds a new repository and branch on your Git provider.
My journey into tech writing started in 2013. Reynolds and Reynolds Software Training I started out my journey into the world of talking and writing about technology and software as a customer trainer at Reynolds and Reynolds. A provider of software and other services for car dealerships, I taught dealership personnel and new ReyRey hires how to use the accounting and payroll portions of the software. I taught mostly online, interactive webinars over Webex, making use of their Hands-on Lab feature.