Почему roadmap в affiliate-продукте ломается не из-за идей, а из-за плохих входных данных

Roadmap часто выглядит как спор о приоритетах. На деле он обычно ломается раньше — на этапе discovery: команда берёт шум за сигнал, а единичную боль за системную потребность.

Что проверять до включения фичи в план:
• проблема повторяется у нескольких сегментов, а не у одного громкого клиента;
• у пользователя уже есть костыль или обходной путь — значит боль реальная;
• решение влияет на деньги, скорость или риск, а не просто «удобнее»;
• вы понимаете, кто примет решение и кто будет пользоваться фичой каждый день.

В affiliate-нише это особенно важно: фаундер может просить «сделайте как у конкурента», но потом выясняется, что у него другой процесс, другая команда и другая мотивация. В итоге roadmap раздувается задачами, которые не двигают retention и не уменьшают ручной труд.

Полезное правило: перед разработкой описывайте не фичу, а изменение поведения. Если после релиза у команды не станет меньше ручных действий, не ускорится цикл или не снизится ошибка, это плохой кандидат в roadmap.

Сначала подтвердите боль и сценарий, потом оценивайте решение. Иначе roadmap превращается в список дорогих предположений.