69. Не навреди фичей своей
У меня был очень авторитарный начальник. Его все боялись. Как-то он прочитал книгу по маркетингу и говорит мне: «Будем проверять дизайн коробки для автомобильного фильтра на фокус-группе». Я смастерил две коробки разных цветов и поставил на стол. Начальник позвал тёток из бухгалтерии и говорит им строго: «Ну что, какая коробка больше нравится?» Женщины тушуются и боятся что-то сказать. Босс потерял терпение и подсказывает: «Ну ведь красная лучше, правда?». Фокус-группа закивала, заулыбалась, да, говорит, красная лучше.
Эта история – иллюстрация, как человек подгоняет результат эксперимента под свои ожидания. Этим занимаются не только дилетанты, но и вполне крепкие профессионалы, вооружившись A/B-экспериментами и статистикой. Когда хочется какую-то фичу, сложно устоять перед соблазном «доказать» ее полезность.
Бывает, надо сделать изменения, необходимость которых давно назрела, но доказать это ростом продуктовых метрик – сложно. Например, редизайн: стало красивее и современнее, но роста первых платежей нет, ретеншн не изменился, средний чек не вырос. И нормально! Не надо правдами и неправдами доказывать, что новая версия работает лучше.
Достаточно проверить, что новая версия не хуже. Продуктовые метрики остались на том же уровне – это тоже хороший результат. «Не навреди» – хороший принцип для продуктологов и других врачей.
У меня был очень авторитарный начальник. Его все боялись. Как-то он прочитал книгу по маркетингу и говорит мне: «Будем проверять дизайн коробки для автомобильного фильтра на фокус-группе». Я смастерил две коробки разных цветов и поставил на стол. Начальник позвал тёток из бухгалтерии и говорит им строго: «Ну что, какая коробка больше нравится?» Женщины тушуются и боятся что-то сказать. Босс потерял терпение и подсказывает: «Ну ведь красная лучше, правда?». Фокус-группа закивала, заулыбалась, да, говорит, красная лучше.
Эта история – иллюстрация, как человек подгоняет результат эксперимента под свои ожидания. Этим занимаются не только дилетанты, но и вполне крепкие профессионалы, вооружившись A/B-экспериментами и статистикой. Когда хочется какую-то фичу, сложно устоять перед соблазном «доказать» ее полезность.
Бывает, надо сделать изменения, необходимость которых давно назрела, но доказать это ростом продуктовых метрик – сложно. Например, редизайн: стало красивее и современнее, но роста первых платежей нет, ретеншн не изменился, средний чек не вырос. И нормально! Не надо правдами и неправдами доказывать, что новая версия работает лучше.
Достаточно проверить, что новая версия не хуже. Продуктовые метрики остались на том же уровне – это тоже хороший результат. «Не навреди» – хороший принцип для продуктологов и других врачей.
70. Как выдать фидбэк, чтобы тебя послушали
Раньше я часто критиковал коллег. Дизайнеров за несовершенный дизайн. Юиксеров за ошибки в интерфейсе. Менеджеров за плохие процессы. Критиковал по делу, конструктивно и объективно. При этом чувствовал себя молодцом – помогаю менее опытным коллегам расти профессионально.
Со временем я стал замечать, что мои советы игнорируются. Ошибки не исправляются, процессы по прежнему плохие. «Вот глупцы, я же предупреждал», – негодовал я. Но почему так происходит? Обидно, когда ты – самый мудрый человек на земле, а тебя не слушают!
Потом я понял: у меня был неправильный мотив. Моей истинной целью было показать себя крутым, обличить непрофессионализм. Поэтому я говорил хоть объективно и по делу, но жестко и часто обидно.
Некоторые менеджеры ходят на курсы по софт-скиллам и учатся выдавать фидбэк более мягко, побольше хвалить. Я же считаю, что изменять надо не манеру речи, а собственные мотивы. Если ты фокусируешься не на самолюбовании и искренне хочешь помочь коллеге, все остальное придет само. Где надо, похвалишь. Где надо, промолчишь. Где надо, найдешь более удачное время. Психологические приемчики – ерунда. Правильная мотивация и доброе сердце – рулит!
Раньше я часто критиковал коллег. Дизайнеров за несовершенный дизайн. Юиксеров за ошибки в интерфейсе. Менеджеров за плохие процессы. Критиковал по делу, конструктивно и объективно. При этом чувствовал себя молодцом – помогаю менее опытным коллегам расти профессионально.
Со временем я стал замечать, что мои советы игнорируются. Ошибки не исправляются, процессы по прежнему плохие. «Вот глупцы, я же предупреждал», – негодовал я. Но почему так происходит? Обидно, когда ты – самый мудрый человек на земле, а тебя не слушают!
Потом я понял: у меня был неправильный мотив. Моей истинной целью было показать себя крутым, обличить непрофессионализм. Поэтому я говорил хоть объективно и по делу, но жестко и часто обидно.
Некоторые менеджеры ходят на курсы по софт-скиллам и учатся выдавать фидбэк более мягко, побольше хвалить. Я же считаю, что изменять надо не манеру речи, а собственные мотивы. Если ты фокусируешься не на самолюбовании и искренне хочешь помочь коллеге, все остальное придет само. Где надо, похвалишь. Где надо, промолчишь. Где надо, найдешь более удачное время. Психологические приемчики – ерунда. Правильная мотивация и доброе сердце – рулит!
Мне написал читатель канала:
Я – начинающий продакт, ищу работу. За спиной год обучения, курс по кастдеву и Go Practice. Может быть у вас есть история про то, как эффективнее искать работу начинающим? Большинство вакансий с минимальным опытом от года.
Не первый раз спрашивают, а я не знаю, что ответить. Я стал менеджером продукта когда таких вакансий просто не существовало. Боюсь, мой опыт вхождения в профессию никак не поможет начинающим продактам сегодня.
Поэтому передаю микрофон каналу @ProductMindset – они в этом разбираются:
————————————
Первое, что стоит сделать – очертить навыки и инструменты, которыми вы уже владеете. Проанализируйте свой опыт и найдите в нем подтверждение необходимых менеджеру продуктов качеств.
📌 В нашей статье мы рассказываем, какие навыки нужны для старта в профессии, как их оценить и прокачать. А также, как применить продуктовый подход к своей карьере, составить резюме и откликаться на вакансии.
📌 Делимся подборкой материалов о необходимых менеджерам продуктов компетенциях и инструментах.
📌 Узнать, что ждут работодатели от менеджеров разных уровней, и как двигаться к следующему.
Второе — если в вашей компании есть возможность пройти стажировку в продуктовом отделе, попросить руководство передать вам часть продуктовых задач, получить релевантный опыт, пробуйте это реализовать. При появлении возможности горизонтального перехода внутри компании, используйте ее. Это простой способ войти в профессию.
Если такой возможности нет, вы все равно можете найти продуктовые задачи на своём текущем месте и поработать над их решением.
📌 Пример такой задачи и решения – применение продуктового подхода к улучшению толстовки Skyeng.
Если во время прохождения курсов, вы работали над учебным кейсом, достигли значимых результатов и можете его презентовать, его также не стыдно добавить в портфолио.
📌 Часто в менеджмент продуктов переходят из смежных профессий: менеджмент проектов, маркетинг, продажи, аналитика, разработка. Вот рассказ о том, как совершить такой переход.
Больше полезных статей о менеджменте продуктов – на канале Product Mindset. Публикуем подборки материалов, советы опытных продактов и кейсы крупных компаний.
#партнерскийпост
Я – начинающий продакт, ищу работу. За спиной год обучения, курс по кастдеву и Go Practice. Может быть у вас есть история про то, как эффективнее искать работу начинающим? Большинство вакансий с минимальным опытом от года.
Не первый раз спрашивают, а я не знаю, что ответить. Я стал менеджером продукта когда таких вакансий просто не существовало. Боюсь, мой опыт вхождения в профессию никак не поможет начинающим продактам сегодня.
Поэтому передаю микрофон каналу @ProductMindset – они в этом разбираются:
————————————
Первое, что стоит сделать – очертить навыки и инструменты, которыми вы уже владеете. Проанализируйте свой опыт и найдите в нем подтверждение необходимых менеджеру продуктов качеств.
📌 В нашей статье мы рассказываем, какие навыки нужны для старта в профессии, как их оценить и прокачать. А также, как применить продуктовый подход к своей карьере, составить резюме и откликаться на вакансии.
📌 Делимся подборкой материалов о необходимых менеджерам продуктов компетенциях и инструментах.
📌 Узнать, что ждут работодатели от менеджеров разных уровней, и как двигаться к следующему.
Второе — если в вашей компании есть возможность пройти стажировку в продуктовом отделе, попросить руководство передать вам часть продуктовых задач, получить релевантный опыт, пробуйте это реализовать. При появлении возможности горизонтального перехода внутри компании, используйте ее. Это простой способ войти в профессию.
Если такой возможности нет, вы все равно можете найти продуктовые задачи на своём текущем месте и поработать над их решением.
📌 Пример такой задачи и решения – применение продуктового подхода к улучшению толстовки Skyeng.
Если во время прохождения курсов, вы работали над учебным кейсом, достигли значимых результатов и можете его презентовать, его также не стыдно добавить в портфолио.
📌 Часто в менеджмент продуктов переходят из смежных профессий: менеджмент проектов, маркетинг, продажи, аналитика, разработка. Вот рассказ о том, как совершить такой переход.
Больше полезных статей о менеджменте продуктов – на канале Product Mindset. Публикуем подборки материалов, советы опытных продактов и кейсы крупных компаний.
#партнерскийпост
71. Продакт не должен продавать фичи
У работы с крупными клиентами своя специфика. Клиент готов платить много и хочет, чтобы продукт доработали под него. Сейлз получает процент со сделки и заинтересован в ее успехе. Поэтому он приходит к менеджеру продукта и всеми правдами-неправдами пытается его уломать сделать доработки для клиента. «Давай запилим эту фичу и получим стопяцот денег», – говорит он. И вот тут продакту важно не начать мыслить как сейлз.
Приведу пример. Крупные компании не используют Google Analytics, вместо него у них Adobe Analytics – более дорогое и безопасное решение. Но мы его не поддерживали. Наши сейлзы постоянно бомбардировали менеджера продукта заявками от крупных клиентов готовых платить за интеграцию с Adobe.
Наконец менеджер продукта с командой реализовали интеграцию с Adobe. Ее попробовали несколько клиентов и не стали пользоваться. Потому что им нужна была не интеграция, а решение их проблем. А проблемы их никто решать даже не пробовал. Не исследовал, зачем клиентам нужна эта интеграция и как они собираются ей пользоваться.
Менеджеру продукта важно помнить, что его роль – развивать продукт и приносить пользу клиентам, а не продавать фичи максимально дорого.
У работы с крупными клиентами своя специфика. Клиент готов платить много и хочет, чтобы продукт доработали под него. Сейлз получает процент со сделки и заинтересован в ее успехе. Поэтому он приходит к менеджеру продукта и всеми правдами-неправдами пытается его уломать сделать доработки для клиента. «Давай запилим эту фичу и получим стопяцот денег», – говорит он. И вот тут продакту важно не начать мыслить как сейлз.
Приведу пример. Крупные компании не используют Google Analytics, вместо него у них Adobe Analytics – более дорогое и безопасное решение. Но мы его не поддерживали. Наши сейлзы постоянно бомбардировали менеджера продукта заявками от крупных клиентов готовых платить за интеграцию с Adobe.
Наконец менеджер продукта с командой реализовали интеграцию с Adobe. Ее попробовали несколько клиентов и не стали пользоваться. Потому что им нужна была не интеграция, а решение их проблем. А проблемы их никто решать даже не пробовал. Не исследовал, зачем клиентам нужна эта интеграция и как они собираются ей пользоваться.
Менеджеру продукта важно помнить, что его роль – развивать продукт и приносить пользу клиентам, а не продавать фичи максимально дорого.
72. Болезнь дизайнеров, от которой надо излечиться
Есть тяжкий недуг продуктологов, дизайнеров и UX-серов, которым я долгие годы болел и излечился. Это переживание из-за мелких недоработок.
В продуктовой разработке внимание к деталям – это хорошо. Например, заметили, что люди вводят номер телефона и с пробелами, и с дефисами, и с +7 в начале, и с восьмеркой. И научились все это обрабатывать и принимать, а не выдавать дебильные сообщения «номер в неправильном формате». А вот переживать, что отступ перед полем «не по гайдлайну» или что тень при наведении на два пикселя меньше – это плохо.
Поправлять мелкие косяки дизайна – можно и нужно. Переживать о них – нельзя. А именно этим страдают многие ребята. Некоторые жутко на меня обижались, что я не разрешал тратить время команды на правки дизайнерских хотелок. Речь шла об админке с аудиторией в 3 человека.
Я сам дизайнер. Меня жутко раздражают мелкие косяки. Но я научился радоваться тому, что мы сделали хорошо. Вместо того, чтобы переживать о мелочах, которые мы не успели исправить.
Есть тяжкий недуг продуктологов, дизайнеров и UX-серов, которым я долгие годы болел и излечился. Это переживание из-за мелких недоработок.
В продуктовой разработке внимание к деталям – это хорошо. Например, заметили, что люди вводят номер телефона и с пробелами, и с дефисами, и с +7 в начале, и с восьмеркой. И научились все это обрабатывать и принимать, а не выдавать дебильные сообщения «номер в неправильном формате». А вот переживать, что отступ перед полем «не по гайдлайну» или что тень при наведении на два пикселя меньше – это плохо.
Поправлять мелкие косяки дизайна – можно и нужно. Переживать о них – нельзя. А именно этим страдают многие ребята. Некоторые жутко на меня обижались, что я не разрешал тратить время команды на правки дизайнерских хотелок. Речь шла об админке с аудиторией в 3 человека.
Я сам дизайнер. Меня жутко раздражают мелкие косяки. Но я научился радоваться тому, что мы сделали хорошо. Вместо того, чтобы переживать о мелочах, которые мы не успели исправить.
73. Продакт и аналитик
Пишет читатель канала:
У меня на работе от менеджера продукта требуют понимание статистики, методик A/B тестирования и умения рассчитывать продуктовые метрики (LTV, Retention, ARPU). Насколько я понимаю, расчеты метрик должен делать аналитик + строить гипотезы и передавать их менеджеру продукта. А продакт уже решает в какую сторону развивать продукт.
Мой препод по квантовой физике говорил: математики мыслят не как обычные люди, тут одному надо было обои на потолок поклеить, так он рассчитал сходящиеся к центру лепестки и долго вырезал их ножницами, в общем математики живут на своей волне.
Ребята и девчата, которые работают у нас аналитиками – это математики. Они не прогуливали мат. статистику и до сих пор шарят в вышке. А еще они читают статьи на английском, как в Нетфликсе уменьшают дисперсию. В общем, мне до них далеко, у меня вышка была первой парой и я вечно просыпал.
Они мыслят как математики и смотрят на продукт под особым углом. Ждать от них, что они принесут годные продуктовые гипотезы – не стоит. Продуктовой аналитикой должен заниматься… (сюрприз!) менеджер продукта. Именно он решает, какие продуктовые метрики надо улучшать и почему.
При этом продакту не обязательно круто шарить в SQL и мат. статистике. Достаточно понимать суть основных продуктовых метрик и уметь грамотно поставить задачу аналитикам, если своих знаний не хватает.
Пишет читатель канала:
У меня на работе от менеджера продукта требуют понимание статистики, методик A/B тестирования и умения рассчитывать продуктовые метрики (LTV, Retention, ARPU). Насколько я понимаю, расчеты метрик должен делать аналитик + строить гипотезы и передавать их менеджеру продукта. А продакт уже решает в какую сторону развивать продукт.
Мой препод по квантовой физике говорил: математики мыслят не как обычные люди, тут одному надо было обои на потолок поклеить, так он рассчитал сходящиеся к центру лепестки и долго вырезал их ножницами, в общем математики живут на своей волне.
Ребята и девчата, которые работают у нас аналитиками – это математики. Они не прогуливали мат. статистику и до сих пор шарят в вышке. А еще они читают статьи на английском, как в Нетфликсе уменьшают дисперсию. В общем, мне до них далеко, у меня вышка была первой парой и я вечно просыпал.
Они мыслят как математики и смотрят на продукт под особым углом. Ждать от них, что они принесут годные продуктовые гипотезы – не стоит. Продуктовой аналитикой должен заниматься… (сюрприз!) менеджер продукта. Именно он решает, какие продуктовые метрики надо улучшать и почему.
При этом продакту не обязательно круто шарить в SQL и мат. статистике. Достаточно понимать суть основных продуктовых метрик и уметь грамотно поставить задачу аналитикам, если своих знаний не хватает.
❤1
74. Положительное подкрепление в интерфейсах
Я регулярно участвую в благотворительных проектах из-за одной истории. В девяностых меня, голодного студента, знакомая накормила пирожками. Без повода, сама подошла и угостила. На вопрос, в честь чего такая щедрость, она ответила: «Всегда хотела заниматься благотворительностью, когда разбогатею; а тут подумала, вдруг никогда не разбогатею, поэтому решила помогать людям прямо сейчас тем, что имею».
Эта история так повлияла на меня, потому что я увидел быстрый результат и получил положительное подкрепление – меня накормили.
В пользовательских интерфейсах поощрение тоже работает. И я говорю не про ачивки.
У нас есть дашборд с виджетами, которые показывают нужные пользователю метрики. Вот только полезен он становится через неделю, когда соберется достаточно данных. Сразу после настройки он выглядит отстойно и бесполезно. Его проектировали для опытных пользователей и не подумали про новичков.
Мы изменили дизайн, чтобы виджеты уже на старте выглядели круто и давали полезную информацию. Пользователь получил положительное подкрепление «не зря настраивал».
Процесс настройки тоже улучшили. Новичкам было сложно найти необходимые для старта данные. Мы придумали, как сгенерировать эти данные автоматически. Теперь пользователь получает настроенный дашборд в пару кликов.
Помочь на старте и дать положительное подкрепление – рецепт хорошего онбординга.
Я регулярно участвую в благотворительных проектах из-за одной истории. В девяностых меня, голодного студента, знакомая накормила пирожками. Без повода, сама подошла и угостила. На вопрос, в честь чего такая щедрость, она ответила: «Всегда хотела заниматься благотворительностью, когда разбогатею; а тут подумала, вдруг никогда не разбогатею, поэтому решила помогать людям прямо сейчас тем, что имею».
Эта история так повлияла на меня, потому что я увидел быстрый результат и получил положительное подкрепление – меня накормили.
В пользовательских интерфейсах поощрение тоже работает. И я говорю не про ачивки.
У нас есть дашборд с виджетами, которые показывают нужные пользователю метрики. Вот только полезен он становится через неделю, когда соберется достаточно данных. Сразу после настройки он выглядит отстойно и бесполезно. Его проектировали для опытных пользователей и не подумали про новичков.
Мы изменили дизайн, чтобы виджеты уже на старте выглядели круто и давали полезную информацию. Пользователь получил положительное подкрепление «не зря настраивал».
Процесс настройки тоже улучшили. Новичкам было сложно найти необходимые для старта данные. Мы придумали, как сгенерировать эти данные автоматически. Теперь пользователь получает настроенный дашборд в пару кликов.
Помочь на старте и дать положительное подкрепление – рецепт хорошего онбординга.
Нужны ли комментарии к постам на этом канале? Предлагаю обсудить в новых нативных комментариях к этому посту.
P.S. Если вы не видите возможность комментировать этот пост, значит ваша версия приложения не поддерживает нативные комментарии. Эта фича должна дойти до всех платформ в ближайшее время.
P.S. Если вы не видите возможность комментировать этот пост, значит ваша версия приложения не поддерживает нативные комментарии. Эта фича должна дойти до всех платформ в ближайшее время.
75. Как слушать пользователей
Надо ли слушать пользователей? Рассмотрим пример этого чата.
На прошлой неделе в Телеграме появились нативные комментарии. Я включил их и спросил читателей, нужны ли они на этом канале. 65% комментаторов поддержали идею, 35% высказались против. Какой вывод можно сделать? Никакого! Назову причины:
1. Высказались 0.7% подписчиков. Статистически незначимая величина.
2. Высказались только любители комментировать. Бо́льшая часть аудитории читает молча.
3. У значительной доли аудитории все еще старая версия приложения и нет технической возможности комментировать.
4. Мой опыт подсказывает, что некоторые противники со временем полюбят фичу, а некоторый сторонники возненавидят.
В итоге из фидбэка пользователей нельзя сделать вывод, стоит ли внедрять фичу. Поэтому надо задать себе несколько вопросов:
– Почему я хочу внедрить эту фичу? Ответ «просто прикольно» тоже принимается.
– Сколько я готов инвестировать в ее реализацию и поддержку? Какие другие фичи отложатся?
– Изменение каких метрик я буду трактовать как успех? В каком случае я признаю поражение и закрою фичу?
Надо ли слушать пользователей? Конечно! Как говорится: «А Васька слушает, да ест».
————————————
В комментариях на этом канале принято дополнять тему поста, приводить примеры из практики и конструктивно критиковать. Мы не гонимся за количеством комментариев и дешёвой славой.
Надо ли слушать пользователей? Рассмотрим пример этого чата.
На прошлой неделе в Телеграме появились нативные комментарии. Я включил их и спросил читателей, нужны ли они на этом канале. 65% комментаторов поддержали идею, 35% высказались против. Какой вывод можно сделать? Никакого! Назову причины:
1. Высказались 0.7% подписчиков. Статистически незначимая величина.
2. Высказались только любители комментировать. Бо́льшая часть аудитории читает молча.
3. У значительной доли аудитории все еще старая версия приложения и нет технической возможности комментировать.
4. Мой опыт подсказывает, что некоторые противники со временем полюбят фичу, а некоторый сторонники возненавидят.
В итоге из фидбэка пользователей нельзя сделать вывод, стоит ли внедрять фичу. Поэтому надо задать себе несколько вопросов:
– Почему я хочу внедрить эту фичу? Ответ «просто прикольно» тоже принимается.
– Сколько я готов инвестировать в ее реализацию и поддержку? Какие другие фичи отложатся?
– Изменение каких метрик я буду трактовать как успех? В каком случае я признаю поражение и закрою фичу?
Надо ли слушать пользователей? Конечно! Как говорится: «А Васька слушает, да ест».
————————————
В комментариях на этом канале принято дополнять тему поста, приводить примеры из практики и конструктивно критиковать. Мы не гонимся за количеством комментариев и дешёвой славой.
#партнерскийпост с ProductStar. Я давно слышал, что они обучают продукту, аналитике, маркетингу и программированию. А недавно подписался на их телеграм канал, потому что там регулярно публикуются ссылки на интересные вебинары.
Меня заинтересовал вот этот: «Машинные методы обработки данных и симуляторы для оптимизации продукта». Я кое-что понимаю в аналитике данных, но в ее автоматизации и машинном обучении – откровенно слаб. Сегодня в 19:00 мск будет этот вебинар, присоединяйтесь.
Чтобы зарегистрироваться и быть в курсе новых вебинаров, подписывайтесь на канал @productstar
Меня заинтересовал вот этот: «Машинные методы обработки данных и симуляторы для оптимизации продукта». Я кое-что понимаю в аналитике данных, но в ее автоматизации и машинном обучении – откровенно слаб. Сегодня в 19:00 мск будет этот вебинар, присоединяйтесь.
Чтобы зарегистрироваться и быть в курсе новых вебинаров, подписывайтесь на канал @productstar
76. Неудачи на работе
У всех бывают неудачные проекты. Я мечтал о своем стартапе, получил шанс его открыть и развивать, а потом стартап обанкротился. Уверен, у вас есть свой список неудач. Иногда полезно обратиться к истории, чтобы найти вдохновляющие примеры людей, кто не сдался.
Кам Таунсенд родился в Калифорнии в 1896 г. С юности он мечтал стать миссионером и рассказывать индейцам Центральной Америки о Боге. На практике это оказалось очень сложно. Индейцы не могли читать Библию, потому что их язык не имел письменности. Один индеец раздраженно спросил его: «Послушай, если твой Бог такой умный, почему Он не выучит наш язык?»
Вопрос застиг Кама врасплох, и он решил изучить язык какчикельских индейцев, разработать для него письменность, перевести Библию и научить индейцев читать. Без лингвистической подготовки Кам столкнулся с огромными трудностями. Например, в языке индейцев существовало четыре звука «к», которые он едва мог отличить друг от друга.
Руководители Кама не понимали его озабоченности переводом Библии, и в конце концов уволили его. Тем не менее, через десять лет напряженного труда, Кам закончил перевод Нового Завета на какчикельский язык. Он стал одним из самых значимых переводчиков XX века и положил начало движению переводов на малые языки.
Давайте посмотрим на Кама Таунсенда как менеджера продукта:
– У него не было необходимых ресурсов и сильно недоставало опыта.
– Задача была «невыполнимой», поэтому ею никто не занимался.
– Много лет у него ничего не получалось.
– Когда он сделал невозможное, руководство этого не оценило.
– Он не сдался и изменил мир.
————————————
В комментариях на этом канале принято дополнять тему поста, приводить примеры из практики и конструктивно критиковать.
У всех бывают неудачные проекты. Я мечтал о своем стартапе, получил шанс его открыть и развивать, а потом стартап обанкротился. Уверен, у вас есть свой список неудач. Иногда полезно обратиться к истории, чтобы найти вдохновляющие примеры людей, кто не сдался.
Кам Таунсенд родился в Калифорнии в 1896 г. С юности он мечтал стать миссионером и рассказывать индейцам Центральной Америки о Боге. На практике это оказалось очень сложно. Индейцы не могли читать Библию, потому что их язык не имел письменности. Один индеец раздраженно спросил его: «Послушай, если твой Бог такой умный, почему Он не выучит наш язык?»
Вопрос застиг Кама врасплох, и он решил изучить язык какчикельских индейцев, разработать для него письменность, перевести Библию и научить индейцев читать. Без лингвистической подготовки Кам столкнулся с огромными трудностями. Например, в языке индейцев существовало четыре звука «к», которые он едва мог отличить друг от друга.
Руководители Кама не понимали его озабоченности переводом Библии, и в конце концов уволили его. Тем не менее, через десять лет напряженного труда, Кам закончил перевод Нового Завета на какчикельский язык. Он стал одним из самых значимых переводчиков XX века и положил начало движению переводов на малые языки.
Давайте посмотрим на Кама Таунсенда как менеджера продукта:
– У него не было необходимых ресурсов и сильно недоставало опыта.
– Задача была «невыполнимой», поэтому ею никто не занимался.
– Много лет у него ничего не получалось.
– Когда он сделал невозможное, руководство этого не оценило.
– Он не сдался и изменил мир.
————————————
В комментариях на этом канале принято дополнять тему поста, приводить примеры из практики и конструктивно критиковать.
❤1
Котаны!
Я ищу QA инженера с менеджерскими задатками в мою команду. Работа мечты, большая ответственность, огромная свобода и возможность проявить себя. Технические требования доостаточно высокие, но ничего сверхестественного. Нужен крепкий и бодрый мидл и выше.
Подробности – по ссылке. Вопросы – в коментах к посту.
https://spb.hh.ru/vacancy/39734226
Я ищу QA инженера с менеджерскими задатками в мою команду. Работа мечты, большая ответственность, огромная свобода и возможность проявить себя. Технические требования доостаточно высокие, но ничего сверхестественного. Нужен крепкий и бодрый мидл и выше.
Подробности – по ссылке. Вопросы – в коментах к посту.
https://spb.hh.ru/vacancy/39734226
77. Умение отказываться от работы
После института я работал инженером-электриком. Работа мне не нравилась, и я тратил все свободное время, чтобы стать дизайнером.
По началу заказов было очень мало. Я брался за любую работу и делал ее максимально хорошо. Помню, мне предложили делать шаблонные сайты за копейки. Я согласился, но делал каждый раз уникальный дизайн и сам верстал макет, хотя это не оплачивалось. Через год у меня было неплохое портфолио.
Появились клиенты, но развилась фобия упустить выгодный заказ. Однажды мне предложили сделать туристический портал для Испании под ключ. Я понимал, что работа слишком большая для меня, но все равно согласился. Полгода я работал почти круглосуточно.
Работая ночью, я почувствовал боль в желудке. На следующую ночь сильнее. Потом боли стали регулярными, но только при ночной работе. Тогда я впервые задумался, что, возможно, не стоит так много работать.
Однажды мне предложили отличный проект, а я отказался: «Спасибо, к сожалению, я занят». И мир не рухнул. Я по прежнему зарабатывал деньги, но теперь спал по ночам и проводил больше времени с женой и детьми.
Теперь моя дочь – начинающий дизайнер. Она с удовольствием берется за любые заказы и бывает засиживается допоздна. Поэтому я научил ее страшному секрету: можно отказываться от работы.
После института я работал инженером-электриком. Работа мне не нравилась, и я тратил все свободное время, чтобы стать дизайнером.
По началу заказов было очень мало. Я брался за любую работу и делал ее максимально хорошо. Помню, мне предложили делать шаблонные сайты за копейки. Я согласился, но делал каждый раз уникальный дизайн и сам верстал макет, хотя это не оплачивалось. Через год у меня было неплохое портфолио.
Появились клиенты, но развилась фобия упустить выгодный заказ. Однажды мне предложили сделать туристический портал для Испании под ключ. Я понимал, что работа слишком большая для меня, но все равно согласился. Полгода я работал почти круглосуточно.
Работая ночью, я почувствовал боль в желудке. На следующую ночь сильнее. Потом боли стали регулярными, но только при ночной работе. Тогда я впервые задумался, что, возможно, не стоит так много работать.
Однажды мне предложили отличный проект, а я отказался: «Спасибо, к сожалению, я занят». И мир не рухнул. Я по прежнему зарабатывал деньги, но теперь спал по ночам и проводил больше времени с женой и детьми.
Теперь моя дочь – начинающий дизайнер. Она с удовольствием берется за любые заказы и бывает засиживается допоздна. Поэтому я научил ее страшному секрету: можно отказываться от работы.
78. Поговорите на тимбилдинге
Команде надо устраивать тимбилдинги (не путайте с корпоративами), чтобы лучше узнать друг друга. Ценность тимбилдинга – в неформальном общении. Не у всех это получается.
Мы делали много прикольного: катались на картах, стреляли из ружей, играли в кёрлинг, посещали мастер-класс по готовке. С одной стороны, это сближает и потом есть, что вспомнить. Но качественного общения не получается. Перекинулись парой слов и всё.
Другой сценарий – выпить и закусить. Кажется, это идеальное время, чтобы поговорить. Но общение выходит однобоким – кто-то балагурит, кто-то молчит, кто-то напился. Сейчас все на удаленке, болтают в Зуме. Половина сидит молча.
Я нашел способ, как устроить запоминающуюся беседу, чтобы все высказались, и ведущему было не напряжно. Это игра «Матрёшка». Там есть карты с вопросами, выбираешь любой и отвечаешь по кругу. Например:
– Опиши свой идеальный день.
– Какое дикое животное ты бы хотел взять в питомцы и почему?
– Если в доме случится пожар, какую одну вещь ты спасешь?
– Что тебе больше всего нравится делать для других?
– Какой первый указ ты издашь, если станешь президентом страны?
Отвечают все, даже самые молчаливые, да еще и остановиться не могут. Узнаешь о коллегах много нового. Такие вопросы можно придумать самостоятельно. Пяти вопросов обычно хватает.
Команде надо устраивать тимбилдинги (не путайте с корпоративами), чтобы лучше узнать друг друга. Ценность тимбилдинга – в неформальном общении. Не у всех это получается.
Мы делали много прикольного: катались на картах, стреляли из ружей, играли в кёрлинг, посещали мастер-класс по готовке. С одной стороны, это сближает и потом есть, что вспомнить. Но качественного общения не получается. Перекинулись парой слов и всё.
Другой сценарий – выпить и закусить. Кажется, это идеальное время, чтобы поговорить. Но общение выходит однобоким – кто-то балагурит, кто-то молчит, кто-то напился. Сейчас все на удаленке, болтают в Зуме. Половина сидит молча.
Я нашел способ, как устроить запоминающуюся беседу, чтобы все высказались, и ведущему было не напряжно. Это игра «Матрёшка». Там есть карты с вопросами, выбираешь любой и отвечаешь по кругу. Например:
– Опиши свой идеальный день.
– Какое дикое животное ты бы хотел взять в питомцы и почему?
– Если в доме случится пожар, какую одну вещь ты спасешь?
– Что тебе больше всего нравится делать для других?
– Какой первый указ ты издашь, если станешь президентом страны?
Отвечают все, даже самые молчаливые, да еще и остановиться не могут. Узнаешь о коллегах много нового. Такие вопросы можно придумать самостоятельно. Пяти вопросов обычно хватает.
79. Глаза боятся, а руки делают
После свадьбы мы с женой купили квартиру в старом питерском доме, где вода нагревается газовой колонкой. Советские строители смонтировали колонку посередине стены. Шкафы повесить не было никакой возможности. Перенести колонку в другое место казалось нереальным.
После пары лет мучений я зашел в соседний магазин, купил новую колонку и длинный шланг. Вызвал газовщика, и через час колонка висела на новом месте. А вскоре появилась нормальная кухня. Проект, казавшийся невозможным, завершился за день.
Семь лет назад в моем стартапе вся команда работала удаленно. Три страны и 5 городов. Перейдя на работу в Семраш, я очень удивился, что все обязаны посещать офис. Вроде модная компания с гибкими процессами. Я пробовал протолкнуть идею свободного посещения офиса, но все считали это невозможным.
В этом году случился карантин и мы перешли на удаленку. Быстро и безболезненно. Стало только лучше. То, что казалось невозможным, оказалось легким.
Хотите, но боитесь? Возможно, спустя годы вы всё же попробуете и воскликните: «Ну почему я не сделал этого раньше!»
После свадьбы мы с женой купили квартиру в старом питерском доме, где вода нагревается газовой колонкой. Советские строители смонтировали колонку посередине стены. Шкафы повесить не было никакой возможности. Перенести колонку в другое место казалось нереальным.
После пары лет мучений я зашел в соседний магазин, купил новую колонку и длинный шланг. Вызвал газовщика, и через час колонка висела на новом месте. А вскоре появилась нормальная кухня. Проект, казавшийся невозможным, завершился за день.
Семь лет назад в моем стартапе вся команда работала удаленно. Три страны и 5 городов. Перейдя на работу в Семраш, я очень удивился, что все обязаны посещать офис. Вроде модная компания с гибкими процессами. Я пробовал протолкнуть идею свободного посещения офиса, но все считали это невозможным.
В этом году случился карантин и мы перешли на удаленку. Быстро и безболезненно. Стало только лучше. То, что казалось невозможным, оказалось легким.
Хотите, но боитесь? Возможно, спустя годы вы всё же попробуете и воскликните: «Ну почему я не сделал этого раньше!»
Короткий образовательный формат
У меня проблема с прослушиванием докладов на конференциях и вебинарами. Первые 45 минут я жутко скучаю, потом минут 15 идет что-то интересное. Остается чувство «можно было покороче». Поэтому на своем канале я пишу только короткие рассказы.
Партнеры @epicgrowth устраивают образовательный сериал для всех, кто занимается развитием продуктов – Epic Growth SEASONS. Его фишка – кейсы роста за 5-15 минут! Только самое главное, без воды. Этот формат мне заранее жутко нравится.
Начиная с 28 октября, каждую неделю будут выходить новые видеокейсы от быстрорастущих продуктов России и Кремниевой долины — Netflix, Miro, HubSpot, Booking. com, Яндекс GO, SoundCloud, Flo, Revolut и других.
Можно оформить подписку к Epic growth за 990 руб/мес. Я в бургерной на днях больше заплатил. Подписка даёт доступ не только к Сезонам, но и куче других докладов.
А для вас, моих любимых читателей, я выбил один бесплатный билет. Чтобы получить его, надо ответить на вопрос. Меня заинтересовал доклад продакта из Revolut «Дизайн Minimum Lovable Product для незнакомого рынка». Так что вопрос будет такой:
В каких случаях надо делать Minimum Lovable Product и как потом понять, что он Lovable?
Ответы пишите в свободной форме в комментариях или присылайте мне в личку, принимаются до 14:00 мск субботы (24 октября). Победителя выберу, опираясь на субъективизм и волюнтаризм.
Подробнее о сериале | #партнерскийпост
У меня проблема с прослушиванием докладов на конференциях и вебинарами. Первые 45 минут я жутко скучаю, потом минут 15 идет что-то интересное. Остается чувство «можно было покороче». Поэтому на своем канале я пишу только короткие рассказы.
Партнеры @epicgrowth устраивают образовательный сериал для всех, кто занимается развитием продуктов – Epic Growth SEASONS. Его фишка – кейсы роста за 5-15 минут! Только самое главное, без воды. Этот формат мне заранее жутко нравится.
Начиная с 28 октября, каждую неделю будут выходить новые видеокейсы от быстрорастущих продуктов России и Кремниевой долины — Netflix, Miro, HubSpot, Booking. com, Яндекс GO, SoundCloud, Flo, Revolut и других.
Можно оформить подписку к Epic growth за 990 руб/мес. Я в бургерной на днях больше заплатил. Подписка даёт доступ не только к Сезонам, но и куче других докладов.
А для вас, моих любимых читателей, я выбил один бесплатный билет. Чтобы получить его, надо ответить на вопрос. Меня заинтересовал доклад продакта из Revolut «Дизайн Minimum Lovable Product для незнакомого рынка». Так что вопрос будет такой:
В каких случаях надо делать Minimum Lovable Product и как потом понять, что он Lovable?
Ответы пишите в свободной форме в комментариях или присылайте мне в личку, принимаются до 14:00 мск субботы (24 октября). Победителя выберу, опираясь на субъективизм и волюнтаризм.
Подробнее о сериале | #партнерскийпост
80. Мало ресурсов – хорошо для продукта
Ограниченность ресурсов – благо для продукта. Вы делаете только самое нужное и создаете прорывные технологии.
Если ограничений нет – надо их придумать. Я пишу короткие притчи, не больше определенного количества знаков. В этом нет необходимости, я ввел лимит, чтобы истории получались лучше.
В менеджменте самое мощное ограничение – время. Когда запускаете продукт, поставьте себе реальный, но вызывающий срок. Скорее всего в процессе что-то пойдет не так, и вам захочется отодвинуть дедлайн. Сдержитесь. Оставьте только самое главное и запуститесь в срок. Дефицит времени заставляет чаще задавать вопрос: «А можем мы запуститься без этой фичи?»
Если у вас бедная компания, мало денег, злой начальник и неадекватные сроки – вы или сломаетесь или сделаете отличную работу. Если у вас богатая компания, много времени и неспешная ритм – скорее всего вы годами будете жевать сопли и в результате выпустите какую-нибудь ерунду.
Нет ограничений? Придумай их сам, на то ты и менеджер!
Ограниченность ресурсов – благо для продукта. Вы делаете только самое нужное и создаете прорывные технологии.
Если ограничений нет – надо их придумать. Я пишу короткие притчи, не больше определенного количества знаков. В этом нет необходимости, я ввел лимит, чтобы истории получались лучше.
В менеджменте самое мощное ограничение – время. Когда запускаете продукт, поставьте себе реальный, но вызывающий срок. Скорее всего в процессе что-то пойдет не так, и вам захочется отодвинуть дедлайн. Сдержитесь. Оставьте только самое главное и запуститесь в срок. Дефицит времени заставляет чаще задавать вопрос: «А можем мы запуститься без этой фичи?»
Если у вас бедная компания, мало денег, злой начальник и неадекватные сроки – вы или сломаетесь или сделаете отличную работу. Если у вас богатая компания, много времени и неспешная ритм – скорее всего вы годами будете жевать сопли и в результате выпустите какую-нибудь ерунду.
Нет ограничений? Придумай их сам, на то ты и менеджер!
Простите, но я снова с само рекламой вакансий в мою команду. На этот раз команда другая. Нужны суровые бэкендеры в новый инфраструктурный продукт. Я много где работал и могу с убежденностью сказать, что у нас очень круто во всех смыслах.
Java + GO Backend developer
GO developer
QA Engineer
Шар, репост, комент, колокольчик или что там у вас.
Java + GO Backend developer
GO developer
QA Engineer
Шар, репост, комент, колокольчик или что там у вас.
81. Незапланированное старение
Один таксист в Германии купил два Мерседес-Бенца. Думал отработает на одном, а когда тот износится, возьмет второй. В результате Мерс отработал в такси 30 лет, а вторая машина стояла нетронутая в гараже и после смерти таксиста досталась его детям. Современные Мерсы проектируют с запланированным старением, чтобы их меняли каждые 5 лет.
А что в IT? Я неоднократно встречал коммерчески успешные продукты, которые через 5 лет были технически мертвы. Клубок нечитаемого кода без документации на устаревших технологиях. Все разработчики уволились, никто не хочет заниматься помойкой. Приходится нанимать новую команду и переписывать продукт с нуля. Полгода-год продукт не развивается и отстает от конкурентов.
В отличии от автомобилей в IT-продуктах это не «запланированное старение», а недальновидность. В погоне за продуктовым ростом экономят на архитектуре, не планируют ресурсы на обслуживание технического долга и не учитывают стоимость поддержки.
Если всё сделать правильно, продукт всё равно будет полностью переписан через 5 лет. Но это произойдет постепенно и незаметно, как обновляются клетки у нас в организме.
Один таксист в Германии купил два Мерседес-Бенца. Думал отработает на одном, а когда тот износится, возьмет второй. В результате Мерс отработал в такси 30 лет, а вторая машина стояла нетронутая в гараже и после смерти таксиста досталась его детям. Современные Мерсы проектируют с запланированным старением, чтобы их меняли каждые 5 лет.
А что в IT? Я неоднократно встречал коммерчески успешные продукты, которые через 5 лет были технически мертвы. Клубок нечитаемого кода без документации на устаревших технологиях. Все разработчики уволились, никто не хочет заниматься помойкой. Приходится нанимать новую команду и переписывать продукт с нуля. Полгода-год продукт не развивается и отстает от конкурентов.
В отличии от автомобилей в IT-продуктах это не «запланированное старение», а недальновидность. В погоне за продуктовым ростом экономят на архитектуре, не планируют ресурсы на обслуживание технического долга и не учитывают стоимость поддержки.
Если всё сделать правильно, продукт всё равно будет полностью переписан через 5 лет. Но это произойдет постепенно и незаметно, как обновляются клетки у нас в организме.
❤1
82. Поделись акцией своей
Сравним нормального и отличного таксистов. Нормальный довезет вас в аэропорт за час, пользуясь навигатором. Отличный таксист знает больше навигатора и довезет за 45 минут, по пути спросит не мешает ли музыка. Разница в эффективности между нормальным и отличным таксистом – 30%.
Разница между нормальным и отличным работником в IT может достигать тысяч процентов. Есть прекрасные программисты, гениальные дизайнеры и крутейшие менеджеры, которые дадут вашему продукту в десятки раз больше, чем их коллеги. При этом стоят они примерно столько же.
Я не понимаю, почему в России до сих пор не существует компания, которая переманит к себе всех топовых инженеров и управленцев. И станет на порядок круче, мощнее и быстрее конкурентов. Конечно, это сложная задача, но есть лазейка – в России не принято делиться акциями.
Компании не делятся своей долей даже с топовыми работниками. Да, есть в Яндексе такая практика, но не во всём и не для всех. Компания, которая в добавок к интересному продукту, правильной культуре и хорошей зарплате ещё и акциями поделится – имеет шанс собрать самых крутых работников российского рынка.
Сравним нормального и отличного таксистов. Нормальный довезет вас в аэропорт за час, пользуясь навигатором. Отличный таксист знает больше навигатора и довезет за 45 минут, по пути спросит не мешает ли музыка. Разница в эффективности между нормальным и отличным таксистом – 30%.
Разница между нормальным и отличным работником в IT может достигать тысяч процентов. Есть прекрасные программисты, гениальные дизайнеры и крутейшие менеджеры, которые дадут вашему продукту в десятки раз больше, чем их коллеги. При этом стоят они примерно столько же.
Я не понимаю, почему в России до сих пор не существует компания, которая переманит к себе всех топовых инженеров и управленцев. И станет на порядок круче, мощнее и быстрее конкурентов. Конечно, это сложная задача, но есть лазейка – в России не принято делиться акциями.
Компании не делятся своей долей даже с топовыми работниками. Да, есть в Яндексе такая практика, но не во всём и не для всех. Компания, которая в добавок к интересному продукту, правильной культуре и хорошей зарплате ещё и акциями поделится – имеет шанс собрать самых крутых работников российского рынка.
Я написал для канала Product Mindset вредные советы. Вроде прикольно получилось, так что опубликую их и на своем канале. Дополняйте вредности в комментариях. #неуникальныйконтент
————————————
ВРЕДНЫЕ СОВЕТЫ ДЛЯ МЕНЕДЖЕРОВ ПРОДУКТА
1. Рассказывайте о бывших. Как только вы познакомились с новой командой, сразу же начинайте объяснять, как все у них неправильно устроено. Расскажите о своей прошлой работе, как там все было прекрасно, и вы ушли с нее, чтобы нести свет знаний в массы.
2. Делайте редизайн. Если вам не повезло стать менеджером старого продукта, начните с редизайна. Пользователи оценят новый красивый дизайн и продажи гарантированно вырастут.
3. Не спешите с релизом. Если вы запускаете новый продукт, постарайтесь до старта сделать как можно больше полезных фич. Все любят богатую функциональность, не страшно, если для ее создания придется задержать релиз продукта на несколько месяцев.
4. Пользуйтесь интуицией. Удачные изменения в продукте можно сделать только интуитивно. Никакая статистика и эксперименты не заменят чуйку продакта.
5. Слушайте пользователя. Вы слышали, что нужно слушать пользователей. А я говорю, слушайте даже одного пользователя. Успешный продукт не стоит слезинки одного человека. Незамедлительно реализуйте все хотелки всех пользователей.
6. Делайте много фич. Пользователи любят фичи. Выпускайте прикольные фичи как можно чаще, это гарантированно улучшить ваш продукт. Чем больше фич, тем лучше.
7. Слушайтесь начальника. Если бизнес-овнер просит что-то изменить в продукте, срочно это делайте. Спорить с ним опасно для карьеры. К тому же, он лучше знает, как развивать продукт.
8. Не удаляйте функциональность. Если запустили какую-то фичу, ни в коем случае не удаляйте ее. Даже если ей пользуется один человек (помните про слезинку пользователя). А если вообще никто не пользуется, все равно не удаляйте, чтобы не обижать разработчиков.
9. Не верьте в технический долг. Тех. долга не существует. Не верьте в эту пагубную ересь. Ее придумали ленивые программисты, чтобы ничего не делать.
10. Меняйте работу часто. Если что-то не получается, просто смените компанию. Идет продуктовый бум, менеджеры нарасхват. Вы легко найдете теплое местечко, где сможете применить эти советы.
————————————
ВРЕДНЫЕ СОВЕТЫ ДЛЯ МЕНЕДЖЕРОВ ПРОДУКТА
1. Рассказывайте о бывших. Как только вы познакомились с новой командой, сразу же начинайте объяснять, как все у них неправильно устроено. Расскажите о своей прошлой работе, как там все было прекрасно, и вы ушли с нее, чтобы нести свет знаний в массы.
2. Делайте редизайн. Если вам не повезло стать менеджером старого продукта, начните с редизайна. Пользователи оценят новый красивый дизайн и продажи гарантированно вырастут.
3. Не спешите с релизом. Если вы запускаете новый продукт, постарайтесь до старта сделать как можно больше полезных фич. Все любят богатую функциональность, не страшно, если для ее создания придется задержать релиз продукта на несколько месяцев.
4. Пользуйтесь интуицией. Удачные изменения в продукте можно сделать только интуитивно. Никакая статистика и эксперименты не заменят чуйку продакта.
5. Слушайте пользователя. Вы слышали, что нужно слушать пользователей. А я говорю, слушайте даже одного пользователя. Успешный продукт не стоит слезинки одного человека. Незамедлительно реализуйте все хотелки всех пользователей.
6. Делайте много фич. Пользователи любят фичи. Выпускайте прикольные фичи как можно чаще, это гарантированно улучшить ваш продукт. Чем больше фич, тем лучше.
7. Слушайтесь начальника. Если бизнес-овнер просит что-то изменить в продукте, срочно это делайте. Спорить с ним опасно для карьеры. К тому же, он лучше знает, как развивать продукт.
8. Не удаляйте функциональность. Если запустили какую-то фичу, ни в коем случае не удаляйте ее. Даже если ей пользуется один человек (помните про слезинку пользователя). А если вообще никто не пользуется, все равно не удаляйте, чтобы не обижать разработчиков.
9. Не верьте в технический долг. Тех. долга не существует. Не верьте в эту пагубную ересь. Ее придумали ленивые программисты, чтобы ничего не делать.
10. Меняйте работу часто. Если что-то не получается, просто смените компанию. Идет продуктовый бум, менеджеры нарасхват. Вы легко найдете теплое местечко, где сможете применить эти советы.