| June 2007 |
| By Chad Broadus |
Google “Product Manager” and you’ll find a number of definitions of exactly what we do…and they’re all right. Being a software product manger requires a diverse set of skills and can be different depending on the type and size of the company.
I work at a small post start up company that is now a small division of a larger corporation, and in my case, a Product Manager does many things.
A Product Manager is a business systems analyst and listener. To really get it right, you have to talk to the Users. Find out what their primary business objective is, and then craft your software to help them be insanely effective. Go onsite every chance you get. Watch the Users interact with the product. Watch what they do, and watch what they don’t do. Both things will tell you a lot and can help you bridge functionality, eliminate mouse clicks, and point out the not-so-obvious design flaws. Ask them questions and listen. Sometimes Users don’t have the vocabulary to tell you, “I’d like to be able to update the Accounts screen and have a nice AJAX fade in that recalculates the totals…and we’re a Microsoft shop, so the solution can’t be OpenSource.”
In addition to listening to the Users, listen to the Tech Support and Customer Service Teams. These customer-facing folks are talking to the Users every day, and are intimate with their recurring problems and mistakes. Users tend to be a little more “candid” with these Teams and may give them details within the emotion-to-functionality ratio that you might not otherwise get.
If it’s difficult to get on site with your Users, then strike up the conversation via email. Throughout the development process, I’m in constant contact with the Users. I run UI mock ups, Use Cases, and new concepts by them to make sure we’re on the right “insanely effective” track.
A Product Manager is a technical writer. To make great software, you have to write great specs. We’ve narrowed our documentation down to a bare minimum. “Sufficient and Unambiguous” is our motto. Generally, we’ll describe the functionality in a Software Requirements Document, and then link out to a series of Use Cases.
The Software Requirements Doc is the overview. It tells everyone that this piece of functionality will do this for these reasons, and this is a list of things that it absolutely has to have/do. The Use Case is a sort of road map for the Developer. It shows them where the User is going, how they will get there, and what they will expect to happen when they arrive.
A Product Manager is a Usability hawk. Get yourself a copy of Don’t Make Me Think and try to apply Krug’s methods to everything you do, whether your product is a web app or not. As you write your specification documents, keep in mind the little thought bubbles that will be going off over the heads of your Users as they are navigating through your product. Your job is to eliminate the question marks in those thought bubbles.
A Product Manager is a politician. You have to let all constituents have their say, then try to represent them all in a way that compromises but doesn’t average out to mediocrity. The CEO may want X for the next release, the Users are threatening revolt unless they get feature Y, and Sales and Marketing want Z for the WOW factor. As the Product Manager, you have to figure out a way to represent all of these diverse goals in your release in a way that’s feasible for the development cycle, makes the Users insanely effective, and motivates Sales and Marketing to really push and believe in the product.
A Product Manager is a perpetual scholar. Keep abreast on what’s happening out there. Get familiar with RSS and then find blogs that you enjoy and subscribe to them. The RSS integrated Google personalized homepage is a great tool to help you, at a glance, keep up with your world. Good blogs will have great discussion and opinion, which will lead you to other sites, which will lead you to new technologies and similar products, which will lead you to think about your product in new and innovative ways.
Read about the business of software from all sides. To be effective at all of the disciplines I’ve outlined above, you have to be able to understand both the psychology and day-to-day working reality of the larger team that you are a part of. Development, Sales, Marketing, Tech Support, Customer Service, and Executives all have their little quirks and world views. The more you know, the better you’ll be able to navigate through your environment with style and ease.
Being a Product Manager is seldom boring and a constant learning process. If being a specialist isn’t your thing, you might try branching out into the Jack Of All Tradesmanship that is Product Management.
RSS link starter kit
http://www.codinghorror.com/blog/
http://headrush.typepad.com/creating_passionate_users/ now defunct, but a goldmine
http://www.joelonsoftware.com/ great history of posts
http://sethgodin.typepad.com/seths_blog/
http://blog.guykawasaki.com/
If you would like to submit an article providing an insider’s view of your tech or engineering job, please send your article to us at ITtrenches@dice.com.
Comments on this article? Share your feedback on our discussion forum, Dice Discussions.
*Please note, you must be a registered job seeker in order to submit your question to Dice Discussions.
|
|
|
