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

Поэтому в следующее воскресенье 4го февраля с 17 до 19мск проведу стрим про системное мышление, инструменты и как его тренировать. Расскажу как я уже почти 20 лет лично применяю его в жизни и управлении компанями: B2С - App in the Air, B2B - RuBeacon, Life in the Air), консалтингового бизнеса - Empatika в далекие 2010е.

Ключевые темы:
- Системное мышление как мировозрение
- Диаграммы обратной связи
- Системная динамика как инструмент сценарного планирования компании
- Системная модель мобильного приложения на примере App in the Air
- Системная модель консалтинговой компании на примере Empatika
- Системная модель b2b компании на примерах Life in the Air и RuBeacon

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

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

Покупаем билет тут: стартовая цена $20 (1800 руб), будет подниматься каждые 24 часа на $5. Оплатить можно зарубежной и российской карточками. До встречи!

Продолжаем качать эмпатию:
Как-то давно прочитал у Дэниела Пинка про упражнение по развитию эмпатии: придумывать истории людей вокруг. Например, сидите в баре и наблюдаете человека в дальнем углу, который потягивает виски. Кто он? Какой был его день? Почему он сейчас в баре? Он ждет кого-то или в одиночестве? Он методично свайпает что-то в телефоне или задумчиво смотрит куда-то? Какой виски? Как быстро он пьет? И тд и тп, you get the drill

Думаю, что это прикольная техника, но с ней есть одна засада: скорее всего вы будете-таки проецировать свои мысли и ситуации на него. Можно ли, не спрашивая этого человека, "расширить" пространство мыслей и историй для этого человека? Я знаю несколько:
1) Художественная литература - считаю писателей людьми, у которых очень выражена эмпатия, поэтому им удается так детально описывать чувства и переживания своих героев, и мы угадываем в них себя и своих близких, поэтому нам нравятся их работы. Кстати, необязательно fiction литература, автобиографии, интервью и сочинения тоже хорошо показывают перспективы других людей.
2) Фильмы - то же, что и 1, но менее "красочно", но зато и менее трудозатратно. Кто-то поспорит про "красочно", думаю это субьективно, просто у меня образы при прочтении книги получаются сильно более интересными для меня. Кстати, посмотрите фильм "Расёмон", его просматривают на курсах по психологии в Стенфорде как пример разнообразия вглядов людей на одну и ту же ситуацию.
3) Путешествия - у Марка Твена есть такая цитата:

Travel is fatal to prejudice, bigotry, and narrow-mindedness, and many of our people need it sorely on these accounts

Как-то рассуждали с подругой о том, что опыт проживания в разных культурах - интересный маркер при найме сотрудников

Ну и, в зейтгест проникновения AI во все аспекты нашей жизни, конечно же поспрашивайте chatgpt по теме. В комментариях к посту выложу пару скриншотов по теме

Как-то давно прочитал про adjacent users theory VP Growth из Instagram & Instacart, и мне оно показалось суперрелевантным для этапа, когда видишь замедление роста в ключевом сегменте пользователей. Cуть теории заключается в том, чтобы представить всех своих юзеров в виде некоторых кластеров по уровню активности в продукте, и методично развивать продукт и маркетинг в сторону менее активных пользователей, так как возможности ядра уже исчерпаны. В комментарии - картинка для Instagram.

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

Как систематически находить такие группы?
1) Делаем кластерный анализ пользователей с учетом их ретеншна и смотрим, каковы центры каждого кластера.
2) Делаем customer interview кластеров, наиболее близких к ядру аудитории, но недотягивающих. Приоритезируем их по размеру и возможностям достучаться до них. К примеру, в App in the Air ядром были частолетающие пассажиры, которые подключили почту и календарь, а ajdacent - люди, которые любят путешествовать и ставят задачей посетить все страны мира. Еще важной, но недостаточно большой аудиторией были стюардессы и пилоты
3) Генерируем фичи и мессаджи с учетом проведенных интервью: для adjacent users в App in the Air важнее были фичи вокруг статистики и соревнования, нежели core функционал по менеджменту твоих путешествий. Хороший пример - вот это выступление Артемия Лебедева, где он в течение всего рассказа фоном показывает карту своих перелетов, сгенерированную нашим продуктом.
4) Тестируем мессаджи и фичи на предмет сдвига ретеншна в те же границы, что и core аудитория.
5) Если нашли такую - концентрируем усилия продакт и маркетинг команды на этой аудитории, пока не будет то же, что и с core.

