Всем привет! Телеграм растёт все больше и больше, собирая в себе качественную и думающую аудиторию, поэтому решил завести канал о продакт-менеджменте. Боль будней, мучения выбора пути, слезы фидбека - обо всем по немногу
Отличный пост от Федора Овчинникова (основатель и руководитель Dodo Pizza) о том, как правильно мечтать и как правильно строить ценность в продукте. Для справки: у Dodo Pizza уже 165 пиццерий по всей России, а сама сеть перегоняет Папу Джонса в России по многим показателям.
"В последнее время люблю ходить пешком. Кажется, я забыл как выглядит Сыктывкар. Да, он выглядит как и сотни других однообразных российских городов. Если вы приедете от куда-нибудь из уютной Европы, наверное, почувствуете здесь безысходность.
Но для меня эти бетонные дворы наполнены большим смыслом. Я иду по дворам и вспоминаю запах влажного воздуха, когда шел на школьную дискотеку или восторг от похода в городской бассейн. И еще сегодня в окружении многоэтажек Сыктывкара я понял наш секрет успеха.
Пару месяцев назад один из директоров крупного фонда прямых инвестиций спросил меня: "Не пониманию, как вы привлекли франчайзи? Как вы можете конкурировать с большими серьезными сетями с многолетней историей? Почему они выбирали вас?".
Этот вопрос тогда ввел в меня замешательство. Все мои возможные ответы вдруг показались банальными, не раскрывающими сути. Как человеку в дорогом костюме из совершенно другого мира просто и понятно объяснить главное? И в чем же это главное?
Почему нас выбрали десятки предпринимателей? Почему наши будущие партнеры продавали свои машины и квартиры, уходили с престижной работы, бросали все и приезжали в Сыктывкар, шли на трудности, переезжали в другие города, меняли свою жизнь? Не смотря ни на что - на отсутствие опыта, ошибки, падающую информационную систему.
В развитие нашей сети вложена уже фантастическая сумма. Только представьте - более двух миллиардов рублей инвестировано в открытие 165 пиццерий нашей сети. Как так получилось, что эта дерзкая безумная мечта, появившаяся вокруг этих однообразных многоэтажек, таких же как и в сотнях городов нашей страны, вдруг стала реальностью? Сегодня я все понял.
Мечта. Все сделала мечта. Мы мечтали. Мечтали вокруг этих бетонных многоэтажек и гаражей, вокруг этой безысходности, о чем-то большем, и к нам шли такие же люди. Люди, которые верили, что безысходности нет. Верили в то, что не важно, откуда ты - из Сыктывкара, Тобольска, Ульяновска или Сарапула, ты сможешь добиться успеха, построить честный открытый бизнес, своими руками, с нуля, в этой стране. Мы просто дали веру. Вот и весь наш секрет.
И я понимаю, что наша миссия сегодня больше, чем просто пицца. На нас смотрят тысячи предпринимателей в России и мы говорим им - нет ничего невозможного. И мы не можем их подвести".
Федор Овчинников, CEO Dodo Pizza
"В последнее время люблю ходить пешком. Кажется, я забыл как выглядит Сыктывкар. Да, он выглядит как и сотни других однообразных российских городов. Если вы приедете от куда-нибудь из уютной Европы, наверное, почувствуете здесь безысходность.
Но для меня эти бетонные дворы наполнены большим смыслом. Я иду по дворам и вспоминаю запах влажного воздуха, когда шел на школьную дискотеку или восторг от похода в городской бассейн. И еще сегодня в окружении многоэтажек Сыктывкара я понял наш секрет успеха.
Пару месяцев назад один из директоров крупного фонда прямых инвестиций спросил меня: "Не пониманию, как вы привлекли франчайзи? Как вы можете конкурировать с большими серьезными сетями с многолетней историей? Почему они выбирали вас?".
Этот вопрос тогда ввел в меня замешательство. Все мои возможные ответы вдруг показались банальными, не раскрывающими сути. Как человеку в дорогом костюме из совершенно другого мира просто и понятно объяснить главное? И в чем же это главное?
Почему нас выбрали десятки предпринимателей? Почему наши будущие партнеры продавали свои машины и квартиры, уходили с престижной работы, бросали все и приезжали в Сыктывкар, шли на трудности, переезжали в другие города, меняли свою жизнь? Не смотря ни на что - на отсутствие опыта, ошибки, падающую информационную систему.
В развитие нашей сети вложена уже фантастическая сумма. Только представьте - более двух миллиардов рублей инвестировано в открытие 165 пиццерий нашей сети. Как так получилось, что эта дерзкая безумная мечта, появившаяся вокруг этих однообразных многоэтажек, таких же как и в сотнях городов нашей страны, вдруг стала реальностью? Сегодня я все понял.
Мечта. Все сделала мечта. Мы мечтали. Мечтали вокруг этих бетонных многоэтажек и гаражей, вокруг этой безысходности, о чем-то большем, и к нам шли такие же люди. Люди, которые верили, что безысходности нет. Верили в то, что не важно, откуда ты - из Сыктывкара, Тобольска, Ульяновска или Сарапула, ты сможешь добиться успеха, построить честный открытый бизнес, своими руками, с нуля, в этой стране. Мы просто дали веру. Вот и весь наш секрет.
И я понимаю, что наша миссия сегодня больше, чем просто пицца. На нас смотрят тысячи предпринимателей в России и мы говорим им - нет ничего невозможного. И мы не можем их подвести".
Федор Овчинников, CEO Dodo Pizza
#основы Продолжаю серию вводных публикаций на тему продакт-менеджмента.
Итак, кто же такой продакт-менеджер?
Вроде бы простой вопрос, но однажды я ради интереса собеседовался в Яндекс.Маркет на позицию, дословно - "менеджер продуктов Яндекс.Маркет".
Каково же было моё удивление, когда рекрутер сказала, что на этой должности мне надо будет следить за товарной составляющей витрины этого маркетплейса. Ну вы поняли 😐
Итак, продукт-менеджер "здорового человека" отвечает за самое главное - процесс постоянного производства и усовершенствования продукта для его пользователей с учетом их потребностей.
В отличие от менеджеров разных отделов (маркетинга, продаж или разработки), продакт-менеджер должен отвечать за то, чтобы перечисленные выше отделы наиболее эффективно взаимодействовали между собой в плане развития проекта, а также за самое главное - пользователей.
Начну с "других отделов". Продакт должен хорошо знать что такое маркетинг (как внутренний, так и внешний), разбираться в человеческой психологии (уметь общаться с совершенно разными людьми и чувствовать их), иметь хорошие организаторские навыки и, что самое главное - не бояться брать на себя и свои решения ответственность.
Данные умения позволят ему правильно интерпретировать поступающую от пользователей продукта информацию и принимать на её основании соответствующие решения для улучшения продукта, процесс реализации и внедрения которых ему впоследствии придётся контролировать (зачастую от этапа постановки задачи до тестирования на сайте).
Правильный продакт берет на себя обязанности (и ответственность) в формировании списка новых продуктовых фич и контролирует их запуск.
Главный друг продакт-менеджера это маркетолог. Вместе с ним они позиционируют продукт, строят в нем и вокруг него стратегию развития, которая, в идеале, должна быть публичной частью всего продукта - пользователи любят открытые компании с прозрачными процессами.
Пользователям отводится отдельное место в работе продакта. Именно он (вместе с маркетологом) отвечает за сбор обратной связи от тех, кто пользуется продуктом и платит за него деньги. Единственная разница продакта и маркетолога в этом процессе лишь в том, где происходит их контакт с пользователями - в рекламе или в процессе работы с продуктом, но я предпочитают сильно не разделять эти точки контакта - в идеале, что юзер видит в рекламе, то он и должен получить в продукте.
П.с В чем разница между проект-менеджером и продукт-менеджером? Сломано много копий.
Моё мнение, что первый отвечает за реализацию продукта в рамках команды без пользователей. Это хорошо работает для команд разработки, когда все необходимые умозаключения уже сделаны и надо просто сделать "быстро и качественно.
Второй отвечает за реализацию продукта с живыми пользователями, когда перед реализацией каждой задачи нужно хорошенько пораскинуть мозгами и прикинуть все варианты её работы для пользователя.
Итак, кто же такой продакт-менеджер?
Вроде бы простой вопрос, но однажды я ради интереса собеседовался в Яндекс.Маркет на позицию, дословно - "менеджер продуктов Яндекс.Маркет".
Каково же было моё удивление, когда рекрутер сказала, что на этой должности мне надо будет следить за товарной составляющей витрины этого маркетплейса. Ну вы поняли 😐
Итак, продукт-менеджер "здорового человека" отвечает за самое главное - процесс постоянного производства и усовершенствования продукта для его пользователей с учетом их потребностей.
В отличие от менеджеров разных отделов (маркетинга, продаж или разработки), продакт-менеджер должен отвечать за то, чтобы перечисленные выше отделы наиболее эффективно взаимодействовали между собой в плане развития проекта, а также за самое главное - пользователей.
Начну с "других отделов". Продакт должен хорошо знать что такое маркетинг (как внутренний, так и внешний), разбираться в человеческой психологии (уметь общаться с совершенно разными людьми и чувствовать их), иметь хорошие организаторские навыки и, что самое главное - не бояться брать на себя и свои решения ответственность.
Данные умения позволят ему правильно интерпретировать поступающую от пользователей продукта информацию и принимать на её основании соответствующие решения для улучшения продукта, процесс реализации и внедрения которых ему впоследствии придётся контролировать (зачастую от этапа постановки задачи до тестирования на сайте).
Правильный продакт берет на себя обязанности (и ответственность) в формировании списка новых продуктовых фич и контролирует их запуск.
Главный друг продакт-менеджера это маркетолог. Вместе с ним они позиционируют продукт, строят в нем и вокруг него стратегию развития, которая, в идеале, должна быть публичной частью всего продукта - пользователи любят открытые компании с прозрачными процессами.
Пользователям отводится отдельное место в работе продакта. Именно он (вместе с маркетологом) отвечает за сбор обратной связи от тех, кто пользуется продуктом и платит за него деньги. Единственная разница продакта и маркетолога в этом процессе лишь в том, где происходит их контакт с пользователями - в рекламе или в процессе работы с продуктом, но я предпочитают сильно не разделять эти точки контакта - в идеале, что юзер видит в рекламе, то он и должен получить в продукте.
П.с В чем разница между проект-менеджером и продукт-менеджером? Сломано много копий.
Моё мнение, что первый отвечает за реализацию продукта в рамках команды без пользователей. Это хорошо работает для команд разработки, когда все необходимые умозаключения уже сделаны и надо просто сделать "быстро и качественно.
Второй отвечает за реализацию продукта с живыми пользователями, когда перед реализацией каждой задачи нужно хорошенько пораскинуть мозгами и прикинуть все варианты её работы для пользователя.
#основы Чем занята голова продакт-менеджера? Мыслями о постоянном улучшении и расширении функционала продукта.
При полном погружении в проект, вам ежедневно на ум приходит множество вариантов того, как может работать та или иная функция, а также различные идеи в духе "вау, это надо запилить".
Любые идеи, связанные с тем, над чем вы работаете, (даже самые бредовые) необходимо в обязательном порядке записывать. Поверьте мне на слово - ваш мозг не в состоянии удержать постоянно проступающий объём информации - её настолько много и она связана с настолько различными направлениями работы продукта, что удержать все эти связи в голове продукт-менеджера очень сложно.
Да и не нужно - я вообще придерживаюсь тактики "свободного рабочего сознания" - ты держишь в голове (и в документации) только приоритетные и самые важные задачи, которые требуют усиленного внимания, а для всего остального есть заметки, которые вы должны приучить себя вести.
Как не потеряться в большом объёме заметок и приучить себя записывать кажущиеся важными и интересными вещи? Довольно просто - найти инструмент, который поможет делать это очень быстро.
Лучший помощник продакт-менеджера в этом - сервис Google Keep, о котором мало кто знает.
Это универсальный сервис универсальных заметок: Вы можете записывать в нем тексты, ссылки, аттачить файлы и ставить напоминания. Приложения, веб-версия, все в гугловском облаке + даже есть расширение для Chrome. И да, все бесплатное
Все, кто раньше использовал Evernote (RIP) и кому я показал этого малыша, без раздумий перешли на него.
Учитывайте и сохраняйте в цифре все, что вам может пригодиться в жизни и работе и не сожалейте о том, что вы забыли что-то интересное просто потому, что вовремя не записали это!
Контролируйте своё сознание и мысли и да прибудет с вами сила!
При полном погружении в проект, вам ежедневно на ум приходит множество вариантов того, как может работать та или иная функция, а также различные идеи в духе "вау, это надо запилить".
Любые идеи, связанные с тем, над чем вы работаете, (даже самые бредовые) необходимо в обязательном порядке записывать. Поверьте мне на слово - ваш мозг не в состоянии удержать постоянно проступающий объём информации - её настолько много и она связана с настолько различными направлениями работы продукта, что удержать все эти связи в голове продукт-менеджера очень сложно.
Да и не нужно - я вообще придерживаюсь тактики "свободного рабочего сознания" - ты держишь в голове (и в документации) только приоритетные и самые важные задачи, которые требуют усиленного внимания, а для всего остального есть заметки, которые вы должны приучить себя вести.
Как не потеряться в большом объёме заметок и приучить себя записывать кажущиеся важными и интересными вещи? Довольно просто - найти инструмент, который поможет делать это очень быстро.
Лучший помощник продакт-менеджера в этом - сервис Google Keep, о котором мало кто знает.
Это универсальный сервис универсальных заметок: Вы можете записывать в нем тексты, ссылки, аттачить файлы и ставить напоминания. Приложения, веб-версия, все в гугловском облаке + даже есть расширение для Chrome. И да, все бесплатное
Все, кто раньше использовал Evernote (RIP) и кому я показал этого малыша, без раздумий перешли на него.
Учитывайте и сохраняйте в цифре все, что вам может пригодиться в жизни и работе и не сожалейте о том, что вы забыли что-то интересное просто потому, что вовремя не записали это!
Контролируйте своё сознание и мысли и да прибудет с вами сила!
#основы О разнице двух ключевых типов онлайн-продуктов
Все онлайн-продукты (а мы здесь ведём речь только об интернете) можно поделить на два условных типа:
1) массовый продукт
2) узкоцелевой продукт
К массовым продуктам можно отнести социальные сети, мессенджеры, агрегаторы, часть проектов из e-commerce сегмента (в т.ч. всякие кешбеки), в общем, онлайн-сервисы, которыми может одновременно пользоваться и муж и жена вне зависимости от их профессии и интересов.
Кстати, это весьма удобный и быстрый способ определить тип продукта, не правда ли?
Обычно, массовые продукты насчитывают десятки и сотни миллионов пользователей. Само собой, именно такие проекты привлекают все больше и больше желающих сделать очередной Твиттер или Юбер и мерять рост своего проекта цифрами с семью порядками.
Бедняги - немногие понимают, что преимуществом и одновременным проклятием массового продукта является то, что с него сложнее получить верную и корректную обратную связь, таргетироваться на качественную целевую аудиторию чтобы понять, что нужно пользователям и куда идти дальше.
Я не говорю уже о том, что деньги на маркетинг такого продукта нужно умножать пропорционально размеру ожидаемой базы пользователей и также считать по стоимости привлечения за пользователя.
Почему так? В массовых продуктах обычно задействуются широкие каналы маркетинга: ТВ, медийка, контекст, за счёт чего весьма сложно собрать условные группы пользователей для проведения опросов и даже если это получится сделать, то не факт, что выборка и фидбек с них будут верными (т.к. чем больше в продукте пользователей, тем больше выборки по ним вам нужны).
В работе над такими продуктами лучше всего подходит "общение" с пользователями через цифры - объемы данных и статистики сайта или приложения настолько огромные, что по ним легко определять "болевые места" и проводить а/б-тестирования без прямого диалога с пользователями - любое изменение и реакция пользовательского поведения на него непременно найдёт своё подтверждение на очередном графике активности.
Узкоцелевые продукты просты в работе и маркетинге над ними (это правда - поверьте, что продвигать узкоцелевое легче, чем широкое), но заранее ограничены своей аудиторией - привлекая пользователей и решая их единственную проблему будет гораздо сложнее предлагать им что-то совершенно другое.
Мне нравится работать с узкоцелевыми проектами - они и их концепции более прозрачны и понятны, и, что самое главное - их пользователей легче "пощупать" и напрямую пообщаться с ними, чтобы понять что им нужно от вашего продукта. Именно в этом их гибкость - четкие аудитории узкоцелевых продуктов дают более чёткие и более полезные ответы.
Всем продуктивной недели!
Все онлайн-продукты (а мы здесь ведём речь только об интернете) можно поделить на два условных типа:
1) массовый продукт
2) узкоцелевой продукт
К массовым продуктам можно отнести социальные сети, мессенджеры, агрегаторы, часть проектов из e-commerce сегмента (в т.ч. всякие кешбеки), в общем, онлайн-сервисы, которыми может одновременно пользоваться и муж и жена вне зависимости от их профессии и интересов.
Кстати, это весьма удобный и быстрый способ определить тип продукта, не правда ли?
Обычно, массовые продукты насчитывают десятки и сотни миллионов пользователей. Само собой, именно такие проекты привлекают все больше и больше желающих сделать очередной Твиттер или Юбер и мерять рост своего проекта цифрами с семью порядками.
Бедняги - немногие понимают, что преимуществом и одновременным проклятием массового продукта является то, что с него сложнее получить верную и корректную обратную связь, таргетироваться на качественную целевую аудиторию чтобы понять, что нужно пользователям и куда идти дальше.
Я не говорю уже о том, что деньги на маркетинг такого продукта нужно умножать пропорционально размеру ожидаемой базы пользователей и также считать по стоимости привлечения за пользователя.
Почему так? В массовых продуктах обычно задействуются широкие каналы маркетинга: ТВ, медийка, контекст, за счёт чего весьма сложно собрать условные группы пользователей для проведения опросов и даже если это получится сделать, то не факт, что выборка и фидбек с них будут верными (т.к. чем больше в продукте пользователей, тем больше выборки по ним вам нужны).
В работе над такими продуктами лучше всего подходит "общение" с пользователями через цифры - объемы данных и статистики сайта или приложения настолько огромные, что по ним легко определять "болевые места" и проводить а/б-тестирования без прямого диалога с пользователями - любое изменение и реакция пользовательского поведения на него непременно найдёт своё подтверждение на очередном графике активности.
Узкоцелевые продукты просты в работе и маркетинге над ними (это правда - поверьте, что продвигать узкоцелевое легче, чем широкое), но заранее ограничены своей аудиторией - привлекая пользователей и решая их единственную проблему будет гораздо сложнее предлагать им что-то совершенно другое.
Мне нравится работать с узкоцелевыми проектами - они и их концепции более прозрачны и понятны, и, что самое главное - их пользователей легче "пощупать" и напрямую пообщаться с ними, чтобы понять что им нужно от вашего продукта. Именно в этом их гибкость - четкие аудитории узкоцелевых продуктов дают более чёткие и более полезные ответы.
Всем продуктивной недели!
Что такое MVP и каким его правильно "пилить"?
Всем привет! Продолжая рубрику #основыPM хочу рассказать вам о самой базовой вещи, с которой должен начинаться любой онлайн-продукт - MVP (эмвипи), что в переводе с английского означает minimum viable product или минимально-рабочий продукт.
Если совсем кратко, то "правильный" MVP это самое первое состояние только что запустившегося проекта, при котором в нем нет крутых фишек, модного UI и дизайна, полноценной внутренней админки, оптимизации кода и прочих вещей, которые есть у уже работающих и доказавших свою востребованность продуктов.
Главное предназначение MVP при запуске новых продуктов - максимально БЫСТРО разработать и выкатить новый продукт в паблик с основной работающей механикой, привлечь на него первую волну юзеров и начать изучать: а) спрос на этот продукт, б) спрос на будущий функционал продукта.
"Правильный" MVP в первой версии всегда должен решать только свою главную и основную задачу, а весь дополнительный функционал должен всегда пилиться позже после публичного старта и первой пользовательской активности.
Почему так? Есть несколько причин:
1) Вы можете пилить функциональный сервис с "фичами и плюшками", который после запуска окажется никому не нужен (такое случается в большинстве случаев). Сделайте минимальную версию продукта и проверьте свою гипотезу насчет его востребованности.
2) Больше фич на страрте = больше времени/сил/денег на их разработку и тем больше времени до начала старта проекта. Можно успеть перегореть еще даже не запустившись.
3) У вас нет фидбека от пользователей и вы не можете знать нужна им эта фича в вашем продукте или нет (вы ведь еще не запустились). А тех, кто уверен, что нужна, я разочарую - не факт, что она нужна им именно такой, какой вы ее сделали - сам множество раз на этом обжигался.
Главная ошибка 80% всех продукт-менеджеров - желание запихнуть в MVP функции, которые "ну точно нужны и пригодятся пользователям". Это оттягивает запуск и настоящую работу над продуктом.
Будьте уверены, что в большинстве случаев о том, что нужно пользователям они скажут сами - вам останется только обработать эту информации и на ее основании сделать выводы и принять дальнейшие решения.
Закончу пост цитатой Рейда Хоффмана, со-основателя LinkedIn и исполнительного директора PayPal
«Если вам не стыдно за первую версию вашего продукта, вы запустились слишком поздно»
Всем хороших выходных 😎
Всем привет! Продолжая рубрику #основыPM хочу рассказать вам о самой базовой вещи, с которой должен начинаться любой онлайн-продукт - MVP (эмвипи), что в переводе с английского означает minimum viable product или минимально-рабочий продукт.
Если совсем кратко, то "правильный" MVP это самое первое состояние только что запустившегося проекта, при котором в нем нет крутых фишек, модного UI и дизайна, полноценной внутренней админки, оптимизации кода и прочих вещей, которые есть у уже работающих и доказавших свою востребованность продуктов.
Главное предназначение MVP при запуске новых продуктов - максимально БЫСТРО разработать и выкатить новый продукт в паблик с основной работающей механикой, привлечь на него первую волну юзеров и начать изучать: а) спрос на этот продукт, б) спрос на будущий функционал продукта.
"Правильный" MVP в первой версии всегда должен решать только свою главную и основную задачу, а весь дополнительный функционал должен всегда пилиться позже после публичного старта и первой пользовательской активности.
Почему так? Есть несколько причин:
1) Вы можете пилить функциональный сервис с "фичами и плюшками", который после запуска окажется никому не нужен (такое случается в большинстве случаев). Сделайте минимальную версию продукта и проверьте свою гипотезу насчет его востребованности.
2) Больше фич на страрте = больше времени/сил/денег на их разработку и тем больше времени до начала старта проекта. Можно успеть перегореть еще даже не запустившись.
3) У вас нет фидбека от пользователей и вы не можете знать нужна им эта фича в вашем продукте или нет (вы ведь еще не запустились). А тех, кто уверен, что нужна, я разочарую - не факт, что она нужна им именно такой, какой вы ее сделали - сам множество раз на этом обжигался.
Главная ошибка 80% всех продукт-менеджеров - желание запихнуть в MVP функции, которые "ну точно нужны и пригодятся пользователям". Это оттягивает запуск и настоящую работу над продуктом.
Будьте уверены, что в большинстве случаев о том, что нужно пользователям они скажут сами - вам останется только обработать эту информации и на ее основании сделать выводы и принять дальнейшие решения.
Закончу пост цитатой Рейда Хоффмана, со-основателя LinkedIn и исполнительного директора PayPal
«Если вам не стыдно за первую версию вашего продукта, вы запустились слишком поздно»
Всем хороших выходных 😎
Всем привет! Подготовил для вас небольшую подборку статей на тему управления продуктами.
Пока есть время на выходных и мозг не занят работой, рекомендую прочитать #основы, которые точно будут вам полезны и интересны.
– Как управлять командой в быстрорастущей компании
– Как узнать за один вечер почти все о целевом рынке, не потратив ни рубля
– Пользовательские сценарии: что это такое, как и для чего их нужно строить
– Двое разработчиков о корпоративной культуре Uber
– Five Models for Making Sense of Complex Systems
Ну, а в понедельник будет пост о том, что такое дизайн продукта и о месте продукт-менеджера в его разработке.
Всем хороших выходных 😎
Пока есть время на выходных и мозг не занят работой, рекомендую прочитать #основы, которые точно будут вам полезны и интересны.
– Как управлять командой в быстрорастущей компании
– Как узнать за один вечер почти все о целевом рынке, не потратив ни рубля
– Пользовательские сценарии: что это такое, как и для чего их нужно строить
– Двое разработчиков о корпоративной культуре Uber
– Five Models for Making Sense of Complex Systems
Ну, а в понедельник будет пост о том, что такое дизайн продукта и о месте продукт-менеджера в его разработке.
Всем хороших выходных 😎
SPARK
Как узнать за один вечер почти все о целевом рынке, не потратив ни рубля
С чего начать, если у вас есть идея нового продукта или услуги, или вы планируете выйти на новый рынок, расширив линейку своих предложений? ...
#основы Читатели пишут в личку и спрашивают:
"Есть ли какой-то алгоритм создания продукта и где работа над продуктом заканчивается?"
Поделюсь своими мыслями на этот счет в виде пошагового чек-листа по превращению идеи в осязаемый продукт.
Шаг №1 Идея. Собираемся с мыслями, упорядочиваем их, выделяем ключевую проблему, которую решает будущий продукт, определяем его целевую аудиторию, думаем над всеми возможными путями решения проблемы. Все выписываем на листочек (бумага рулит).
Важно - на этом этапе ни за кем из конкурентов пока не подглядываем. Дайте вашему мозгу свободно и без примеров подумать над решением проблемы - возможно, благодаря этому он придумает то, до чего еще никто не додумался.
Шаг №2 Оценка возможностей и перспектив идеи. Думаем, к̶у̶д̶а̶ ̶п̶р̶и̶в̶о̶д̶я̶т̶ ̶м̶е̶ч̶т̶ы̶ над потенциалом будущего продукта и его возможном применение на другие проблемы/отрасли или направления рынка, т.е. оцениваем его возможную масштабируемость.
Шаг №3 Анализ рынка. И только щас внимательно изучаем рынок, его особенности и то, как он работает.
В обязательном порядке и не меньше месяца читаем о нем кучу материалов/статей/интервью - вам нужно понять и разобраться как уже работает отрасль, в которую вы хотите залезть со своим продуктом и как ваш продукт может быть для нее полезен.
Одновременно с этим, собираем инфу по лидерам и основным игрокам, читаем и собираем фидбек от их пользователей по ним, трясем вопросами самих конкурентов под видом их пользователей и хитрыми путями узнаем как работает их внутренняя "кухня". Попутно аккумулируем всю инфу и ищем их сильные и слабые места и примеряем все на свой будущий продукт.
Шаг №4. Оцениваем затраты на запуск MVP. Чикаем из минималки всё ненужное, оставляем только ключевую идею и решение ключевой проблемы (пост об этом: https://yangx.top/ruspm/21).
Прикидываем, во сколько сил, рук, денег и времени нам обойдется запуск MVP и плюсуем к получившимся цифрам еще 30% для подстраховки.
Реклама. Без нее никуда и деньги на нее должны быть. Времена свободных ниш и "Запилил - выстрелило" давно прошли. Не тешьте себя иллюзиями. Сколько денег нужно? Чем больше, тем лучше. Но хотя бы тыщ 150 - 300.
Шаг №5. Принятие решения о запуске MVP. Теперь у вас перед глазами есть вся информация, которая поможет вам принять взвешенное решение. Трезво оцениваем свои силы, средства и знания и принимаем его.
Шаг №6 Разработка MVP. Пилим MVP :) Пока команда разработки (или программист) делает это, начинаем готовить и планировать маркетинговые активности под MVP. Это отдельная тема, возможно, когда-нибудь я напишу об этом пост.
Шаг №7 Маркетинговое тестирование MVP. Ура - продукт в MVP запилен и настало время проверить, действительно ли он востребован теми, для кого создавался.
Включаем маркетинг, льем неспеша трафик, воронка продаж, все дела. Смотрим как всё работает, тестируем продукт самостоятельно и через пользователей и, самое главное - собираем от них фидбек.
Шаг №8 Оценка результатов и принятие решения. После 3-6 месяцев такого маркетинга и непосредственной работы пользователей с продуктом становится понятно, есть ли смысл развивать MVP дальше в полноценный продукт, наращивая на него фичи и вливая еще больше денег в маркетинг.
Важный момент - на этом этапе и в этот срок мы лишь проверяем нашу идею, а не выводим продукт на окупаемость. На основании чего принимать решение? Сложный вопрос. Играет роль и обратная связь от юзеров и общая тональность отзывов и цифры статистики по рекламе и конверсиям.
Решений бывает два:
а) Убедиться в состоятельности идеи/продукта, двигаться и развиваться дальше, расширяя функционал и наращивая базу пользователей.
б) либо признаться в несостоятельности идеи и закрыть проект минусами. Ничего страшного в этом нет - гораздо страшнее развивать "мертворожденный продукт" и спустя N лет его также закрыть, но с еще большими минусами.
Отвечая на вопрос: "Где работа над продуктом заканчивается?"
Нигде и никогда. Работа над продуктом это постоянный процесс поиска, анализа и совершенствования, который никогда не должно прекращаться.
"Есть ли какой-то алгоритм создания продукта и где работа над продуктом заканчивается?"
Поделюсь своими мыслями на этот счет в виде пошагового чек-листа по превращению идеи в осязаемый продукт.
Шаг №1 Идея. Собираемся с мыслями, упорядочиваем их, выделяем ключевую проблему, которую решает будущий продукт, определяем его целевую аудиторию, думаем над всеми возможными путями решения проблемы. Все выписываем на листочек (бумага рулит).
Важно - на этом этапе ни за кем из конкурентов пока не подглядываем. Дайте вашему мозгу свободно и без примеров подумать над решением проблемы - возможно, благодаря этому он придумает то, до чего еще никто не додумался.
Шаг №2 Оценка возможностей и перспектив идеи. Думаем, к̶у̶д̶а̶ ̶п̶р̶и̶в̶о̶д̶я̶т̶ ̶м̶е̶ч̶т̶ы̶ над потенциалом будущего продукта и его возможном применение на другие проблемы/отрасли или направления рынка, т.е. оцениваем его возможную масштабируемость.
Шаг №3 Анализ рынка. И только щас внимательно изучаем рынок, его особенности и то, как он работает.
В обязательном порядке и не меньше месяца читаем о нем кучу материалов/статей/интервью - вам нужно понять и разобраться как уже работает отрасль, в которую вы хотите залезть со своим продуктом и как ваш продукт может быть для нее полезен.
Одновременно с этим, собираем инфу по лидерам и основным игрокам, читаем и собираем фидбек от их пользователей по ним, трясем вопросами самих конкурентов под видом их пользователей и хитрыми путями узнаем как работает их внутренняя "кухня". Попутно аккумулируем всю инфу и ищем их сильные и слабые места и примеряем все на свой будущий продукт.
Шаг №4. Оцениваем затраты на запуск MVP. Чикаем из минималки всё ненужное, оставляем только ключевую идею и решение ключевой проблемы (пост об этом: https://yangx.top/ruspm/21).
Прикидываем, во сколько сил, рук, денег и времени нам обойдется запуск MVP и плюсуем к получившимся цифрам еще 30% для подстраховки.
Реклама. Без нее никуда и деньги на нее должны быть. Времена свободных ниш и "Запилил - выстрелило" давно прошли. Не тешьте себя иллюзиями. Сколько денег нужно? Чем больше, тем лучше. Но хотя бы тыщ 150 - 300.
Шаг №5. Принятие решения о запуске MVP. Теперь у вас перед глазами есть вся информация, которая поможет вам принять взвешенное решение. Трезво оцениваем свои силы, средства и знания и принимаем его.
Шаг №6 Разработка MVP. Пилим MVP :) Пока команда разработки (или программист) делает это, начинаем готовить и планировать маркетинговые активности под MVP. Это отдельная тема, возможно, когда-нибудь я напишу об этом пост.
Шаг №7 Маркетинговое тестирование MVP. Ура - продукт в MVP запилен и настало время проверить, действительно ли он востребован теми, для кого создавался.
Включаем маркетинг, льем неспеша трафик, воронка продаж, все дела. Смотрим как всё работает, тестируем продукт самостоятельно и через пользователей и, самое главное - собираем от них фидбек.
Шаг №8 Оценка результатов и принятие решения. После 3-6 месяцев такого маркетинга и непосредственной работы пользователей с продуктом становится понятно, есть ли смысл развивать MVP дальше в полноценный продукт, наращивая на него фичи и вливая еще больше денег в маркетинг.
Важный момент - на этом этапе и в этот срок мы лишь проверяем нашу идею, а не выводим продукт на окупаемость. На основании чего принимать решение? Сложный вопрос. Играет роль и обратная связь от юзеров и общая тональность отзывов и цифры статистики по рекламе и конверсиям.
Решений бывает два:
а) Убедиться в состоятельности идеи/продукта, двигаться и развиваться дальше, расширяя функционал и наращивая базу пользователей.
б) либо признаться в несостоятельности идеи и закрыть проект минусами. Ничего страшного в этом нет - гораздо страшнее развивать "мертворожденный продукт" и спустя N лет его также закрыть, но с еще большими минусами.
Отвечая на вопрос: "Где работа над продуктом заканчивается?"
Нигде и никогда. Работа над продуктом это постоянный процесс поиска, анализа и совершенствования, который никогда не должно прекращаться.
В этом посте хотел бы поговорить об одной из самых важных вещей для любого продукта - его дизайне.
Говоря о дизайне для продуктов, имеются ввиду эти вещи:
1) UX (user experience) — опыт взаимодействия, возникающий в результате использования продукта пользователем.
2) UI (user interface) — разновидность интерфейсов, в котором одна сторона представлена человеком (пользователем), другая — устройством/сайтом.
Как вы видите, эти две вещи являются вытекающими и дополняющими друг из друга и именно на них строится дизайн любого продукта.
Для этого и придумали отдельную должность в виде UX/UI-дизайнера (не путать с веб-дизайнером, который просто рисует картинки как считает нужным).
Возвращаемся к теме поста. Я считаю, что невозможно купить эффективно работающий дизайн продукта в веб-студии или у Самого Охуенного Дизайнера, хотя бы потому, что... эти люди не работают в вашей команде, они не сидят с вами чате в Слаке, они не читают сообщения в сапорт.
И если они не работают с вашим продуктом и его пользователями - откуда им знать, как ваш продукт должен эффективно работать?
Кто тогда должен рисовать дизайн для продукта? Кто, как не человек, который способен осмыслить пользовательские потребности и выразить их в виде визуального решения!
Мое личное мнение, что в идеале это тот, кто плотнее всех работает со всем направлениями жизни и деятельности продукт - продукт-менеджер.
Рисуя интерфейс самостоятельно, вы не только сможете лучше разобраться в пользователях и продукте, глядя на них "со стороны", но и продумать что можно улучшить или расширить в самом продукте (ведь дизайн это в первую очередь, решение задач, а не украшательства).
Для этих целей можно использовать программы, позволяющие набрасывать простейшие прототипы будущего дизайна, чтобы потом передать их веб-дизайнерам, которые на их базе нарисуют вам полноценный дизайн в цвете.
Для этого отлично подойдет figma.
Т.е. схема выглядит как: PM собирает фидбек и определяет фичи -> рисует простые прототипы под них -> отдает их дизайнеру на фин. отрисовку.
Благодаря этой схеме, на выходе мы получаем продуманный с точки зрения UX интерфейс и красиво отрисованный дизайн, а не фантазии дизайнера на тему его видения и восприятия реальности.
Помните, что хороший дизайн это не красивая обертка - это быстрое решение проблем и задач пользователей.
Говоря о дизайне для продуктов, имеются ввиду эти вещи:
1) UX (user experience) — опыт взаимодействия, возникающий в результате использования продукта пользователем.
2) UI (user interface) — разновидность интерфейсов, в котором одна сторона представлена человеком (пользователем), другая — устройством/сайтом.
Как вы видите, эти две вещи являются вытекающими и дополняющими друг из друга и именно на них строится дизайн любого продукта.
Для этого и придумали отдельную должность в виде UX/UI-дизайнера (не путать с веб-дизайнером, который просто рисует картинки как считает нужным).
Возвращаемся к теме поста. Я считаю, что невозможно купить эффективно работающий дизайн продукта в веб-студии или у Самого Охуенного Дизайнера, хотя бы потому, что... эти люди не работают в вашей команде, они не сидят с вами чате в Слаке, они не читают сообщения в сапорт.
И если они не работают с вашим продуктом и его пользователями - откуда им знать, как ваш продукт должен эффективно работать?
Кто тогда должен рисовать дизайн для продукта? Кто, как не человек, который способен осмыслить пользовательские потребности и выразить их в виде визуального решения!
Мое личное мнение, что в идеале это тот, кто плотнее всех работает со всем направлениями жизни и деятельности продукт - продукт-менеджер.
Рисуя интерфейс самостоятельно, вы не только сможете лучше разобраться в пользователях и продукте, глядя на них "со стороны", но и продумать что можно улучшить или расширить в самом продукте (ведь дизайн это в первую очередь, решение задач, а не украшательства).
Для этих целей можно использовать программы, позволяющие набрасывать простейшие прототипы будущего дизайна, чтобы потом передать их веб-дизайнерам, которые на их базе нарисуют вам полноценный дизайн в цвете.
Для этого отлично подойдет figma.
Т.е. схема выглядит как: PM собирает фидбек и определяет фичи -> рисует простые прототипы под них -> отдает их дизайнеру на фин. отрисовку.
Благодаря этой схеме, на выходе мы получаем продуманный с точки зрения UX интерфейс и красиво отрисованный дизайн, а не фантазии дизайнера на тему его видения и восприятия реальности.
Помните, что хороший дизайн это не красивая обертка - это быстрое решение проблем и задач пользователей.
#основы Как правильно определять новые фичи для продукта
Решил поделиться мыслями на счет того, каким образом лучше всего принимать решения о запуске новых функций в продуктах.
Итак, важно понимать, что в основе любой новой фичи всегда должны лежать две цели, которые влияют на продукт и которые являются основными для его развития:
1) лояльность и(или) активность пользователей
2) деньги пользователей
Эти цели плотно взаимосвязаны между собой - чем более удовлетворены ваши пользователи, тем вам легче продать им продукт или услугу и заработать денег.
Решения принимаются исходя из ваших текущих целей и KPI проекта.
Для разных стадий они разные: кто-то еще только наращивает пользовательскую базу, кто-то уже начинает монетизацию проекта, кто-то растет по прибыли и готовится к ежегодному отчету перед советом директоров.
Для каждого этапа свои цели, поэтому, для понимания того, соответствует ли фича текущим целям проекта, отвечаем на следующие вопросы:
1) Новая фича увеличит лояльность/активность текущих пользователей?
2) Новая фича увеличит средний чек от текущих пользователей?
3) Новая фича принесет новых пользователей?
Ответы на эти три вопроса дадут вам понимание насколько новая фича поможет в достижении поставленных перед вами и продуктом целях.
Хорошего дня 😎
Решил поделиться мыслями на счет того, каким образом лучше всего принимать решения о запуске новых функций в продуктах.
Итак, важно понимать, что в основе любой новой фичи всегда должны лежать две цели, которые влияют на продукт и которые являются основными для его развития:
1) лояльность и(или) активность пользователей
2) деньги пользователей
Эти цели плотно взаимосвязаны между собой - чем более удовлетворены ваши пользователи, тем вам легче продать им продукт или услугу и заработать денег.
Решения принимаются исходя из ваших текущих целей и KPI проекта.
Для разных стадий они разные: кто-то еще только наращивает пользовательскую базу, кто-то уже начинает монетизацию проекта, кто-то растет по прибыли и готовится к ежегодному отчету перед советом директоров.
Для каждого этапа свои цели, поэтому, для понимания того, соответствует ли фича текущим целям проекта, отвечаем на следующие вопросы:
1) Новая фича увеличит лояльность/активность текущих пользователей?
2) Новая фича увеличит средний чек от текущих пользователей?
3) Новая фича принесет новых пользователей?
Ответы на эти три вопроса дадут вам понимание насколько новая фича поможет в достижении поставленных перед вами и продуктом целях.
Хорошего дня 😎
Не могу пройти мимо сегодняшней новости об IPO Snapchat
К началу торгов торгов стоимость акций Snap выросла на 44% — изначальная цена была установлена на уровне $17 за штуку и к выходу на биржу она увеличилась до $24.
По итогам первого дня торгов состояние каждого из основателей Snapchat выросло на $1,6 млрд., pа счёт чего они поднялись более чем на 150 строк в рейтинге 500 самых богатых людей мира по версии Bloomberg, заняв 280 и 281 место.
Уходя от вопроса денег и зависти к вопросу продукта и пользователей.
Целевой аудиторией и пользовательским ядром Snapchat являются "миллениалы" (поколение родившихся после 1981 года, характеризующееся глубокой вовлечённостью в цифровые технологии), которые... могут утратить интерес к модному приложению также быстро и легко, как он у них появился.
Воистину - и дар и проклятье 😈
К началу торгов торгов стоимость акций Snap выросла на 44% — изначальная цена была установлена на уровне $17 за штуку и к выходу на биржу она увеличилась до $24.
По итогам первого дня торгов состояние каждого из основателей Snapchat выросло на $1,6 млрд., pа счёт чего они поднялись более чем на 150 строк в рейтинге 500 самых богатых людей мира по версии Bloomberg, заняв 280 и 281 место.
Уходя от вопроса денег и зависти к вопросу продукта и пользователей.
Целевой аудиторией и пользовательским ядром Snapchat являются "миллениалы" (поколение родившихся после 1981 года, характеризующееся глубокой вовлечённостью в цифровые технологии), которые... могут утратить интерес к модному приложению также быстро и легко, как он у них появился.
Воистину - и дар и проклятье 😈
Пятничная подборка статей для чтения на выходных
Огромный объем ценнейших знаний, который я сам сейчас с упоением поглощаю. Учебные материалы и пособия по курсу product management от Harvard Business School - https://sites.google.com/site/hbspm101/home/2015-16-sessions/.
-----------------------------
Психология ценообразования: 30 тактик по формированию цены продукта - https://vc.ru/p/price-psychology. Просто must read и в закладки
-----------------------------
Как пользовательские исследователи могут взаимодействовать с менеджерами продуктов так, чтобы добиваться максимальной пользы для продукта - https://goo.gl/0SPByD. Статья на английском от нашей соотечественницы Алены Лугиной (UX Research в Spotify)
-----------------------------
Как создавать UX-дизайн с учетом психологии пользователей - https://goo.gl/M3XKzF. О чем я часто говорю - дизайн должен помогать в решении задач пользователей, а не просто быть красивым.
-----------------------------
59 способов монетизации мобильных игр - https://goo.gl/Dq9hPr. Отличная статья для понимания того, на каких пользовательских слабостях и механиках можно зарабатывать (не только в играх).
-----------------------------
Каналы, которые рекомендую к чтению:
Канал Аркадия Морейниса (инвестор) - https://yangx.top/temno
Канал Михаила Калашникова (Tribuna Digital & Sports.ru)- https://yangx.top/mediaskunk
Всем хороших выходных 😎
Огромный объем ценнейших знаний, который я сам сейчас с упоением поглощаю. Учебные материалы и пособия по курсу product management от Harvard Business School - https://sites.google.com/site/hbspm101/home/2015-16-sessions/.
-----------------------------
Психология ценообразования: 30 тактик по формированию цены продукта - https://vc.ru/p/price-psychology. Просто must read и в закладки
-----------------------------
Как пользовательские исследователи могут взаимодействовать с менеджерами продуктов так, чтобы добиваться максимальной пользы для продукта - https://goo.gl/0SPByD. Статья на английском от нашей соотечественницы Алены Лугиной (UX Research в Spotify)
-----------------------------
Как создавать UX-дизайн с учетом психологии пользователей - https://goo.gl/M3XKzF. О чем я часто говорю - дизайн должен помогать в решении задач пользователей, а не просто быть красивым.
-----------------------------
59 способов монетизации мобильных игр - https://goo.gl/Dq9hPr. Отличная статья для понимания того, на каких пользовательских слабостях и механиках можно зарабатывать (не только в играх).
-----------------------------
Каналы, которые рекомендую к чтению:
Канал Аркадия Морейниса (инвестор) - https://yangx.top/temno
Канал Михаила Калашникова (Tribuna Digital & Sports.ru)- https://yangx.top/mediaskunk
Всем хороших выходных 😎
"Разработать с учётом _____"
Фраза, которую должен использовать каждый продукт-менеджер в постановке задач для тимлида или команды разработки на новые фичи в продукте.
Работает она просто - если вы ставите задачу на разработку новой фичи и вы, как PM, понимаете, что она по механике связана с другими будущими фичами в продукте, не поленитесь лишний раз обратить внимание ребят из разработки на это.
Тем самым вы снизите вероятность того, что они запилят что-то новое, которое будет плохо работать или будет сложносовместимо с будущими разработками по пересекающимся функциям.
Объясню на примере. Ваш продукт дает пользователям доступ к базе данных какой-либо информации. Доступ к этой базе пользователь получает после выполнения определенного вами действия внутри продукта (лида).
Пользователи жалуются, что у них нет возможности "пощупать" базу перед тем, как выполнять это действие и они не хотят быть "лидами" до этого момента.
Вы, как "добренький PM", решили пойти им навстречу и дать ограниченный доступ к первым 10 объектам из этой БД, чтобы пользователи могли посмотреть примеры вашей базы. Само собой, это надо пилить, а значит, надо формуировать задачу команде разработки.
Но вы знаете, что через НН недель в разработку уйдет уже другой спринт с платной подпиской на доступ к этой самой базе данных без выполнения пользователем действий внутри продукта.
Именно поэтому при постановке задачи на ограниченный доступ к первым 10 объектам было бы не лишним написать и обозначить разработчикам, что эту фичу нужно "Разработать с учетом" того, что через НН недель будет еще одна фича, которая по механике и коду будет затрагивать эту же область.
Зачем это делать? Вам повезло, если вы работаете с разработчиками, которые смотрят наперед и умеют кодить не только шаг за шагом, но и с расчетом на будущее.
Если вам не повезло, то в обязательном порядке нужно обозначать, в каком формате будет работать та или иная функция и какие ее могут ждать изменения в будущем. Иначе костыли и велосипеды станут средствами передвижения для вашей команды и продукта.
И да, человечество еще не придумало как другие люди могут читать ваши мысли, поэтому не стесняйтесь рассказывать и делиться вашими планами на продукт и его функционал с тем, кто его пилит.
Всем хорошего дня! 😎
Фраза, которую должен использовать каждый продукт-менеджер в постановке задач для тимлида или команды разработки на новые фичи в продукте.
Работает она просто - если вы ставите задачу на разработку новой фичи и вы, как PM, понимаете, что она по механике связана с другими будущими фичами в продукте, не поленитесь лишний раз обратить внимание ребят из разработки на это.
Тем самым вы снизите вероятность того, что они запилят что-то новое, которое будет плохо работать или будет сложносовместимо с будущими разработками по пересекающимся функциям.
Объясню на примере. Ваш продукт дает пользователям доступ к базе данных какой-либо информации. Доступ к этой базе пользователь получает после выполнения определенного вами действия внутри продукта (лида).
Пользователи жалуются, что у них нет возможности "пощупать" базу перед тем, как выполнять это действие и они не хотят быть "лидами" до этого момента.
Вы, как "добренький PM", решили пойти им навстречу и дать ограниченный доступ к первым 10 объектам из этой БД, чтобы пользователи могли посмотреть примеры вашей базы. Само собой, это надо пилить, а значит, надо формуировать задачу команде разработки.
Но вы знаете, что через НН недель в разработку уйдет уже другой спринт с платной подпиской на доступ к этой самой базе данных без выполнения пользователем действий внутри продукта.
Именно поэтому при постановке задачи на ограниченный доступ к первым 10 объектам было бы не лишним написать и обозначить разработчикам, что эту фичу нужно "Разработать с учетом" того, что через НН недель будет еще одна фича, которая по механике и коду будет затрагивать эту же область.
Зачем это делать? Вам повезло, если вы работаете с разработчиками, которые смотрят наперед и умеют кодить не только шаг за шагом, но и с расчетом на будущее.
Если вам не повезло, то в обязательном порядке нужно обозначать, в каком формате будет работать та или иная функция и какие ее могут ждать изменения в будущем. Иначе костыли и велосипеды станут средствами передвижения для вашей команды и продукта.
И да, человечество еще не придумало как другие люди могут читать ваши мысли, поэтому не стесняйтесь рассказывать и делиться вашими планами на продукт и его функционал с тем, кто его пилит.
Всем хорошего дня! 😎