How do we define product qualities?
posted by: Nick Roman on 2/17/2010
I talked briefly about product qualities in my previous post, and I would like to pursue this a bit further. Software products have a set of product qualities attached to them, whether we like it or not! A product/system is more or less: user-friendly, intuitive, productive, maintainable, reliable, scalable, etc. This is not a choice, it’s a fact.
However, we have a choice in how we deal with these product qualities. I see two obvious options:
- Let the product qualities materialize themselves by chance, and thrust our luck and good fortune that the features we implement are user-friendly enough. Features are what matters, right?
- Actively and consciously define desired product qualities, and let these be our guiding star in the development of software and systems.
In my view, you have a better chance of creating a desirable product for the client by sticking to option 2. So the question is:
How do we define product qualities?
First, we have to take a step back and ask ourselves: Who are our stakeholders? A brainstorming session will probably give you a sizable list (end users, sales, marketing, operational department (hosting), purchasing managers, own support department, etc.). Prioritize this list and ask yourself another important question:
What are the stakeholders’ values/requirements for the new piece of software you are building?
Example of stakeholder value: “It must be possible to create a simple survey without attending a training course.” This is a clear and unambiguous stakeholder value/requirement.
Once you have defined a set of stakeholder values for your new module/sub-system, it’s time to convert these into product qualities and let the developers design these qualities into the software. I’ll talk more about how we define product qualities in a precise, quantifiable manner in my next post.
Here’s a challenge: try to quantify love.