Lists / Product Management

Ten New Product Manager Tips

Posted on:

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.

Requirements

Abstraction And “Requirements”

Posted on:

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.

Product Management / Requirements

Valuable and Functional Requirements

Posted on:

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.

Requirements / Software development

Alphabet Soup – Requirements Documents

Posted on:

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.

Communication / Product Management / Requirements / Requirements Models / Software requirements specification / Use Cases

Communicating Intent With Implementers

Posted on:

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.