​​Сколько-то лет назад после очередных препирательств о том, что для пользователей ценнее, сформулировал для себя пирамиду ценностей на основе пирамиды потребностей Маслоу.

Тогда получилось вот так и с тех пор кажется не изменилось:
1. Function - функциональность. Пока софт не делает нечто нужное, потребности в нем нет вообще.
2. Reliability - надежность и качество. Следующим критерием будет вероятность корректного выполнения необходимой функции. Если софт свою работу делает через раз - то прочие характеристики этого софта уже не важны.
3. Security - безопасность. Предполагается что при реальной и осознанной угрозе лишиться чего-то ценного, пользователь предпочтет не-комфортное и не-прикольное (см.ниже), но безопасное приложение. В свою очередь, безопасный софт, которые не выполняет свою функцию (Function и Reliability, см.выше) также не нужен.
4. Comfort - после удовлетворения первичных потребностей, пользователю становится важен комфорт. А именно - объем усилий, которые он должен потратить не поддержание Function, Reliability и Security.
5. Fancy - и наконец в последнюю очередь пользователю важны всякие "вкусняшки" и "красивости", не относящиеся к первым четырем потребностям.

Как и в пирамиде физиологических потребностей мы должны понимать, что потребность не абсолютна и актуально только до насыщения, после которого развивается интерес к следующему уровню. Стоит слегка согреться, и уже хочется кушать. Как только софт начал делать что-то полезное (может даже еще не все), возникает интерес, чтобы этот минимум был стабилен. И так до прекрасности.

Опять же, аналогично пирамиде физиологических потребностей, в случае существенного дефицита, можно нарушить приоритеты. В номер голод приоритетнее безопасности, но если снаружи пещеры рыщет саблезубый лев, то можно немного поголодать. Аналогично, если известна громадная дыра в безопасности, то можно на какое-то время отключить необходимые функции или поступиться их надежностью.

Тогда, 7 лет назад, мне казалось правильным следовать модели "согрелся, ну теперь поем". То есть продукт развивается снизу вверх. Вначале удовлетворить основную потребность, потом все остальное. Когда распространилась концепция MVP (Minimal Viable Product), оно казалось вполне соответствующим этой модели - начинай с самого нужного.