Есть ли возможность вносить предложения в продукт?
Что проверяют
Как вы относитесь к продукту: только переводите требования из одной формы в другую или замечаете проблемы и доводите идеи до решения. Важно не наличие идей, а то, чем вы их обосновываете. Следом спросят: «Приведите пример. А что было, когда идею отклонили?».
Как отвечать
Нужна одна реальная история, разложенная по шагам:
- где увидели проблему: обращения в поддержку, воронка в Яндекс Метрике или AppMetrica, SQL-выборка по логам, интервью с пользователями;
- как оформили: проблема, гипотеза, кого касается, ожидаемый эффект и примерная трудоёмкость, прикинутая с разработкой. Удобно оценить приоритет по RICE или ICE, чтобы разговор с продактом шёл о цифрах, а не о вкусах;
- через какой канал: задача в бэклоге Jira, страница в Confluence, обсуждение на груминге. Приоритет решает владелец продукта, ваша работа в том, чтобы у него были данные;
- чем закончилось: что сделали, как и за какой период измерили результат. Если не мерили, так и скажите.
Цифры только свои и такие, которые вы сможете объяснить. «Обращений по доставке стало примерно вдвое меньше за два месяца, считали по тегам в Service Desk» звучит сильнее круглых двадцати процентов из воздуха.
Если опыта нет, не придумывайте. Джуну честнее рассказать о небольшом улучшении: шаблоне требований, который приняла команда, найденной несостыковке в процессе, выводах из учебного проекта. И добавить, как вы бы действовали.
Если этот вопрос задаёте вы в конце встречи, уточните по делу: как идея аналитика попадает в бэклог и кто решает о приоритете.
Где спотыкаются
Рассказывают идею без обоснования: «предложил сделать удобнее, всем понравилось». От аналитика ждут данных, а не впечатлений.
Приписывают себе результат всей команды и называют метрики, которые не могут объяснить. Первый уточняющий вопрос про расчёт разрушает историю.
Рассказывают только об успехах или о том, как продавили идею через голову владельца продукта. Сильнее история, где идею отклонили, а вы поняли почему и вернулись с новыми данными.