Growth hacking без «взлома роста»: зачем командам такой подход? 🧐

В продакт-менеджменте есть интересная особенность: со временем некоторые термины и инструменты могут использоваться не совсем так, как они изначально задумывались.

Growth Hacking – один из таких примеров. В последнее время подмечаю ситуации, когда команды используют для «взлома роста», а как удобный фильтр для проверки гипотез, перед тем, как идти в полноценный проект.

Почему такой подход тоже имеет право на жизнь?

Во-первых, в таких компаниях редко когда основательно считают экономику проектов и в ситуации, когда проект не взлетает, с продакта требуют цифры (которых нет). В этом случае growth hacking помогает: быстрый тест идеи лучше, чем крупные инвестиции в проект, который может не взлететь.

Во-вторых, слабая культура аргументированного обсуждения инициатив и отказа от заведомо неудачных. Уверен, вам знакомы ситуации, когда от C-level прилетает «гениальная» идея, и команда обязана её реализовать. Вместо месяцев работы над полноценным проектом growth hacking позволяет быстро проверить основу идеи. Если на тестах метрики слабые – в проект больше не инвестируют.

Какие метрики важны при таком использовании growth hacking?

1️⃣ Стоимость теста. Если для проверки нужна разработка модуля, редизайн или целый спринт — значит, тест спланирован плохо. Упрощайте: почти всегда можно проверить быстрее и дешевле.

2️⃣ Скорость и количество. Один тест в месяц? Это не процесс, а карго-культ. Хороший бенчмарк, к которому нужно стремиться – около 15 тестов в месяц.

Если вы хотите узнать больше про growth hacking – от идеи до внедрения и обратно – а также про другие продуктовые инструменты, обратите внимание на канал Юлии Путиловой «О чём плачут продакты».

7 популярных креативных техник в продакт-менеджменте

А вот и обещанный обзор креативных техник, которые я применял в своей практике:

1️⃣ Double Diamond – методика, разработанная British Design Council в 2005 году и основанная на чередовании дивергентного и конвергентного мышления.
– На первом этапе мы исследуем и выявляем проблему (Discover → Define). Генерируем как можно больше идей без критики (designing the right thing).
– На втором этапе мы фокусируемся на создании и тестировании решений исходной проблемы (Develop → Deliver). Включаем аналитику и отбираем жизнеспособные идеи (designing things right).
Цель Double Diamond – структурировать креативный процесс и снизить риски при разработке продукта.

Существует и расширенная модель Triple Diamond, которая добавляет ещё один «бриллиант» с фокусом на масштабировании продукта.

2️⃣ ТРИЗ (Теория Решения Изобретательских Задач) – методика, разработанная советским инженером Генрихом Альтшуллером в 1940-1960-х годах. Основная идея ТРИЗ: каждая задача может сводиться к противоречию, которое можно решить, применяя проверенные принципы из анализа тысяч изобретений. Кратко ТРИЗ не описать, тянет на отдельный пост.

3️⃣ SCAMPER. Название – это акроним, в котором зашито 7 креативных приёмов: Substitute, Combine, Adapt, Modify, Put to Another Use, Eliminate, Reverse. Цель методики – помочь в генерации идей и систематизировать их.

4️⃣ CRAFT (Creative Algorithms, Frames & Tools) – методика, разработанная основателем студии IKRA Василием Лебедевым в 2010-х годах. В основе «фреймы» и поиск способов изменения взаимодействия. Например, есть проблема, что люди не хотят кликать по баннерам, это «фрейм», а что, если сделать баннер-лотерейный билет, кликнув по которому, можно выиграть приз? Как и ТРИЗ кратко описать будет сложно, тянет на отдельный пост.

5️⃣ Латеральное мышление – методика, разработанная Эдвардом де Боно в 1967 году, в основе которой лежит «боковой подход», цель которого увидеть проблему под новым углом. Наверняка вы слышали про «Шесть шляп мышления», есть ещё подход с провокацией (высказывание парадоксальной идеи), инверсией (меняем местами привычные вещи), аналогией (поиск параллелей в других сферах) и случайным символом (попытка связать случайное слово/образ и с задачей).

