Обычно под TTM понимают длительность пути от идеи до доступного рыночного предложения. В зависимости от компании в этот путь включают исследование, проектирование, разработку, тестирование, согласования, публикацию и первые действия по продвижению.

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

Собственнику стоит проверить границы показателя. С какого момента начинается отсчет, что считается выходом на рынок, учитываются ли возвраты на доработку и как связана скорость с коммерческим эффектом. Также полезно отделять TTM от частоты релизов и от времени до получения ценности клиентом. Частые обновления могут говорить о хорошем потоке поставки, но сами по себе не доказывают, что продукт быстрее достигает рынка.

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

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