Product Strategy

Программист в пещере мёртв (но большинству команд об этом не сказали) Существует ментальная модель, которая десятилетиями преследует технологические компании. Вы знаете о такой: гениальный программист, изолированный в своей пещере, получает задание, реализует решение точно по спецификации и отправляет его. Чисто. Транзакционно. Абсолютно бессмысленно. Вот неудобная правда: если ваша инженерная команда работает именно так, вы оставляете на столе огромные суммы денег. Не потому, что инженеры не пишут код — они пишут. Но они пишут код, не понимая «зачем», «для чего» или «что будет, если мы этого не сделаем»....

Представьте: вы находитесь на совещании по продукту, и кто-то предлагает разработать функцию, о которой буквально ни один пользователь не просил. В комнате воцаряется тишина. Кто-то неловко кашляет. Менеджер по продукту выглядит так, будто только что стал свидетелем смертного греха против священного евангелия разработки, ориентированной на пользователя. Но вот в чём дело — некоторые из самых революционных функций в истории технологий родились именно в такой ситуации. Ограничение на количество символов в Twitter не было запрошено пользователями, жаждущими краткости....

Давайте начнём с ереси: лучшее программное обеспечение создаётся не путём слепого следования требованиям, а благодаря пониманию того, когда нужно сказать: «Это то, о чём вы просили, но вот что вам нужно». Подобно шеф-повару, отказывающемуся поливать филе-миньон кетчупом, иногда мы должны защищать пользователей от их собственных запросов. Колесо рулетки требований Когда-нибудь играли в «испорченный телефон» со стейкхолдерами? Вот как обычно эволюционируют требования: graph LR A[Пользовательский запрос] --> B["Нам нужна красная кнопка!"] B --> C["...