Как в Amazon отказались от PowerPoint

В Amazon смогли воплотить мечту многих продактов – отказ от PowerPoint на встречах 🙃 Вместо бесконечных слайдов участники начинают с того, что молча читают заранее подготовленный документ Six Pager.

Как проходит «документоцентричное совещание»:
1. Подготовка. Документ рассылается участниках встречи заранее.
2. Тихое чтение ≈ 20-30 мин. За это время можно внимательно проанализировать 6 страниц, поэтому объём документа ограничен именно этим. Остаток встречи (30-40 мин) отдают обсуждению.
3. Обсуждение. Либо высказывается каждый, либо автор проходит по разделам и собирает обратную связь. Отдельно отмечу практику disagree & commit – можно не соглашаться с идеей, но поддержать её реализацию, если команда решила двигаться вперёд.
4. Фиксация итогов в документе, с общим доступом для всех участников.

Почему именно текст, а не слайды?
– Глубина. Слайды часто поверхностны, а текст подталкивает анализировать и вникать в суть.
– Логика. Письменная форма подталкивает к простым и понятным формулировкам и прозрачным причинно-следственным связям, подбору аргументов, подкрепляющих тезис.
– Single version of the Truth. Все получают одинаковый, полный документ, без когнитивных искажений за счёт оформления или питчинга.

Такой подход в Amazon ещё называют «замедление ради ускорения» 🐢🐆

Структура Six-Pager

Документ – это, прежде всего, связанная история. Конечно, в нём могут присутствовать списки с тезисами (tenets), но все они поясняются развернутыми предложениями. Иначе вместо рассказа мы получим PowerPoint, просто переупакованную в Word.

Документ может принимать разные формы, но предлагаю обратить внимание на эту структуру:

1️⃣ Введение (½ - 1 стр)
Простое объяснение про что Six Pager, причём даже для тех, кто не знаком с предметной областью.

2️⃣ Цели (½ стр)
Описывается, как будет выглядеть успех с точки зрения метрик: метрика сейчас → метрика в будущем → срок.
Важно: это отправная точка для всего документа. Если кто-то не согласен с этим утверждением, проще обсудить его напрямую, чем далее разбирать все аргументы, которые его поддерживают.

3️⃣ Принципы (½ стр)
Стратегические идеи, которые лежат в основе вышеизложенного решения.

4️⃣ Состояние бизнеса (1 стр)
Подробная и честная картина текущего положения дел, с точки зрения реализации стратегических целей.

5️⃣ Полученные знания (½-1 стр)
Описываем сложности и неудачи, с которыми сталкивались в прошлом и что хорошо сработало. Подкрепляем данными. Честно и откровенно.

6️⃣ Стратегические приоритеты (2-3 стр)
Это ключевая часть Six Pager, по сути это детальный план действий, как вы планируете достичь выше обозначенных целей. Важно, чтобы план действий и исходный тезис были связны.

7️⃣ Приложения
Таблицы, графики и всё то, что поддерживает выдвинутый вами тезис и аргументы в его поддержку

Six Pager – это не просто альтернатива слайдам, а инструмент, который меняет культуру обсуждения проектов и продуктов, провоцируя глубокое, осмысленное обсуждение ценой более тщательной проработки на старте

Что делает продакта настоящим лидером 🤔

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

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

На моей практике оптимальный подход здесь – это занять лидерскую позицию.

Лидерство в роли продакта

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

Как это проявляется на практике:
1️⃣На старте проекта – сформулировать смысл и цель прежде всего для себя, а затем донести это до команды: вдохновить, объяснить, зачем мы идём в эту сторону (здесь нужны навыки и инструменты сторителлинга).
2️⃣В процессе работы – убирать барьеры, решать проблемы, слушать и поддерживать. Создавать процессы и среду, в которых команда может показывать максимум результата (здесь отлично работают модели Servant Leadership, Co-active Leadership Model, о них думаю написать отдельно).
3️⃣В кризисных или нестандартных ситуациях – лидер будет последним, кто отступит, лидер будет продолжать упорно искать способы решения. Самомотивация, устойчивость, выносливость в работе менеджера, может быть примером, который позволит команде не опускать руки.