6️⃣ Theory of Constraints – методика, разработанная Элияху Голдраттом в 1980-х годах. Методика строится на системном подходе к решению проблем. Основная идея: выявить корневую проблему с помощью древовидной структуры, затем разработать прорывное решение, снова опираясь на эту модель. После этого решаются возникающие противоречия и конфликты, и формируется пошаговый план внедрения, направленный на максимальное улучшение системы. Если хотите разораться глубже, то прочитайте книги Голдратта «Цель» и «Цель 2.0».

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

Креативных техник довольно много. Вот несколько хороших подборок, где можно посмотреть и выбрать подходящие для себя:
– Design Kit от IDEO
– Подборка Project of How
– Hyper Island Toolbox
– Innowiz Online tools
– Vetas

По-настоящему сильные продукты: взгляд жюри Startech.Awards 💪

В этом году я попробовал себя в новой роли – участвовал в жюри Startech.Awards. Это как российский «Оскар» для стартапов.

За пару недель мне пришлось оценить более 50 стартапов (из 1680 заявок!) по таким критериям:
– Технологическая или инновационная составляющая
– Опыт работы на рынке / коммерческий трекшн
– Конкурентные преимущества
– Размер целевого рынка
– Укомплектованность и квалификация команды

💡 Интересный вывод: самым слабым местом большинства проектов было конкурентное преимущество. Давайте разберём, что это такое на примере методологии Гамильтона Хелмера.

Устойчивое конкурентное преимущество – это способность компании создавать ценность для клиентов и удерживать её дольше конкурентов благодаря защитным механизмам. Хелмер выделяет 7 сил:

1. Экономия масштаба – чем больше компания производит, тем дешевле обходится каждая единица.
2. Сетевые эффекты – ценность продукта растёт с ростом числа пользователей.
3. Контрпозиционирование – уникальное позиционирование продукта, которое конкуренты не могут скопировать без ущерба для себя.
4. Высокие затраты на переключение – клиентам неудобно или дорого менять продукт на другой.
5. Сила бренда – доверие к бренду, которое обеспечивает долгосрочное сотрудничество с клиентами.
6. Контроль уникальных ресурсов – патенты, технологии, команды экспертов.
7. Операционная эффективность и процессы – уникальные процессы или алгоритмы, которые сложно повторить.

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

Попробуйте взглянуть на свой продукт под этим углом: есть ли у него устойчивое конкурентное преимущество?
Ну а если хотите увидеть финал Startech.Awards, где поборются самые крутые стартапы с сильным конкурентным преимуществом, способные в будущем сделать disrupt рынка, приходите 19 сентября в ВЭБ Центр (Новинский бульвар, 31, Атриум).

Узнать подробности 🎫

Что такое дерево метрик? 🌳

Дерево метрик – это иерархичная визуализация как разные метрики в продукте влияют друг на друга: от верхнеуровневой к низкоуровневым.

Его ещё называют пирамидой метрик или иерархией метрик.

Главная ценность дерева в том, что из неструктурированного набора метрик, вам становятся видны рычаги влияния на верхнеуровневую метрику – North Star Metric.

North Star Metric (NSM) – главная метрика, измеряющая успешность продукта. NSM является производной от других метрик, которые отражают эффективность работы продукта в разных его частях. В контексте дерева метрик NSM его вершина. Цель продакта – работать над улучшением North Star Metric. Подробнее о NSM писал мой коллега Павел Беляев, тимлид дата-аналитиков в Яндекс eLama рекомендую не только почитать его пост, но подписаться на канал.

Дерево метрик помогает:

1. Фокусироваться на главном: выделить наиболее важные метрики, которые напрямую влияют на NSM. Благодаря этому команды могут направить усилия на наиболее значимые задачи и избегают распыления на второстепенные задачи.

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

