Архив недели
Понедельник
Всем привет!
На этой недели с вами Дима Абрамов, с 1 января — CPO появившегося во время карантина бизнес-юнита "Интерактивная тетрадь Skysmart" в Skyeng
Расписание на неделю
пн: менеджмент — самый недооцененный навык продактов
вт: во вторник будет мало твитов, поговорим про скрамы и канбаны
ср: продуктовая команда
чт: продуктовый фреймворк управления
пт: как запускать продукты за неделю
сб: стратегия продукта
вс: просто поболтаем
Так, сегодня говорим про менеджмент.
Продакт менеджер, как следует из названия он про продукт и про менеджмент. Вот только что-то пошло не так.
Откройте любой курс для продактов из сотни на рынке и вы увидите кастдев, mvp, канвасы и ничего про самый обычный регулярный менеджмент
Давайте даже проверим.
Опрос для тех, кто учился на каких-нибудь продуктовых курсах.
У вас было что-то про то, как проводить f2f встречи, как писать фоллоу апы, как делегировать?
Тред первый.
Что такое менеджмент и почему это недооцененный навык, который вам надо развивать
Я буду писать свои соображения, а вы можете спорить и не соглашаться ;)
У нас в команде, мы смотрим на менеджмент, как на науку о том, как достигать целей.
По сути — абсолютно любую цель можно достичь. Ограничение, лишь в management capacity — насколько комплексные, сложные, далекие цели вы можете достигать.
Почему это точка роста среднестатистического менеджера продукта?
Как мы выяснили раньше, на курсах для продактов этому практически не учат.
Не учат → мало фокуса → эта область компетенций слабо развита → это одна из самых значимых точек роста
Если что, это почти универсальное правило. Если вы какую-то область развиваете слабо — наверняка там зарыты клады с точки зрения буста вас и вашей компании.
Ещё одна причина, почему мало кто прокачивает менеджмент — это очень скучно.
Серьезно, писать фоллоу апы после встреч, жить по таймингам, составлять адженду перед встречами, смартировать каждый проект, четко описывать таргеты.
Пойду лучше канвас нарисую
Тред 2
Основные инструменты регулярного менеджмента.
Встречи, шаблоны, рутины и тд.
Сначала вопрос
Вы руководитель и у вас есть несколько тимлидов в подчинении. Одному из них вы полностью поручили важный проект. Сколько часов в неделю у вас будет уходить на этот проект, если вы хотите, чтобы он был успешен?
Однозначно правильного ответа, конечно нет. Зато есть однозначно неправильный — 0. Если вы делегировали проект, но нет никакой функции контроля, то вероятность его выполнения ±0.
В остальном, это конечно зависит от
- проекта и его важности для вас
- компетенций сотрудника, которому вы его делегировали
Однако, если вы тратите больше 5-10 часов в неделю на регулярный менеджмент проекта, который ведете не вы, это значит, что ваша пропускная способность как менеджера ограничена всего парой таких проектов, максимум.
Обычно, картина выглядит следующим образом:
Проект, который делегирован сильному лиду — должен занимать у вас 1-2 часа в неделю на его контроль. Удобнее всего в рамках F2F-встреч (30-60 минут) + возможно регулярной встречи рабочей группы проекта (в режиме слушателя)
Конечно, может быть необычная неделя. На стадиях планирования проекта, либо когда ситуация вышла сильно за рамки зеленой зоны — может потребоваться большее вмешательство и выделение времени. Но это уже отдельные случаи.
Также есть проекты из разряда "срочные и важные". У себя в команде мы для таких проектов разработали специальный фреймворк работы. Такой проект может занимать у вас до 5 часов в неделю.
3 регулярные встречи в неделю + F2F. Однако, если таких проектов много — что-то идет не так
Собственно, один из самых сильных, на мой взгляд инструмент регулярного менеджмента — F2F встреча.
По сути, ничего сложного. Регулярная встреча руководителя с сотрудником.
Однако, если правильно к ней подходить — это очень классный инструмент
У меня есть F2F-встреча с тимлидом каждой команды: продуктовой и функциональной.
С продуктовыми руководителями встречи обычно по 1 часу, с функциональными по 30 минут (бывает, обговариваем расширенный тайминг).
С каждым сотрудником есть ноушен-страничка с логом всех F2F встреч.
Все встречи структурированы одинаковым образом:
есть подготовленные вопросы с моей стороны и со стороны тимлида. В начале встречи обсуждаем список вопросов, если успеваем не всё — выбираем самые важные.
Во время встречи — фиксируются договоренности с обеих сторон.
Ладно, это обычное дело, теперь секреты
Ключевое в проведении F2F встреч — это подготовка. У меня в календаре стоит отдельный слот не менее 50% от времени встречи для подготовки вопросов к ней.
Рассмотрим пример, как провести F2F с лидом, который ведет самостоятельно проект
Контроль договоренностей (это начало любой встречи, без вариантов)
Статус по проекту (ключевые точки, светофор по метрикам)
"Докапывающиеся вопросы"
п3:
Моя задача зачелленджить планы тимлида, найти в них узкие места, удостовериться, что у него есть план их расшития.
Не нужно делать планы самому. Вы просто задаете вопросы. Если плана расшития нет — договоренность когда он появится. Если нужна ваша помощь, он попросит.
Это может казаться очевидным, но я видел на своем и на чужом опыте, что в момент когда менеджер осознает тот факт, что он может не придумывать сам план решения проблемы, но при этом подсветить проблему сотруднику — становиться переломным моментом в качестве делегирования
Здесь кстати рекомендую всякие коучинговые механики. Коуч — чувак, который вообще обычно не шарит в предметной области, но за счет крутых вопросов выводит собеседника на классные идеи.
Каждый руководитель — немного коуч.
Помимо движения по проектам, обязательно обсуждайте на F2F встречах, как минимум раз в месяц:
- Движение по KPI схеме
- Движение по PDP / развитие сотрудника
- Личное состояние, атмосферу в команде
Давайте итоги про F2F
Хорошо:
- Встречи в одно и тоже время, каждую неделю
- Лог встреч в одном месте
- Подготовка вопросов с каждой стороны заранее
- Фиксация договоренностей и обязательный возврат к ним каждую встречу
- Челлендж ответов, а не просто "ответ для галочки"
Плохо:
- Следующая встреча будет "как договоримся"
- Поговорили час и нет ни одной договоренности (такое может быть пару раз в квартал, чисто для мотивации)
- Договорились и никогда потом не проверяли результат
- Обсуждаем что в голову придет, без плана встречи и привязки к целям
Формулировки! Заслужили отдельный тред.
Это даже более важно, чем весь менеджмент. Формулировки очень важны, я смело утверждаю, что вы обязаны развить в себе нулевую толерантность к размытым, неконкретным формулировкам.
Любимое из планов на неделю разных менеджеров:
- Набросаем варианты дизайна регистрации
- Приберемся в репозиториях
- Постараюсь успеть прособеседовать трёх кандидатов
- Отсмотрю записи четырех интервью
Ну офигенно же не?
Если что, это формулировки, которые спокойно проскакивают у менеджеров с 3, 5 и 10 годами опыта.
Волосы дыбом встают (теперь, раньше я тоже этим грешил постоянно).
Всем внутривенно рекомендую посмотреть формулировки какого-нибудь руководителя из операционки. Там за такое уволят.
Еще из великолепного, примеры итогов недели:
- Почти успели выкатить
- Осталось протестировать
- Встретились, обсудили, фоллоу ап еще не написал
- Занимались этим два дня (ну охуеть, теперь, простите)
Я думаю, мысль понятна.
Формулировка должна быть четкая, по SMART. Не может быть задачи "делать", может быть "сделать"
У задачи всегда должен быть итоговый артефакт. Задача "посмотрю запись", которая не имеет на выходе артефакта — не имеет смысла.
Итоги всегда бинарны.
Вангую, если вы с завтрашнего дня включите режим нулевой терпимости к плохим формулировкам, то
в конце недели процент выполненных задач упадет раза в 3
на горизонте месяца эффективность вырастет процентов на 25-100
Инструмент: планирование встречи.
У каждой встречи должны быть известны: agenda с таймингом, роли участников, как минимум роль ведущего встречи.
Ведущий встречи (aka фасилитатор, модератор) не всегда == организатор встречи (aka заказчик)
Если нет тайминга встречи — вы не знаете когда закончиться встреча, не в курсе успеваете ли вы вовремя, не затянули ли. Если нет тайминга — когнитивная нагрузка на фасилитатора вырастает раз в 10, на участников раза в 2-3.
Хороший тайминг, это слоты максимум по 10 минут.
Чем больше участников встречи, тем жёстче должен быть тайминг и более прокачан фасилитатор. Блок "обсуждаем почему мы не достигли цели" ещё прокатит на F2F встрече, но на ретроспективе на 10 человек, это будет балаган без какой-либо пользы в конце.
Если вы ведете встречи на 5+ человек, особенно большие и сложные, типа стратегических сессий — читайте книжки по фасилитации (например facilitator's guide to participatory decision-making)
Ах да, что я сразу к таймингу.
Если у встречи нет адженды — можно вообще на неё не приходить, всё равно же смысла нет.
Адженда это смартированная цель встречи. Нет цели — нет встречи, давайте это просто как правило возьмём.
Моя любимая адженда, которую я запомню навсегда "Цель встречи: принять верное решение". И всё.
5 лет прошло, а всё ещё смешно. Кстати до этого пять встреч на эту тему было.
Если что, встреча начинается не когда все в зум подключились, а когда вы сели планировать её. А заканчивается, не когда звонок кончился, а когда вы опубликовали фоллоу ап.
Планирование встречи должно занимать время. Если встреча регулярная — планирование может быть коротким (50% от длины встречи)
Если встреча нерегулярная — 100%-400%. Чем важнее встреча, тем больше времени надо потратить на её проектирование.
У фасилитаторов считается нормой потратить 4 часа на проектирование одного часа встречи. Это не просто так. Если вы проектируете стратегическую сессию, лучше вы потратите x4 времени, чем все менеджеры вместе проведут неэффективно 8-24 часа.
В конце каждой встречи должен быть фоллоу ап.
Фоллоу ап это не конспект встречи, это артефакт, который описывает достигнутую цель +все договоренности, которые проговорили на встрече.
Если что, договоренность это кто - что сделает - когда, а не "договорились обсудить архитектуру"
@produnderhood Лучше придти на заранее запланированную встречу и сказать: -А что будет? Не, я ничего не читал Вот это прям топчик
Супер классный коммент.
Чтобы такого не было, мы наши важные встречи прокачали, сделав "домашнее задание" (мы для школьников работаем, нам положено) twitter.com/valioozz/statu…
Домашнее задание — это структурированный документ с материалом, необходимым для ознакомления участниками встречи ДО встречи. Как и у любой задачи, у домашки есть образ результата, обычно это написанное эссе с выводами, или иной формат записанных мыслей по поводу целей встречи
Особенно часто мы используем домашку перед стратегическими встречами. Чтобы принимать стратегические решения, наши нейронки в голове должны быть прогреты. Поэтому каждый тимлид должен освежить в памяти знания о пользователях и тд.
Кто не сделал домашку — не допускается на встречу
Ну и про ведущего, как вы понимаете, если нет ведущего — нет встречи. Посидели, поболтали — это не встреча, это тусовка. Тусовки зашибись, но даже у них есть организаторы обычно, если конечно тусовка хорошая)
Ночью еще напишу как прокачивать скилл менеджмента, а пока давайте отрефлексируем день.
Как вам контент?
В тред пишите любой честный фидбек
Вторник
Как и обещал, сегодня очень мало постов, потому что весь день встречи.
Но я тут, приступаем.
Сегодня говорить будем про процессы. Всякие скрамы, канбаны и прочие лессы. Про них много говорить и не нужно)
Самое главное, что нужно понимать про любой фреймворк/подход/метод, что это лишь инструмент. Не нужно делать скрам ради скрама, не нужно надеятся, что он решит все ваши проблемы. Если у вас "медленно продукты запускаются", вам нужно искать способ ускориться, а не внедрять скрам
Тред про Скрам!
Можно похоливарить, но я не фанатик, со мной сложно будет.
Важно, что нужно понимать про Scrum:
Это конкретный фреймворк организации процессов, у него есть создатели, у него есть инструкция и в ней описано, что является скрамом, а что нет. Не надо называть скрамом какую-то нелепую фигню, которую вы сами придумали, а потом жаловаться.
Среда
Ещё одно.
Скрам — очень дорогой фреймворк. Он не ускоряет разработку, он добавляет много новых встреч и так далее. И это нормально, просто не надо использовать его для ускорения.
Скрам придуман для работы в условиях высокой неопределенности. Причем при соблюдении кучи других пререквизитов. Например, у вас должна быть кроссфункциональная команда, где есть все необходимые специалисты, которые работают только над этим продуктом фултайм
Высокая степень неопределенности, это, например, запуск нового продукта. Когда больше чем на неделю вперёд ничего не понятно. Для этого скрам работает очень круто.
Но только если вы действительно поняли что к чему и не выкидываете "лишние" ретроспективы и обзоры спринта
Тред про канбан!
Сразу важно: канбан доска != Канбан метод != Канбан из Тойоты != Канбан из книжки "Скрам и канбан: выжимаем максимум" за которую Книберг потом извинялся. Я буду говорить только про Канбан-метод, автор Дэвид Андерсон. Поддерживается Kanban University
И снова: это всего лишь инструмент. Не надо думать, что он вам бизнес построит.
Канбан-метод — это метод оптимизации. По сути, это инструмент, с помощью которого, вы можете оптимизировать свои процессы таким образом, чтобы они лучше всего проходили под ваши текущие цели бизнеса. Просто!
Удивительно, но чтобы достичь какую-то цель, её надо сначала поставить. Не всегда очевидно, но цель оптимизации не всегда скорость, иногда это предсказуемость сроков, иногда гарантия, что вы готовы быстро зарешать внезапную проблему.
Ещё один миф, что Канбан это скрам без спринтов. Это конечно же не верно, потому что Канбан не говорит какие должны быть итерации, вполне может быть, что спринты из скрама это самый оптимальный процесс.
Многие знают, что Канбан это не только доска, но ещё и wip-лимиты. Гораздо меньше знают, что это не только лимиты, но и классы обслуживания, явное описание политик и каденции, позволяющие системно улучшать разные аспекты процесса.
Когда использовать Канбан:
- если у вас есть какой-то процесс и вы хотите его улучшить, и знаете про какие параметрам
- если вы хотите найти узкие места в своих процессах
- если у вас вообще непонятно, что за процессы
Кучу пользы обещаю
Только все равно больно, особенно лимиты
Чтобы узнать как использовать читайте книжки Дэвида Андерсона и Алексея Жеглова, либо хотя бы Kanban guide. Лежит бесплатно в интернетах
Сегодня говорим про продуктовую команду.
Кто входит, какая структура, как нанимать.
Буду рассказывать про то, как у нас и то, почему так.
Продакт всему голова. По моему глубокому убеждению, он должен отвечать за финансовые метрики и быть прямыми руководителем продуктовой команды. Это самый простой способ оргструктурно дать ему все необходимые ресурсы. Матрица — сразу несёт в себе огромные накладные расходы.
Скорее всего, вы делаете it-продукт, значит ключевые люди у вас в команде — инженеры. Ключевые, потому что это самый дорогой этап и единственный, который несёт ценность пользователю. Если продукт операционный, есть ещё операционнка, но она по опыту вне продукта.
Если ключевые люди это инженеры, значит вам надо растить долю инженеров в команде. Меньше менеджеров, больше инженеров. Если нужен новый менеджер, лучше, чтобы он ещё и инженером был.
Если у вас много людей без базовых инженерных знаний, то у вас потом и количество разработчиков, аналитиков будет расти. У нас есть правило, каждый тимлид должен уметь написать простой запрос к бд, собрать отчёт в табло и в идеале даже собрать себе простую админку на retool
Кто есть в команде помимо программистов:
Design, Research, Analytics, QA.
У каждой команды есть тимлид, это важно, он отвечает за развитие команды, процессы в ней, лучшие практики. Он является ответственным за результат перед продактом.
Конечно же, тимлид в команде из двух человек не только менеджерит. В основном он такой же специалист + небольшая менеджерская нагрузка.
Четверг
Открытие года: наличие выделенного отдела ресерч — огромный левел ап вашего продукта. Да, продакт должен сам общаться с пользователями. Но если у вас есть люди, которые это делают все время, а ещё собирают инфу о рынке и конкурентах, то ваше интегральное знание растет на порядки.
Ключевое про найм и развитие продуктовой команды. Простое правило: нанимать сильных, увольнять слабых, это понятно.
Здесь расскажу про то, на что я обращаю особое внимание.
Самоходность: супер важный навык без которого к нам не попасть. Он означает, что человек не будет ждать задачу, он сам каскадирует её из целей продукта, сам проявит инициативу, и пойдет фигачить.
Самоходность — основа команд, в которых руководитель не бутылочное горлышко.
Проверять самоходность можно вопросами про опыт человека, где он проявлял инициативу, какие изменения организовал и тд. Но в целом, обычно это видно даже просто по общению и по вопросам, которые кандидат задаёт на собеседовании.
Готовность к критике и способность держать удар. Есть два одинаково плохих сценария: оборонительный, "да ты не понимаешь, я разбираюсь в этом" и покорный, "хорошо, пойду переделаю". У нас в команде мы челленджим абсолютно всех, такие реакции просто заблокируют работу.
Классная реакция на критику и челлендж, это его отработка:
- "да, я рассмотрел этот риск, вот данные которые говорят, что мне решение лучше"
Или
- "спасибо, я и правда не подумал об этом, возьму задачу расписать такой вариант"
Или даже
- "спасибо, но я рискну и сделаю по-своему"
Проверить этот навык на собеседовании очень просто — даёте кейс любой, начинаете в процессе челленджить решение кандидата, смотрите как он реагирует.
Кстати, если его легко продавить на ваше решение — это даже хуже, чем если он агрессивно реагирует.
Ну и наверно ключевое качество кандидатов, которое я ищу — охренеть какое желание расти. Кстати, это нужно не во всех продуктах. Рост — требует того куда расти, если у вас нет особо таких перспектив, это не самое классное качество.
Почему я ищу таких людей: у нас очень амбициозные цели на 25 и 30г. Я точно знаю, что текущая команда не способна достичь эту цель сейчас. Также я знаю, что на рынке всего человек 10, кто это может и их почти нереально схантить. Зато мы можем найти тех, кто очень сильно вырастет.
И вырасти сами конечно же!
Чтобы понять, что человек хочет и готов расти, я спрашиваю две вещи
на сколько и как он вырос за последний год, и насколько осознанно
готов ли он работать больше, чем требуется/положено. Я не фанат больших переработок, но это очень хороший показатель того,что важно человеку
Теперь развитие:
у всех тимлидов должен быть PDP
в kpi должен быть заложен PDP, чтобы не него был фокус
PDP должен быть четко привязан к целям и задачам продукта
PDP может быть совсем личным или направленным на развитие всей функции
Как и в любой другой сфере, в PDP должны быть четкие, смартированные задачи, а артефакты должны быть связаны с реальной работой.
Я не верю в ценность задачи "пройти курс по построению орг структур", без продолжения "скорректировать орг структуру на основе лучших практик из курса"
Повышение оклада и карьерный рост очень удобно накладывать на движение по PDP.
А ещё это круто работает, когда тимлид функции, хочет сделать фазовый переход, например в продакты.
"Отстрой самый классный отдел ресерча — доверим тебе продукт"
Если у вас нет активного найма — мониторьте рынок кандидатов на самые важные менеджерские позиции. Если вы найдёте супер крутого кандидата — его надо брать.
Если нет позиции, можно поставить его руководителем текущего лида, хотя бы на время.
Воспитывайте культуру в команде, в которой возможность расти под руководством топового чувака ценится больше, чем ярлычок, что ты самый главный. Тогда вы сможете собирать реально лучших людей с рынка, растить с их помощью ещё более крутых из текущей команды.
Ну и конечно же, есть движение не только вверх, но и вниз. Если человек не справляется и понимает это — предложите ему меньше ответственности. Если систематически не достигает цели и не знает что с этим делать и меньше ответственности не хочет — увольняйте.
И я не буду долго расписывать, но считаю очевидным фактом, что надо без сомнений увольнять:
- хитрецов / интриганов
- токсичных людей, которые демотивируют всех вокруг и саботируют процессы
Рандомные мысль, как вы можете кратно прокачать себя и свою эффективность, если у вас повысился оклад на 20-100к в месяц. И кстати это хороший вопрос для собеседования, проверить насколько много кандидат вкладывается в свое развитие
Обучение
Тут все понятно, курсы, книжки и тд
Психотерапия
Стоит как раз тысяч 10-20 в месяц, даёт кратный рост осознанности, а с ней много всяких плюшек, спустя полгода год, после старта
Прокачка бытовой траты ресурсов
Метро — такси, уборка — qlean, готовка — кухня/Яндекс/кухарка.
Для кого-то готовка, это лучше медитации, тем конечно не нужно.
Но глобально, все такие мелочи в сумме освободят вам тонну времени.
Персональный ассистент
Это вообще космос, настолько оптимизировать свой фокус, как это позволяет сделать крутой ассистент — нереально без него. Рост эффективности кажется раза в 3-4, если ассистент крутой.
Менторы, коучи и прочие люди помогающие. Но только если вы понимаете какой и к кому запрос.
Задача любого руководителя, особенно высокого уровня — выстраивать систему управления. Об этом будем говорить сегодня.
Мы в команде называем это "Продуктовый фреймворк", он описывает как мы работаем в продуктовой команде
Продуктовый фреймворк (PF) — это комплекс артефактов, событий, бизнес-процессов и принципов принятия решений, который максимально полно описывает работу вашей команды. С бизнес-процессами всё наверняка понятно, нет цели описывать их в каких-то сложных нотациях, хотя можно
Артефакты, тоже знакомое, но уже более редкое явление. Основной артефакт нашего продуктового фреймворка — ключевой файл с гипотезами.
По сути, это просто файлик, где все наши текущие и закрытые гипотезы, в структурированном виде, со всеми ссылками и выводами.
В куче компаний, для этого пытаются использовать таск трекеры (у кого-то даже неплохо получается). Однако на моей практике, любой таск трекер (даже мой любимый @kaiten_io) оказывается одновременно недостаточно гибким и слишком сложным.
Ключевые задачи этого файла:
- Обеспечивать прозрачность и синхронизацию всех команд по поводу того, какие гипотезы сейчас прорабатываются
- Хранить в себе консолидированную информацию обо всех гипотезах, которые уже были проверены.
Вы удивитесь, но я видел кучу команд, которые тестили одни и те же гипотезы, потому что просто забывали, что уже проверили их год назад, и они не сработали.
Если на первый взгляд, кажется, что это всего лишь говорит о лишних тратах пары сотен тысяч рублей, на самом деле всё хуже.
По сути, это значит, что в команде отсутствует процесс постоянного накопления интегрального знания всей команды о пользователях и рынке. А это очень страшно
И тут мы подбираемся, пожалуй, к ключевому компоненту продуктового фреймворка — правилам работы и принципам принятия решений.
По сути, система правил и принципов — это эмпирически выведенные ограничения, которые заставляют нашу команду двигаться всегда в нужном направлении.
На самом старте, мы выяснили, что мы продуктовая команда, а значит наша главная задача — лучше всех на рынке знать пользователя, его потребности, его контекст. А помимо наличия знания, надо все решения принимать именно на основании этого знания (кстати очень важное уточнение)
В процессе работы, мы проводим ретроспективы и находим изъяны в наших процессах накопления знания и принятия решений. У нас рождаются новые принципы.
Ниже некоторые примеры
- Нельзя участвовать в страт.встрече не сделав домашку (использование знания)
- На каждой странице в фигме должна быть формулировка проблемы пользователя, подтвержденная исследованием
- Каждый дизайн начинается со сбора референсов конкурентов
- Каждый тимлид минимум раз в неделю общается с пользователем
- Экран для учителя должен быть без кастомных скроллов
- Для учеников мы сначала рисуем мобильный дизайн
- Никогда не пишем слово платный
Как можно заметить, принципы могут быть супер разные, от глобальных, до мелких. Они описывают наш эмпирический опыт и помогают проверить качество принятых решений, выбранных гипотез, нарисованных фичей.
PF это часть системы управления всего бизнес-юнита. Это взгляд сверху на все продуктовые команды. Но можно и идти дальше в глубь. Фреймворк процессов в разработке, дизайне, ресерче. На каждом уровне могут быть дополнительно свои принципы, более детализированные процессы.
Я считаю очень важным уметь визуализировать всю свою систему управления.
Это позволяет вам быстро онбордить новых членов команды, потому что визуально легче понять.
Это позволяет вам заметить, что у вас всё слишком сложно
У нас это выглядит как-то так (подробнее не покажу)
Ну и почему я считаю, что это важно:
Система управления — сильнее менеджера, который ее построил. При условии, что в нее заложены механизмы ретроспективы
Менеджер перестает быть узким горлышком
Классная система эффективно дает влияние сильным и защищает от влияния слабых
Последний пункт достигается, если в систему заложены принципы меритократии.
По сути, вы не только выстраиваете систему управления, которая круче вас, но и защищаете её от своего дурного влияния, если вы ошибаетесь
Ну и да, читайте "Принципы" Рэя Далио ;)
Завтра буду рассказывать о том, как запускать продукты за неделю.
А пока, я понял что не рассказал, что за продукт я делаю. В треде расскажу, что такое "Интерактивная тетрадь Skysmart" и почему это самый крутой продукт в детском образовании сегодня.
2020 год, 30 марта, школьники РФ на ковид-каникулах. Становиться понятно, что через неделю в школы они не выйдут...
В недрах Скайенга совет директоров решает рискнуть и стартануть необычный для компании продукт. Без операционки, зато очень масштабный.
Руководить новым запуском выбирают двух супер сильных менеджеров, в тот же день они набирают команду из ребят со всей компании, которые готовы ради страны поработать в авральном режим 14/6 в течении ближайших недель.
За неделю, был сделан 1 пивот и собран продукт.
6 апреля, пресс-релиз.
sn.ria.ru/20200406/15696…
Продукт очень простой, но бьет в самую сильную боль преподавателей на карантине. Нужно как-то задавать и проверять тонну домашних заданий.
15 июня. Школьники закончили учебный год.
За два месяца в рабочей тетради было решено 10 миллионов домашних заданий. Зарегистрировано более 2 миллионов школьников и 70 тысяч учителей.
После недельного отдыха, команда собирается, чтобы решить, а что мы будем делать дальше. Хотим ли мы развивать продукт и как мы его видим в будущем.
Формулируется цель команду на ближайшие 10 лет.
"Вырастить поколение взрослых, которые любят и умеют достигать значимые цели".
Чтобы сделать нашу миссию более оцифрованной, после серий интервью детей и их родителей. Мы поставили смартированную цель.
"Повысить средний доход выпускника школы на 30%, сократить срок от поступления в первый класс, до получения первого дохода на 3 года".
Цели — не всегда финансовые. Однако алгоритм достижения любой цели, всегда один и тот же. А финансы легче считать.
Однако мы отдаем себе отчет, что финансовые цели будут не у всех, а значит на самом деле дельта должна быть ещё больше.
Пока всё. То что мы делаем прямо сейчас рассказывать не буду. Дальше скорее мои мысли о том, почему я лично горю этим продуктом и думаю, он реально самый крутой.
Это продукт, который должен (иначе цель не достигнуть) попасть к 80% школьников РФ. Масштабно!
Это образование — самый сильный рычаг изменения мира (потому что меняет как в моменте, так и в будущем, за счет выращивания нового поколения)
Пятница
Я до сих пор помню, а после интервью с детьми, вспомнил ещё ярче, как скучно было учиться в школе. Это наш шанс поменять ситуацию
Поднять доход выпускника школы на 30% — это огромный толчок среднего дохода в стране, а значит буст всего благосостояния страны
И даже если не смотреть в 2030 год. Планы на этот! 2021 год!
Освободить школьникам 15 миллионов часов, только за этот год. Часов, которые мы сможем наполнить актуальными, полезными и интересными детям материалами.
Короче, это круто!
Если вдруг вам тоже интересно, запрыгивайте в ракету, есть еще пара мест.
Ну что, пятница!
Рассказываю как запускать продукты за одну неделю, а также о том, что нужно, чтобы максимизировать вероятность того, что продукт полетит!
База: не важно запускаем мы новый продукт, или решаем срочную проблему в текущем, нам нужен план.
Причем, неожиданно, но чем меньше времени у вас на запуск, тем детальнее должен быть план, а значит больше времени необходимо потратить на его составление (и потратить эффективно).
Пока у вас нет плана до запуска продукта — у вас должен быть как минимум план на первый день. В том числе, в нем должен быть план того, как получится долгосрочный план. Inception!
Если вы хотите запустить что-то быстро, вам придется микроменеджерить, в данном случае, это необходимость. Всем необходимо быть в максимальном синке и точно знать кто что делает
Для такого синка, нужно много коммуникаций, что опять же для многих звучит контр-интуитивно (работать надо а не болтать).
На запуске, у нас были:
Синк всех тимлидов в 9, синк продуктового направления в 9:30, синк разработки в 10, чек в обед, демо вечером.
Как я уже сказал, план должен быть
Сразу до запуска продукта
Подробным
Но конечно же, на ближайшие часы/дни он проработан всегда больше, чем на дальние.
И самое важное! Абсолютно нормально постоянно переделывать план.
В первый день работы над тетрадкой, мы думали, что будем делать систему для проведения онлайн урока. Нарисовали архитектуру и собрали первую заготовку.
Однако вечером на основе ресерчей за день поняли, что это не нужно, автоматизация проверки дз в разы востребованнее.
Суббота
Чтобы запустить продукт за неделю, вы должны минимизировать блокирующие зависимости в работе.
Лучше всего этому помогает фулстечность членов команды. Разработчик не всегда должен ждать дизайнера, продакт не должен ждать аналитика и тд. Чем более фулстечная команда — тем лучше.
Помимо фулстечности, опять же планирование.
Продакт нарисовал схему интерфейса в miro -> дизайнер пошел дизайнить -> разработчики расдробили на задачи -> начали делать те, где меньше верстки предстоит -> аналитики расписали где какие ивенты и пошли делать датасорс на мок-данных
Итого:
- Микроменеджмент
- Детальнейший план до запуска
- Максимальная синхронизация
- Фулстечность
Следующий тред про людей будет
Вчера вневременно пошел спать, так что тема продолжается.
Как собирать команду, чтобы запустить успешный продукт за неделю.
Погнали!
Только синьоры
Дело не только в том, что они делают быстрее и качественнее — это не главное. Главное, что синьора можно оставить без перепроверки, он более самостоятельный и вы доверите ему принятие важнейших решений.
В каждом направлении должен быть тимлид, которого уважают и который будет иметь власть
В обычном режиме работы это не так критично
В режиме спринта — может быть некогда долго спорить. Тимлид должен иметь возможность без эскалаций вынести вердикт, которому все последуют
У тимлидов должна быть власть увольнять людей из команды без промедления
Увольнять из команды != увольнять из компании. Компания потом разберется, но если человек мешает команде работать — нет времени на медиацию и прочий коучинг
В команду нужно подобрать людей, для которых достижение общей цели интереснее, чем потешить своё эго в моменте
Эгоисты — это прекрасно, но эгоизм бывает разный, но если у вас будут эгоисты, которым важно быть важными здесь и сейчас — пункты 2-3 не сработают
Людей должно быть мало
Должны быть покрыты по максимуму все функции, но именно людей должно быть мало, чтобы сокращать коммуникации. В тоже время, не стоит одним человеком закрывать дизайн, ресерч и маркетинг. Человек не сможет сфокусироваться.
Добавьте в команду тимлидов проджекта/бизнес ассистента
С команд нужно снять всю орг. нагрузку. Заказать технику, инфраструктуру, выдать доступ, собрать материалы в один файл, собрать респондентов, профасилитировать встречу. Миллион нагрузки снимается одним бизнес-ассистентом
Команда должна быть готова отдаваться запуску фултайм и больше
Вам нужны люди, которые достигают цель, а не люди, которые "работают". Первые пару недель мы работали по 80 часов в неделю (некоторые трекают время и это не метафора). Но все сразу знали на что шли, это весело
А теперь просто советы, как сделать чтобы запуск был успешным.
Поставьте амбициозную измеримую цель и считайте её императивом. Не "протестировать рынок и узнать, есть ли там деньги", а "заработать 100 млн рублей".
Не "проверить гипотезу, что учителям нужен продукт с домашками", а "10 млн домашек к 15 июня"
С самого начала трекайте движение к этой цели. Ежедневно, еженедельно отслеживайте в красной или зеленой зоне находитесь.
Жесткий регулярный менеджмент с самого старта дает команде понимание, что есть только один сценарий — достичь цель
Празднуйте маленькие победы. Первый релиз, красивые цифры, публикации. Отмечайте это, пишите эмоциональные посты, заряжайте команду.
Проводите ресерч на самых ранних этапах продукта и не останавливайте его никогда. Минимального времени на ресерч не существует. Можно сделать за 4 часа и уже получить ценное знание. Делайте пивоты.
Будьте жесткими по отношению к несработавшим наработкам. Всё время ищите фичи, которые надо удалить из продукта. Неиспользуемая фича — затраты. Удаленная фича — знание.
Абсолютно все в команде должны общаться с пользователями и использовать продукт на регулярной основе. Помимо этого, очень важно настроить канал сбора фидбека от пользователей пространство, доступное всем в команде
Идеальное команда строится под руководством тандем из сильных продуктового и операционного менеджера. Вероятность, что это один человек — сильно мала.
Воскресенье
Последний день веду этот аккаунт. Напишу немного про то, как работать со стратегией продукта и буду заканчивать.
А пока заранее опрос
Как вам неделя?
Как сделать крутую стратегию продукта я не расскажу, потому что у каждого продукта, на разных рынках она разная. Однако, последний тред будет про то, как встроить регулярную работу над стратегией в рутины менеджера.
После старта продукта, очень легко завязнуть в экзекьюшене недельных и квартальных планов, напрочь забыв про долгую перспективу
Самый простой способ этого избежать, на уровне календаря забронировать себе минимум трехчасовой слот в неделю Strategic time.
Ваша задача на этот слот — не думать про ваш продукт сегодня. Необходимо с нуля анализировать рынок, пользователя, его проблемы, конкурентов. Искать средства монополизации, нечестные конкурентные преимущества, новые способы решить проблему в 10 раз эффективнее
Чтобы думать таким образом, лучше вообще не начинать с продукта. Можно начинать с базовых циклов на вашем рынке. Всё время рекомендую визуализировать.
Рисуйте карты взаимодействия субъектов в системе, анализируйте их цели и ищите базовые проблемы, которые двигают рынок.
Ниже я приведу пример рассуждения, который мне очень нравится. Примерная схема рассуждений Илона Маска о том, как придумать Neurolink. Она отлично иллюстрирует суть подхода к поиску фундаментальных проблем и анализу возможности их решить. Поехали.
Идея: сделать максимально быстрый интерфейс Мозг - Компьютер. Задача стоит давно, пока самый быстрый интерфейс это клавиатура, но он пипец долгий.
Начинаем искать проблему, почему интерфейс до сих пор не создан. Можно ли считать информацию из мозга?
Как считать из мозга информацию: уже давно известно, что есть особые волны, их можно улавливать и в дальнейшем расшифровывать на компьютере. Ок.
Есть ли датчики, которыми можно считать эти волны? Да, можно сделать специальные электроды, они поймают волны и передадут их дальше.
В чем тогда проблема? В том, что никто пока не придумал, как поместить электроды в мозг, чтобы дальше все заработало
Ок, почему это проблема? Потому что твердый электрод, если его засунуть в мозг, вызывает реакцию и вокруг него образуется что-то по типу мозоли и мозг умирает
Ок, есть ли другие варианты?
Есть мягкие электроды, они не вызывают такой реакции.
Ок, в чем проблема их использования?
В том, что электрод нужно поместить достаточно глубоко, а мягкий электрод это нитка, очень сложно нитку в желе засунуть глубоко.
Это не похоже на фундаментальную проблему, нитку в желе можно засунуть с помощью иголки, можно ли это использовать в случае мозга?
Да, но мозг это очень деликатное желе, в котором очень много сосудов, чтобы провести туда нитку, нужно обойти все сосуды, обычная швея промахнется
Ок, нужна сверхточная швейная машинка, и сверхдетальная карта мозга, чтобы построить алгоритмом по ней маршрут, для иголки с электродом.
Есть ли с этим проблемы? Карту мозга делать уже умеют, есть сканеры специальные, а вот машинку еще не создавали, не нужно было.
Легким движением руки, у нас получился стартап, где нужно построить швейную машинку и написать алгоритм расчета траектории иголки. Внезапно, научная фантастика становится детальным планом по достижению цели. Есть еще проблемы с отторжением электрода, но их можно решить химией.
Этот пример — один из вариантов рассуждений, которые могут быть у вас на Strategic time. По сути вы с нуля придумываете продукты, чтобы затем понять, как это можно использовать в вашей ситуации.
Конечно не только так, можно изучать конкурентов и их слабые места, можно пытаться понять базовые цели всей системы рынка, на которой вы работаете. Вот мы делаем детское образование. Можно посмотреть как на систему "онбординга в жизнь", а можно как на "KPI министра образования"
Короче, можно очень много разрезов смотреть, никогда не знаешь, где окажется самый полезный инсайт. Тут конечно я в очередной раз выскажусь за строгость менеджмента: если вы размышляя нашли какое-то важное знание, вы должны запланировать его внедрение
Как минимум: сделать воркшоп для команды тимлидов и рассказать к чему пришли. Цель — систематизировать знание, пока вы готовитесь к встрече, а также расшарить его компетентным людям, для максимизации вероятности, что кто-то придумает как его развить.
Как максимум: конкретный план, как вы из своей идеи получите профит. Запуск нового продукта, пивот текущего, новая фича, новый канал привлечения и тд...
Ну что, время прощаться.
Самая крутая вакансия для сильного продакта: notion.so/skyengteam/Sen…
Также ищем CTO и Unity-разработчиков!
Со мной можно поболтать в фейсбуке: facebook.com/dmitriyabr/ или найти в телеге t.me/dmitriyabr
Ссылки на лучшие треды в треде :)
Ключевое про найм и развитие продуктовой команды. Простое правило: нанимать сильных, увольнять слабых, это понятно. Здесь расскажу про то, на что я обращаю особое внимание.
Регулярный менеджмент: twitter.com/produnderhood/…
Формулировки: twitter.com/produnderhood/…
Скрам: twitter.com/produnderhood/…
Канбан: twitter.com/produnderhood/…
Продуктовая команда, состав: twitter.com/produnderhood/…
Продуктовая команда, найм: twitter.com/produnderhood/…
Вчера вневременно пошел спать, так что тема продолжается. Как собирать команду, чтобы запустить успешный продукт за неделю. Погнали!
Ночные мысли про эффективность: twitter.com/produnderhood/…
Продуктовый фреймворк: twitter.com/produnderhood/…
Что за продукт я делаю: twitter.com/produnderhood/…
Как запускать продукт за неделю: twitter.com/produnderhood/…
Команда для крутого запуска: twitter.com/produnderhood/…
Как сделать крутую стратегию продукта я не расскажу, потому что у каждого продукта, на разных рынках она разная. Однако, последний тред будет про то, как встроить регулярную работу над стратегией в рутины менеджера.
Советы для успешного запуска: twitter.com/produnderhood/…
Как системно работать со стратегией: twitter.com/produnderhood/…
Надеюсь было интересно, крутанов жду к нам в команду, остальным просто удачи и хорошего настроения xD
