B2B SaaS: Customer Success* vs Product management 😤
(часть 1)
*Customer Success (далее CS) - это client-facing подразделение, отвечающее за отношения между компанией и клиентами и помогающее клиентам решать их бизнес задачи с помощью SaaS (и не только) продукта.
Название - шуточный кликбейт. Очевидно, что эти подразделения должны быть "за одно". Но шутка очень точно отражает, как это зачастую выглядит в реальности.
Я уже почти 2 года пытаюсь осознать для себя, что такое product management в b2b. В прошлом году уже писал лонгрид на эту тему.
Но сегодня после дискуссии за обедом с коллегой, восхитительной Юлей Беленковой, кажется, произошёл качественный скачок в понимании. Инсайтами и попробую поделиться.
Мы небольшая компания c (в моём случае) очень молодым продуктом, поэтому на плечи немногочисленных продактов ложится всё и сразу:
- писать требования
- следить за метриками
- интервьюировать клиентов
- отвечать на вопросы CS, Sales, Technical Support
- приоритизировать бэклог
- готовить аннонсы фичей
- исследовать рынок
- и ещё полсотни пунктов...
И я никогда не работал в больших B2B компаниях. Поэтому мои инсайты могут кому-то показаться очевидными, а кому-то оказаться совсем нерелевантными. Тем не менее... 😁
Проблема 1: Вовлечённость в операционку
В B2B продукте вопросы о функциональности продукта от клиентов никогда не иссякают. Есть 100500 специфических сценариев, для которых в продукте нет явного решения, но есть вариант придумать workaround.
С этой задачей зачастую не справляются сами CS/Sales, по очевидным причинам обладающие худшей экспертизой в продукте, чем продакты. И поэтому они непрерывно “генериют” работу для продакта.
Это приводит к тому, что продакт значительную часть своего времени тратит на операционку.
За неделю в отпуске у меня собирается от 30 до 50 mentions в Slack на вдумчивое разгребание которых я трачу в среднем 2-3 полных рабочих дня. Получается, от 40 до 60% рабочего времени. И это только такие вопросы, которые делегировать реально некому.
Это не абсолютное зло, потому что помогает лучше понимать потребности клиента и корнер-кейсы.
Но есть сильно негативный эффект: невозможность управлять ритмом. Можно день-два-три игнорировать Slack, но за это потом придётся расплачиваться.
Это приводит к тому, что у продактов нет времени "подумать".
Почему-то мне кажется, что в B2C в отсутствии Sales/CS это иначе. Там тоже конкуренты, желание вырасти и cashburn до выхода на самоокупаемость диктуют ритм. Но это не совсем то же самое.
Возможные решения:
1. Увеличить штат продактов: часть отвечает на вопросы, пока другая часть концентрируется на страгетегическом развитии
2. Выделить роли product expert внутри CS/Sales/TS: к кому идут с вопросами в первую очередь, а уже потом вместе с экспертом к продакту, если эксперт не справился
То есть, разделение на 1 и 2 линию обороны.
#product_management #b2b #saas
(часть 1)
*Customer Success (далее CS) - это client-facing подразделение, отвечающее за отношения между компанией и клиентами и помогающее клиентам решать их бизнес задачи с помощью SaaS (и не только) продукта.
Название - шуточный кликбейт. Очевидно, что эти подразделения должны быть "за одно". Но шутка очень точно отражает, как это зачастую выглядит в реальности.
Я уже почти 2 года пытаюсь осознать для себя, что такое product management в b2b. В прошлом году уже писал лонгрид на эту тему.
Но сегодня после дискуссии за обедом с коллегой, восхитительной Юлей Беленковой, кажется, произошёл качественный скачок в понимании. Инсайтами и попробую поделиться.
Мы небольшая компания c (в моём случае) очень молодым продуктом, поэтому на плечи немногочисленных продактов ложится всё и сразу:
- писать требования
- следить за метриками
- интервьюировать клиентов
- отвечать на вопросы CS, Sales, Technical Support
- приоритизировать бэклог
- готовить аннонсы фичей
- исследовать рынок
- и ещё полсотни пунктов...
И я никогда не работал в больших B2B компаниях. Поэтому мои инсайты могут кому-то показаться очевидными, а кому-то оказаться совсем нерелевантными. Тем не менее... 😁
Проблема 1: Вовлечённость в операционку
В B2B продукте вопросы о функциональности продукта от клиентов никогда не иссякают. Есть 100500 специфических сценариев, для которых в продукте нет явного решения, но есть вариант придумать workaround.
С этой задачей зачастую не справляются сами CS/Sales, по очевидным причинам обладающие худшей экспертизой в продукте, чем продакты. И поэтому они непрерывно “генериют” работу для продакта.
Это приводит к тому, что продакт значительную часть своего времени тратит на операционку.
За неделю в отпуске у меня собирается от 30 до 50 mentions в Slack на вдумчивое разгребание которых я трачу в среднем 2-3 полных рабочих дня. Получается, от 40 до 60% рабочего времени. И это только такие вопросы, которые делегировать реально некому.
Это не абсолютное зло, потому что помогает лучше понимать потребности клиента и корнер-кейсы.
Но есть сильно негативный эффект: невозможность управлять ритмом. Можно день-два-три игнорировать Slack, но за это потом придётся расплачиваться.
Это приводит к тому, что у продактов нет времени "подумать".
Почему-то мне кажется, что в B2C в отсутствии Sales/CS это иначе. Там тоже конкуренты, желание вырасти и cashburn до выхода на самоокупаемость диктуют ритм. Но это не совсем то же самое.
Возможные решения:
1. Увеличить штат продактов: часть отвечает на вопросы, пока другая часть концентрируется на страгетегическом развитии
2. Выделить роли product expert внутри CS/Sales/TS: к кому идут с вопросами в первую очередь, а уже потом вместе с экспертом к продакту, если эксперт не справился
То есть, разделение на 1 и 2 линию обороны.
#product_management #b2b #saas
🔥4
B2B SaaS: Customer Success vs Product management 😤
(часть 2)
Проблема 2: Качество обратной связи от клиентов
В любом B2B получается четырёхугольник взаимодействия: продакт, продукт, клиент, CS. Продакт доставляет клиенту ценность через продукт и получает обратную связь от клиента через CS.
У этого четырёхугольника есть существенный дефект - CS-менеджеры редко мыслят продуктово.
Во многих случаях получается следующее:
- Клиент приходит к CS с запросом на фичу и неизменным "срочно"
- CS ровно в таком же виде транслирует это продакту
- Продакт пытается получить подробности через CS
- Через сломанный телефон получается информация, не поясняющая суть проблемы
- Продакт отчаивается и идёт сам на созвон с клиентом
- Часто на звонке выясняется, что проблема надуманная или уже решена
В худших случаях, CS ещё клиенту на 2-ом шаге пообещал, что всё сделают в лучшем виде. 😅
И всё бы ничего, но продакт опять потратил время на реактивные действия по решению локальной проблемы, вместо стратегической работы над продуктом.
Это может быть оправдано в случае запроса от топового клиента, приносящего существенную долю MRR. Но не масштабируемо на остальных.
На моей практике передача CS даже конкретного списка вопросов, которые нужно задать клиенту, не помогает прояснить суть запрос. Нужно именно думать по-продуктовому.
Возможные решения:
1. Выделение отдельной позиции "исследователя": кто общается с клиентом, используя продуктовы подход (5 почему и вот это вот всё), и просто передаёт качественную информацию продакту
То есть, добавление в четырёхугольник нового элемента.
2. Игнорировать запросы не_топ клиентов: обращать внимание только на частотные, а остальные отбривать с вежливым “ваше мнение очень важно для нас" вообще без затрат времени
То есть, авто-приоритизация, исходя из "веса" клиента с неизбежным игнорированием низа бэклога.
#product_management #b2b #saas
(часть 2)
Проблема 2: Качество обратной связи от клиентов
В любом B2B получается четырёхугольник взаимодействия: продакт, продукт, клиент, CS. Продакт доставляет клиенту ценность через продукт и получает обратную связь от клиента через CS.
У этого четырёхугольника есть существенный дефект - CS-менеджеры редко мыслят продуктово.
Во многих случаях получается следующее:
- Клиент приходит к CS с запросом на фичу и неизменным "срочно"
- CS ровно в таком же виде транслирует это продакту
- Продакт пытается получить подробности через CS
- Через сломанный телефон получается информация, не поясняющая суть проблемы
- Продакт отчаивается и идёт сам на созвон с клиентом
- Часто на звонке выясняется, что проблема надуманная или уже решена
В худших случаях, CS ещё клиенту на 2-ом шаге пообещал, что всё сделают в лучшем виде. 😅
И всё бы ничего, но продакт опять потратил время на реактивные действия по решению локальной проблемы, вместо стратегической работы над продуктом.
Это может быть оправдано в случае запроса от топового клиента, приносящего существенную долю MRR. Но не масштабируемо на остальных.
На моей практике передача CS даже конкретного списка вопросов, которые нужно задать клиенту, не помогает прояснить суть запрос. Нужно именно думать по-продуктовому.
Возможные решения:
1. Выделение отдельной позиции "исследователя": кто общается с клиентом, используя продуктовы подход (5 почему и вот это вот всё), и просто передаёт качественную информацию продакту
То есть, добавление в четырёхугольник нового элемента.
2. Игнорировать запросы не_топ клиентов: обращать внимание только на частотные, а остальные отбривать с вежливым “ваше мнение очень важно для нас" вообще без затрат времени
То есть, авто-приоритизация, исходя из "веса" клиента с неизбежным игнорированием низа бэклога.
#product_management #b2b #saas
B2B SaaS: Customer Success vs Product management 😤
(часть 3)
Проблема 3: Объём и скорость сбора обратной связи от клиентов
Берём обратный кейс, когда продакту нужно собрать количественные данные для оценки потенциала фичи или обратную связь по уже внедрённому функционалу. Конкретные предельно однозначные вопросы уже сформулированы, осталось получить ответы.
Тут мы обычно сталкиваемся с двумя сложностями:
- CS-менеджеры (как и продакт) заняты много чем, и совершенно неизвестно с каким приоритетом будет обрабатываться этот запрос от продакта
- часть клиентов вообще не отвечают на письма CS, пока у них самих не появится потребности что-то уточнить (я тоже так делаю)
На небольших объёмах (при клиентской базе 500-1000 клиентов) попытки сбора ОС по другим каналам (опросы в продукте, email или чатах поддержки) тоже терпят крах. Процент ответов там явно недостаточный для принятия взвешенных решений.
Получается, что продакт "бегает" за CS-менеджерами с уговорами таки помочь ему собрать данные.
Возможные решения (а скорее их комбинация):
1. Описать и внедрить процесс сбора ОС через CS: в идеале, продакт ставит задачу в Jira на CS department, и в согласованный deadline получает обязательный ответ на каждого клиента
2. У CS должны существовать регулярные созвоны с клиентами*: где, помимо прочего, можно задать вопросы "от продакта", и в прогнозирумый срок получить нужную информацию
То есть, переводим сбор ОС в асинхронный режим.
*Это реализуемо, только если продукт представляет для клиента существенную ценность. Я сам игнорирую предложения созвониться от второстепенных для моей работы продуктов.
Эти шаги могут позволить сделать работу над B2B продуктом намного более осмысленной и предсказуемой.
Для меня, почти смирившегося с тем, что product management в b2b - это сплошная нервотрёпка, это настоящее открытие. "Похоже, бывает иначе! 😲”
Казалось бы, очевидно: продакт должен заниматься принятием продуктовых решений.
Всё остальное нужно с него снять. Чем больше снимешь, тем выше будет качество решений. Но в компаниях со скромным бюджетом и без зрелой продуктовой культуры так не получается. И качество решений страдает, а продакты выгорают. 😓
А ещё кажется, что работу CS можно свести к очень предсказуемому строго регламентированному процессу. Иначе оно не скейлится. Но это работает, только если бюджета достаточно для адекватного и предсказуемо рассчитываемого количества CS-менеджеров. И это лишь мнение со стороны - у меня есть опыт работы только в Support, в CS не пробовал.
Вот такие мысли. Мне интересно, как реально выглядит взаимодействие продактов и CS в больших компаниях. Если есть такой опыт, делитесь в комментариях. 😉
#product_management #b2b #saas
(часть 3)
Проблема 3: Объём и скорость сбора обратной связи от клиентов
Берём обратный кейс, когда продакту нужно собрать количественные данные для оценки потенциала фичи или обратную связь по уже внедрённому функционалу. Конкретные предельно однозначные вопросы уже сформулированы, осталось получить ответы.
Тут мы обычно сталкиваемся с двумя сложностями:
- CS-менеджеры (как и продакт) заняты много чем, и совершенно неизвестно с каким приоритетом будет обрабатываться этот запрос от продакта
- часть клиентов вообще не отвечают на письма CS, пока у них самих не появится потребности что-то уточнить (я тоже так делаю)
На небольших объёмах (при клиентской базе 500-1000 клиентов) попытки сбора ОС по другим каналам (опросы в продукте, email или чатах поддержки) тоже терпят крах. Процент ответов там явно недостаточный для принятия взвешенных решений.
Получается, что продакт "бегает" за CS-менеджерами с уговорами таки помочь ему собрать данные.
Возможные решения (а скорее их комбинация):
1. Описать и внедрить процесс сбора ОС через CS: в идеале, продакт ставит задачу в Jira на CS department, и в согласованный deadline получает обязательный ответ на каждого клиента
2. У CS должны существовать регулярные созвоны с клиентами*: где, помимо прочего, можно задать вопросы "от продакта", и в прогнозирумый срок получить нужную информацию
То есть, переводим сбор ОС в асинхронный режим.
*Это реализуемо, только если продукт представляет для клиента существенную ценность. Я сам игнорирую предложения созвониться от второстепенных для моей работы продуктов.
Эти шаги могут позволить сделать работу над B2B продуктом намного более осмысленной и предсказуемой.
Для меня, почти смирившегося с тем, что product management в b2b - это сплошная нервотрёпка, это настоящее открытие. "Похоже, бывает иначе! 😲”
Казалось бы, очевидно: продакт должен заниматься принятием продуктовых решений.
Всё остальное нужно с него снять. Чем больше снимешь, тем выше будет качество решений. Но в компаниях со скромным бюджетом и без зрелой продуктовой культуры так не получается. И качество решений страдает, а продакты выгорают. 😓
А ещё кажется, что работу CS можно свести к очень предсказуемому строго регламентированному процессу. Иначе оно не скейлится. Но это работает, только если бюджета достаточно для адекватного и предсказуемо рассчитываемого количества CS-менеджеров. И это лишь мнение со стороны - у меня есть опыт работы только в Support, в CS не пробовал.
Вот такие мысли. Мне интересно, как реально выглядит взаимодействие продактов и CS в больших компаниях. Если есть такой опыт, делитесь в комментариях. 😉
#product_management #b2b #saas
👍1
Побочный эффект Вадима Капитанова
Юзабилити выбора реакций допилили. 😁 Но, по-прежнему, список эмоджи ограничен. После Slack особенно не хватает 👀, ➕ и ✅. Интересно, делается ли специально при выборе доступных эмоджи акцент на том, что это социальный, а не бизнес мессенджер. 🤔
Зря я ругал Телеграм за ограничения, потому что проблема недостающих реакций решается загрузкой любых кастомных emoji.
Поэтому я сам решил свою проблему. 😁
Встречайте сет из недостающих реакций: https://t.iss.one/addemoji/MoreEmoji_side_effect
Буду дополнять по мере необходимости.
Правда, работать они будут только в чатах - в каналах кастомные реакции недоступны.
Поэтому я сам решил свою проблему. 😁
Встречайте сет из недостающих реакций: https://t.iss.one/addemoji/MoreEmoji_side_effect
Буду дополнять по мере необходимости.
Правда, работать они будут только в чатах - в каналах кастомные реакции недоступны.
🍌2
Corner-cases 😖
Недавно размышлял про поиск баланса между быстрой доставкой ценности и качественным продумыванием редких сценариев. Вопреки общепризнанному подходу с MVP, реальность бывает сложнее. Мыслями про это хочу поделиться.
Очевидно, что в условиях ограниченных ресурсов (то есть, всегда) приходится выбирать, насколь качественно реализовывать функционал.
Продумать и отшлифовать прямой флоу - это <50% работы. Вот заренее предусмотреть и качественно обыграть редкие сценарии - обычно самая жопа. И она тем глубже, чем выше комплексити продукта.
В моём продукте глубина просто запредельная...
При этом реализация фичей на текущем этапе - это довольно редко именно "тестирование гипотезы". Чаще это реализация того, что точно понадобится. Вопрос только в том, когда именно.
При этом обратная связь от реальных пользователей доезжает довольно медленно, по причине проблем описанных в прошлом посте. Поэтому итеративности разработки не получается.
И здесь мы попадаем раз за разом в ситуацию, когда хорошо продуманная фича, потребовавшая много недель на реализацию пылится без дела, ожидая своего часа.
Понятно, что потраченные ресурсы жалко и возникает соблазн сэономить, делая "на коленке". А уже "по ходу" доделывать то, чего не хватает.
Но есть, как минимум три "НО", которые стоит при этом держать в голове:
1. Бомба с часовым механизмом
Каждый недодуманный корнер-кейс когда-то выстрелит. Если не перебрать заранее в голове возможные сценарии, то можно упустить из вида даже частотные. И что они не выстрелях сразу, скорее усугубляет ситуацию.
В непредсказуемый момент времени, когда реальное использование фичи таки начнётся, на команду может упасть незапланированный скоуп работы. От этого пострадают другие планы.
А ещё эти "взрывы" могут накладываться по времени, превращая работу в непрерывное тушение пожаров на месяцы и просранные коммитменты.
2. Хреновые архитектурные решения
Не смотря на 3-4 шага вперёд, а отталкиваясь только от текущих требований, можно легко разработать фичу, которую дальше не получится развивать.
Осознанные с опозданием корнер-кейсы могут потребовать такого количества технических костылей, чтобы их покрыть, что фичу может оказаться проще переписать с нуля. Получаются и двойные затраты времени, и демотивация команды разработки.
3. Потеря контекста
Когда я дизайню фичу, я последовательно осознаю её взаимосвязи с другим функционалом, порокручиваю в голове возможные упущения. Чем дольше продумываю, тем больше нюансов осознаю.
Но, когда я через 2-3 месяца после написания требований разбираю возникшую на проде ошибку, контекст потерян напрочь. И чтобы придумать качественное решение для редкого сценария и потрачу в 2-3 раза больше времени, чем на старте.
Однако, есть и обратная сторона.
В B2B в момент принятия клиентом решения о покупке продукта наличие/отсутствие критичных фичей может быть show-stopper'ом для продолжения диалога. Поэтому даже костыльно покрытые только прямые сценарии в момент продажи могут представлять преимущество. Ведь, что они не работают нормально, клиент может узнать уже после подписания договора.
Некоторые наши конкуренты умудряются работать по такой схеме:
- отдали фичу через 2 недели
- клиент пытается использовать и ругается об ошибках
- ошибки планимерно правятся как инциденты
- фактически фича работает через 2 месяца
При этом у клиента в голове остаётся иллюзия, что "фичи доставляют быстро". Профит!
Только всегда стоит помнить, что это "вера в светлое будущее", как с кредитами. Это работает только до тех пор, пока компания в стадии роста. Как только бюджет схлопывается, догоняющий технический долг "разворачивает реки вспять".
Восхищаюсь подходом Егора Данилова про "отключаем нах" неработающих фичей - позволяет сдерживать комплексити продукта. Но пока не понимаю, как это применить в B2B, и без бюджета на отдельную growth team. Пойду думать дальше. 😆
#product_management
Недавно размышлял про поиск баланса между быстрой доставкой ценности и качественным продумыванием редких сценариев. Вопреки общепризнанному подходу с MVP, реальность бывает сложнее. Мыслями про это хочу поделиться.
Очевидно, что в условиях ограниченных ресурсов (то есть, всегда) приходится выбирать, насколь качественно реализовывать функционал.
Продумать и отшлифовать прямой флоу - это <50% работы. Вот заренее предусмотреть и качественно обыграть редкие сценарии - обычно самая жопа. И она тем глубже, чем выше комплексити продукта.
В моём продукте глубина просто запредельная...
При этом реализация фичей на текущем этапе - это довольно редко именно "тестирование гипотезы". Чаще это реализация того, что точно понадобится. Вопрос только в том, когда именно.
При этом обратная связь от реальных пользователей доезжает довольно медленно, по причине проблем описанных в прошлом посте. Поэтому итеративности разработки не получается.
И здесь мы попадаем раз за разом в ситуацию, когда хорошо продуманная фича, потребовавшая много недель на реализацию пылится без дела, ожидая своего часа.
Понятно, что потраченные ресурсы жалко и возникает соблазн сэономить, делая "на коленке". А уже "по ходу" доделывать то, чего не хватает.
Но есть, как минимум три "НО", которые стоит при этом держать в голове:
1. Бомба с часовым механизмом
Каждый недодуманный корнер-кейс когда-то выстрелит. Если не перебрать заранее в голове возможные сценарии, то можно упустить из вида даже частотные. И что они не выстрелях сразу, скорее усугубляет ситуацию.
В непредсказуемый момент времени, когда реальное использование фичи таки начнётся, на команду может упасть незапланированный скоуп работы. От этого пострадают другие планы.
А ещё эти "взрывы" могут накладываться по времени, превращая работу в непрерывное тушение пожаров на месяцы и просранные коммитменты.
2. Хреновые архитектурные решения
Не смотря на 3-4 шага вперёд, а отталкиваясь только от текущих требований, можно легко разработать фичу, которую дальше не получится развивать.
Осознанные с опозданием корнер-кейсы могут потребовать такого количества технических костылей, чтобы их покрыть, что фичу может оказаться проще переписать с нуля. Получаются и двойные затраты времени, и демотивация команды разработки.
3. Потеря контекста
Когда я дизайню фичу, я последовательно осознаю её взаимосвязи с другим функционалом, порокручиваю в голове возможные упущения. Чем дольше продумываю, тем больше нюансов осознаю.
Но, когда я через 2-3 месяца после написания требований разбираю возникшую на проде ошибку, контекст потерян напрочь. И чтобы придумать качественное решение для редкого сценария и потрачу в 2-3 раза больше времени, чем на старте.
Однако, есть и обратная сторона.
В B2B в момент принятия клиентом решения о покупке продукта наличие/отсутствие критичных фичей может быть show-stopper'ом для продолжения диалога. Поэтому даже костыльно покрытые только прямые сценарии в момент продажи могут представлять преимущество. Ведь, что они не работают нормально, клиент может узнать уже после подписания договора.
Некоторые наши конкуренты умудряются работать по такой схеме:
- отдали фичу через 2 недели
- клиент пытается использовать и ругается об ошибках
- ошибки планимерно правятся как инциденты
- фактически фича работает через 2 месяца
При этом у клиента в голове остаётся иллюзия, что "фичи доставляют быстро". Профит!
Только всегда стоит помнить, что это "вера в светлое будущее", как с кредитами. Это работает только до тех пор, пока компания в стадии роста. Как только бюджет схлопывается, догоняющий технический долг "разворачивает реки вспять".
Восхищаюсь подходом Егора Данилова про "отключаем нах" неработающих фичей - позволяет сдерживать комплексити продукта. Но пока не понимаю, как это применить в B2B, и без бюджета на отдельную growth team. Пойду думать дальше. 😆
#product_management
👍4
Forwarded from Охуенно
This media is not supported in your browser
VIEW IN TELEGRAM
Yoann Bourgeois, "Success isn't linear"
👍8🔥6
Переезд 🚙
Шило в жопе никак не даёт мне покоя... Всю сознательную жизнь мне не сидится на месте. Сначала это было про место работы, теперь про локацию.
Если честно я пиздец как устал от этого и уже очень хочу обрести место, которое смогу называть и ощущать своим "домом". Но "компромиссы" - это не про меня.
Поэтому в позапрошлые выходные я проехал >3600 километров через 7 стран: Литва > Польша > Нидерланды > Бельгия > Германия > Испания > Португалия. По пути встретился аж с четырьмя друзьями и переслушал с огромным удовольствием половину биографии Джобса.
И вот уже 2 недели я на благословенной щедрой на солнечные дни португальской земле у восхитительного Атлантического океана. (Да, я тогда не шутил.)
Со стороны выглядит, как “Фак еее!” Но изнутри это самый стрессовый переезд из тех, что мне пока довелось пережить. Даже побег на лето от локдауна в 2020-ом году с годовалым ребёнком в страшненький деревенский дом, кажется, проходил легче.
Последние полтора месяца (если не больше) я пребываю в постоянном стрессе по поводу подготовки отправки всех вещей, оформления ВНЖ, аренды квартиры и не только.
Ситуацию усугубляет взаимосвязь всех этих компонентов. Чтобы оформить ВНЖ, нужно арендовать квартиру. Если не арендовать квартиру до окончания временной аренды, то я попадаю на дополнительные расходы, а все вещи придётся перевозить два раза. И т.д.
Всё это закручивается в торнадо непрерывной тревоги и чисто физически не даёт расслабиться и по достоинству насладиться прекрасным пейзажем за окном, пришедшим на смену постоянной хмурости Вильнюса.
Чтобы жизнь не казалось мёдом, на этой неделе я ещё и поучаствовал в самой крупной IT конференции в Европе - WebSummit. Грех было не сходить, раз уже перебрался в Лисcабон.
Да, там было достаточно интересно, а я вышел с пачкой интересных и (надеюсь) полезных знакомств. Но 3,5 дня постоянно на ногах, общаясь с полусотней новых людей в день, попутно пытаюсь работать и разруливать вышеперечисленные вопросы, меня добили.
Поэтому свой вчерашний день рождения я встретил в постели, укутавшись в одеяло, с трудом не рыдая про то, как я устал. К обеду стало полегче, но "праздничным настроением" пока даже не пахло.
Но я знаю, что все вышеперечисленные проблемы и сложности разрулятся. Это лишь вопрос времени. А океан, солнце и радушные местные жители, ради которых я всё это и затеял, останутся.
И мама права, когда говорит, что я "как локомотив" иду к своим целям. В очередной раз захотел и сделал. Пожалуй, я молодец.
Десяток лет назад в книгах Макса Фрая я встретил замечательное понятие "вершители". Это те, чьи желания неизбежно исполняются, "рано или поздно, так или иначе". Для меня это очень глубокая идея, за которую я с тех пор держусь краешком сознания.
И я точно обрету свой дом. Именно такой, как я хочу. Рано или поздно... Так или иначе...
#about_me
Шило в жопе никак не даёт мне покоя... Всю сознательную жизнь мне не сидится на месте. Сначала это было про место работы, теперь про локацию.
Если честно я пиздец как устал от этого и уже очень хочу обрести место, которое смогу называть и ощущать своим "домом". Но "компромиссы" - это не про меня.
Поэтому в позапрошлые выходные я проехал >3600 километров через 7 стран: Литва > Польша > Нидерланды > Бельгия > Германия > Испания > Португалия. По пути встретился аж с четырьмя друзьями и переслушал с огромным удовольствием половину биографии Джобса.
И вот уже 2 недели я на благословенной щедрой на солнечные дни португальской земле у восхитительного Атлантического океана. (Да, я тогда не шутил.)
Со стороны выглядит, как “Фак еее!” Но изнутри это самый стрессовый переезд из тех, что мне пока довелось пережить. Даже побег на лето от локдауна в 2020-ом году с годовалым ребёнком в страшненький деревенский дом, кажется, проходил легче.
Последние полтора месяца (если не больше) я пребываю в постоянном стрессе по поводу подготовки отправки всех вещей, оформления ВНЖ, аренды квартиры и не только.
Ситуацию усугубляет взаимосвязь всех этих компонентов. Чтобы оформить ВНЖ, нужно арендовать квартиру. Если не арендовать квартиру до окончания временной аренды, то я попадаю на дополнительные расходы, а все вещи придётся перевозить два раза. И т.д.
Всё это закручивается в торнадо непрерывной тревоги и чисто физически не даёт расслабиться и по достоинству насладиться прекрасным пейзажем за окном, пришедшим на смену постоянной хмурости Вильнюса.
Чтобы жизнь не казалось мёдом, на этой неделе я ещё и поучаствовал в самой крупной IT конференции в Европе - WebSummit. Грех было не сходить, раз уже перебрался в Лисcабон.
Да, там было достаточно интересно, а я вышел с пачкой интересных и (надеюсь) полезных знакомств. Но 3,5 дня постоянно на ногах, общаясь с полусотней новых людей в день, попутно пытаюсь работать и разруливать вышеперечисленные вопросы, меня добили.
Поэтому свой вчерашний день рождения я встретил в постели, укутавшись в одеяло, с трудом не рыдая про то, как я устал. К обеду стало полегче, но "праздничным настроением" пока даже не пахло.
Но я знаю, что все вышеперечисленные проблемы и сложности разрулятся. Это лишь вопрос времени. А океан, солнце и радушные местные жители, ради которых я всё это и затеял, останутся.
И мама права, когда говорит, что я "как локомотив" иду к своим целям. В очередной раз захотел и сделал. Пожалуй, я молодец.
Десяток лет назад в книгах Макса Фрая я встретил замечательное понятие "вершители". Это те, чьи желания неизбежно исполняются, "рано или поздно, так или иначе". Для меня это очень глубокая идея, за которую я с тех пор держусь краешком сознания.
И я точно обрету свой дом. Именно такой, как я хочу. Рано или поздно... Так или иначе...
#about_me
❤25🔥3👏1
Media is too big
VIEW IN TELEGRAM
Когда конец октября выглядит так, кажется, что оно того стоило… 😏
❤19
🔥5👍4😁2🥰1
Страх 😨
Ребёнок с середины ночи планомерно отвоёвывал у меня подушку, поэтому я спал чёрти-как. Зато у меня было много времени понаблюдать за спонтанно возникающими мыслями. И я увидел (наконец!) важную штуку. Такую важную, что в 5 утра я сел писать этот пост.
В основе большой (или даже большей) части моих действий лежит страх.
- Это и побеги из России 2-го марта и 21-го сентября. Из страха, что потом не смогу уехать, обёрнутого в "просто не хочу рисковать".
- Это и переживания по поводу предстоящих рабочих встреч, к которым я не сделал того, что обещал. Из страха, что меня обвинят в безответственности.
- Это и привычка обязательно сбегать в туалет перед рабочим созвоном. Из страха, что приспичит в процессе.
- Это и излишние усилия при выборе товара для покупки или авиабилетов. Из страха самобичевания за упущенный лучший вариант.
- Это и стремление быстрее переехать в комфортную мне страну. Из страха упустить возможность жить так, как я хочу.
- Это и таскание с собой кучи полезностей в рюкзаке. Из страха, что понадобится, а под рукой не окажется.
- Это и желание скорее записать важную мысль, когда она возникла. Из страха, что потом забуду.
- Это и рефлекторное громкое (громче, чем нужно) окрикивание сына в ситуациях потенциальной опасности. Из страха, что случится беда.
- Это и склонность коллекционировать мемы. Из страха, что потом не найду, когда будет к случаю.
- Это и чрезмерное использование “отложенных сообщений". Из страха побеспокоить человека в неудобный момент.
И ещё сотни других примеров. Моё "не жду ничего хорошо" с тантры тоже про это. Его сердцевина - это именно страх.
Пиздец каким подготовленным ко всему меня это сделало.
Большинство людей, которые меня хорошо знают, скажут вам, что я удивительно смелый.
- Я прыгал 7-метровые разрывники на велосипеде и съезжал "чёрные" трассы.
- Я менял компании, как перчатки, будучи уверенным, что всегда найду работу и в любой области разберусь.
- Я руководил группами и подразделениями, когда ещё совсем не умел руководить.
И куча других внешних признаков.
Два года назад на курсе Вани Замесина я услышал инструмент "делать страшное" и таким образом постоянно сдвигать границу "невозможно страшного".
С вот уже два года я я оголтело врываюсь в самое пекло. "Если страшно, то точно это сделаю!" - говорю я друзьям. И даже: "Хочу избавиться от всех страхов, чтобы они не контролировали мои действия."
И граница, действительно, сдвигается. В первую очередь, в области коммуникации. Что допустимо и недопустимо сказать другому человеку. Насколько честно и уязвимо можно показать себя настоящего. Со всеми: от жены до коллеги, от близкого друга до случайного встречного.
Я даже гордо отвечаю друзьям и близким на их предостережения, что я не боюсь описанных ими рисков.
Но, вот беда, получается, что глубинный источник страха никуда не делся.
И первые мысли, которые возникают в голове, проснувшись среди ночи - это страхи. Что я чего-то не учёл, к чему-то не подготовился, что что-то пойдёт не так.
Получается, моё стремление делать страшное - это просто попытка отделаться от этого неприятного чувства.
Но обширный опыт показывает, что так не работает. Любая попытка подавить эмоцию оборачивается сопротивлением и только питает её, делает более изворотливой.
Пора поискать способ интегрировать страх.
Спасибо, Макс и моя осознанность, что я это увидел. А то бы всё проспал. 😁
#midnfulness #fear #about_me
Ребёнок с середины ночи планомерно отвоёвывал у меня подушку, поэтому я спал чёрти-как. Зато у меня было много времени понаблюдать за спонтанно возникающими мыслями. И я увидел (наконец!) важную штуку. Такую важную, что в 5 утра я сел писать этот пост.
В основе большой (или даже большей) части моих действий лежит страх.
- Это и побеги из России 2-го марта и 21-го сентября. Из страха, что потом не смогу уехать, обёрнутого в "просто не хочу рисковать".
- Это и переживания по поводу предстоящих рабочих встреч, к которым я не сделал того, что обещал. Из страха, что меня обвинят в безответственности.
- Это и привычка обязательно сбегать в туалет перед рабочим созвоном. Из страха, что приспичит в процессе.
- Это и излишние усилия при выборе товара для покупки или авиабилетов. Из страха самобичевания за упущенный лучший вариант.
- Это и стремление быстрее переехать в комфортную мне страну. Из страха упустить возможность жить так, как я хочу.
- Это и таскание с собой кучи полезностей в рюкзаке. Из страха, что понадобится, а под рукой не окажется.
- Это и желание скорее записать важную мысль, когда она возникла. Из страха, что потом забуду.
- Это и рефлекторное громкое (громче, чем нужно) окрикивание сына в ситуациях потенциальной опасности. Из страха, что случится беда.
- Это и склонность коллекционировать мемы. Из страха, что потом не найду, когда будет к случаю.
- Это и чрезмерное использование “отложенных сообщений". Из страха побеспокоить человека в неудобный момент.
И ещё сотни других примеров. Моё "не жду ничего хорошо" с тантры тоже про это. Его сердцевина - это именно страх.
Пиздец каким подготовленным ко всему меня это сделало.
Большинство людей, которые меня хорошо знают, скажут вам, что я удивительно смелый.
- Я прыгал 7-метровые разрывники на велосипеде и съезжал "чёрные" трассы.
- Я менял компании, как перчатки, будучи уверенным, что всегда найду работу и в любой области разберусь.
- Я руководил группами и подразделениями, когда ещё совсем не умел руководить.
И куча других внешних признаков.
Два года назад на курсе Вани Замесина я услышал инструмент "делать страшное" и таким образом постоянно сдвигать границу "невозможно страшного".
С вот уже два года я я оголтело врываюсь в самое пекло. "Если страшно, то точно это сделаю!" - говорю я друзьям. И даже: "Хочу избавиться от всех страхов, чтобы они не контролировали мои действия."
И граница, действительно, сдвигается. В первую очередь, в области коммуникации. Что допустимо и недопустимо сказать другому человеку. Насколько честно и уязвимо можно показать себя настоящего. Со всеми: от жены до коллеги, от близкого друга до случайного встречного.
Я даже гордо отвечаю друзьям и близким на их предостережения, что я не боюсь описанных ими рисков.
Но, вот беда, получается, что глубинный источник страха никуда не делся.
И первые мысли, которые возникают в голове, проснувшись среди ночи - это страхи. Что я чего-то не учёл, к чему-то не подготовился, что что-то пойдёт не так.
Получается, моё стремление делать страшное - это просто попытка отделаться от этого неприятного чувства.
Но обширный опыт показывает, что так не работает. Любая попытка подавить эмоцию оборачивается сопротивлением и только питает её, делает более изворотливой.
Пора поискать способ интегрировать страх.
Спасибо, Макс и моя осознанность, что я это увидел. А то бы всё проспал. 😁
#midnfulness #fear #about_me
❤13👍6
Если бы я знал, что умру через год… 😵
Разгребая старые заметки, нашёл давно забытый bucket list. 😁
- Я всё ещё не побывал в Америке и Cirque du Soleil.
- По-прежнему читаю меньше книг, чем хотел бы.
- И пока не сделал ничего социально значимого в достаточном масштабе.
- А проводить выходные дома мне иногда даже нравится.
А вот в остальном всё получилось. Моя жизнь сейчас максимально похожа на то, о какой я мечтал 7 лет назад.
И для этого не потребовался смертельный диагноз. 😅
#about_me
Разгребая старые заметки, нашёл давно забытый bucket list. 😁
- Я всё ещё не побывал в Америке и Cirque du Soleil.
- По-прежнему читаю меньше книг, чем хотел бы.
- И пока не сделал ничего социально значимого в достаточном масштабе.
- А проводить выходные дома мне иногда даже нравится.
А вот в остальном всё получилось. Моя жизнь сейчас максимально похожа на то, о какой я мечтал 7 лет назад.
И для этого не потребовался смертельный диагноз. 😅
#about_me
❤8👍5
WhatsApp 💩
Когда в следующий раз меня спросят “Ну и чем этот ваш Telegram лучше, чем WhatsApp?!”, я предложу человеку пройти квест по переносу истории чатов с Android на iPhone.
Большего унижения, чем это, я не испытывал со времён последнего похода в налоговую в 2019-ом.
Дело в том, что уёбки из Meta в целях экономии на серверах придумали, что WhatsApp на Android будет бэкапиться в Google Drive, а на iOS - в iCloud Drive. И просто перенести архив нельзя, потому что они ещё и используют разный алгоритм шифрования.
Поэтому настройка ВООБЩЕ ВСЕХ ПРИЛОЖЕНИЙ на новом iPhone у меня заняла 1,5 часа. А перенос WhatsApp - 3,5 часа.
За это время я прошёл все стадии от отрицания до принятия. И не один раз.
Выглядело это так:
- решить настраивать iPhone с нуля (для меня переезд на новое устройство - всегда повод избавиться от старья)
- настроить всё, кроме богомерзкого WA
- вспомнить про перенос истории его чатов
- охуеть от того, что официальная инструкция предлагает перенос только при исходной настройке iPhone
- пролистать десяток статей в поисках другого решения
- попытаться использовать сторонний софт (доступны исключительно no-name разработчики)
- охуеть от того, что он просит не только доступ ко всем медиа на телефоне, но ещё и код настройки WA на новом устройстве (а с такими угрозами приватности я точно не готов иметь дело)
- вычитать в одной из статей, что можно после переноса данных WA восстановить остальное содержимое iPhone из бэкапа
- смириться, что придётся сбрасывать iPhone до заводских настроек
- сбросить iPhone и перенести историю WA через предложенный Apple “Move to iOS” (WhatsApp на полном серьёзе при это требует следить, чтобы телефон в процессе не заблокировался)
- еле сдержать от слёз, что похерилась настройка всего, что было уже готово, а частичного восстановления из бэкапа в iOS нет
- охуеть в третий раз, что WA предлагает подождать 6+ часов перед отправкой нового SMS кода подтверждения
- залить бэкап WA в iCloud
- сбросить iPhone ещё раз
- восстановить iPhone из бэкапа в iCloud
- благословить разработчиков Apple за то, что довели бэкап до ума, и всё действительно восстановилось
- удалить WA и установить заново (потому что восстановить бэкап можно только при настройки с нуля)
- вздохнуть с облегчением, что этот кошмар закончился
Количество матерных слов, произнесённых и сдержанных в процессе, не поддаётся подсчёту.
Знаете, как выглядел перенос Telegram?
- скачать Telegram
- подтвердить новое устройство
Готово!
И помимо этого конкретного случая, я могу перечислять недостатки WhatsApp бесконечно. Как и преимущества Telegram.
У WhatsApp осталось последний козырь - это большая пользовательская база, что неоспоримо является самым важным для мессенджера.
Но я верю, что это вопрос времени, когда трахнутые во все щели пользователи осознают, что так страдать необязательно.
#hell_UX
Когда в следующий раз меня спросят “Ну и чем этот ваш Telegram лучше, чем WhatsApp?!”, я предложу человеку пройти квест по переносу истории чатов с Android на iPhone.
Большего унижения, чем это, я не испытывал со времён последнего похода в налоговую в 2019-ом.
Дело в том, что уёбки из Meta в целях экономии на серверах придумали, что WhatsApp на Android будет бэкапиться в Google Drive, а на iOS - в iCloud Drive. И просто перенести архив нельзя, потому что они ещё и используют разный алгоритм шифрования.
Поэтому настройка ВООБЩЕ ВСЕХ ПРИЛОЖЕНИЙ на новом iPhone у меня заняла 1,5 часа. А перенос WhatsApp - 3,5 часа.
За это время я прошёл все стадии от отрицания до принятия. И не один раз.
Выглядело это так:
- решить настраивать iPhone с нуля (для меня переезд на новое устройство - всегда повод избавиться от старья)
- настроить всё, кроме богомерзкого WA
- вспомнить про перенос истории его чатов
- охуеть от того, что официальная инструкция предлагает перенос только при исходной настройке iPhone
- пролистать десяток статей в поисках другого решения
- попытаться использовать сторонний софт (доступны исключительно no-name разработчики)
- охуеть от того, что он просит не только доступ ко всем медиа на телефоне, но ещё и код настройки WA на новом устройстве (а с такими угрозами приватности я точно не готов иметь дело)
- вычитать в одной из статей, что можно после переноса данных WA восстановить остальное содержимое iPhone из бэкапа
- смириться, что придётся сбрасывать iPhone до заводских настроек
- сбросить iPhone и перенести историю WA через предложенный Apple “Move to iOS” (WhatsApp на полном серьёзе при это требует следить, чтобы телефон в процессе не заблокировался)
- еле сдержать от слёз, что похерилась настройка всего, что было уже готово, а частичного восстановления из бэкапа в iOS нет
- охуеть в третий раз, что WA предлагает подождать 6+ часов перед отправкой нового SMS кода подтверждения
- залить бэкап WA в iCloud
- сбросить iPhone ещё раз
- восстановить iPhone из бэкапа в iCloud
- благословить разработчиков Apple за то, что довели бэкап до ума, и всё действительно восстановилось
- удалить WA и установить заново (потому что восстановить бэкап можно только при настройки с нуля)
- вздохнуть с облегчением, что этот кошмар закончился
Количество матерных слов, произнесённых и сдержанных в процессе, не поддаётся подсчёту.
Знаете, как выглядел перенос Telegram?
- скачать Telegram
- подтвердить новое устройство
Готово!
И помимо этого конкретного случая, я могу перечислять недостатки WhatsApp бесконечно. Как и преимущества Telegram.
У WhatsApp осталось последний козырь - это большая пользовательская база, что неоспоримо является самым важным для мессенджера.
Но я верю, что это вопрос времени, когда трахнутые во все щели пользователи осознают, что так страдать необязательно.
#hell_UX
👏5