Основной риск этого подхода, что core аудитория может начать жаловаться и уходить из продукта. Следует:
а) внимательно отслеживать их параметры, не потерять из вида
б) если возникает системное различие в поведении (core - активно уходит, а adjacent - активно приходит), то выбираем одну из них. Может даже, разделяем продукты на 2 отдельных продукта.

Удачи!

P.S. Хотите покрутить применение этой теории к вашему кейсу - велком на консультацию

Проблема vs Функция

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

Я в свое время писал про кейс про курение, но еще парочка для закрепления:
1) Высокая цена или иной барьер для пользования продуктом является эффективным фильтром, то есть остаются самые замотивированные --> хорошие показатели монетизации и ретеншна. Убирая эти барьеры, у вас просядет куча метрик + появится много "шума", мешающего разобраться и сконцентрироваться на важной аудитории. Недавно как раз обсуждали с предпринимателем про onboarding и важность снижения уровня шума на первых стадиях продукта. Я про это рассказывал в этом выступлении на Epic Growth
2) Недостаток supply в маркетплейсе может давать повышенный заработок текущим поставщикам; как компенсировать эту функцию при прокачивании supply?
3) Нехватка ресурсов в стартапе заставляет команду концентрировать усилия, более тщательно выбирать гипотезы для тестов - что будет, если ресурсов станет сильно больше? "Stay hungry, stay foolish" как завещал Джобс

Внимательно: я не говорю, что не надо устранять проблемы. Я говорю, что размышляя о проблеме, надо не забыть про функции и про то, что восполнит эти функции. Можно и наоброт: если есть полезная функция, то какую проблему она создает? К примеру, это ключевой фрейм Кристенсена в Дилемме Инноватора: именно потому что incumbent концентрируется на своих самых прибыльных клиентах и внедряет инновации, которые помогают им делать это лучше, он фильтрует подрывные инновации.

Отсюда совет: при решении очередной проблемы потратьте лишние 15 мин команды, чтобы подумать про полезные функции.

P.S. Это, кстати, хороший пример системного мышления, о котором говорим в это воскресенье

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

Буду очень благодарен за ваш фидбек (на каждый ответ бота можно ставить лайк или дизлайк).

🛑ВАЖНО: все вопросы сейчас логируются и будут читаться нашей командой для улучшения работы бота, поэтому не передавайте плиз конфиденциальные данные. В будущем, мы снимем это ограничение.

Для старта просто пройдите по этой ссылке

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

Я думаю про работу CEO в стартапе как работу с неопределенностью: внимание должно быть сконцентрировано на неопределенности. На этапе pre-PMF это одно, growth - другое. Внимание по определению ограничено, поэтому нужно выбирать чему его посвящать, а уровень неопределенности - идеальный критерий для этого. Причем же тут “моделирование”? Зачем мне прикидывать, как мы будем достигать GMV? Как раз, чтобы правильно распределить свое внимание. Чтобы “упереться” в невозможность “выйти на окупаемость за 12 месяцев” и включить креативность всей команды на то, а как же таки этого достичь? Именно здесь важна иерархия метрик, о которой я писал ранее. Раскладывая цель в $300K/month в GMV на конкретные подцели, фичи и действия, вся команда видит, что текущими подходами и рычагами мы не достигнем задачи, и поэтому начинает придумывать “хаки”.

