Как я создаю Prod

Задача и первая гипотеза

Подготовка к работе продактом распадается на несколько задач: разобрать свой опыт, понять формат интервью, потренировать решение и не потерять организационные детали. Изначально я собирал полезные материалы и инструменты рядом, чтобы уменьшить это переключение.

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

Моя роль

Я определяю пользовательские сценарии, редактирую материалы, задаю требования к ответам ИИ и принимаю решения об изменениях интерфейса. Для разработки, проверки кода и экспериментов использую ИИ-инструменты. Их предложения требуют проверки, как и ответы модели внутри продукта.

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

От универсального чата к помощи под ситуацию

Одна из проблем Ассистента состояла в слишком общих советах. Я разделил подготовку запроса на общие правила общения, сценарий встречи и подходящие материалы. Для HR, нанимающего менеджера, фит-интервью и продуктового кейса нужны разные рекомендации.

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

Другая проблема проявилась в подборе кейсов: русское название компании не совпадало с её техническим идентификатором. Исправление поиска улучшило соответствие. При этом метка компании остаётся средством навигации: она не гарантирует, что задача попадётся на интервью. Происхождение базы объясняется отдельно, а открытые источники добавляются к материалам при наличии.

Эксперимент: более дорогая модель

Я сравнил Flash и Pro на одинаковых вопросах, системном промпте и материалах. На вопросе о финальном интервью обе модели дали почти одинаковое уточнение. Причина была в логике выбора сценария: слово «финал» не определяло конкретный формат.

В другом прогоне, с описанием продуктового кейса и ограничением в один час, Flash ответил за 5,4 секунды, Pro за 14,2. Pro подробнее раскрыл инструменты, но добавил неподтверждённые предположения о метрике продукта. Flash аккуратнее обозначил ограничения найденных материалов. Обе модели почти пропустили проектное управление, хотя оно было указано в запросе.

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

Ограничения и решения

• Слишком широкий набор функций усложняет выбор первого действия. Приоритетом становятся законченные сценарии, а не количество разделов.
• Оценка ответа моделью не равна объективному измерению навыка. Нужны понятные критерии, примеры и экспертная проверка.
• Материалы имеют разное происхождение. Название компании и похожесть задачи не доказывают, что она использовалась на интервью.
• У запросов к модели есть стоимость. Лимиты рассчитываются по токенам и тарифу, смена модели требует пересмотра экономики.

Что сделано и что предстоит доказать

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

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