Интенсив «Level Up 2.0: старт в продакт-менеджменте» 🤩

Product Star проводят очередной интенсив для начинающих продактов. Как тот, на котором выступал я сам.

В этот раз тоже будет куча полезного:
✦ про продуктовые метрики - уже сегодня
✦ про когортный анализ
✦ про CustDev
✦ про дешёвую проверку гипотез

Короче, сплошной поток must have скиллов. Всего 8 выступлений от тех, кто практикует эти скиллы в ежедневной работе.

Как обычно, у PS это сопровождается:
✦ возможностью задавать вопросы в чате спикерам
✦ розыгрышем сертификатов на курсы PS на общую сумму 560 000 рублей
✦ бесплатными карьерными консультациями
✦ и не только…

С 5-го по 19-е октября в 19:00. Да, он уже стартовал. И выступление Миши вы уже пропустили (можно посмотреть в записи). Не пропустите вторую серию сегодня. ☝️

Полная программа интенсива и регистрация здесь.

#промо

Про продуктовые команды 🤝
(Часть 4 - Teach-Lead и Project Manager)

Scrum Guide декларирует равноправие членов команды. Нет руководителей, ответственность только коллективная. На практике "самоорганизующиеся команды” - скорее миф. Как я уже описал выше, роль руководителя возлагается на продакта, как ответственного за результат в терминах достижения целевых метрик.

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

Но за пределами бизнесовых вопросов есть ещё огромный пласт технической реализации и предсказуемого delivery.

Чтобы мозг продакта не взорвался окончательно от необходимости вникать и в эти аспекты, и Сбер, и Яндекс вводят в командах роль teach lead. Получается довольно гармоничное разделение: продакт решает “что делать”, а Tech-Lead - “как делать” и "кому делать”. (Sporify Tribes, прообраз Сберовских трайбов, существуют по схожей логике. И да, это очень похоже на обычную матричную структуру.)

Предполагается, что Tech-Lead обычно отвечает за:
✦ классический people management: мотивация, 1-1, найм…
✦ delivery: предсказуемость и скорость, оптимизация процессов…
✦ унификацию технических аспектов в рамках компании: технологический стек, правила работы с репозиторием…

Но я чаще встречал ситуации, когда это работает не полностью. Tech-Lead чаще обладает глубокой экспертизой, чем скиллами типичного менеджера (или стоит очень много). Поэтому продакту, наверняка, придётся разбираться в том, как выстраивать эффективный процесс разработки. Потому что, если delivery хромает, количеством кастдева/аналитики эту проблему не решить.

Приходя в новую команду, я склонен врываться в оптимизацию процессов, пока не "обучу нейронки" команды действовать с понятной мне логикой. Когда статусы задач в таск-трекере начинают отражать реальную картину, и становятся достаточно прозрачными, чтобы не выяснять каждый раз “а это мы зачем делаем?", я постепенно перестаю участвовать в Daily. Planning и Retrospective остаются в календаре продакта насовсем - без них потеряешь связь с реальностью. (Если опыта в построении эффективных процессов пока немного, рекомендую “Цель” Голдратта - ставит мозги на место, послужит неплохим базисом.)


В вопросам требующих сложной координации появляются и Project Manager’ы. Они могут быть быть как частью конкретной команды, если у неё много завязок с окружающими, так и координировать большие проекты, вовлекающие множество команд и подразумевающие жёсткие deadline. (В Яндекс.Браузере, судя по рассказу Галины Митричевой, всё ещё интереснее.)

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


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

#product_teams #product_management #tech_lead #project_management

Про продуктовые команды 🤝
(Часть 5 - Soft Skills)

Не смотря на наличие Tech-Lead’а, работать с командой только через него не получится. (Это будет жалким подобием работы реальной продуктовой команды.) Взаимодействие продакта с командой составляет от 20 до 70% рабочего времени. Поэтому быть хорошим продактом без прокачанных soft skills почти нереально.

Если конкретнее, то из essential для продакта soft skills я бы выделил:

✦ Умение делиться информацией. Очень рекомендую погружать команду в контекст исследований и логику приоритизации задач, держать в курсе долгосрочной стратегии и результатов работы - обратной связи от руководителей/заказчиков/рынка. Больше информации - сильнее чувство "причастности" и возможность принимать лучшие решения. Например, проектировать новую фичу с учётом перспектив её развития.