У нас эта работа построена следующим образом - есть 2 типа встреч:
a) zoom in - еженедельные встречи, на которых мы смотрим на то, как мы достигаем месячных целей по GMV, и что нужно сделать на следующей неделе, чтобы приблизить нас к этому результату. Обязательно с кроссчеком по претотайпинг техникам. Встреча заканчивается небольшим опросом, насколько мы верим в то, что достигнем цели по 10ти балльной системе. Это хороший индикатор общей уверенности
б) zoom out - брейнстормы, к которым я готовлю мини-эссе, чтобы задать тему - например, результаты jobs to be done интервью - и мы размышляем о том, как будем идти к более high level целям.

Это постоянное zoom in, zoom out переключение я считаю ключевым, чтобы “не терять лес за деревьями” самому, и всей команде. Поэтому не надо слепо верить тем, кто говорит про абсурдность бизнес-планов для стартапа (ваш покорный слуга included) —> дело не в плане, дело в процессе планирования. Подкрепляя свой нарратив цифрами, вы делаете себя и команду увереннее, а это точно источник дополнительной энергии и производительности.

P.S. В воскресенье обязательно покажу, как делать такое моделирование при помощи инструментов системного мышления

Продолжая тему проведения интервью [1,2], стихотворение Киплинга в переводе Маршака, к которому я обращаюсь каждый раз, когда у меня заканчиваются вопросы.

Есть у меня шестёрка слуг,
Проворных, удалых,
И всё, что вижу я вокруг, -
Всё знаю я от них.

Они по знаку моему
Являются в нужде.
Зовут их: Как и Почему,
Кто, Что, Когда и Где.

Я по морям и по лесам
Гоняю верных слуг.
Потом работаю я сам,
А им даю досуг.

Я по утрам, когда встаю,
Всегда берусь за труд,
А им свободу я даю -
Пускай едят и пьют.

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

Она гоняет, как собак,
В ненастье, дождь и тьму
Пять тысяч Где, семь тысяч
Как, Сто тысяч Почему!

К примеру: мы анализируем недостачную конверсию в подписку:
1) Как сейчас покупают подписку? --> беру и руками прокликиваю весь UX, с возможными ответвлениями, пытаясь понять, что может остановить человека. Делаю гипотезы и формулирую, как их проверить: количественно (по аналитике) или качественно (через опросы)
2) Почему (не) покупают? Из-за цены - могу ли проверить? Недостаточно ценности - по сравнению с чем? Говорим с пользователями, возможно тестируем разные цены и ценностные предложения
3) Кто покупает? - что мы знаем о пользователе? Страны, девайсы, браузеры, источники, разрешения экрана и тп? Знаем ли что-то глубже: как часто пользуются продуктом, возникает use case? Кто они? Откуда они узнали про нас? Что еще они используют? и тп
4) Что покупает? - что подтолкнуло человека к покупке: только что вбил всю историю своих полетов? За что именно он платит? Встречает Маму в аэропорту и хочет получать уведомления? Работает в логистической компании и отслеживает грузы?
5) Когда покупает? - когда узнал о продукте? После согласования с начальством? Прочитав отзывы?
6) Где покупает? - в аэропорту? по дороге туда? За день до вылета?

Я думаю, подход понятен 🙂 Просто держите эти вопросы рядом и “примеряйте” их к тому, что вам говорят

P.S. В рамках консультаций я иногда прослушиваю интервью, проведенными моими собеседниками, и даю обратную связь, где недоспросил, и какие вопросы забыл.

CEO - зачастую одинокий человек. Ему/ей не к кому прийти и попросить помощи. Когда кто-то не может что-то сделать, он - последняя инстанция.

Ему также нужно излучать уверенность. Он должен создавать у команды ощущение, что он знает, что делает. И даже в те минуты, когда очень тяжко, не положено показывать слабость. Как в детстве “мальчики не должны плакать”. Он не может вам рассказать все проблемы, что у него накопились. Он не может отдать вам свою работу; ту работу, что может сделать только он.

