As an Agile practitioner, I pride myself on delivering business value for our customers. But sometimes, software developers (myself included) tend to think that we know what business value means (to us anyways), but that’s potentially dangerous.
Sometimes I caught myself saying “this is only a minor formatting bug… low priority”. But when the bug pops up, it undermines the confidence of the end-users in your software. When “perceived quality” is low, you might lose business.
So my points are:
1) “business value” is a broad term; perceived quality could be a business value. A software product that delivers exceptional functionality but poor perception, is delivering value only to a few customers; only a product that gets past the gatekeepers and reach the hands of many users are delivering value.
2) Compared to internal IT projects, software products are trickier for which to define business value, because it’s harder to intimately know each of your end users and their requirements. The wider your potential audience, the more important “perceived quality” could be. I learned that last year when I had the privilege to work on a product team.
Thanks to insomnia, I finally got up and wrote a long overdue entry for this blog here.
Agree and perception is a major topic in management. I sometimes compare low perception value but with real quality and great perception value but low real quality, which one is the less of the two evil?