Software product success.
We ran a series called Writing Good Requirements – The Big Ten Rules in May 2006. Bloggers are notorious for not being able to count. We had ten rules at the time, and now we’re adding an eleventh. Writing Correct Requirements may have been the unwritten rule, but now we take a look at it.
Imagine if potential customers gathered together, each donating some funds, to specify the development of software. Those funds would be paid to whomever agreed to meet their demands. Essentially a free market system, balancing out supply and demand. Well, this has happened recently. Read on to take a first look at this and join in the discussion.
Does your product have soul? Michael Shrivathsan asks this question, and we take it in a slightly different direction.
The polls are open! Go to their announcement to take the annual Product Management and Marketing Survey! Then check our our post for links to previous survey results and trends.
What is the difference between a business rule and a business requirement? Does the difference matter? A business requirement is something that is multi-customer, and a business rule represents a single customer’s approach to meeting that requirement. Product managers and analysts care about both, but product managers emphasize requirements, and analysts focus more on rules.
When a client asks for a capability or feature – is it a want or a need? How do we prioritize them?
Kathy Sierra writes (another) great article at Creating Passionate Users. This time, she talks about why users don’t upgrade and presents ways to get users to install the latest version. We focus in this article on one way in particular – using goal-driven documentation to encourage upgrading.
Why do we write documentation? Because someone told us to write it? Because our competitors have it? Or because we want our software to be easier to use? It should be the third one, but often, writing documentation is an afterthought, and it is deprioritized, and we just get it done, instead of thinking about the goals for doing it in the first place and doing it right.
We all remember how to do it – both following and leading. Product Managers do not have corresponding authority for all of their areas of responsibility. We have to manage somehow, and what better way than follow the leader?