✦ Совместное принятие решений. Если информацией делились достаточно, то команда, с минимумом подталикиваний, поможет генерить идеи и качественные решения. Генерация идей в коллаборации мозгов, почти всегда лучше, чем в одиночку - позволяет компенсировать собственные слепые пятна. Особенно, поиск оптимальных в плане трудоёмкости и ценности вариантов. Даже просто возможность отрефлексировать логику в процессе рассказа про неё крайне полезна - легче заметить шероховатости, донося идею до кого-то. Не вваливайтесь в “я руководитель, поэтому слушайте меня” - это тупиковая ветвь, когда команда просто "смотрит в рот" продакту, даже не пытаясь самостоятельно думать.

✦ Делегирование. Нужно учиться доверять команде - что запланированная задача будет выполнена. Типичная ошибка: “если не проконтролировать, всё сломается” приводит к микроменеджменту. За стремлением контролировать всё часто прячется потребность доказать самому себе свою нужность, постоянно работать на разрыв, чтобы удовлетворить внутреннего критика. На самом деле, если постоянно контролировать, то это никогда не закончится - члены команды будут ждать пинка, без которого ничего не работает. Нужно иногда "отпускать" и просто наблюдать результат, позволять команде учиться на своих ошибках. Сколько свободы давать - очень тонкая грань, экспериментируй.

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

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

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

#product_teams #product_management #soft_skills

Про продуктовые команды 🤝
(Часть 6 - Тесное взаимодействие vs Документация)

Бонусом от тесного взаимодействия продакта с командой является отсутствие необходимости в излишней детализации требований. Как детализация является излишней - ситуативно.

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

При этом (имея опыт работы с 7+ подрядчиками по fix price) я ни разу не встречал такого документа с требованиями, к которому бы не возникало вопросов в процессе разработки. А возникающие вопросы в старой модели взаимотношений "заказчика” и "исполнителя” это приводит к одному из двух сценариев:
✦ "ну тогда сделаю на своё усмотрение" - и будет плохо, потому что, кроме чтения этого документа, я вообще хз что мы делаем
✦ "ваши документы плохие, не могу работать" - постоянные простои в работе и пинг-понг по статусам

А в ситуации, когда команда разработки погружена в контекст, “на своё усмотрение" внезапно оказывается отличной стратегией. Чем больше нейронки команды обучаются принимать правильные решения самостоятельно по обратной связи от продакта, тем меньше потребность в детализации документов. И тем больше продакт мозг продакта освобождается для принятия судьбоносных для продукта решений, вместо расписывания логики работы каждой кнопки.

Казалось бы, проблему можно решить введением роли бизнес-аналитика - продакт описывает требований верхнеуровнево, а аналитик детализирует. Но на практике этот механизм ломается об:
✦ разработчики спихивают принятие даже мелких решений на БА - он становится bottleneck’ом
✦ даже сильно вовлечённый в контекст БА будет отчасти сломанным телефоном - продакту приходится вычитывать все подробности и убеждаться, что его поняли верно
✦ если решать прошлую проблему обсуждениями "всем вместе”, то БА превращается в "писаря" - всё обсудили, все поняли, а Коля зафиксирует

В Сбере и Яндексе требования к подробности документации сильно варьиюруются от команды к команде. Но даже самая подробные из встреченных мной там документов не идут ни в какое сравнение с BRD от бизнес-аналитиков в Ренессанс Кредите, где один только процесс их согласования мог занимать месяцы. (Угадаете, какой в РК был T2M?)

Ещё один бонус от не_слишком детальных требований - их не так обидно отбрасывать, когда выяснится, что задуманное слишком трудоёмко в реализации. А на стадии формирования MVP фичи/продукта стадия потрошения неизбежна.

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

На мой субъективный взгляд, тесное взаимодействие при, всех его недостатках, бьёт детальную документацию, если для бизнеса критична скорость доставки функционала. (А это почти все компании в текущих реалиях.) Естественно, сильно зарегулированные (банки, здравоохранение…) или высоко-рисковые индустрияи (авиация, энергетика…) накладывают свои ограничения - там всё немного иначе.

Делитесь информацией с разработкой, не считайте их просто "руками" - это окупится ростом самостоятельности. 🤓

#product_teams #product_management #documentation

Про продуктовые команды 🤝
(Часть 7 - Кто разрабатывает, тот и поддерживает)

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

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

*Здесь и далее речь про 2-ю линию с теническим уклоном. 1-ая линия, общаюящаясь с клиентом, конечно, никуда не денется.

"If a human operator needs to touch your system during normal operations, you have a bug." - Carla Geisser, Google SRE.

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

