Но это уже решение менеджмента, а не команды, и ответственность тоже на менеджменте. Не хотите переписывать роадмап - придержите свои новые вводные (вариант: наймите для их реализации дополнительных людей).

В стартапе реально так, повторяемость задач минимальная, вероятность измененй требований в процессе - зашкаливает, запаса по ресурсам нет, кол-во ресерча - огромное и тд

Ты зачем то распространяешь некий частный случай на общность, мне кажется. Точнее пытаешься свести в то, что любой общий случай сводится к твоему частному через некоторые действия и хоть теоретически это возможно, практически - нет и часто не имеет смысла.

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

Нет, почему? @pankiru уже вот выше дал комментарий о чем конкретно речь даже.

К ещё не работающему)

Оу. А зачем неработающему продукту роадмап?)

Хотим с первой закрытой беты двигаться четко с публичным роадмапом но не таким подробным как внутренний

(извините, я, видимо, пропустил важную часть беседы)

А чем это отличается от просто установки даты релиза и списка фич, которые войдут в релиз?

Только тем что хотим чтобы и дата и список на 100% были выполнены

Но команда вроде бы в обоих случаях коммитится на набор фич и дату, но в случае роадмапа ещё и на то, что доставит эти фичи в определённом порядке в определённое время. Это такой инструмент самовыгорания получается. Bodyflamethrower как развитие паттерна footgun.

Кажется, сделать такое даже сильной сработанной командой на горизонте нескольких кварталов просто нереально. Я бы за такое взялся только при условии неограниченного финансирования)

Я, конечно, не вхожу даже в топ-10% engineering managers страны, а где-то до сих пор живы люди, запустившие человека на Луну к поставленному дедлайну и вроде бы даже не вышедшие за бюджет больше чем в два раза.

Вот что бывает, когда гениальные люди работают с и так фантастическим бюджетом:)

Да интересно было бы послушать)

В общем, здравый смысл диктует тут следующий подход: очертить набор фич, совокупность которых позволит считать их MVP и оценить дату его запуска так, чтобы она была не более, чем в полугоде от сегодняшнего дня. Если не получается - расширить команду. Дописать снизу все остальные фичи в порядке приоритета, и оценить каждую по отдельности с точностью плюс-минус 2 недели. Потом приниматься за работу, и корректировать все оценки каждые две недели. Мне кажется, что куда важнее начать как можно раньше получать обратную связь от пользователя/заказчика, чем запилить все-все-все его хотелки, даже безотносительно сроков.

Вот ты явно стартап не делал) MVP в реальности рождается в процессе, процент того что выбрасывается в первые полгода >50% это если ты еще срезаешь углы, возможно мой частный случай но это мой четвертый такой опыт и не сильно меняется картинка

Да наверное правильн оскзаать что мы 2 раза пивотились один сильно и один не очень сильно

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