Чек-лист перед релизом функции в SaaS: 7 пунктов готовности

Кто не читал прошлый пост, короткий дисклеймер: релиз в SaaS-е — это не когда его показали миру. Это куда более замороченная подкапотная история. Иначе новая фишка может быть технически готова и все равно провалиться. Без багов, без аварий, без грозных предзнаменований. Просто ее не поняли, не внедрили, не объяснили, не измерили.

Поэтому перед запуском стоит проверять не только код. Нужно проверять готовность продукта, продаж, поддержки, внедрения, аналитики и коммуникации. А так как делюсь чисто своим опытом по запуску сааса в б2б, буду благодарен, если вы сможете что-то еще добавить со своих колоколен для обмена опытом.

Собственно, чек-лист:

1. Продуктовая готовность

1. Понятно, кто основной пользователь новой функции
2. Сформулирована конкретная проблема, которую функция решает
3. Проверено, что это не запрос/желание всего одного крупного клиента*
4. Описан основной сценарий: где пользователь находит это, что делает первым, как получает результат
5. Понятно, какое действие считается успешным использованием
6. Зафиксированы ограничения: для каких сценариев это не подходит

2. Коммерческая готовность

1. Понятно, зачем нововведение бизнесу: удержание, upsell, привлечение, снижение нагрузки или повышение ценности продукта
2. Определено место новинки в тарифах, если она влияет на монетизацию
3. Продажи понимают, каким клиентам это будет полезно и как объяснять ценность
4. Зафиксировано, чего нельзя обещать клиентам, чтобы не продать ложное ожидание

3. Готовность внедрения у клиента

1. Понятно, сможет ли клиент начать пользоваться сам или потребуется помощь
2. Определено, какие роли на стороне клиента должны участвовать в настройке
3. Есть инструкция, короткий гайд, демо или подсказки в интерфейсе
4. Понятно, как довести клиента до первого полезного результата

4. Готовность поддержки

1. Поддержка заранее знает о релизе и логике новой фишки
2. Есть гайды и FAQ
3. Описаны возможные ошибки и способы их решения
4. Понятно, что считать багом, а что ограничением функции
5. Есть маршрут эскалации сложных обращений

5. Техническая готовность

1. Протестированы критичные сценарии
2. Проверены права доступа и ограничения по ролям
3. Проверены интеграции и передача данных, если они есть
4. Настроен мониторинг ошибок
5. Есть план отката или временный обходной сценарий

6. Аналитическая готовность

1. Определена главная метрика успеха
2. Настроены события для ключевых действий пользователя
3. Разделены случайное открытие и реальное использование
4. Понятно, за какой период оцениваем первые результаты
5. Есть планы действий на случай малой активности использования

7. Коммуникационная готовность

1. Подготовлено короткое объяснение пользы понятным языком
2. Понятно, где сообщаем о запуске: интерфейс, письмо, база знаний, блог, менеджеры, etc.
3. Есть отдельные сообщения для клиентов и внутренних команд
4. Подготовлено краткое описание изменений для клиентов и команды

*Проверено, что это не запрос/желание всего одного крупного клиента — в целом, этот пункт можно и пропустить, особенно если вся разработка и так заточена под одну конкретную компанию. Однако в ряде случаев, когда продукт планируется «для всех», а допиливается исключительно по требованию одного отдельного крупняка, можно завести себя в нехилый такой тупик. Более того, клиент может хотеть, но в итоге не пользоваться (передумал, не понял и т.п.). Так что момент такой, немаловажный.