Ошибался ли в анализе задачи

Ошибался ли в анализе задачи

Да, ошибался. И это одна из самых важных частей работы Product Manager — уметь признавать ошибки, учиться на них и делиться опытом.

Пример ошибки из реальной практики:

Контекст: Мы разрабатывали новую фичу "быстрое добавление товара в корзину с одного экрана" (One-Step Checkout). Проанализировал данные, увидел, что процесс добавления в корзину занимает 3 шага и думал, что сокращение до 1 шага резко повысит конверсию.

Мой анализ был:

• 30% пользователей бросают корзину после первого шага
• Если убрать 2 шага, потеряем 30% усилий
• Вывод: конверсия в покупку вырастет на 25-30%
• Приоритет: высокий

Что я упустил:

1. Не учел, почему люди бросают корзину

   • Я предположил: "Сложно, слишком много шагов"
   • На самом деле (из интервью потом): "Я хочу проверить цену в других местах", "Может, мне не нужно это", "Дорого!"
   • Убирание шагов не решало настоящую проблему

2. Не сегментировал данные

   • 30% — это усреднённая цифра
   • На самом деле:

     - На мобильных: 50% (да, нужна оптимизация)
     - На десктопе: 15% (проблема меньше)
     - Новые пользователи: 60% (нет доверия, не шаги)
     - Постоянные клиенты: 5% (нет проблемы)

• Я решал проблему мобильных, но одним решением для всех

1. Забыл про риск потери данных

   • One-step checkout часто означает меньше полей → меньше информации для CRM
   • Это вредило персонализации позже
   • Упущенная выручка > выигрыш от скорости

2. Не проверил гипотезу через A/B тест сразу

   • Потратил 3 месяца разработки
   • Когда запустили A/B тест: прирост был 4%, не 25%
   • Мог был получить этот вывод за неделю с минимальным кодом

3. Игнорировал паттерны других категорий

   • Посмотрел на Amazon, eBay: оба предлагают несколько шагов checkout
   • Если бы это было проблемой, они бы исправили
   • Я подумал: "Они, наверно, ошибаются"
   • На самом деле: люди ХОТЯТ потребовать время (проверить покупку)

Что сделал неправильно (анализ ошибки):

Чему я научился:

1. Корреляция != Причинность

• Коррелирует: много шагов + много отказов
• Но причина может быть что угодно (цена, недоверие, не в настроении)
• Нужны интервью, не только метрики

2. Пример явно лучше гипотезы

• Я думал: "давайте сделаем как в мобильных приложениях"
• Мобильные приложения — другой контекст (маленький экран, нет клавиатуры)
• Интернет-магазин — другие правила

3. Минимальный тест перед разработкой

• Можно сделать One-Step Checkout за неделю (выключить 2 шага в UI)
• Запустить A/B тест на 10% трафика
• Получить ответ за 2-3 недели
• Вместо 3 месяцев разработки

4. Ошибки в анализе стоят дорого

• 3 месяца разработки × 3-5 инженеров = 120-200k потерянных
• Упущенная конверсия (ложный прирост не произошел)
• Но хуже всего: команда теперь скептична к моим гипотезам

5. Признание ошибки помогает

• После того, как я признал ошибку перед командой
• Мы установили правило: "A/B тест перед разработкой если непонятно"
• Экономия времени с того момента: ~40%

Как я анализирую теперь:

Чеклист перед разработкой:

• Есть ли интервью с пользователями? (минимум 5)
• Какая гипотеза? (ясно сформулирована?)
• Есть ли противоположная гипотеза? (может, я ошибаюсь?)
• Сегментированы ли данные? (не усреднено ли?)
• Что будет, если я ошибаюсь? (риск-анализ)
• Можно ли A/B протестировать перед разработкой?
• Смотрел ли конкурентов? (есть ли бенчмарк?)
• Какой размер выборки? (3 интервью = слишком мало)

Общий вывод:

Ошибки в анализе — это нормально. Важно:

1. Признать ошибку быстро, не защищаться
2. Научиться (не повторять одну ошибку дважды)
3. Поделиться (кейсы ошибок помогают команде)
4. Систематизировать (добавить в чеклисты, процессы)

Лучше сделать 10 маленьких ошибок и выучиться, чем одну большую и потом сомневаться в себе. Product Manager — это постоянное обучение на своих ошибках.