Welcome to product management! Over the the better part of three months, Adrienne Tan at brainmates, product management people, put together a series of posts with ten tips for new product managers. Check out our article for a quick summary, and links to all the articles at brainmates.
APR: Corporate Goals
Corporate Goals for the Product We have two corporate goals for our agile project. One of them directly drives the features and functionality, and the other one is a driver of a constraint on the implementation approach. Both types of goal are relevant. A process that relies on structured requirements […]
Flashback: A Year Ago This Week on Tyner Blain [2006-01-27]
A look back at the best from a year ago.
Abstraction And “Requirements”
I don’t know how many of our readers have reached a conclusion to this debate, but we have for now. Thanks to everyone who has contributed to, enjoyed, or at least tolerated this ongoing discussion. Roger had some good comments in our previous article – we’ll try and address one of his points here. His point, I believe, is that using the word “requirements” to describe multiple levels of abstraction in the definition of a product is a bad thing.
Requirement Naming – Stick A Fork In It?
The discussion about requirements and the naming of things continues? Can we stick a fork in it already? Maybe, but probably not. Catch up on the cross-blog discussion with Roger and Adam.
Valuable and Functional Requirements
Roger asked some interesting questions on one of our previous posts about market and product requirements. In a couple recent articles, we presented some specific examples to clarify the semantics and language of different types of requirements. Roger asks six questions about functional and non-functional requirements in the comments on the last article. In this article, we answer them.
From Market Requirement To Product Requirements
We looked previously at an example of market analysis, defining first a market opportunity, and then a market requirement. We wrote an article a while ago about how to go from an MRD to a PRD. In this article, we will look at the journey from our market requirement to associated product requirements. And thanks, Roger, for throwing down the gauntlet.
Alphabet Soup – Requirements Documents
This is my requirements document. There are many like it, but this one is mine. My requirements document is my life. [Kubrick, with some editing]. Michael provides a comparison of requirements documentation formats seen in the wild. A good companion to our earlier piece, Michael provides some “what to expect” guidance about how different companies use the different documentation formats. Check it out.
Communicating Intent With Implementers
Giving a functional spec to developers and testers is not sufficient for creating great software. To a developer, a spec is only the what and not the why. And for a tester, the software requirements specification is neither. Use cases provide the why that explains the intent of the system for the implementation team.