Archive of Product Management Articles

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.

Pragmatic Marketing’s 2007 survey of product managers includes questions that identify product managers as having technical backgrounds. Product management involves many responsibilities that require some level of technical acumen. In this article, we look at the survey responses to see if the degree of technical skill has a correlation with compensation.

We wrote previously about some of the salary data from Pragmatic Marketing’s 2007 Product Manager survey data. Since that time, we’ve had the opportunity to analyze the complete data set. One of our readers asked if we could crunch the numbers for more senior positions - directors and executives - who responded to the survey.

Traditional requirements happen after a multi-system architecture has been defined.

But what about the requirements that feed into that architecture? The requirements that drive the enterprise architecture decisions in the first place? We haven’t talked about those before.

Pragmatic Marketing’s 2007 survey results are in, and we’ve done some number crunching - looking at total compensation data. Total compensation is salary plus bonus. See how the numbers come out across experience, sex, age, state, and international region.

The polls are open! Go to their announcement to take the annual Product Management and Marketing Survey!