Например, тимлид говорит: «Нужно заняться техдолгом». Продакт смотрит на дерево метрик и видит: 2% оплат не проходят из-за багов → если убрать техдолг в этой части, ошибок станет меньше → меньше ошибок = рост выручки выручки.

3. Улучшение качества принятия решений. Чёткая структура дерева метрик помогает принимать более обоснованные и эффективные решения. Команды сразу видят, какие метрики требуют внимания, и понимают, какие шаги нужно предпринять для их улучшения.

Например, вместо абстрактного «надо срочно добавить такую фичу», можно обосновать это через дерево метрик: эта фича улучшает Retention → растёт LTV → рост LTV мощный рычаг для роста Revenue, нашей NSM

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

Продвинутый уровень использования Дерева метрик – в связке с OKR и с Unit-экономикой продукта.

Как построить дерево метрик?

1️⃣ Определите North Star Metric
В большинстве продуктов это выручка (Revenue) или прибыль (Profit).

2️⃣ Разложите NSM на метрики 1 уровня
Они должны быть конкретными и измеримыми. Не забываем про принцип MECE:
– метрики не должны пересекаться (Mutually Exclusive);
– но вместе должны полностью описывать влияние на верхнюю метрику (Collectively Exhaustive).

Например, выручка может раскладываться на количество клиентов и LTV (Lifetime Value)

3️⃣ Разложите метрики 1 уровня на метрики 2 уровня
Например, LTV можно разложить на:
– время жизни клиента (Lifetime)
– выручку от платящего пользователя (ARPU)
Количество клиентов – на количество новых и возвращающихся клиентов.

4️⃣ Повторяйте для метрик 2 уровня и ниже
Как понять сколько уровней дерева нужно?
На моей практике 4-5 уровней было достаточно. Главное идти до того уровня, где на отдельные метрики уже реально можно влиять через проведение тестов, экспериментов, изменения в продукте.

Есть и альтернативный способ построения дерева метрик: «снизу вверх», т.е. от базовых метрик к NSM. Но на моей практике он встречается реже.

5️⃣ Проанализируйте дерево
И найдите проседающие метрики, у которых сильное влияния на NSM

6️⃣ Сгенерируйте гипотезы
Определите, какие действия помогут подтянуть эти метрики и в итоге повлияют на NSM.

Ошибки при построении дерева метрик 🔴

В продолжение темы давайте разберём ошибки, с которыми я так или иначе сталкивался в своей практике:

1️⃣ Неправильный выбор метрик для оценки того, что на что влияет.
Как себя перепроверить: используйте фреймворки, например, AARRR или HEART, чтобы разложить продукт на составляющие и проверить логику.

2️⃣ Построение дерева в одиночку. Да, продакт хорошо разбирается в продукте, но реальность всегда сложнее, продукт не существует в вакууме.

Состав метрик и их влияние нужно обсуждать вместе с командой:
– договориться, какие метрики действительно важны;
– объяснить и согласовать подход к расчёту метрик и их влияния;
– сделать саму иерархию прозрачной.

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

3️⃣ Слишком большое дерево. Как писал выше, на моей практике 4-5 уровней было достаточно. Главное идти до того уровня, где на отдельные метрики уже реально можно влиять через проведение тестов, экспериментов, изменения в продукте.

4️⃣ Дерево метрик не обновляется. В IT всё очень динамично: измениться может что угодно — от стратегии компании до модели монетизации продукта или каналов привлечения пользователей. Конечно, такие изменения должны отражаться и в дереве метрик.

На этом у меня всё. Спасибо за внимание 🙌

Когнитивные искажения в IT и как их обходить 🧠

Многие уже знакомы с наиболее известными когнитивными искажениями – эвристикой доступности, эффектом якоря и предвзятостью подтверждения. Если же вы о них ещё не слышали, советую заглянуть в мой пост для канала Yandex for Products. Сегодня хочу продолжить разговор о когнитивных искажениях и поделиться пятью не менее важными, но куда реже обсуждаемыми искажениями, с которыми часто сталкиваются в IT.

