Теория ограничений как аргумент не пилить новые фичи

Смысл в том, чтобы рассматривать проект как линию производства. Например, цех состоит из трех этапов: На первом этапе делают 10 заготовок в час, на втором обрабатывают 8, на третьем красят 10 шт. В итоге полноценных крашеных деталей за час цех производит 8 штук. Всё из-за черепах на обработке. Поэтому есть смысл решать проблему на обработке, а не вкладываться в улучшение покраски.

На примере сервиса может быть так, что у нас из 10.000 пользователей, но только 10 покупают pro-версию. Соответственно нет смысла разрабатывать какой-то новый крутой функционал, а стоит разобраться куда мы профукали 9.990 по дороге до pro-версии

На практике теория для дизайнера — это привычка задавать себе следующие вопросы: — Это проблемное место? — Самое проблемное? — Дойдут ли пользователи до экранов, которые я рисую? — А сколько дойдёт? — Можно ли нарисовать что-то проще, с тем же результатом? — А если не рисовать вовсе? — Ну а серьезно, на@$& это рисовать?

Ценность этой теории для дизайнера в том, чтобы перестать думать фичами, а находить узкие места и чинить их, потому что это точки кратного роста. Улучшение таких мест приносит в проект деньги из которых вам платят зарплату) Плюс ещё в том, что уходит синдромы самозванцев, ведь вы реально можете влиять на бабки, которые можно посчитать Юнит экономикой (будет позже) а не рисуете фичи, до которых пользователь не доходит

От себя отмечу, что самое частое узкое место — это активация пользователя, поэтому рекомендую стремиться в команды активации и нарабатывать там опыт. Рисовать онбординги, первые сессии, различные промо и другие штуки для превращения пользователя из пассива в актива