Сколько реальных часов в день вы работаете? (анонимно)
Anonymous Poll
5%
Менее 3 часов
16%
3-4 часа
32%
4-7 часов
26%
7-10 часов
9%
10+ часов
13%
Показать ответы
Выступление Димы Салливана (Sulliwan Studio) про поиск вдохновения, образование, дизайн, айти, работу, бизнес, рекламу, саморазвитие и многое другое.
Видосу почти десять лет, а инфа из него актуальна по сегодняшний день. Кому не хватает творческого заряда – welcome!
😎
Видосу почти десять лет, а инфа из него актуальна по сегодняшний день. Кому не хватает творческого заряда – welcome!
Please open Telegram to view this post
VIEW IN TELEGRAM
Vimeo
Lecture at the BHSAD
Art director Dmitry Sulliwan met with the students of British Higher School of Art and Design
Как понять уровень своих продуктовых навыков, знаний и опыта? Какой должности они сейчас соответствуют и что надо подтянуть, чтобы вырасти?
В дополнение к созданному мною год назад древу навыков продакт-менеджера, решил добавить таблицу для оценки этих самых навыков и компетенций.
С помощью неё гораздо проще увидеть свои сильные и слабые стороны и понять, на каком этапе карьерного развития ты сейчас находишься.
Блок справа (целевой показатель по должностям) – усреднённые показатели для Senior/Director/VP. Внизу можно увидеть свой итоговый результат и сравнить его с целевыми показателями для роста.
Ленивые эйчары (и не только) могут использовать эту табличку для предварительной оценки навыков будущих кандидатов. В таком случае, блок с целевыми показателями для вышестоящих должностей стоит скрыть.
👉 Статью с этой табличкой выложил на Виси, буду рад, если поддержите её там лайком :)
😎 RUSPM
В дополнение к созданному мною год назад древу навыков продакт-менеджера, решил добавить таблицу для оценки этих самых навыков и компетенций.
С помощью неё гораздо проще увидеть свои сильные и слабые стороны и понять, на каком этапе карьерного развития ты сейчас находишься.
Блок справа (целевой показатель по должностям) – усреднённые показатели для Senior/Director/VP. Внизу можно увидеть свой итоговый результат и сравнить его с целевыми показателями для роста.
Ленивые эйчары (и не только) могут использовать эту табличку для предварительной оценки навыков будущих кандидатов. В таком случае, блок с целевыми показателями для вышестоящих должностей стоит скрыть.
👉 Статью с этой табличкой выложил на Виси, буду рад, если поддержите её там лайком :)
Please open Telegram to view this post
VIEW IN TELEGRAM
В комментах ко вчерашней табличке про (само)оценку навыков продакт-менеджера на Виси развернулась странная дискуссия о том, должен ли руководитель быть умнее своих сотрудников.
Должен ли руководитель быть умнее своих сотрудников?
Anonymous Poll
25%
Да
53%
Нет
22%
Покажите ответы
#философияPM Два столпа, на которых держится м̶и̶р̶ любой продукт. Если рухнет один — другой не выстоит.
Объясняю простыми словами о двух главных подходах в развитии любого продукта, и главном – балансе между ними.
Объясняю простыми словами о двух главных подходах в развитии любого продукта, и главном – балансе между ними.
Telegraph
Два столпа, на которых держится любой продукт
✨ Безупречность. Продукты, ориентированные на безупречное исполнение, запускаются и развиваются там, где УЖЕ есть явные конкуренты и устоявшаяся пользовательская проблема/потребность (ясные потребности пользователей в основе). Сила: в отлаженной работе продукта…
#grow Вчера наткнулся на крайне увлекательный и смелый лонгрид про теорию вероятности, случайности и статистику.
Простой подброс монеты (точнее, 2 подхода к подсчету кардинально разных результатов одного события) позволит по новому взглянуть на современную экономику, финансы, социологию и другие отрасли. Всё приправлено математикой, Талебом и щепоткой конспирологии.
Читать: 300 лет в искаженной реальности (19 min read).
Вначале немного скучно, можно начать читать с "Из прошлого в будущее много путей, но реализуется лишь один".
Простой подброс монеты (точнее, 2 подхода к подсчету кардинально разных результатов одного события) позволит по новому взглянуть на современную экономику, финансы, социологию и другие отрасли. Всё приправлено математикой, Талебом и щепоткой конспирологии.
Читать: 300 лет в искаженной реальности (19 min read).
Вначале немного скучно, можно начать читать с "Из прошлого в будущее много путей, но реализуется лишь один".
Medium
300 лет в искаженной реальности
Назрел крупнейший прорыв в понимании случайности
#best #монетизация Продукт выстрелил и начал кратно расти. Что в таких случаях, обычно, меняется в команде/процессах "здорового продукта"?
1. Быстрый рост (и его последствия) усиливают желание экспериментировать с чем-то новым внутри продукта. "У нас же куча пользователей, давайте их пересегментируем, узнаем какие у них ещё проблемы и предложим каждой группе что-то новое?".
2. С одной стороны это норма и масштабирование через увеличение базы платящих клиентов, внедрение/копирование фич/продуктов, дробление на подпродукты/фичи и т.п. (12 нестандартных способов монетизации продуктов) это единственный путь для ещё большего роста.
3. С другой стороны, с ростом такой смелости и кол-ва решений увеличивается вероятность смещения фокуса (с основного продукта) и... совершения ошибок.
4. И да — чем быстрее вы растёте, тем больше смелость в решениях и... тем больше будет цена ошибок.
5. Смелость решений = смелость мышления. Поздравляю — вам больше не нужно думать, как привлечь 1,000 пользователей в месяц. Теперь вам надо думать как привлечь и удержать 100,000,000 пользователей.
Думаю, что не стоит капитанить и говорить о том, что retention это единственное, что никогда не должно выходить из вашей головы.
6. Итак, востребованность подтверждена (деньгами), выручка/юниты движутся вверх, сломать уже работающее вряд ли получится, а развиваться дальше надо.
Именно поэтому быстрый рост — идеальное время для того, чтобы начать переводить продукт/команду от ручного управления к автономному.
7. Ключевой момент — с ростом продукта появляется больше необходимой для принятия решений информации и возможностей для их генерации. Теперь задачи/идеи не должны спускаться сверху, а рождаться внутри команды/отделов (если этого не было ранее).
8. Снова капитаню — ищите слабые и сильные стороны своей команды, избавляйтесь от слабых, поддерживайте сильных в масштабах всей организации, а не единиц талантливых сотрудников (конкретно они должны толкать и мотивировать других своими талантами).
9. Ещё одно отличие быстрого роста — количество принимаемых решений и быстрота их принятия. Вы растёте с сумасшедшей скоростью. Неужели вы будете 6 месяцев проводить касдев и начинать аналогичные спринты?
Вы заметили, как быстро Телеграм и другие сетки выкатил голосовые чаты после "успеха" Клабхауса? Уот так уот.
10. Именно поэтому, рост самостоятельности и экспериментов в быстрорастущем продукте не способен сосуществовать с долгосрочным планированием.
События последних десятилетий наглядно показывают, насколько хрупки попытки успокоить себя тем, что мы всё просчитали и спланировали на годы вперёд.
1. Быстрый рост (и его последствия) усиливают желание экспериментировать с чем-то новым внутри продукта. "У нас же куча пользователей, давайте их пересегментируем, узнаем какие у них ещё проблемы и предложим каждой группе что-то новое?".
2. С одной стороны это норма и масштабирование через увеличение базы платящих клиентов, внедрение/копирование фич/продуктов, дробление на подпродукты/фичи и т.п. (12 нестандартных способов монетизации продуктов) это единственный путь для ещё большего роста.
3. С другой стороны, с ростом такой смелости и кол-ва решений увеличивается вероятность смещения фокуса (с основного продукта) и... совершения ошибок.
4. И да — чем быстрее вы растёте, тем больше смелость в решениях и... тем больше будет цена ошибок.
5. Смелость решений = смелость мышления. Поздравляю — вам больше не нужно думать, как привлечь 1,000 пользователей в месяц. Теперь вам надо думать как привлечь и удержать 100,000,000 пользователей.
Думаю, что не стоит капитанить и говорить о том, что retention это единственное, что никогда не должно выходить из вашей головы.
6. Итак, востребованность подтверждена (деньгами), выручка/юниты движутся вверх, сломать уже работающее вряд ли получится, а развиваться дальше надо.
Именно поэтому быстрый рост — идеальное время для того, чтобы начать переводить продукт/команду от ручного управления к автономному.
7. Ключевой момент — с ростом продукта появляется больше необходимой для принятия решений информации и возможностей для их генерации. Теперь задачи/идеи не должны спускаться сверху, а рождаться внутри команды/отделов (если этого не было ранее).
8. Снова капитаню — ищите слабые и сильные стороны своей команды, избавляйтесь от слабых, поддерживайте сильных в масштабах всей организации, а не единиц талантливых сотрудников (конкретно они должны толкать и мотивировать других своими талантами).
9. Ещё одно отличие быстрого роста — количество принимаемых решений и быстрота их принятия. Вы растёте с сумасшедшей скоростью. Неужели вы будете 6 месяцев проводить касдев и начинать аналогичные спринты?
Вы заметили, как быстро Телеграм и другие сетки выкатил голосовые чаты после "успеха" Клабхауса? Уот так уот.
10. Именно поэтому, рост самостоятельности и экспериментов в быстрорастущем продукте не способен сосуществовать с долгосрочным планированием.
События последних десятилетий наглядно показывают, насколько хрупки попытки успокоить себя тем, что мы всё просчитали и спланировали на годы вперёд.
#философияPM Попробовал рассмотреть крайне глубокую и непростую тему – интуицию в работе продакт-менеджера (хотя, наверное, и любого другого сотрудника, просто продакты чаще сталкиваются с ситуациями, когда возникает необходимость принятия решений в нестандартных условиях).
Мыслительные процессы, знания и опыт, аналитика и логика, а также немного философии, чтобы узнать что-то новое и отвлечься от суеты понедельника в статье ниже.
Мыслительные процессы, знания и опыт, аналитика и логика, а также немного философии, чтобы узнать что-то новое и отвлечься от суеты понедельника в статье ниже.
Telegraph
Инструкция по интуиции для продакт-менеджера
Интуиция, интуиция, интуиция. На небе только и разговоров, что об интуиции. Там говорят о том, как чертовски здорово наблюдать за результатами интуитивных решений. Хорошее вступление, чтобы рассказать о самом сложном, эффективном и крайне обманчивом навыке…
Please open Telegram to view this post
VIEW IN TELEGRAM
Долго принимаете решения даже по легким задачам и ждёте множество внешних подтверждений для этого?
По Безосу, есть два основных типа решений, которые вы можете принимать:
1) Принимаемое решение невозможно повернуть вспять. Безос называет такие решения «дверь в одну сторону» (по-английский звучит как "one-way door") и они означают, что переиграть решение будет либо крайне трудно, либо невозможно.
Например: продажа компании, увольнение с работы. Как только вы примете такое решение, пути назад уже не будет. Именно поэтому на них стоит тратить столько времени, сколько кажется нужным и не торопиться с решением.
2) Принимаемое решение можно вернуть назад. Он называет эти решения «дверь в обе стороны» ("two-way doors"). Такие решения всегда можно откатить и переиграть назад. Например: новая фича, реклама и т.п.
Всё что нужно делать, сталкиваясь с "two-way doors" решениями — не бояться быстро принимать, даже если у вас не хватает данных для этого, и так же быстро их откатывать, если что-то пошло не так.
😎 RUSPM
По Безосу, есть два основных типа решений, которые вы можете принимать:
1) Принимаемое решение невозможно повернуть вспять. Безос называет такие решения «дверь в одну сторону» (по-английский звучит как "one-way door") и они означают, что переиграть решение будет либо крайне трудно, либо невозможно.
Например: продажа компании, увольнение с работы. Как только вы примете такое решение, пути назад уже не будет. Именно поэтому на них стоит тратить столько времени, сколько кажется нужным и не торопиться с решением.
2) Принимаемое решение можно вернуть назад. Он называет эти решения «дверь в обе стороны» ("two-way doors"). Такие решения всегда можно откатить и переиграть назад. Например: новая фича, реклама и т.п.
Всё что нужно делать, сталкиваясь с "two-way doors" решениями — не бояться быстро принимать, даже если у вас не хватает данных для этого, и так же быстро их откатывать, если что-то пошло не так.
Please open Telegram to view this post
VIEW IN TELEGRAM
#job #team Умение эффективно коммуницировать с командой – один из ключевых навыков в работе продакт-менеджера.
Сегодня разбираемся в том, как и в каких случаях продакту правильно говорить "нет" вместо "подумаю/давай позже".
😎 RUSPM
Сегодня разбираемся в том, как и в каких случаях продакту правильно говорить "нет" вместо "подумаю/давай позже".
Please open Telegram to view this post
VIEW IN TELEGRAM
Telegraph
Как говорить "нет", если ты продакт-менеджер
В здоровом продукте со здоровой командой всегда будет входящий поток запросов на фичи, задачи, предложения и просто "интересные идеи" от команды/СЕО/инвесторов и даже пользователей, который будет только увеличиваться с ростом продукта и команды. Беда в том…
#market Пирамида Маслоу – визуализация базовых потребностей человека. Считается, что всё вокруг в мире строится именно на этих человеческих запросах.
Но задумывались ли вы о том, попадает ли ваш продукт, его проблема/решение хотя бы в одну из ступеней этой пирамиды?
Самореализация: продукты, которые развивают творческие способности и самовыражение.
Уважение: продукты, которые стимулируют чувство престижа и ощущение достижений.
Принадлежность: ощущение причастности к той или иной социальной группе.
Безопасность: продукты, дающие вам чувство безопасности во всех её видах и проявлениях.
Базовые потребности: удовлетворение базовых жизненных запросов.
Как вы уже поняли из картинки выше, чем больше разных функций вашего продукта будут подпадать под потребности людей (и чем больше проблем вы сможете ими закрыть), тем больше привязка/вовлечение пользователей к вашему продукту.
😎 RUSPM
Но задумывались ли вы о том, попадает ли ваш продукт, его проблема/решение хотя бы в одну из ступеней этой пирамиды?
Самореализация: продукты, которые развивают творческие способности и самовыражение.
Уважение: продукты, которые стимулируют чувство престижа и ощущение достижений.
Принадлежность: ощущение причастности к той или иной социальной группе.
Безопасность: продукты, дающие вам чувство безопасности во всех её видах и проявлениях.
Базовые потребности: удовлетворение базовых жизненных запросов.
Как вы уже поняли из картинки выше, чем больше разных функций вашего продукта будут подпадать под потребности людей (и чем больше проблем вы сможете ими закрыть), тем больше привязка/вовлечение пользователей к вашему продукту.
Please open Telegram to view this post
VIEW IN TELEGRAM
#fun Скучаете на совещаниях?
Сыграйте в бинго для продакт-менеджера!
Версия для печати: http://bit.ly/product-bingo
Сыграйте в бинго для продакт-менеджера!
Версия для печати: http://bit.ly/product-bingo
#job #философияPM Концепция продукта не является чем-то постоянным. Более того, она должна расти и развиваться вместе с продуктом, поэтому сегодня поговорим о том, из чего складывается концепция "здорового" продукта.
😎 RUSPM
Please open Telegram to view this post
VIEW IN TELEGRAM
Telegraph
Целостная концепция продукта
Обычно эти уровни изображаются в виде расширяющихся слоев, выстраивающихся друг над другом. Круги весьма удобны для визуализации и помогают понять, когда та или иная суб-концепция начинает подпирать другую или даже выходить за её рамки, сигнализируя продакт…
5 зависимостей, которые медленно убивают твой продукт
1. Зависимость от существующих клиентов. Постоянная и единственная аудитория с зафиксированным портретом/проблематикой является бомбой замедленного действия для продукта. Клиент не давал вам клятву финансовой верности в горе и здравии и даже если вам уже более года кажется, что "пользователи всем довольны", это может измениться в любой момент.
2. Зависимость от существующей бизнес-модели. Частично, этот пункт связан с первым, но думаю, что стоит выделить его отдельно, так как аудитория клиентов может (и должна) обновляться, но сама бизнес-модель может стоять на месте годами. Именно так с начала 2000-ых тонет рынок enterpise-решений, уступая место облачным решениям и SaaS с помесячной оплатой.
3. Зависимость от существующей технологии. Очень часто разработчики останавливаются на технологических решениях, которые они приняли на старте (5-10 лет назад) и на которых пытаются масштабировать свои продукты по сегодняшний день. Итог: техдолг, костыли и велосипеды, баги и слёзы разработчиков. Именно с этим постоянно борются в FAANG через покупку молодых современных стартапов или копирования их фич (но что делать с их нынешними продуктами – большой геморрой для их управленцев).
4. Зависимость от процессов. Бюрократия — бич любого бизнеса. Помни, что внутренние процессы должны расти и развиваться вместе с продуктом, ОБЛЕГЧАЯ и помогая команде в этй задаче, а не добавляя на каждый этап ещё больше отчетов/презентаций/апрувов. Про трансформацию продукта и процессов во время роста недавно писал здесь.
5. Зависимость продукта от самого себя. На самом деле, это обобщающий пункт. Каждый продукт начинает с одного единственного позиционирования "проблемы-решения", которое включает в себя все факторы, которые описаны выше.
Задача любого продукта — максимально расширить самого себя через решение большего количества пользовательских проблем.
Замкнулся на чём-то одном в своём продукте → игнорируешь остальные факторы и развитие рынка в целом → стоишь на месте → тебя обгоняют → You Lose!
😎 RUSPM
1. Зависимость от существующих клиентов. Постоянная и единственная аудитория с зафиксированным портретом/проблематикой является бомбой замедленного действия для продукта. Клиент не давал вам клятву финансовой верности в горе и здравии и даже если вам уже более года кажется, что "пользователи всем довольны", это может измениться в любой момент.
2. Зависимость от существующей бизнес-модели. Частично, этот пункт связан с первым, но думаю, что стоит выделить его отдельно, так как аудитория клиентов может (и должна) обновляться, но сама бизнес-модель может стоять на месте годами. Именно так с начала 2000-ых тонет рынок enterpise-решений, уступая место облачным решениям и SaaS с помесячной оплатой.
3. Зависимость от существующей технологии. Очень часто разработчики останавливаются на технологических решениях, которые они приняли на старте (5-10 лет назад) и на которых пытаются масштабировать свои продукты по сегодняшний день. Итог: техдолг, костыли и велосипеды, баги и слёзы разработчиков. Именно с этим постоянно борются в FAANG через покупку молодых современных стартапов или копирования их фич (но что делать с их нынешними продуктами – большой геморрой для их управленцев).
4. Зависимость от процессов. Бюрократия — бич любого бизнеса. Помни, что внутренние процессы должны расти и развиваться вместе с продуктом, ОБЛЕГЧАЯ и помогая команде в этй задаче, а не добавляя на каждый этап ещё больше отчетов/презентаций/апрувов. Про трансформацию продукта и процессов во время роста недавно писал здесь.
5. Зависимость продукта от самого себя. На самом деле, это обобщающий пункт. Каждый продукт начинает с одного единственного позиционирования "проблемы-решения", которое включает в себя все факторы, которые описаны выше.
Задача любого продукта — максимально расширить самого себя через решение большего количества пользовательских проблем.
Замкнулся на чём-то одном в своём продукте → игнорируешь остальные факторы и развитие рынка в целом → стоишь на месте → тебя обгоняют → You Lose!
Please open Telegram to view this post
VIEW IN TELEGRAM
This media is not supported in your browser
VIEW IN TELEGRAM
#fun Легендарное видео и страшный сон любого продакт-менеджера.
20 апреля 1998 года на конференции Comdex IT сотрудник Microsoft Крис Капоссела пытался подключить сканер к комьютеру, на котором была установлена Windows 98.
Этой презентацией Microsoft хотели показать возможности своей операционной системы и нового для тех времен формата подключения устройств "plug-and-play" (воткнул и пользуешься).
Как это часто случается, прямо во время презентации (и её трансляции по телеканалу CNN), в Windows что-то пошло не так и весь мир узнал, что означает фраза «синий экран смерти» и как она связана с продукцией Microsoft.
«Наверное, поэтому мы еще не поставляем Windows 98» - пошутил во время презентации Билл Гейтс.
P.S. Впрочем, этот фейл не помешал Windows стать операционкой №1, а Крису Капоселле получить должность директора по маркетингу Microsoft (спустя почти 16 лет после этого события).
😎 RUSPM
20 апреля 1998 года на конференции Comdex IT сотрудник Microsoft Крис Капоссела пытался подключить сканер к комьютеру, на котором была установлена Windows 98.
Этой презентацией Microsoft хотели показать возможности своей операционной системы и нового для тех времен формата подключения устройств "plug-and-play" (воткнул и пользуешься).
Как это часто случается, прямо во время презентации (и её трансляции по телеканалу CNN), в Windows что-то пошло не так и весь мир узнал, что означает фраза «синий экран смерти» и как она связана с продукцией Microsoft.
«Наверное, поэтому мы еще не поставляем Windows 98» - пошутил во время презентации Билл Гейтс.
P.S. Впрочем, этот фейл не помешал Windows стать операционкой №1, а Крису Капоселле получить должность директора по маркетингу Microsoft (спустя почти 16 лет после этого события).
Please open Telegram to view this post
VIEW IN TELEGRAM
#tools DDDD – подход от Британского совета по дизайну, который помогает систематизировать процесс работы над чем угодно (исследования, дизайн, разработка, маркетинг и т.д.)
Так, любой процесс состоит из двух областей работы над ним – Область проблемы (с расходящимся потоком информационной дивергенции и конвергенции) и Область решения.
Каждая из областей является составной частью другой и включает в себя этапы работ:
1. Discover (изучение). Включает в себя поиск и сбор информации по поставленной проблеме, рынку, данным и т.п.
Задавай вопросы, проводи исследования и собирай всю необходимую информацию для определения потенциальных возможностей и решений.
2. Define (определение). Аналитика и обработка полученной информации, её интерпретация на предмет дальнейшего возможного внедрения, стратегия продукта, его цели и основные функции.
На этом этапе также создается каркас продукта, включая пользовательские сценарии, требования и макеты.
3. Develop (разработка). Переход в область непосредственных работ по интеграции, внедрению, запуску (и тестированию) решения.
На этом этапе происходит процесс создания дизайна, разработки, тестирования и итеративного улучшения продукта.
4. Deliver (доставка). Дальнейшие действия, когда решение "передаётся" в руки того, для кого оно предназначается – пользователей или заказчиков.
Этот этап включает подготовку продукта к запуску, управление релизом, маркетинговые и PR-активности, а также обратную связь пользователей и мониторинг его использования.
Соблюдение этого порядка действий позволяет "не терять то, с чего начали" и держать фокус на логике процессов.
Так, любой процесс состоит из двух областей работы над ним – Область проблемы (с расходящимся потоком информационной дивергенции и конвергенции) и Область решения.
Каждая из областей является составной частью другой и включает в себя этапы работ:
1. Discover (изучение). Включает в себя поиск и сбор информации по поставленной проблеме, рынку, данным и т.п.
Задавай вопросы, проводи исследования и собирай всю необходимую информацию для определения потенциальных возможностей и решений.
2. Define (определение). Аналитика и обработка полученной информации, её интерпретация на предмет дальнейшего возможного внедрения, стратегия продукта, его цели и основные функции.
На этом этапе также создается каркас продукта, включая пользовательские сценарии, требования и макеты.
3. Develop (разработка). Переход в область непосредственных работ по интеграции, внедрению, запуску (и тестированию) решения.
На этом этапе происходит процесс создания дизайна, разработки, тестирования и итеративного улучшения продукта.
4. Deliver (доставка). Дальнейшие действия, когда решение "передаётся" в руки того, для кого оно предназначается – пользователей или заказчиков.
Этот этап включает подготовку продукта к запуску, управление релизом, маркетинговые и PR-активности, а также обратную связь пользователей и мониторинг его использования.
Соблюдение этого порядка действий позволяет "не терять то, с чего начали" и держать фокус на логике процессов.
#tools Начнём рабочую неделю с простых и очевидных вещей – инкрементальной доставки (и ещё немного про циклы Деминга).
Telegraph
Инкрементальная доставка и "Циклы Деминга"
Инкрементальная доставка – концепция поиска, разработки, внедрения и получения пользователем продукта или его компонентов в рамках небольших временных промежутков и этапов (шагов). Концепция берет своё начало еще в 30-ых годах, когда эксперт по проблемам…