Last fall, Austin PMM had a discussion around how to measure product manager (PdM) performance. Much of the conversation centered around products developed for external customers and focused on sales or profit metrics. My experience, however, has typically been in product management for internal systems where there are no clear-cut external metrics like sales or [...]

Two weeks ago I attended the monthly meeting of the Austin Product Marketing and Management group. The session was titled Agile Software Development and its Impact on Product Management and was a panel discussion with three panelists and 30+ audience members. It was the second largest gathering I have seen in the year I’ve been [...]

This is post number two in my continuing series of requirements model discussions. You can view my first post here. This time around, I’d like to discuss decision tree diagrams. These simple flowcharts can make your life much easier when writing a software requirements document. A decision tree diagram really only has three parts – [...]

The short answer is that a software requirements spec is done when you can convince the stakeholders to sign on the dotted line. The long answer is that a requirements specification is truly never done. It should be a living document that is updated throughout the project. As decisions are made or requirements clarified, the [...]

Do you ever get the uneasy feeling that no one is reading your software requirements specification? The reality is that the development team is probably busy on the last release and that the business stakeholders are busy doing their jobs in the business. What is a lonely Product Manager to do? How do you get [...]

My name is Eric, and I am a Requirements Analyst. Before November, the acronym “RA” held only connotations of dorm hall meetings and stale pizza, as I have only recently shed my student skin and joined employed society. I graduated from the University of Texas with a Bachelors in Communication Studies and a minor in [...]

I am encouraged by the the growing conversation about good requirements. For example, a recent issue of Manufacturing Business Technology had a good discussion about how quality requirements are necessary to save time and money in Best-in-class report proves out commonsense guide: minimize change (registration required). Quoting Doug Putnam, Change in [software] requirements is the [...]