Когда команда сама поддерживает функционал, выработка более качественных решений неизбежна, иначе растущей технический долг и количество порождаемых им инцидентов однажды приведут к тому, что весь ресурс команды станет уходить на "выплату процентов”

Поэтому и в Яндексе, и в Сбере большинство команд поддерживают сами тот функционал, который разрабатывают. Соотношение ресурсов на решение инцидентов и разработку новых фичей определяется в диалоге продакта и Tech-Lead’а Сверху за этим приглядывают ребята из поддержки. Но их роль не в решении инцидентов, а в
✦ координации решения особенно крупных факапов
✦ разбор их причин и предотвращении их повторения
✦ развитии систем мониторинга

Баланс между развитие и поддержкой хорошо раскрывает концепция "error budget" из Google SRE. (Хотя, во всей книге речь скорее про отдельные развитие и поддержку.) Если коротко, то суть сводится к тому, что инцидент неизбежны, если продукт развивается. Отсутствие инцидентов = отсутствие изменений = проигрыш рынка конкуренту. Баланс между развитием (внесением возмущения в прод) и стабильностью сводится к бюджету даунтаймов. Например, 10 часов в квартал сервис может быть недоступен, и это нормально. Но, как только бюджет израсходован, новые фичи не выносятся в прод, а все ресурсы разработки до конца квартала переключаются на повышение стабильности. Размер бюджета отражает понимание бизнес владельцев систем об относительных приоритетах непрерывности сервиса и развития нового функционала.

Ещё одним преимуществом поддержки функционала самой командой является то, что инциденты попадают на глаза продакту. (По крайней мере, критичные.) Будучи погружённым в контент, он может понять реальный приоритет проблемы, чтобы бы ни было по этому поводу написано в тикете. Например, можно не чинить функционал, если мы уже запланировали его замену целиком. Или можно найти компромиссное решение, закрывающее конкретный проблемный кейс костыльно, но быстро. Такие "пируэты" невозможны, когда решением инцидентов занимается поддержка в силу несравнимо худшего понимания контекста.

Будьте в курсе инцидентов - помогает не терять связь с реальностью и не забывать о corner-кейсах, фантазируя невероятные новые фичи. 🙄


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

#product_teams #product_management #support

Цитаты: Тупые вопросы 🤨

Прочтите короткий пост в источнике. Егор шикарно сформулировал.

Невозможно сосчитать, сколько раз ещё до прочтения это цитаты я задавал вопросы:
✦ А почему нельзя сделать так: … ?
✦ А зачем мы это делаем?
✦ А что такое ...?
✦ А почему процесс такой?
✦ А как это работает?

Вообще всем вокруг. Начальству. Коллегам. Подчинённым. Архитекторам, когда ничего не знал про архитектуру. Аналитикам, первый раз видя их дэшборды.

И эта способность неизбежно приводит к дичайшей скорости моей адаптации. На вопрос, в чём я хорош, я обычно отвечаю именно так: “Я быстро адаптируюсь/учусь.” Обратная связь подтверждает: руководители охреневают именно от моей скорости включения.

Кажется, способность базируется на фундаментальной уверенности “я не тупой” - тогда не страшно казаться тупым. И с каждый разом всё менее страшно, потому что через Х итераций ты становишься прокачаннее тех, кто считал тебя тупым. Это явно следствие воспитания. Не знаю, можно ли развить во взрослом возрасте, но пробовать точно стоит.

И ещё пара напутствий:
✦ Если на твой вопрос не могут ответить доходчиво, то одно из двух: либо человек сам не разобрался достаточно глубоко, либо ты пока, и правда, не в силах осознать ответ. Распознавать буллшит - отдельный скилл.
✦ Да, можно погуглить или почитать доку, но это дольше. Нужно учиться интуитивно чувствовать баланс, когда быстрее спросить, а когда не отвлекать и поискать ответ самому.
✦ “Тупые” вопросы работаю ещё круче при переходе из одной индустрии в другую. Начинаешь привносить подходы, о которых здесь и не задумывались.
✦ Если в компании не принято задавать “тупые” вопросы, беги из такой компании. Там нечего ловиться - вот там ты реально станешь тупым.

Больше тупых вопросов! 😜

#quotes #about_me #stupid

Отзыв на книгу “Dune” by Frank Herbert
(aka “Дюна”)

Ozon | Amazon

