📕 Книга Decode and Conquer: Answers to Product Management Questions Или как через CIRCLES и DIGS дойти до ICE MoSCoW
Неплохая книжка по продуктовому менеджменту, которая помогает системно отвечать на продуктовые вопросы, через решение различных кейсов, хотя иногда и бывало скучно. Все используя готовые фреймворки, о которых далее
⭐️ CIRCLES — для анализа и декомпозиции задачи:
• Comprehend: Понять проблему и ситуацию. Например, если обнаружена ошибка в проде:
- Discovery-подход: Определить, какой бизнес-сегмент просел, какие метрики изменились
- Delivery-подход: Проанализировать последние изменения, релизы и потенциальные баги
• Identify: Кто пользователь и его потребности, кого аффектит история?
• Report the customer’s needs: Определить ключевые пользовательские потребности
• Cut: Расставить приоритеты на основе ограничений и целей. Например, используя методы приоритезации (R)ICE или MoSCoW
• List: Предложить несколько решений проблемы
• Evaluate: Оценить компромиссы и trade-offs между решениями
• Summarize: Итоговые выводы
В целом некоторые шаги объединяемы иначе можно уснуть отвечая на все из них, например Identify и Report.
⭐️ DIGS — для структурированного ответа на кейсы (короче и больше сути):
• Define: Сформулировать задачу и гипотезы
• Identify: Определить основные метрики и ограничения
• Generate: Придумать несколько вариантов решений
• Select: Обосновать выбор наилучшего решения
⭐️ MoSCoW — для приоритизации задач:
• Must-have: Критичные функции, без которых продукт не работает
• Should-have: Важные, но не критические задачи
• Could-have: Желательные улучшения (если есть время)
• Won't-have: То, что пока не войдет в фокус
⭐️ RICE = Reach х Impact х Confidence / Effort для приоритизации задач:
• Reach (Охват): Сколько пользователей затронет задача
• Impact (Влияние): Насколько сильно решение повлияет на пользователей
• Confidence (Уверенность): Насколько уверены вы в данных и оценках? (например, 80% уверенности — высокая, 50% — средняя
• Effort (Затраты): Сколько времени или ресурсов займет реализация задачи (ПШЕ)
🤔 Кажется решать через CIRCLES долго, а вот через DIGS как раз:
• Define: Задача: Увеличить конверсию из просмотров в заявки на объявления. Гипотеза: Конверсия низкая из-за сложной формы заявки и недостаточно заметного CTA.
• Identify:
- Метрики. Конверсия из просмотра объявления в заявку (%). Количество незавершенных заявок.
- Ограничения: Временные ресурсы на разработку и дизайн.
• Generate: Решения. (1) Улучшить видимость кнопки "Оставить заявку". (2) Упростить форму заявки. (3) Добавить пуш-уведомления о новых предложениях. (4) Показать доверие к объявлениям через метрики (рейтинг продавца).
• Select: Выбираем решение с максимальным ROI (RICE): Решение 1 и 2: Легко внедряемые с высоким влиянием на конверсию.
Неплохая книжка по продуктовому менеджменту, которая помогает системно отвечать на продуктовые вопросы, через решение различных кейсов, хотя иногда и бывало скучно. Все используя готовые фреймворки, о которых далее
⭐️ CIRCLES — для анализа и декомпозиции задачи:
• Comprehend: Понять проблему и ситуацию. Например, если обнаружена ошибка в проде:
- Discovery-подход: Определить, какой бизнес-сегмент просел, какие метрики изменились
- Delivery-подход: Проанализировать последние изменения, релизы и потенциальные баги
• Identify: Кто пользователь и его потребности, кого аффектит история?
• Report the customer’s needs: Определить ключевые пользовательские потребности
• Cut: Расставить приоритеты на основе ограничений и целей. Например, используя методы приоритезации (R)ICE или MoSCoW
• List: Предложить несколько решений проблемы
• Evaluate: Оценить компромиссы и trade-offs между решениями
• Summarize: Итоговые выводы
В целом некоторые шаги объединяемы иначе можно уснуть отвечая на все из них, например Identify и Report.
⭐️ DIGS — для структурированного ответа на кейсы (короче и больше сути):
• Define: Сформулировать задачу и гипотезы
• Identify: Определить основные метрики и ограничения
• Generate: Придумать несколько вариантов решений
• Select: Обосновать выбор наилучшего решения
⭐️ MoSCoW — для приоритизации задач:
• Must-have: Критичные функции, без которых продукт не работает
• Should-have: Важные, но не критические задачи
• Could-have: Желательные улучшения (если есть время)
• Won't-have: То, что пока не войдет в фокус
⭐️ RICE = Reach х Impact х Confidence / Effort для приоритизации задач:
• Reach (Охват): Сколько пользователей затронет задача
• Impact (Влияние): Насколько сильно решение повлияет на пользователей
• Confidence (Уверенность): Насколько уверены вы в данных и оценках? (например, 80% уверенности — высокая, 50% — средняя
• Effort (Затраты): Сколько времени или ресурсов займет реализация задачи (ПШЕ)
• Define: Задача: Увеличить конверсию из просмотров в заявки на объявления. Гипотеза: Конверсия низкая из-за сложной формы заявки и недостаточно заметного CTA.
• Identify:
- Метрики. Конверсия из просмотра объявления в заявку (%). Количество незавершенных заявок.
- Ограничения: Временные ресурсы на разработку и дизайн.
• Generate: Решения. (1) Улучшить видимость кнопки "Оставить заявку". (2) Упростить форму заявки. (3) Добавить пуш-уведомления о новых предложениях. (4) Показать доверие к объявлениям через метрики (рейтинг продавца).
• Select: Выбираем решение с максимальным ROI (RICE): Решение 1 и 2: Легко внедряемые с высоким влиянием на конверсию.
Please open Telegram to view this post
VIEW IN TELEGRAM
👍8🔥4👌2
В октябре съездил в Кейптаун, ЮАР – поездка всего на неделю, но удалось много чего посмотреть. Только сейчас разобрал фотки с поездки. Трансфер занял всего 24 часа с пересадкой в Эфиопии – зато смена времени на полгода: пока в Москве была осень, там уже весна. Это был тур через @heapcheaptrips_tours, что сняло вопросы организации. Была небольшая группа из 6+ человек.
🌍 Океаны (Индийский и Атлантический), горы, причем непростые, а столовые (с плоской вершиной), – всё это создает интересные пейзажи. В школе читал про мыс доброй надежды, а вот удалось на нем побывать.
🏘 Достаточно безопасно, но ночью мы это не проверяли. При этом все отели обнесены колючей проволокой под напряжением. Напоминание о сложности истории — многокилометровые тауншипы (гетто), оставшиеся со времен апартеида.
🌸 Весна в ЮАР – это время цветения множества растений, большинство из которых растет только там, создается ощущение эдакой другой планеты. Весной еще приплывают киты и пингвины, последние, конечно, бесконечно милые. Пока плыли к китам, проплыли сквозь стаю дельфинов 🐬 — их, наверное, под сотню. Ощущение, как в фильме про дикую природу.
🦁 Настоящее сафари – в Национальном парке Крюгер, но туда нужно ехать в глубь страны до Йоханнесбурга, от которого еще столько же до самого парка. Там настоящая жизнь, но это время + риск малярии. Нам же удалось одним днем съездить в питомник: это не сафари, но уже точно не зоопарк. Посмотреть на львов на расстоянии вытянутой руки с открытой машины, не говоря уже об африканских слонах, буйволах и т. д., – <3
Рекомендую :)
🌍 Океаны (Индийский и Атлантический), горы, причем непростые, а столовые (с плоской вершиной), – всё это создает интересные пейзажи. В школе читал про мыс доброй надежды, а вот удалось на нем побывать.
🏘 Достаточно безопасно, но ночью мы это не проверяли. При этом все отели обнесены колючей проволокой под напряжением. Напоминание о сложности истории — многокилометровые тауншипы (гетто), оставшиеся со времен апартеида.
🌸 Весна в ЮАР – это время цветения множества растений, большинство из которых растет только там, создается ощущение эдакой другой планеты. Весной еще приплывают киты и пингвины, последние, конечно, бесконечно милые. Пока плыли к китам, проплыли сквозь стаю дельфинов 🐬 — их, наверное, под сотню. Ощущение, как в фильме про дикую природу.
🦁 Настоящее сафари – в Национальном парке Крюгер, но туда нужно ехать в глубь страны до Йоханнесбурга, от которого еще столько же до самого парка. Там настоящая жизнь, но это время + риск малярии. Нам же удалось одним днем съездить в питомник: это не сафари, но уже точно не зоопарк. Посмотреть на львов на расстоянии вытянутой руки с открытой машины, не говоря уже об африканских слонах, буйволах и т. д., – <3
Рекомендую :)
👍10🔥7❤2🥰1
Удалось побывать DS-ментором на одном из хакатонов в конце прошлого года, где моя команда заняла 3-е место 🎉 . Исходный проект был посвящён кластеризации событий брокера сообщений/логов.
Коллективным разумом были предложены следующие идеи ниже. Ожидаемо хотелось применить трансформеры, но из-за объёма данных и доступных ресурсов был выбран другой подход. Как вы думаете, какой?
1. Baseline: scaNN + любимый эмбеддер
• ScaNN — супербыстрый на CPU алгоритм поиска ближайших соседей (быстрее Faiss)
• Benchmarks алгоритмов кластеризаций
2. Готовый алгоритм ранжирования текстов: Rank-BM25 — улучшенный tf-idf, который может плохо выделять если признаков мало, и очень быстро растет размер словаря при увеличении кол-во n-gramm
3. Алгоритм с кастомным эмбеддингом
• Используем токенизатор (например, BPE). Обучаем его на логах
• Переводим логи в последовательность токенов
• Генерируем tf-idf для 1-, 2-, 3-грамм (размер словаря ~10⁶)
• Создаём эмбеддинги для токенов (например, с помощью предобученной модели)
• Кластеризуем эмбеддинги (например, на 100-800 кластеров)
• Для нового текста создаём вектор, учитывающий частоту кластеров
• Результат — компактные векторы, подходящие для кластеризации и обнаружения аномалий
4. Быстрая работа со строками + dbstream clustering
• RapidFuzz — библиотека с быстрыми реализациями функций string similarity.
• Jaro-Winkler Distance — быстрее Левенштейна на коротких строках.
5. Итеративное выделение кластеров с помощью LLM
• Генерируем ключевые слова и типы ошибок по существующим кластерам
• Покрываем базу кейвордами (~50%)
• Обрабатываем оставшиеся данные, выделяя новые кластеры
• Повторяем процесс, пока покрытие не станет полным
• Удобно выделяем ключевые виды ошибок (например, SQLException, JavaException, Timeout и т.д.)
6. Имплентация от Jetbrains (📕Статья: Aggregation of Stack Trace Similarities for Crash Report Deduplication, ⭐️ код на GitHub)
Внутри решение k-NN с хитрой агрегацией stack trace логов ошибок с временными метками
Коллективным разумом были предложены следующие идеи ниже. Ожидаемо хотелось применить трансформеры, но из-за объёма данных и доступных ресурсов был выбран другой подход. Как вы думаете, какой?
1. Baseline: scaNN + любимый эмбеддер
• ScaNN — супербыстрый на CPU алгоритм поиска ближайших соседей (быстрее Faiss)
• Benchmarks алгоритмов кластеризаций
2. Готовый алгоритм ранжирования текстов: Rank-BM25 — улучшенный tf-idf, который может плохо выделять если признаков мало, и очень быстро растет размер словаря при увеличении кол-во n-gramm
3. Алгоритм с кастомным эмбеддингом
• Используем токенизатор (например, BPE). Обучаем его на логах
• Переводим логи в последовательность токенов
• Генерируем tf-idf для 1-, 2-, 3-грамм (размер словаря ~10⁶)
• Создаём эмбеддинги для токенов (например, с помощью предобученной модели)
• Кластеризуем эмбеддинги (например, на 100-800 кластеров)
• Для нового текста создаём вектор, учитывающий частоту кластеров
• Результат — компактные векторы, подходящие для кластеризации и обнаружения аномалий
4. Быстрая работа со строками + dbstream clustering
• RapidFuzz — библиотека с быстрыми реализациями функций string similarity.
• Jaro-Winkler Distance — быстрее Левенштейна на коротких строках.
5. Итеративное выделение кластеров с помощью LLM
• Генерируем ключевые слова и типы ошибок по существующим кластерам
• Покрываем базу кейвордами (~50%)
• Обрабатываем оставшиеся данные, выделяя новые кластеры
• Повторяем процесс, пока покрытие не станет полным
• Удобно выделяем ключевые виды ошибок (например, SQLException, JavaException, Timeout и т.д.)
6. Имплентация от Jetbrains (📕Статья: Aggregation of Stack Trace Similarities for Crash Report Deduplication, ⭐️ код на GitHub)
Внутри решение k-NN с хитрой агрегацией stack trace логов ошибок с временными метками
🔥11👍8⚡4❤2