Prioritization can be hard, especially when we’re dealing with a lot of variables. Peter Abilla, at shmula.com takes a fairly esoteric tool (interrelation digraphs) and applies it as a prioritization tool. Opthamologists have learned that they can’t show us a bunch of blurry images and have us tell them which one looks the best, and then prescribe a corrective lense. They have to ask us “Is it better like this? Or better like this?” Peter’s approach does the same thing, but with a quantitative edge.
Goldilocks and the Three Products
Michael on High-Tech Product Management and Marketing has a fantastic “wish I wrote that” post about the importance of having the right number of features. He has several references, the best of which is Kathy Sierra’s Featuritis vs. the Happy User Peak post from June 2005. The two posts combined provide great insight into why having too many features is bad, while acknowledging that too few is just as bad. In this post we will look at what we can do to apply these insights and also change the rules some, making our software more desireable than our competition.
Competent Users and Software Requirements
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