Ошибка атрибуции 🏆
Мы склонны объяснять свои успехи личными достоинствами, а свои неудачи – внешними обстоятельствами. Для чужих успехов и неудач – всё наоборот.

Мой провал → помешали обстоятельства
Провал другого человека → свойства личности

Как проявляется в ИТ:

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

Как снизить влияние:
Техника 5 Why, чтобы сместить фокус свойств личности на факты и причинно-следственные связи.

Эффект Хиндсайта 🔮
Люди склонны воспринимать уже произошедшие события или подтверждённые факты как очевидные для них. Также этот эффект известен как знание задним числом.

Как проявляется в ИТ:

«Я же говорил, что эксперимент не взлетит», хотя изначально прогнозов не было или они были противоречивыми.

Эффект хиндсайта базируется на трёх опорах:
1⃣ Искажение памяти – мы вспоминаем свои прежние оценки и мнения как более близкие к реальному исходу, чем они были: «Я говорил, что это произойдёт»
2⃣ Иллюзия неизбежности – после факта цепочка причин выглядит единственно возможной, а альтернативы кажутся маловероятными или несущественными: «Это должно было случиться»
3⃣ Иллюзия предсказуемости случившегося – убеждение, что исход можно было увидеть заранее, будто признаки были очевидны: «Я знал, что это произойдёт».

Как снизить влияние:
1. Ведите журнал прогнозов: формулируйте гипотезы заранее с вероятностями и сроками, потом сверяйте точность. См. HADI-циклы
2. Признайте сильное влияние случайности и вероятности

Непринятие потерь 😨
Люди склонны придавать большую важность потенциальным потерям, чем эквивалентным приобретениям.

Как проявляется в ИТ:

«Не будем трогать монолит продукта – вдруг всё сломаем», хотя текущая скорость работы уже тормозит развитие.

Как снизить влияние:
1. Считайте Сost of Delay: что мы теряем, ничего не меняя?
2. Соотносите ожидаемую ценность (expected value) с тем, что вы можете потерять.

Искажение оптимизма 😎
Люди склонны недооценивать вероятность негативных исходов для себя и своей команды по сравнению с другими.

Как проявляется в ИТ:

«У нас стабильная платформа, инцидентов не будет», хотя алерты не покрывают продукт целиком.
«Мы точно успеем к концу квартала», при этом игнорируются зависимости от внешних команд.

Как снизить влияние:
1. Осознайте свою предвзятость через сверку и фиксацию расхождений между вашими планами и фактами.
2. Проводите Ретро в команде правильно: отмечайте, что помогало, усиливайте это; выявляйте, что мешало, и ищите решения.

Ошибка планирования ⏳
Излишняя самонадеянность и недооценка всех факторов, которые могут сыграть против вас. Тесно переплетается с искажением оптимизма.

Как проявляется в ИТ:

«Эта интеграция по API займёт неделю», а выходит на 3 недели из-за доступов, тестовых стендов, миграций.

Как снизить влияние:
1. Сверяйте свои прогнозы и факт, анализирутйе расхождения
2. Закладывайте буферы, а сверка прогноза и факта позволит вам понять насколько вы промахиваетесь
3. Продумывайте и оценивайте риски
4. Просите коллег почелленджить ваш план

Как придумать продукт по методологии CRAFT 💡

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

Возьмём, например, YouTube: пользователи получают персонализированный и увлекательный контент, а платформа монетизирует часть этой ценности через рекламу во время просмотра.

Как продакт может генерировать такие сильные идеи? Один из вариантов – это методология CRAFT, разработанная в ИКРЕ. В основе методологии – поиск новых способов изменения взаимодействия между человеком и продуктом. Разберём пошагово, как применить CRAFT на практике.

1️⃣ Фокусировка

Можно сфокусироваться через мотивы и барьеры – такая формулировка называется инсайт:
– Мотив: зачем человеку это нужно
– Барьер: что мешает это получить
– Конфликт между ними = точка входа для новой идеи

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

