Back in June, I posted an image of an infogrpahic that I had created for ProductCamp Atlanta on Snagits facebook page. Snagit is a screen cap software that allows you to take screen shots and make edits to that screen capture. But there is so much functionality, that it's almost like a slimmed down Photoshop.
After posting the infographc, a Techsmith employee (Techsmith makes snagit) messaged me asking if i would mind being interviewed in a blog post on how I created the infographic using snagit. This was just incredible to me. I was very excited to be given the opportunity. After all, this is a software that I love and use everyday. How could I say no?
So about a week or later, Daniel Foster posted the questions he sent me along with a break down of how I created the infographic. You can find the blog post here.
Currently, I am reading a book a friend has lent me called Product Leadership: Creating and Launching Superior Products by Robert G. Cooper. It was written in 1998, and although some aspects of the text seem relevant today, there are some that are not. There is a particular instance where Cooper describes the basis of product leadership and gives examples of companies that are "winners", and some that are "losers" struggling to identify themselves as " new product" companies.
Some of the winners included Merck, 3M, Microsoft, and HP. Then he goes on to list the "losers." The "losers" included GM, Chrysler, and Apple. That's right, Apple! The company who just earlier this week announced record sales and is becoming one of the most valuable companies in the world.
I don't think anyone could have predicted such a turnaround from a company that was struggling to be profitable just 13 years ago to now have one of the highest quarterly earnings of all time. Apple has completly changed their approach on new products, having paved the way to revolutionary products and carving new industries.
For the past two years, I have worked on a few different products ranging from Small Business CRM's to online business plan builders. As requirements and features are documented and created, it's very easy to overlook why certain features are requested or added. Sometimes you have to ask yourself (and others), what is the benefit of this feature?
To borrow a technique from Robert Dempsey (found while searching how other product managers document requirements) I created a Google document for each product that we have, and document the following requirements before we bring a feature to development:
It was this simple thought process that led me to another simple question to ask yourself: For every input, what is the output? In other words, the feature is asking me to input information, what will the output be? This doesn't apply to every product, but is especially the case in CRM, where reports are imperative and users rely on the system/software to tell them where their opportunities and sales (output) are based on the information (input) the user puts in.