Есть ли интерес к продуктовой разработке
Что проверяют
Компания со своим продуктом хочет понять, осознанно ли вы к ней идёте: видите ли разницу между продуктом и проектной работой на заказчика и готовы ли думать о метриках, а не только о требованиях. Следом обычно спрашивают, как вы поймёте, что сделанная фича была нужна.
Как отвечать
Ответ «да, интересно» без содержания ничего не стоит. Покажите, что понимаете, чем продуктовая работа аналитика отличается:
- цель: в заказной разработке успех это принятое ТЗ и подписанный акт, в продукте это изменение метрики: конверсии, удержания, частоты использования;
- гипотезы вместо требований: задача звучит не «сделать фильтр», а «пользователи бросают поиск, почему». Аналитик участвует в discovery, разбирает CJM, проводит интервью по JTBD, формулирует гипотезу и критерий успеха заранее;
- проверка: A/B-тест или поэтапный выпуск за фича-флагом, данные из AppMetrica, Amplitude или своего хранилища через SQL;
- длинный горизонт: вы живёте с продуктом годами и видите последствия своих решений, включая долг в требованиях.
Затем свой пример. Подойдёт любой случай, где вы смотрели дальше спецификации: предложили изменить сценарий по обращениям в поддержку, посчитали, скольких пользователей затронет доработка, отказались от фичи после проверки. Цифры берите из своего опыта и будьте готовы объяснить, как их считали.
Если продуктового опыта нет, скажите прямо: «Я работал в заказной разработке, но на последнем проекте сам попросил доступ к аналитике и смотрел, как пользуются тем, что мы сдали». Это честнее и убедительнее выдуманного роста вовлечённости.
Где спотыкаются
Говорят о продукте как пользователь: «люблю ваш сервис». Симпатия к приложению не равна интересу к продуктовой разработке.
Не называют ни одной метрики. Аналитик, который не знает, как измерить результат своей работы, для продуктовой команды выглядит исполнителем ТЗ.
Приписывают себе решения продакт-менеджера. Лучше чётко разделить: что вы предложили и посчитали, а что решила команда.