2️⃣ Поиск фреймов и гора идей

– Берём фреймворк Компас фреймов
– В каждой части круга придумаем фреймы, в которых проблема пользователя уже решена
– Выберем топ-3 фрейма, которые нам кажутся наиболее перспективными
– Опишем каждый из них на конкретные продуктовые составляющие. Можно сделать это в фреймворке ИКРЫ
– Выберем один фрейм, который в большей степени нам подходит

Разовьём наш пример со TrueLocal. Инсайт – люди как бы проживают чужую жизнь, узнают жизненные истории о памятных местах и событиях. Можно вбырать фрейм разговора дедушки со внуком: когда в деревню к дедушке приезжаешь, у него найдется целый ворох таких историй из молодости (как качался на этой яблоне, как упал с той колокольни и т. д.).

3️⃣ Проработка механик

Углубим разработку выбранной идеи.

TrueLocal – мобильное приложение для персонализированных маршрутов и локального опыта по всему миру. Оно анализирует интересы пользователя (кухня, культура, природа, ночная жизнь и т. д.) и формирует маршруты путешествий по нетуристическим местам с экскурсиями, с рассказами от старожилов этих регионов. Это и есть то самое погружение, которое ожидала целевая аудитория.

4️⃣ Проверка гипотезы

А вот и подошло время для теста. На этом шаге создадим прототип цифрового решения, я в последнее время использую Lovable, из альтернативных – Marvel или Figma. Затем найдем аудиторию, которая протестирует наше решение и даст нам обратную связь, вариантов тут много – это может быть как решенческое интервью, так и немодерируемое UX-исследование

5️⃣ Доработка решения

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

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

6️⃣ Дальнейшие шаги

Если прототип успешно прошёл проверку, стадия Discovery завершается, время переходит к Delivery, но в начале нужно полноценно проработать будущий продукт и подготовить PRD, об этом я уже писал в другом посте

Основные UX-законы, которые стоит знать продакту

Десять эвристик Якоба Нильсена, основатель компании Nielsen Norman Group

1️⃣ Видимость состояния системы
Пользователь всегда должен понимать, где он сейчас, что только что сделал и что будет дальше. Нильсен говорил: «Хороший интерфейс, как хороший собеседник».
Примеры: индикатор загрузки, сообщение о том, что действие выполнено.

2️⃣ Соответствие системы реальному миру
Интерфейс должен говорить на языке пользователя, а не на техническом. Чем ближе его логика привычным действиям в реальной жизни, тем проще людям понять, что делать.
Примеры: иконки-метафоры (корзина, лупа), цифровые процессы, которые повторяют реальные.

3️⃣ Контроль и свобода пользователя
Возможность отменять или повторять действия даёт пользователю контроль над процессом. Люди часто ошибаются, и интерфейс должен позволять быстро исправить эти ошибки.
Примеры: кнопки «Назад» и «Повторить», подтверждение действий, автосохранение, возможность заполнять формы в любом порядке.

4️⃣ Консистентность и стандарты
Одни и те же элементы должны выглядеть одинаково, называться одинаково и работать по одним и тем же правилам во всём продукте. Это снижает нагрузку на мозг и делает продукт предсказуемым.
Примеры: одинаковые кнопки «Сохранить» в разных разделах, единые UI-гайдлайны на уровне продукта и платформы.

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

6️⃣Распознавание вместо вспоминания
Распознавание – это когда интерфейс показывает пользователю, что делать. Запоминание – когда приходится вспоминать самому. Второй вариант сложнее и медленнее. Поэтому не заставляйте людей держать в голове то, что можно показать на экране. UX-дизайн должен упрощать жизнь, а не усложнять её.
Пример: выпадающие подсказки вместо ввода с нуля, автозаполнение, история действий.

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