Где-то год спустя ухода из app in the air, я встретился с одним из бывших сотрудников, и он сказал что-то в стиле “извини, что я упрекал тебя в чем-то. я сейчас понимаю, что это было некорректно, и была куча проблем у тебя, о которых мы не могли даже догадываться”.

К чему я это?
Если вы - CEO --> не теряйте себя, бывайте в ситуациях, где вы не рулите, и отдыхайте там. Хоть как я, ходите по светофорам в незнакомом городе: когда идешь туда, где горит зеленый свет. Общайтесь с другими CEO, найдите поддержку в менторах или эдвайзерах, а идеально - в совете директоров.

Если вы - не CEO --> найдите правильный момент и поддержите своего CEO. Не буду советовать как именно. Просто сделайте так, чтобы он(а) почувствовал, что его ценят и он не один. Помню, как ребята, узнав, что я буду в Ереване перед уходом из компании, прилетели и подписали реквизит из нашего любимого паба в Москве. До сих пор ношу его в рюкзаке.

Поверьте, одной улыбки и одной степени уверенности будет больше у него, а значит - и у вашей команды!

Хорошей рабочей недели вам, Друзья!

P.S. У меня все отлично :)

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

В интервью с пользователями не всегда респондент может хорошо обьяснить, какую задачу выполняет для него ваш продукт. Поэтому полезно применить схожую технику: задаете вопрос в стиле "Какой продукт или услуга выполняет для вас ту же функцию, что и наш продукт? В чем схожесть? А в чем отличие?" —> к примеру, неожиданно (но постфактум логично!) для меня один респондент сравнил mindshare консультации с chatgpt и было интересно понять, что схожего и различного между этими 2мя формами получения "взгляда со стороны"

Еще вариация на тему: “Приведите аналог нашего продукта в другой части вашей жизни/индустрии” —> например, для app in the air один пользователь привел банковское приложение. Я сразу не понял и попросил пояснить, в ходе чего выяснилось, что банковское приложение - это все про его финансы; app in the air - про его полеты.

Задавайте “точки опоры”, чтобы лучше извлечь инсайты о jobs to be done вашего продукта.

P.S. Если захотите поговорить об этом - вы знаете, что делать

Управленческий цинизм

Одно из сильных потрясений для новоиспеченного руководителя - первое увольнение. В смысле, когда надо уволить кого-то. Я помню лида, который аж сам трясся из-за того, что ему пришлось бы это сделать. Из-за того, что это огромное потрясение, ожидаемо люди откладывают это, жалеют подопечных, не хотят быть плохими, и затягивают решение проблемы. Поэтому одной из важных задач руководителя новоиспеченного менеджера является мониторинг и помощь в подобных решениях.

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

Если бы тебе сейчас пришлось уволить одного сотрудника из твоей команды, то кто бы это был?

Для меня показательными были 2 вещи:
1) Как долго человек думает про ответ на этот вопрос
2) Кого он назовет

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

Почему ты тратишь свое ограниченное время на тех, кто "не хочет", вместо того, чтобы инвестировать в тех, "кто хочет"?

Обычно этого было достаточно, чтобы сдвинуть человека с точки. Подвести рационально к решению и осознать свой страх. А далее моей задачей было помочь сделать этот шаг, стать "проводником" в этот неизведанный страх: мы делали звонок на троих, планировали сам руководитель озвучит, что включилось "правило трёх предупреждений", или мне сделать это за него. В следующий или через следующий раз руководитель уже был готов сам озвучивать свое решение, и ему не более не требовалось моего толчка. В такой момент моей задачей было лишь следить, чтобы он не переусердствовал 😉

В заключение - слова Джобса Ларри Пейджу, когда тот стал CEO Google:

Dont try to be too good as a CEO

Некоторое время назад в чатике спросили про ошибки построения системы метрик для компании, отвечаю:
1) Не проходит MECE критерий - декомпозиция метрик не удовлетворяет известному принципу "взаимно исключающее, совместно исчерпывающее". К примеру, в примере выше общая выручка однозначно описывается выручкой от подписок и от бронирований; других источников выручки у компании не было и не планировалось на тот момент

