Оля совершенно невероятный персонаж. Волшебно сочетает успешную карьеру (McKinsey, MBA в Harvard и сейчас CEO крупной сети клиник) и глубокую духовность, осознанность, эмоциональность.
Посты часто попадают в середечко. ❤️
С днём рождения, Оля!
Посты часто попадают в середечко. ❤️
С днём рождения, Оля!
❤1👏1
Forwarded from Соколова наизнанку
Сегодня у меня день рождения 🥳 уииии! Мне 38 лет.
У меня был очень счастливый год, даже не представляла, что так бывает. Если бы я могла этим как-то заглушить то горе, что происходит, я бы все отдала, но я не могу 😢
Загадываю себе дальше много творчества и быть всегда влюблённой в жизнь! 🤍
Хочу вас попросить сегодня!
Расскажите, пожалуйста, о моем телеграм канале у себя и своим друзьям, для меня это важно! 🙏
Мои самые настоящие посты - о моей чёрной дыре и о потере опор (здесь есть часть 2).
Самые распространяемые - о студентах в Гарварде и манифест женщинам и тайм-менеджмент.
Самые засердеченные ❤️ из сердечных - про я не уеду и хлеб.
Мой самый нежный про гладить по голове и я загадываю так себе жить.
И медицинские самые цитируемые - про формулу выручки, формулу выручки 2, факторы загруженного врача, выгоду говорить спасибо.
Канал стал самым неожиданным и интересным событием для меня в прошлом году, интересно, что дальше!!!
У меня был очень счастливый год, даже не представляла, что так бывает. Если бы я могла этим как-то заглушить то горе, что происходит, я бы все отдала, но я не могу 😢
Загадываю себе дальше много творчества и быть всегда влюблённой в жизнь! 🤍
Хочу вас попросить сегодня!
Расскажите, пожалуйста, о моем телеграм канале у себя и своим друзьям, для меня это важно! 🙏
Мои самые настоящие посты - о моей чёрной дыре и о потере опор (здесь есть часть 2).
Самые распространяемые - о студентах в Гарварде и манифест женщинам и тайм-менеджмент.
Самые засердеченные ❤️ из сердечных - про я не уеду и хлеб.
Мой самый нежный про гладить по голове и я загадываю так себе жить.
И медицинские самые цитируемые - про формулу выручки, формулу выручки 2, факторы загруженного врача, выгоду говорить спасибо.
Канал стал самым неожиданным и интересным событием для меня в прошлом году, интересно, что дальше!!!
👍5
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.me/addemoji/MoreEmoji_side_effect
Буду дополнять по мере необходимости.
Правда, работать они будут только в чатах - в каналах кастомные реакции недоступны.
Поэтому я сам решил свою проблему. 😁
Встречайте сет из недостающих реакций: https://t.me/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