“Дюна” великолена - лучшая научная фантастика, что я читал. Входит в топ-3 моих любимых художественных книг. (Остальные две: “Стрелок” и “Убить пересмешника”.) Здесь плотно замешаны политика, религия, генетика, судьба и предвидение.

Вселенная, которую придумал Герберт, поражает своей многогранностью и продуманной предысторией:
✦ Бене Гессерит, десятки поколений закулисно занимающиеся селекцией ради получения своего Квизац Хадерача.
✦ Ментаты - люди, способные проворачивать в уме вычисления на уровне компьютера, пришедшие на смену умным машинам после Бутлерианского джихада.
✦ Гильдия, имеющая монополию на межпланетные перевозки, с навигаторами, обладающими даром предвидения для прокладывания курса между звёздами.

И много чего ещё… Просто отрыв башки! 🤯

А ещё после тантры совсем иначе ощущаются упоминания “предназначения” и “сознания рассы”… От этого ещё сильнее кроет.

Перечитал перед походом в кино. На удивление, фильм не разочаровал. Историю пришлось сильно упростить, чтобы уместить в экранное время. Но атмосфера хороша.

В общем, очень рекомендую. 😉

#books #novel

Всё по-взрослому 😄

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

Но в сентябре произошло ещё одно важное изменение, которое для большинства из вас прошло незаметно. Взрослому блогу положен взрослый логин. Поэтому блог прееехал с @vaduz_pro_product на @side_effect. (Это было не очень просто, но об это позже.)

А в эти выходные я актуализировал все использовавшиеся ссылки на предыдущие посты и попутно привёл в порядок хэштеги. Поэтому встречайте актуальный набор тематик.

Надеюсь, он поможет новым подписчикам находить ценное среди старых постов - в них было вложено немало души. 😄

#blog

Тематики канала

#longread - выжимка знаний по темам, в которых я (кажется) разобрался, заслуживают отдельного внимания:
✦ Инсайты за год работы в сфере целевого маркетинга - по результам года работы в Яндекс.Маркете
✦ Как стать продактом? - прикладное руководство по мотивам 2-х лет прокачки, 4-х работ и 50+ собеседований
✦ Про продуктовые команды - главное за 6+ лет в менеджменте разработки ПО
✦ Рефклексия 2021 - результаты года на фоне психотерапии и тантры

#mindfulness - всё про осознанность, включая #tantra и #psychotherapy
#books - отзывы на книги и всё, что связана с книжной тематикой
#about_me - про меня, путь развития, странности
#product_management - всё про управление продуктами
#marketing - всё связанное с маркетингом, включая мой личный опыт
#support - про поддержку пользователей
#tools - инструменты, которые я использую и люблю, полезные хинты
#quotes - цитаты, которые повлияли на мой образ мышления
#thoughts - мои рассуждения на разные темы
#UX_heaven и #UX_hell - примеры крутого и отстойного клиенского опыта
#eatandtalk - мои встречи с интересными ребятами
#blog - всё про развитие этого блога

Я в других соцсетях 👋
✦ Facebook
✦ Instagram
✦ LinkedIn
✦ VK

А ещё есть “свой” стикер-пак! 😉

“Кэш почисти”

Узнал недавно модный способ чистить кэш конкретной страницы в Chrome:
✦ вызываешь “Inspect”
✦ кликаешь правой кнопкой на “Обновить страницу”
✦ выбираешь “Empty cache and hard reload”

Экономит нервные клетки, когда слышашь в очередной раз “кэш почисти” от фронт-разработчика. 😅

#tools #lifehack

С психотерапии: Удовлетворение от работы 🙄

Буду делиться особо интересными инсайтами, которые вынес с сеансов психотерапии.

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

Получилось разобраться, что для меня есть 4 способы получить удовлетворение от работы:

✦ Превзошёл ожидания. На предыдущих местах работы случались ситуации, когда делал что-то по-настоящему классное. Такое, что даже внутренний критик не мог обесценить это. Ещё на первой работе, оператором в колл центре, разобравшись с особо сложным случаем, я удовлетворённо потягивался в кресле и восклицал “да я просто охуенен!” (Некоторые воспринимали это как “вы все говно”, но это отдельная история.) Но планка “действиетльно классного” поднимается с каждым разом всё выше.

✦ Вижу результат своей деятельности. Выпустил задачу в прод - уже нанёс микро-пользу. Но сейчас большинство моих проеков - долгострои. И от момента начала формулирования до момента “клиент получил новую игрушку” иногда проходят месяцы. За это время дофаминовые запасы сильно истощаются. Ещё это круто работает, когда есть возможность менять процессы. Например, после каждого ретро с командой видеть, как ускорился delivery. Но сейчас я очень мало участвую в жизни разработки.