8️⃣ Эстетичный и минималистичный дизайн
Интерфейс должен быть свободен от лишней информации, чтобы пользователь мог сосредоточиться на своих задачах. Красивый и аккуратный дизайн создаёт приятные эмоции и мотивирует взаимодействовать с продуктом (думаю сделать отдельный пост про эстетичесикй интеллект).
Примеры: «воздух» между элементами, лаконичные и легко читаемые шрифты, цветовые акценты.

9️⃣ Помощь пользователям с ошибками
Если пользователь сделал ошибку, интерфейс должен сразу показать проблему и предложить, как её исправить.
Примеры: визуальная обратная связь, указание места ошибки, понятные подсказки вместо кодов ошибок (401, 404 и т.д.) с инструкциями, что делать дальше.

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

ℹ️ Эвристики Якоба Нильсена – это не строгие правила, а удобный набор ориентиров для продакта при оценке интерфейса

Кстати, некоторые из них перекликаются с принципами Дональда Нормана из книги The Design of Everyday Things (рекомендую к прочтению):
▪️Affordance – форма элемента подсказывает, что с ним можно взаимодействовать.
▪️Feedback – система всегда отвечает на действия пользователя.
▪️Mapping – логичное соответствие между управлением и результатом.
▪️Constraints – ограничения помогают избежать ошибок.

OKR без воды: руководство из личного опыта

OKR (Objectives & Key Results) – это, пожалуй, самая популярная система целеполагания и отслеживания прогресса, которую используют такие компании как Google, Intel, Microsoft и многие другие ИТ-лидеры.

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

Успешные OKR – это результат сочетания инициатив сверху от C-Level и снизу от команд. Такой подход позволяет всем влиять на то, что действительно стоит времени и усилий.

В начале работы с OKR ответьте всего на два вопроса:
▪️Куда я хочу прийти? Ответ на этот вопрос – ваша цель (Objective).
▪️Как я буду отслеживать прогресс на этом пути? Это ваши ключевые результаты (Key Results).

1⃣ Objectives

CEO и CPO определяют цели на уровне всего продукта и компании. Обычно, цели базируются на стратегии, возможностях и угрозах бизнеса, ожиданиях акционеров.

Цели в OKR специально делают амбициозными, они должны вдохновлять и мотивировать команду, и, что важно, притягивать сильных специалистов. В Google, например, считают успехом, если достигнуто около 70% цели, а полное выполнение уже выдающийся результат. Хорошая цель не решается простой работой по накатанной, чтобы её достичь нужно реально постараться.

Рекомендации по формулировке Objectives
– Определите 3-5 целей, не больше. Если их слишком много, это сигнал расфокуса и потенциальной потери эффективности
– Избегайте формулировок типа «продолжать…», они не вдохновляют команду
– Используйте яркие, осязаемые формулировки, например, «запустить продукт X», «запустить функциональность Y»
– Используйте простые и понятные термины, стороннему человеку должно быть понятно, достигнута цель или нет

📣 Важно: OKR не используют для оценки сотрудников, потому что их главная задача не контроль, а мотивация и фокус на амбициозных целях. Если же привязать выполнение OKR напрямую к зарплате или бонусу, люди начнут ставить себе слишком лёгкие цели, чтобы гарантированно получить хорошую оценку.

Примеры:
Запустить новую монетизационную модель, чтобы увеличить выручку от продукта
Запустить международную версию продукта

2⃣ Key Results

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

Рекомендации по формулировке Key Results
– Определите около 3 KR на каждую цель
– Только измеримые показатели
– Описывайте результат, а не процесс
– Используйте «шкалу амбиций», на моей практике это были следующие уровни: base (ожидаемый результат) – stretching (амбициозный результат) – outstanding (выдающийся результат)

Примеры:

Objective: Запустить новую монетизационную модель, чтобы увеличить выручку от продукта
KR1: Конверсия в оплату выросла с 3% до 4,5%
KR2: Средний чек увеличился с 250₽ до 300₽
KR3: Запуск и внедрение двух новых платных функций до конца квартала

Objective: Запустить международную версию продукта
KR1: Локализовано приложение на 3 новых языка
KR2: Запущена платёжная интеграция для 3 новых стран
KR3: Получено 1 000 новых пользователей в каждой новой стране за 2 месяца