Лидер ≠ должность
Лидер – это не роль в оргструктуре, а человек, которого команда готова слушать. Именно хороший менеджер делает из коллектива разработчиков, дизайнеров, аналитиков слаженную продуктовую команду.

Альтернатива?
Конечно, можно ограничиться операционным, менеджерским уровнем: просто описывать PRD и распределять задачи по спринтам, планировать и приоритизировать бэклог фичей. Команда при этом будет просто писать код и выкатывать его в прод.

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

Такая отрицательно раскручивающаяся спираль «фабрики фичей».

Как вы могли уже заметить, один из ключевых компонентов лидерской позиции – это умение мотивировать и вдохновлять команду. В этой теме много нюансов и практических приёмов, о которых хорошо рассказала моя коллега в ❤️ – Женя Кадомец в своём канале Карьера, тренды и котики. Если вы хотите в этом по-настоящему разобраться читайте пост и подписывайтесь на канал Жени – у нее много полезного про то, как руководить командами, строить карьеру и не только – будет интересно 🙌

Какие практики ведения проектов выделяют хорошего менеджера? 📖

К своему стыду, я редко нахожу время на чтение книг, в т.ч. и на профессиональную литературу. Но книгу Егора Ганина «Как приготовить проект» я всё-таки прочитал. И вот почему.

Егор – известный эксперт в узких кругах российского IT. В Яндексе он отвечал за Почту, а в VK – за Облака. Мне было особенно интересно изучить его менеджерский опыт, ведь сам я в этой сфере уже более 13 лет.

Интересно, что книга совсем небольшая, но плотность информации в ней – высокая. Условно для себя я разделил её на две части:
– Роль менеджера в IT;
– Авторская методология ведения проектов.

В первой части книги Егор рассказывает, что отличает хорошего менеджера, от backlog holder и передатчика информации. Менеджмент – это не просто набор правил Kanban, Agile, Waterfall, а система принятия решений. Причём менеджер в этой системе должен накапливать знания и аккумулировать экспертизу, чтобы 2-5-10 проекты качественно отличались.

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

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

1️⃣ Умение вникать. «Услышать и передать не тоже самое, что услышать вникнуть и передать».

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

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

2️⃣ Умение планировать. «Цель без плана – мечта. Постановка цели – это половина успеха». Если менеджер поставил и запланировал задачу, именно он отвечает за её выполнение. Важно, что чем дольше и дальше мы движемся по проекту, тем сложнее нам сохранять объективность из-за туннельного мышления и других спецэффектов мозга.

3️⃣ Умение организовывать. Обеспечивать прозрачность и предсказуемость процессов – это одна из главных задач, на решение которой нанимают менеджера. Не менее важна системность: день за днём, неделю за неделей повторять одни и те же действия, не теряя оптимизма. Настоящий менеджер остаётся последним, кто не отказывается от проекта, продолжая искать способы его реализации. Его сила в умении сохранять энергию, не поддаваться унынию и обеспечивать движение команды вперёд.

4️⃣ Умение контролировать. Осознанный менеджер отвечает за всё: за себя, за команду, за проект, сроки, встречи, обещания, запуски и сбои. При этом умение признать вину и ответственность за некачественный результат снижает шансы повторения ошибки и повышает стоимость менеджера на рынке труда. Хороший менеджер не ограничивается тем, чтобы просто констатировать срыв сроков. Он разбирается в причинах, выявляет узкие места и предлагает решения.

Контроль – это ещё и умение находиться в «суперпозиции»: одновременно быть внимательным к деталям и при этом видеть общую картину проекта. А проактивность и инициативность позволяют выявлять и устранять проблемы ещё до того, как их заметят остальные.

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

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

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

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

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

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

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

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

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

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

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 – ограничения помогают избежать ошибок.