2) Целевые и текущие значения - недостаточно декомпозировать метрики, надо еще посчитать текущие и назначить им целевые значения, e.g. 1000 авиа бронирований в день

3) Временной период - очевидно, что цели должны быть ограничены во времени, e.g. 1000 авиа бронирований в день в декабре 2024.

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

К чему я это? На начальных этапах функционирования любого бизнеса (системы) у вас недостаточно информации и истории о поведении системы, поэтому это нормально, что вы столкнетесь с невозможностью сформулировать или декомпозировать метрики. Вопрос лишь в том, чтобы осознать это ограничение и разобраться с ним. Не пытайтесь сразу сделать все правильно; начните с простейшего и постепенно наслаивайте и "взращивайте" систему. В том числе систему метрик. Не забывам про один из законов систем

A complex system that works is invariably found to have evolved from a simple system that worked. A complex system designed from scratch never works and cannot be patched up to make it work. You have to start over with a working simple system

P.S. Хотите чекнуть свою систему метрик либо вместе ее сформулировать для вашего кейса - welcome на консультацию.

Одним из самых трансформирующих этапов моей жизни был период работы в 1C Франчайзи “Masan Business Consulting”. Мне было неполных 18, когда я устроился туда, чтобы зарабатывать на клубы и модную одежду из Mexx & Sisley 😛

Почему? Потому что работа программиста 1С в франчайзи заключается в общении с сотрудниками клиента и доработке стандартной конфигурации 1С под потребности конкретной компании: от главбуха нефтегазовой компании в особняке в Гагаринском переулке до простого кладового где-то в складских помещениях на Войковской. А я, ну как бы вам это сказать, от стеснения в детстве мог окунуться в тарелку супа в попытке спрятаться от людей, задающих мне вопросы (реальная история).

Мне нужно было не только говорить с клиентами, но и научиться их понимать, иногда переубеждать, иногда подчиниться, но главное - сделать их счастливыми через комбинацию речи и кода.
Думаю, именно этот опыт спустя годы мне очень пригодился в стартапе. Несмотря на до сих пор щемящее чувство и дискомфорт внутри, я старался и стараюсь общаться с пользователями и клиентами, чтобы лучше чувствовать, что им на самом деле нужно. В предыдущих постах я частично уже писал об этом [1, 2, 3, 4].

Пора все эти знания упаковать в стройную систему. Систему теоретических знаний о том, как и зачем интервьюировать пользователей. А чтобы усилить пользу от оной, помимо теории, сделаем практику: проведем jobs to be done интервью в режиме реального времени, храбрецов-волонтеров выберем по ходу дела.

Итого: 18 февраля с 17 до 19мск говорим и учимся делать jobs to be done исследование.

Для кого это?
⁃ Фаундеров-продактов, у которых нет желания или возможности нанимать специально обученных людей; которые хотят самостоятельно разобраться в потребностях своей целевой аудитории
⁃ Продактов, которым кажется, что они не до конца чувствуют, для чего именно пользователи нанимают их продукт, и поэтому не понимают, как приоритизировать хотелки других
⁃ CEO и CPO, которые ищут пути для роста и хотят давать пользователям то, что делает их жизнь лучше, а не натягивать сову на глобус, предлагая скидки и захламляя главный экран продукта.

Структура встречи:
⁃ предпосылки jtbd и связь с теорией подрывных инноваций Кристенсена
⁃ Фреймворк 4х сил прогресса
⁃ Вопросы для старта, углубления, и заключения
⁃ Как суммировать результаты и чем chatgpt мог бы помочь
⁃ Как интерпретировать то, что получилось, и делать выводы про продукт
⁃ И для закрепления практикум: «для какой джобы вы наняли этот вебинар?»

