Software product success.
Johanna Rothman just wrote an article titled Implicit Requirements are Still Requirements. She points out that her expectations were not met, even though her needs might have been. Johanna also implicitly begs the question – how do we gather implicit requirement?
Yesterday we wrote about focusing our documentation on what our users are trying to accomplish. With a structured requirements approach, or with an interaction-design driven approach, we’ve already solved half the problem – determining what to document.
Sometimes we forget that people use our software. Neil Mix reminds us that we should treat our users like people. For anyone who’s worked retail or food service jobs (like yours truly), we shoud treat our customers like customers.
When Alan Cooper and Kent Beck debated the benefits of eXtreme Programming versus Interaction Design, they disagreed on a lot of things. One thing they agreed on is that Agile processes are designed to minimize the impact of changing requirements. Cooper believes that it makes more sense to minimize future change by understanding the requirements better up front. Beck believes that the requirements can not be understood by the team until something is delivered. Beck’s point is that the customer doesn’t understand the requirements until he has something in his hands. We’ve shown how this is both a strength and a weakness for Agile in the real world. In The Hobbit, the dragon Smaug was missing a scale on his belly, that made him vulnerable. Agile processes have a similar weak spot.
Most teams think about testing in terms of code coverage – what % of the lines of code are covered? What matters to our stakeholders is how well the software works. More precisely, how well does the software let the users work? We should be targeting our quality message in terms of use cases, because that matches their perspective and context.
Different people approach the same goal very differently. When we don’t truly identify our users, we end up with software that dehumanizes, waters-down, and otherwise fails to succeed at anything more than grudgingly tolerated functionality. Even worse, we may ignore the needs of our key demographic, resulting in software failure. When we use personas instead of generic use cases, we can avoid both the misery of a failed product and mediocrity of marginal success.
Michael has posted a great definition of the product manager role on his blog, Product Management and Product Marketing – A Definition. He covers a whole host of activities in six seperate areas. Some of the responsibilities, while not product management, are often the responsibility of the product manager. It’s a good real-world assessment of what product managers are often asked to do.
We were all student drivers at one point. But no one stays a beginner indefinitely. Almost no one becomes an expert driver either. Most of us are competent drivers. Driving skill probably even follows a bell curve distribution, with most drivers being OK, some “bad”, some “good”, and very few experts or beginners. We’ll show in this post how to apply this pattern to software requirements and design.
The same is true of our users
The information age is ending and the conceptual age is beginning. In A Whole New Mind, Daniel Pink proposes that six characteristics of right-brain thinking are key to success in the new economy. Nils Davis realizes that these characteristics are embodied by good product managers today. We will define the conceptual age, review the six characteristics, and see how this applies to product management.