✦ Чувство завершённости. Альтернативный источник удовлетворения: “я разгрёб все задачи”. Но в какой-то момент я забил на формирование скоупа на день/неделю, а стал работать с полным списком всего, что хорошо бы сделать. А этот список, очевидно, бесконечен. Получается, что, сколько бы я ни пахал, уходя домой, я вижу ещё 150 задач в бэклоге из 155 на начало дня.

✦ Похвала извне. Позитивная обратная связь от начальства/коллег. Она есть, но я сам её обесцениваю. У меня часто включается “я сам лучше знаю, когда я по-настроящему хорош”. И я пропускаю чужую похвалу мимо ушей, воспринимая её как недостойную внимания, или как должное.

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

✦ Праздновать микро-победы. Дописал один раздел требований - уже молодец! Запилил классный дизайн - красавчики! (Об этом упоминает Харитон здесь.) Этому нужно учиться - не обесценивать то, что кажется мелочью, а давать этому больше внимания.

✦ Принимать похвалу. Даже если незнакомая бабушка на улице поблагодарила за помощь и сказала, что ты молодец, этому можно порадоваться. Внутренне согласиться с этим, а не “любой бы на моём месте”. Нет, не любой. Да, и правда, молодец. А уж если коллега сказал, что тобой восхищается - сам бог велел порадоваться.

✦ Таки планировать заранее день/неделю. Выбирать таски из общего бэклога и радоваться, если осилил хотя бы 80%. Scrum про то же. Даже если фичу пилить полгода, у каждого спринта есть goals, не позволяющие отвлекаться. И цель спринта - достичь целей спринта, а не грустить, глядя на бэклог продукта.

Большие достижения складываются из множества маленьких шагов. Радоваться только “на вершине Эвереста” - значит, тащить себя весь путь на вершину на одной силе воли. А наслаждение жизнью проистекает из кайфа от процесса, а не от результатов. 😉

А как вы получаете удовлетворение от работы?

#mindfulness #psychotherapy

Очень важное уведомление от банка, ради которого мне кинули push и заставили залогониться в приложение. 🤦‍♂

#UX_hell

Как не убить свой стартап?

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

Начал с формулирование принципов, по которым я хочу двигаться. В этом мне помог пост Димы Грудина. Опыт неудачных запусков ценнее, чем сказочные истории с конференций.

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

А в канале @mooveprogramme хорошая смесь советов для начинающих стартаперов и материалов, помогающих быть в теме актуальных трендов. Думаю, многим поригодится. 😉

#промо

Тишина в эфире 🤫

Периодически я ощущаю что-то непраильное в том, что редко пишу в блог. (Это не чувство вины.) Но затишью есть несколько весомых причин. Хочу ими честно поделиться.

1. Запара на работе, в хорошем смысле этого слова. Нет, я не работаю по 60 часов в неделю. (Раньше так делал, надеюсь, это не повторится без веских на то оснований.) Но в рабочее время я занят на все 100% - нужно много и быстро думать, решать сложные задачки. Поэтому нет времени думать о чём-то другом. После окончания дня “язык на плечо", а мозг постанывает от усталости. Я неплохо представляю, сколько это продлится, и какой результат принесёт. В этом конкретном случае “игра стоит свеч”.

2. Осознал, что мало читаю. Мне нравится думать, что сам факт чтения книг время от времени уже позволяет мне войти в топ-5% самых читающих людей планеты. Но всего 6-7 книг, прочитанные за 2021 год меня скорее разочаровывают. Потому что на полке уже скопилась “очередь” из 20 непрочитанных. И я продолжаю их покупать, ничего не могу с собой поделать - это мой guilty pleasure. Теперь стараюсь выделять время на чтение регулярно - надеюсь в 2022 улучшить метрику, хотя бы, вдвое.

3. CustDev Замесина. Я вписался в курс Вани. Слышал про него разные отзывы - решил сформировать своё собственное мнение. (К тому же, бюджет на обучения до конца года нужно было куда-то потратить, пока не сгорел.) Мне казалось, что я неплох в интервьюировании, но в процессе узнаю много нового - действительно недооценивал JTBD. Так вот, чтобы получить “классный” диплом, нужно за время курса (24 дня) успеть провести 16 JTBD-интервью (10 в случае B2B) и 6 UX-тестов. Это примерно по созвону в день, помимо основной работы (совмещать не получается). Можно было бы махнуть рукой и получить “не самый классный” диплом, но обычно я так не делаю.

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