На выходе:
⁃ презентация и запись встречи
⁃ список вопросов для разных стадий интервью
⁃ Промпты для chatgpt в помощь

Бронируем билеты здесь: $20 (1800руб), каждый день цена растет на $5.

До встречи в следующее воскресенье 18го февраля!

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

то есть вроде есть какая-то сетка, но ощущение каких-то 2= островов элементов
и еще посередине выступает берег из скролла недель )))

Но несколько ребят из команды логично аргументировали:

- с мобайла все выглядит сильно лучше, уверен, что очень небольшая часть трафика будет с веба (даже с wingman так было, а тут вообще тул на которую ведут из соцсетей)
- Если за первую версию не стыдно, значит выпустили слишком поздно!

Я принял аргумент и мы стали готовить продукт к релизу:

Хороший аргумент про мобайл
Окей. Давайте релизить

Но что-то мне не давало покоя: в моменте у меня не было времени осознать и подумать про это, так как было утро и были подряд звонки, но вечером, размышляя над ситуацией, я попросил чекнуть цифры по использованию мини-аппа в Телеге (благо, мы логировали инфу о типа трафика). + поскольку веб версию мы, в основном, делали для использования в LinkedIn, то коллега еще решил чекнуть рыночную стату по нему. В итоге оказалось, что десктоп трафик занимает 40-45% o__O Цифры реально удивили!

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

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

P.S. Подумал про AI агента, который сидит в чатике и периодически играет “адвоката дьявола” на важные решения или подкидывает релевантную статистику из веба по спорным вопросам.

Давным-давно я преподавал в РГГУ и после завершения семестра мы со студентами пошли в бар отметить это. Одна из студенток заметила, что после этих курсов она чувствует себя неполноценной: “бизнес такой сложный, оказывается”, хотя к тому времени она уже несколько лет вполне успешно вела один.

Очевидно, что это не то, что должно делать образование. И “горе от ума” никто не отменял. Но я почему-то подумал о другом аспекте: в одной из моих любимых книг “Success Equation” Мабуссина упоминается парадокс навыков Джея Гоулда. Суть парадокса в том, что удача играет бОльшую роль с ростом “зрелости” инудстрии: когда отличие самого сильного от самого слабого становится минорным в результате конкуренции, для outstanding результатов ключевую роль играет удача, поскольку навыки более-менее одинаковы. Таким образом, больше навыков приводит к большей значимости удачи. Обратное тоже верно: даже если вам очень повезёт в шахматах, но вы не особо умеете в них, то навряд ли это спасет вас в игре с гроссмейстером.

Вот и я подумал, что у некоторых из вас, вероятно, складывается похожее ощущение: зачем так усложнять бизнес? Все эти системные мышления, джобстубиданы и тп. Можно ведь проще, и (кажется) есть много примеров, когда этого достаточно. Но по мне в ситуации глобальной конкуренции (а именно с этим сталкивается большинство цифровых продуктов) определенный уровень скиллов - это необходимое условие для успешной конкуренции. Особенно, если это “молодые” отрасли, где разброс навыков пока еще достаточно высок.

Также, если мы примем, что успех бизнеса зависит от некоторой комбинации навыков и удачи, а на удачу мы не можем особо влиять, то навыки это единственное, чем мы реально можем управлять. Поэтому мне хочется верить, что теории, фреймворки и мысли из этого канала вам посильно помогут, а удача - тут уж как повезёт 🙂

Хорошей вам недели!

P.S. Кстати, желание управлять “удачей” приводит нас к суевериям --> хорошая идея для канала, м? 🙂

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

Иду я как-то в метро, как сейчас помню - Арбатская. Жду своего поезда до Бауманки. Навстречу идут двое ребят и спрашивают: есть ли у меня зажигалка? На автомате я отвечаю, что не курю, а в ответ слышу “мы тоже”. Зависаю. Бросаю взгляд на них. В руках у них по бутылке пива. Все становится очевидно - им нужна была зажигалка, чтобы открыть бутылку.

