Archive of Product Management Articles

Too much information about requirements or too little? Too much documentation or too little? Use the NICE framework to get it just right.

How do you approach starting a small requirements project as part of a large initiative within a massive enterprise? Do you boil the ocean? Your customer knows she needs “requirements” to give to her development team. She asks you - what will you deliver, and how long will it take? Great questions. If you have to write a statement of work, with time/cost estimates, and a list of deliverables - what would you do?

Learning how to write use cases can be tough, but it is simple compared to the balancing act of determining which use cases to write and how to manage the expectations of all the stakeholders that are involved. It can be a difficult balancing act to prioritize use cases to assure that you meet the goals of the business while satisfying the needs of the users.

[photo by Henkster]

Writing good requirements is more than just about following a set of rules. You can capture knowledge about your goals and your product with a set of well crafted requirements. But to truly write good requirements, you have to gain a level of understanding that surpasses knowledge. Insight springs from understanding, and insight leads to great requirements and ultimately great products.

When we’re part of a team creating software for the enterprise - an internally focused, IT initiative, we usually don’t think about product managers. Business analysts, systems analysts, and architects (of all varieties) are all commonplace. But not product managers. Product managers bring a perspective and a strategic focus that can influence the success of an IT enterprise initiative.

You want your software to be used, not to sit on the shelf. You can’t achieve the ROI of your software if people don’t use it. And you can’t achieve the ROI of your software by forcing people to use it either.  Some will fail to achieve the benefits, and others will delay using it or refuse to use it entirely.  You have to make them want to use it, and you have to design the software for the users who must use it.  Otherwise, you won’t achieve the ROI.

No matter how good your quality process is, you are introducing bugs. This article reviews the places where bugs are introduced in the software development process (from stakeholders to users), and reviews ways to address those bugs.

We’ve written before about several characteristics of well written requirements, and one of those characteristics is testability. Ahamad has written an list of 10 tests of requirements, with an emphasis on assessing the testability of the requirements. The testability of the requirement determines if the resultant product can be tested to determine if it meets the requirement.

We use actor hierarchies to organize the different users of a system. Different people play different roles, and thus do different jobs. We use different actors to identify and organize those people. When deploying a system globally, we usually discover people that do the same jobs, but do them differently. Incorporating the notion of personas lets us deal with this.

We re-analyzed some of our earlier numbers with the final data, including compensation by region and state. We also looked at some other factors, like who you report to, how large your company is, and if your company is public or private.