7 правил эффективных OKR
1. Objectives: амбициозные, заставляющие выйти из зоны комфорта
2. KR: измеримы в числовом выражении, про результат, а не процесс
3. OKR прозрачны для всей компании
4. Оптимальное выполнение 70%
5. Если вы постоянно достигаете целей, то они недостаточно амбициозны, вам нужно мыслить масштабнее
6. Низкое выполнение OKR помогает корректировать будущие OKR
7. OKR не используются для оценки сотрудников

Напоследок: OKR не единственная система целеполагания, по которой мне доводилось работать, были и SMART, и KPI и другие системы, о тонкостях работы c которыми расскажу в другой раз 👨‍💻

8 паттернов эффективной работы с AI 🤖

AI усиливает, ускоряет работу, но вникать, думать, принимать решение и нести за него ответственность всё равно должен продакт. И здесь на первое место выходит даже не то, какими инструментами, моделями вы пользуетесь, а то, как вы ими пользуетесь.

Чем опасно полное делегирование мышления 🚩
1. Снижение уровня критического мышления и логики.
2. Потеря навыка принятия решений, т.е. вы начинаете принимать готовые ответы, а не думать.
3. Формирование зависимости от AI.
4. Снижение качества вашей работы за счёт шаблонизации и ошибок из-за галлюцинаций моделей.

Свой подход к работе с AI я выработал, опираясь на:
1. Понимании чёткой цели, что мне нужно от AI, без цели даже лучшая модель даст бесполезный результат. Как говорил римский философ и стоик Сенека: «Для корабля, который не знает, в какую гавань ему идти – ни один ветер не будет попутным».
2. Осознание слабых мест моделей: возможность галлюцинаций, ограниченный объём хранимого контекста, недетерминированность ответов и ограниченную актуальность данных, на которых модель обучалась (не все могут в RAG).
3. Чётком понимании: во-первых, что я могу и хочу делегировать, а что оставляю за собой; во-вторых, факт-чекинг – это must have.

Эффективные паттерны работы с AI:

1️⃣ Критический анализ. Если у меня уже есть решение, прошу модель стать моим оппонентом: указать слабые места и предложить способы улучшения. Это помогает выявить риски и недочёты, которые я мог не заметить. Advanced-level: прошу провести анализ от лица разных ролей – разработчика, дизайнера, финансиста, юриста, безопасника. Такой подход значительно повышает качество финального решения, но важно грамотно задать роли.

2️⃣ Самопроверка и кросс-валидация. Прошу нейросеть перепроверить свой же ответ: оценить степень уверенности, сформулировать проверочные вопросы и затем задать их ей. Advanced-level: задать одну и туже задачу нескольким нейросетям, и, затем устроить кросс-проверку их ответов.

3️⃣ One/few-shot. Когда задаю запрос, сразу привожу 1-2 хороших «пристрелочных» примера так модель лучше понимает направление и попадает ближе к нужному результату.

4️⃣ Chain of Thought. Обычно модели дают готовый ответ, но я же прошу их проговаривать промежуточные шаги «шаг за шагом». Да, это занимает больше времени, но повышает прозрачность и контроль, что важно в сложных задачах.

5️⃣ Декомпозиция задачи. Да, современные reasoning-модели могут сами разложить задачу на части. Но в сложных кейсах важно держать руль, сам задаю логику и структуру, а нейросети поручаю выполнение отдельных подзадач. Так сохраняю контроль и качество результата.

6️⃣ Доработка запроса. Помогает, когда я не до конца не уверен в грамотной постановке задачи, то прошу нейросеть саму уточнить или дополнить мой исходный запрос.

7️⃣ Отдельные чаты по задачам: история чата влияет на ответы нейросети – разнос контекстов помогает это преодолевать.