Эмпатическое проектирование - это набор методов наблюдения за пользователем в естественной среде, не фокус-группы и интервью, где пользователь пытается правильно ответить. Обычно такое наблюдение вскрывает новые способы использования вашего продукта, латентные потребности, которые клиенты могут не осознавать или не замечать, так как свыклись с ними. В примере выше использование зажигалки для открытия бутылки - как раз такое неочевидное использование. Знатоки сия знают, что дешевые зажигалки быстро ломаются из-за этого, и потому предпочитают металлические. Подобным образом [через эмпатическое проектирование], кстати, были придуманы складывающиеся кресла в джипах: руководитель одного из авто-производителей заметил семью на парковке супермаркета, которая не может уложить все свои покупки в свой огромный автомобиль.

Как мы “наблюдали” за пользователями?
1) App in the Air - часто в аэропорту я сидел с блокнотиком и наблюдал за людьми у гейта. Так, я узнал, что пожилые люди часто не могут увидеть надписи на табло. Или что люди любят показывать близким свои штампы в паспорте. Отсюда родились соответствующие фичи в продукте (cм в комментариях)
2) Life in the Air - как я уже писал выше, мы летали на пилотных рейсах и наблюдали за людьми на борту. Например, в комментариях фотка моего любимого пользователя, которого я показывал в наверное каждой презентации-продаже: обратите внимание, сколько всего он накупил и еще продолжает смотреть в аппчик, выбирая себе суп-лапшу, кажется. За тот рейс он потратил в 7 раз больше среднего чека (см в комментариях)
3) RuBeacon - ребята зачастую работали вместе с бариста в кофейных точках и иногда переделывали продукт на ходу: помню, как у нас была фича, что при каждом заказе играл такой звук свистка тепловоза. Когда в реальных условиях стали наблюдать, то стало быстро очевидно, что нахрен этот звук надо выключить :))) Но, к примеру, красным подсвечивать просроченные заказы и по-другому сортировать их.

Правда, не всегда есть возможность наблюдать пользователей в их реальном контексте, поэтому можно использовать аналитику или “веб-визор”-подобные системы в качестве замены, но об этом в следущий раз.

P.S. На семинаре по jobs to be done в воскресенье я расскажу не только про интервьюирование, но и про другие методы наблюдения за пользователями, особенно вкупе с интервьюированием, чтобы подготовить вопросы получше.

“Как организовать правильное выполнение работы людьми, а не доделывать самому?” - на эту тему мы майндшерили сегодня. Пример: продакт находит баги, которые пропустил тестировщик.

Я часто сталкивался с такой ситуацией и в 90% случаях дело было в отсутствии одной из 2х вещей:
1) сценария тестирования
2) критериев важности бага

Давайте разбираться:
1) Если нет согласованного сценария тестирования, то не стоит надеяться, что тест будет сделан качественно, потому что нет единого понимания, что такое качественно. Для продакта качественно может быть, чтобы покупка подписки работала, а для тестировщика - регистрация (я утрирую, конечно). Добавьте сюда постоянную нехватку времени, когда приходится срезать углы и пропускать тестирование некоторых частей продукта, и у вас гарантированно будут вылезать ненайденные ошибки... Просто договорившись о том, как мы будем тестировать продукт, мы системно снижаем потенциал для сюрпризов.
2) как мы определяем важность того или иного дефекта (читай, невыполненного тест шага в сценарии тестирования) - защита от самодура-начальника. Если мы договорились, что ошибки на этапе оплаты продукта БЕЗ возможности workaround-а - это критический баг, а невыравненный текст - это низкий, то не придется все бросать ради мелочей.

Безусловно тестировщик и продакт - элементы этой системы. И в них тоже может быть дело. Но чаще проблема в правилах (связях) о том, как мы тестируем продукт и что важно. Определение важности же - есть прямое следствие стратегии, о чем я уже писал ранее.

Удачи!

