Michael on Product Management and Marketing has posted the first in his series of product management commandments – Know Thy Customer. He provides five tips on how to know your customer better. We extend his idea to include understanding our customers’ markets, and provide more tips. By analogy, this is the difference between a detective who studies a criminal and a profiler who seeks to understand a class of criminals.
Communication / Foundation series / Requirements / Requirements Models / Use Cases
Posted on:
Foundation Series: How To Read a Formal Use Case
Use cases represent the activities that people do when interacting with a system to achieve their goals. Use cases are a very effective tool for communicating and documenting what a system is intended to accomplish. Formal use cases are use cases that use a specific structure to represent the information. Knowing how to read a formal use case is important.
Lists / Product Management / Requirements / Requirements Models / Use Cases
Posted on:
The 8 Goals of Use Cases
Why do we write use cases? For the same reasons that our users use our software – to achieve a goal. In our case, we want to assure that we are creating the right software. By looking at this goal in more detail, we can make decisions that drive the best possible use case creation. Lets apply our product management skills to writing better use cases by writing an MRD for use cases
Process Improvement / Product Management / Requirements / Requirements management software / ROI / Software development
Posted on:
Companies Will Waste $1B This Year on Software Tools
Gartner reported that companies spent $3.7 Billion USD on application development tools in 2004, with a 5% annual growth rate. The Standish Group has shown that 40% to 60% of project failures are due to requirements failures. At least 1/3 of the money spent on getting more efficient at coding is being wasted – it should be spent on writing the right software.
People management / Requirements / Requirements gathering
Posted on:
Mozilla Director of Product Management Blog
The director of product management at Mozilla (makers of firefox) has started a blog, Sherman’s Blog, about how Mozilla approaches product management. From the first post on the Role of Product Management by (Mr.?) Sherman, I think this blog is likely to be one to watch.
Product Management / Requirements / Requirements gathering
Posted on:
Brainstorming Stirs the Pot
The Wall Street Journal apparently wrote a critique of brainstorming that questions its value. Bob Sutton (professor, author, etc) responds with an entertaining read. Prof. Sutton critiques the data analysis, the experiment execution, and the people involved. Seems the WSJ messed up on everything except the topic.
Product Management / Requirements / Software requirements specification / Writing
Posted on:
Writing Passionate Requirements
One of the ten big rules of writing a good MRD is writing passionate requirements. What in the world is a passionate requirement [they were all wondering]? When you believe in the product, are committed to the work, and aren’t bored, you can write passionately. The goal of a requirement is to create sustained understanding. A dry document can create understanding, but an engaging document will sustain it.
Product Management / Requirements / Software requirements specification / Writing
Posted on:
Writing Atomic Requirements
One of the ten big rules of writing a good MRD is writing atomic requirements. Just as verifiable requirements must be concretely measurable as having been met or not, so must atomic requirements. If a requirement has multiple elements that can be implemented separately, it is not atomic.
Product Management / Requirements / Software requirements specification / Testing / Writing
Posted on:
Writing Verifiable Requirements
One of the ten big rules of writing a good MRD is writing verifiable requirements. Verification is both a function of having a precise goal, and having the ability to affordably measure the requirement. A precise goal is a verifiable requirement if we can clearly answer “yes” or “no” when asked if the requirement has been implemented. We also face the practical realities of being able to measure the results profitably.