Поэтому пока так. 🤷‍♂️

#blog #books #learning

Notion и платная подписка 😧

У Notion шикарный сценарий перехода к платной подписке! 😄

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

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

1000 записей вполне достаточно для небольшой команды, чтобы ощутить все преимущества продукта. А внезапность произошедшего не оставляет особо времени на размышления.

У меня бесплатные блоки закончились в момент спешной подготовки к проведению JTBD-интервью. Представьте:
- до интервью осталось 5 минут
- я в спешке после прошлой встречи дописываю скрипт
- в процессе “бац!” и не могу создать следующую строку
- сверху красная строка с одной кнопкой “Upgrade plan”
- по клику открывается сразу страницу оплаты, не нужно думать

Рука автоматически потянулась скорее оплатить подписку и продолжать. Потому что “мне же нужно прямо сейчас!” Потребовалось усилие воли, чтобы остановить себя, минутку подумать и просто продолжить написание скрипта в личное пространстве Notion.

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

При этом, в отличие от более ушлых сервисов, Notion позволяет вполне безболезненно скопировать всю информацию или выгрузить в CSV/PDF. То есть, нет ощущения манипуляции “взяли в заложники результаты моего труда”.

Кстати, Notion оценивается в $10 billions, при штате в 200 сотрудников. 😅

#product_management #Notion #tools

Иллюстрации. ⬇️

Отзыв на книгу "How to get rich" by Naval Ravikant
(aka "Как стать богатым")

Amazon | Nav.al | Zamesin (перевод)

Биография Наваля говорит, что его советы на эту тему стоит слушать.

Книга представляет себя транскрипцию подкаста, в которой Наваль и Ниви разворачивают идеи из Tweetstorm'а Наваля How to Get Rich (without getting lucky). Это не практическое руководство, а набор идей и принципов.

Вот главные, что я для себя вынес:

✦ Богатство - это positive-sum game (в отличие от статуса). Чем больше людей имеют дома, тем дешевле и эффективнее процесс их постройки ⇒ ещё больше людей могут позволить себе дома.

✦ Существует 4 вида удачи:
1. Слепая удача - покупка лотерейного билета
2. От суетливости - много делаете, создаёте много возможностей, одна из них может "прокнуть"
3. От предварительной работы - уметь видеть возможности, когда они возникают, за счёт опыта
4. От уникальных качеств - обладать уникальными навыками, которые в определённый момент понадобятся кому-то

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

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

✦ Рычаги ранее представляли из себя либо человеческие ресурсы, либо богатство. Но в современном мире им на смену приходят продукт и медиа. Многие цифровые продукты не имеют стоимости производства "ещё одной копии" - это позволяет не растить штат. А медиа дают безграничные возможности поиска аудитории даже очень нишевой информации. Поэтому рычаги стали доступные намного большему числу людей.

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

✦ Чистый интеллект без реального опыта - опасная штука. Он создаёт иллюзию, что можно приложить его к любой области. Но без опыта невозможно предугадывать corner-кейсы. Поэтому переход из одной области в другую - это потеря накопленного прогресса.

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

✦ Важно быть верным себе. Вместо того, чтобы "переделывать" себя под потребности мира, полезнее понять, в чём ты уже хорош, что доставляет тебе удовольствие (обычно коррелирует). Если в тебе есть такая комбинация скиллов, которая может быть востребована рынком, это только вопрос времени, когда она потребуется.

✦ Верность себе позволит избежать конкуренции. Никто не может быть тобой лучше, чем ты. Конкуренция часто скатывается в банальное копирование. Уделение ей излишнего внимания отвлекает от концентрации на том, что действительно важно.

✦ Достаточно входить в топ 25% лучших в 3-х разных навыках, чтобы быть супер-востребованным в определённых случаях. Это намного проще, чем быть топ-1 в одном навыке.

✦ Постоянно учитесь. Читайте книги, учитесь на работе, пробуйте новые подходы. Если текущая работа непрямую не ведёт к богатству, ищите способы осваивать на ней новые навыки, которые пригодятся, когда станете предпринимателем. Берите ответственность, чтобы учиться на практике. В идеале, работайте с тем, у кого хотите учиться.

И ещё куча крутых выводов, которые не помещаются в пост. Сплошное золото. 😲

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

#books #entrepreneurship