P.S. Если захотите помайндешерить - welcome на 1:1 консультацию

Знаете, почему в опаздывающий проект не нужно подключать еще больше разработчиков - этот знаменитый закон Брукса? Глобально 3 причины:
1) Новичков надо обучить, чтобы они стали продуктивны, а это не только занимает время оных, но и отвлекает текущую команду
2) Не все задачки легко декомпозировать для выполнения разными людьми
3) Чем больше людей в команде, тем больше затраты на коммуникацию и координацию

Вот о 3й проблеме и хочу поговорить. Каким образом она возникает? Обычно, чем большему количеству людей необходимо коммуницировать, тем выше не только затраты на коммуникацию, но и вероятность context collapse. Уверен, вы бывали в ситуации, когда в командном чатике идет обсуждение топика, который совсем нерелевантен другим людям. В этот момент и появляются процессы как способ упорядочить коммуникацию, чтобы снизить вероятность таких коллапсов.

В простых случаях эти процессы просто про создание отдельных чатов по топикам (dev, design, team, etc), в сложных - это дробление на команды (появление иерархии), установление правил взаимодействия внутри и между командами, появление индикаторов для координации команд (цели, планы, метрики), и появление людей для координации этих взаимодействий.

Поэтому я сторонник эволюционно появляющихся процессов: когда команда чувствует негативные последствия коллапсов и осознает необходимость в их снижении. Как раз здесь и возникают вопросы а-ля “централизация vs децентрализация”. Важно отметить, что команда может чувствовать проблему, но не понимать, как ее решить, поэтому знания и опыт управления большими коллективами может быть очень кстати. На эту тему вновь рекомендую книгу “Elegant Puzzle” Уилла Ларсона

Симптомы контекст-коллапсов:
1) группа людей создает отдельные чатики по какому-то проекту или топику
2) 80% стафф митинга 2 человека обсуждают какую-то свою проблему, до которой остальным нет никакого дела
3) разработка внезапно узнает о новой кампании, уже запущенной маркетингом, хотя “в чатике это же обсуждалось”
4) на митингах есть люди, присутствие или отсутствие которых никак не сказывается на результатах митинга
5) люди сидят на 2х зум-митингах одновременно (!)

Добавляйте свои в комментариях :)

За эту неделю было 2 похожих запроса о том, как систематизировать обратную связь от пользователей. Глобально подход заключается в следующем:
1) Берем нашу иерархию метрик
2) Группируем запросы по смыслу и оцениваем, как они влияют на ключевую метрику (Impact), допустим GMV. Оцениваем это влияние по опыту своему, через претотайпинг, или через рыночные бенчмарки. Допустим, мы хотим прикрутить чекаут без регистрации и согласно рынку около четверти всех чекаутов отменяют из за необходимости зарегистрироваться --> четверть от потерь это потенциал.
3) Дальше оцениваем трудозатраты (Effort), про это много техник от planning poker до пальцем в небо.
4) Располагаем фичи по матрице Effort - Impact (см картинку) и берем в работу согласно порядку, приведенному на картинке. Для идей из квадранта High Impact - High Effort обязательно делаем претотайпинг. К примеру, в MindShare мы так сделали подписку на групповые встречи: в первой версии это была просто ссылка и покупка через бота, без какого либо UI и особой сложной логики. Я написал личные сообщения тем, кто был хотя бы на 2х моих стримах и в первый же день продали 5 подписок из 7 возможных (включая пользователей, что просили ее до этого). Важно, что это позволило докрутить value proposition подписки: один из купивших уточнил сначала, какие темы планируются на будущих стримах, другой - про доступность записей в случае неучастия. Квадрант low impact - high effort лучше выбрасываем совсем: например, вчера мы обсуждали требования одной из платежных систем к веб-версии продукта и решили просто не поддерживать ее с учетом наших оценок.
5) Возвращаемся к пункту 1 через несколько релиз циклов.

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

На стриме в воскресенье об этом тоже немного поговорим