8️⃣ Время на подумать. Использую такой запрос: «Прежде чем отвечать, пожалуйста, тщательно поразмышляй над этим вопросом. Рассмотри различные факторы, которые могут влиять на ответ, потенциальные ограничения и все возможные подходы, прежде чем рекомендовать лучшее решение».

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

Servant Leadership 👤

Существует множество стилей лидерства, например:
– По степени контроля: авторитарный (директивный) и демократичный (коллаборативный);
– По мотивации: транзакционный («Ты мне – я тебе») и трансформационный (вдохновляющий, мотивирующий);
– По подходу к людям и EQ: ситуативный и служащий (servant).

Сегодня я хочу подробнее остановиться на последнем стиле – лидерстве-служении, Servant Leadership. На мой взгляд, этот стиль может подходить для многих продактов в ИТ.

И вот почему:

1️⃣ Продакт – не начальник, зачастую, у него нет формальной власти над командой, но за бизнес-результат он отвечает. Подход здесь - вдохновлять и мотивировать команду работать над продуктом, который создаст бизнес-результат.

2️⃣ Фокус продакта на эффективном решении задач пользователя. Servant Leader глубоко понимает нужды своей команды и помогает реализовать их потенциал – как продакт помогает решать задачи пользователей.

3️⃣ Задача продакта – устранять организационные препятствия для команды, он создает условия для эффективной работы, что близко к идее Servant Leadership: лидер делает всё, чтобы команда могла делать свою работу эффективно, вместо того чтобы навязывать решения сверху.

4️⃣ Продакт фокусироваться на стратегическом успехе продукта, так же, как и лидер в Servant Leadership настроен на построение крепкой команды, которая сплочённо будет работать вместе.

Термин Servant Leadership ввёл в 1970-х американский консультант Роберт Гринлиф. Сегодня этот стиль лидерства применяют в Microsoft, Google, Starbucks, Marriott, Patagonia, Southwest Airlines и других компаниях. Почему так? Исследования показывают: этот лидерский стиль повышает лояльность и производительность команд, что отражается и в росте ценности продукта, что в свою очередь влияет на уровень счастья конечных пользователей.

Если обратиться в поп-культуру, то мой любимый персонаж в стиле Servant Leadership – Тед Лассо из одноименного сериала:
• Он создаёт среду доверия, где игроки команды не боятся ошибиться, а учатся на ошибках.
• Он мотивирует через поддержку и пример, а не угрозы или наказания
• Он не командует авторитарно, вместо этого он узнаёт каждого игрока, понимает их страхи и сильные стороны.

Как продакту на практике применять Servant Leadership?

1️⃣ Устранять барьеры. Помогайте команде фокусироваться на работе: решайте вопросы с доступами, ресурсами, координацией между командами и с партнерами. Представляйте и защищайте интересы команды перед стейкхолдерами. При этом продакт не должен давать возможность сесть себе на шею, тут есть тонкая грань.

2️⃣ Создавать безопасное пространство для вопросов, открытого обсуждения идей, ошибок и полученных уроков.

3️⃣ Вовлекать команду в принятие решений. Лучшие решения те, к которым команда приходит сама и в которые искренне верит.

4️⃣ Активно слушать. Не перебивайте, не додумывайте за других, не спешите с выводами. Это создает доверие и снижает напряжение.

5️⃣ Управлять эмоциями, особенно в стрессовых ситуациях. Саморегуляция делает продакта якорем спокойствия в хаосе и это усиливает его лидерство. Будьте примером.

6️⃣ Давать конструктивный feedback, который вовлекает в поиск решения («Да, и»), а не давит («Да, но»).

7️⃣ Проявлять эмпатию. Не гасить эмоции других, но признавать их. Важно не просто включать «эмпатичный» тон и фразы, команда считает эту фальш, но действительно проявлять эмпатию.

Вместе с тем, Servant Leadership – это не универсальный инструмент, он подойдёт не для всех коллективов и компаний. И если вы хотите глубже и лучше разобраться в теме управления командами, то подписывайтесь на канал моей коллеги Ангелины Зинченко – «Управляй этим!».