По-настоящему сильные продукты: взгляд жюри 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 – это не универсальный инструмент, он подойдёт не для всех коллективов и компаний. И если вы хотите глубже и лучше разобраться в теме управления командами, то подписывайтесь на канал моей коллеги Ангелины Зинченко – «Управляй этим!».

Yandex Cup: реальный шанс попасть в Яндекс 👨‍💻

Один из самых частых вопросов, с которыми ко мне обращаются новички – а как попасть в Яндекс? Уверен, что многие уже слышали про стажировки Young&&Yandex, но сегодня я к вам с другим предложением - Yandex Cup 🏆

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

⚫️Важно, что можно выбрать своё направление – фронтенд, бэкенд, ML, аналитика и другие. Есть и отдельный поток для юниоров, в котором можно участвовать уже с 14 лет
⚫️Финал состоится в Стамбуле. Туда отправятся 180 сильнейших и это возможность для мощного нетворкинга и соревнования лучшими из лучших
⚫️Самые сильные смогут попасть в Яндекс по fast-track
⚫️Конечно, кроме классного опыта (который украсит ваше резюме), поездки в Стамбул и возможности попасть в Яндекс, будет и денежные приз от 100 до 500 тысяч руб., а общий фонд - 12 миллионов руб.

📆 Заявки на участие принимаются до 29 октября

📝Если вы любите программировать – не упустите шанс и подавайте заявку

Из чего состоит работающая Go-To-Market стратегия ⚙️

Go-To-Market – это стратегия вывода продукта на рынок, которая, отвечает на четыре вопроса:

– Что: какую проблему решает продукт, в чём его ценность.
– Кто: в каких целевых сегментах ценность нашего продукта превосходит доступные и известные пользователям альтернативные продукты.
– Где: через какие каналы коммуникации мы сможем эффективно «дотягиваться» до целевой аудитории.
– Как: мы привлекаем клиентов, как у нас выстроены продажи и монетизация, какая у нас бизнес-модель.

Разберём подробно из чего состоит GTM стратегия 🧩

1️⃣ Целеполагание
Как и любая стратегия, нам нужно определиться, где мы находимся сейчас (точка А), куда мы хотим прийти (точку B), каким именно способом мы пройдём этот путь, как будем измерять наше движение и достижение цели. Также продумайте сроки реализации GTM, как минимум, они должны быть согласованы всеми участвующими командами.

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

3️⃣ Целевой сегмент
Выделите целевой сегмент пользователей, для которых именно ваш продукт создаёт наибольшую добавочную ценность, относительно конкурентов (Product/Market Fit). Важно, чтобы добавочная ценность была действительно значимо больше (в идеале ×10 раз). Про описание целевого сегмента – см. пост про Метод Персон, а про ценность продукта – про Switching Model.

4️⃣ Ценностное предложение и модель монетизации
Сформулируйте, какую конкретно задачу решает продукт, причём простыми словами, понятными пользователям из вашего целевого сегмента. Подумайте, почему они будут выбирать ваш продукт, а не продукт конкурентов (вы быстрее, дешевле, удобнее, надёжнее). Продумайте как вы будете монетизировать ценность вашего продукта, какая у вас будет модель монетизации.

5️⃣ Воронка / Путь пользователя
Опишите путь вашего пользователя от первоначального интереса, изучение разных продуктов, выбор и тестирование вашего продукта, прохождения онбординга, активации, достижение a-ha-момента и покупки. Для описания пути пользователя можно воспользоваться CJM, Лестницей Ханта, AIDA, для воронок подойдёт фреймворк AARRR. Есть ещё интересный подход Consumer Decision Journey, про который сделаю отдельный пост.

6️⃣ Модель дистрибуции
Прорабатываем модель дистрибуции, каналы коммуникации и креативы. На первой итерации сфокусируйтесь на 2-3 каналах, через которые вам проще всего «дотянуться» до вашей аудитории. Подготовьте креативы, сделайте тестовые закупки трафика, оцените стоимость привлечения (CAC) и соотнесите её с потенциальным LTV, проанализируйте точки отвала пользователей. Из инструментов здесь будут полезными – когортный анализ и анализ воронок. На старте не стоит тестировать много каналов, повторюсь, что лучше выбрать 2-3, итерационно искать те, которые работают в рамках вашей unit-экономики.

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

Важно, что GTM должна быть гибкой: скорее всего, не всё сработает с первого раза, нужно быть готовым сделать несколько итераций пока вы не найдёте устойчивую конструкцию – либо на одном из уровней (продукт, целевой сегмент, каналы продвижения, модель монетизации) либо на нескольких сразу. А в следующем посте цикла разберём основные виды GTM-стратегий. Stay Tuned 🙌