Продакт-менеджмент: Пособие для продакт-менеджеров

• Автор: Миролюбов Владимир, EXP.fm.
• Исключительные права: Миролюбов Владимир.
• Обновлено: 30.11.2020
• Тип лицензии: CC BY 4.0 (ссылка на эту страницу как источник).

Содержание пособия:

1. Введение в продакт-менеджмент
2. Идея продукта
3. Продукт и пользователи
4. Как запускать продукты
5. Команда продукта
6. Продвижение продукта
7. Рост продукта
8. Юнит-экономика продуктов
9. Советы по продакт-менеджменту

Я начинал первое издание этой книги с вопроса "что такое product-management, кто такой продакт-менеджер и чем он должен заниматься"? С момента ее издания прошло почти 3 года, за которые отрасль, механики, инструменты, и, надеюсь, я сам, шагнули далеко вперед, а значит есть необходимость заново изучить и проанализировать весь накопленный опыт и знания под призмой нового времени.

Данное руководство представлено в виде переработанного и расширенного издания предыдущего краткого руководства. Каждая глава расширена примерно в три раза, добавлено много схем, инструкций, а главное – в издание интегрированы ссылки на наиболее качественные образовательные статьи со всего интернета (отдельное спасибо команде Единорога).

Приятного чтения!

Введение в продакт-менеджмент

Всем привет! Как вы знаете, этой фразой я приветствую людей, с которыми хочу начать или поддерживать хорошие отношения — казалось бы, всего два слова, но именно они задают правильный тон предстоящему общению, раскрепощают и объединяют участников диалога. И я благодарен вам за проявленный к этой книге и её тематике интерес.

О чем эта книга?

Данная книга является промежуточным результатом моего личного опыта работы в качестве продакт-менеджера, маркетолога, веб-дизайнера, руководителя, а также собственника ряда интернет-проектов, наиболее известные среди которых: Meteoagent,  EPICSTARS, Exp.fm, E-pepper.ru. На самом деле, проектов больше и однажды мне даже пришлось посчитать их для презентации на вводной лекции в ВШЭ.

Не подумайте, что моя цель похвастаться количеством, наоборот – как показало время, часть из этих продуктов были изначально запущены мертворожденными, а большая часть из этих проектов вообще давно канули в лету.

Почему я не понял этого сразу... Мне не хватало тех самых знаний опыта, которые у меня есть сейчас и благодаря которым я могу дать оценку самому себе и своим действиям десять лет назад.

Но предлагаю не забегать так сильно назад (или вперед?) и поговорим об этом подробнее где-нибудь в середине книге.

Построенное на основе реального опыта, а также опыта российский и международных продуктовых команд, это пособие последовательно расскажет вам о том, как правильно подходить к разработке, запуску и постепенному развитию онлайн-продуктов.

Вы узнаете о том, как и где искать, формировать, развивать под них команду и работать с ней над продуктом, выступая в роли продакт-менеджера, который хочет эффективно развивать свой продукт и дойти по карьерной лестнице до  позиции СЕО.

Про СЕО я специально уточнил этот важный момент, который очень редко объясняют на курсах продактов и чему еще реже обучают на вебинарах.

Как в поговорке про плохого солдата, не мечтающего стать генералом – плох тот продакт-менеджер, который не мечтает стать СЕО, поэтому, в данном руководстве будут также затронуты процессы, не свойственные классическим процессам продактов: рекрутинг, проект-менеджмент, маркетинг, дизайн и даже немного про операционную деятельность – как раз всё то, что должен понимать среднестатистический СЕО и к чему должен идти любой продакт-менеджер.

На страницах руководства также собраны наиболее распространенные ошибки, которые могут возникать на всем пути жизни практически любого продукта и даны наиболее оптимальные варианты их решения для тех случаев, когда они все же были совершены.

Работая над ее первым изданием, мне показалось правильным начать ее с самых азов, постепенно и по нарастающей переходя к более сложным вещам. Сейчас это переработанное издание и сама структура книги останется неизменной. Расширится лишь содержание каждой из глав.

Эта книга будет полезна для прочтения как начинающим продуктовым менеджерам, так и работающим не один год senior product manager и даже некоторым свежеиспеченным СЕО у "которых нет конкурентов".

Что такое продукт?

Как вы видите, во главе всего стоит продукт. Под продуктом подразумевается любой онлайн-сервис, сайт, мобильное приложение – любое из них при условии наличия решаемой проблемы и доступности в онлайне обычным пользователям могут считаться продуктами.

Пару лет назад в одном из тредов в Твиттере подняли вопрос визуализации продукта в голове продакта. Мне понравился образ конструктор типа Лего. Это идеальный пример декомпозиции чего-то цельного на кучки мелких задач/этапов/проблем и их решений, которые собираются в один продукт и которые местами заменяемы/можно выкинуть/добавить новое или превратить вообще в нечто отличное от начального.

Именно поэтому, в основе данной книги лежит несколько базовых принципов, которых я придерживаюсь в своей работе и, наверное, должен придерживаться каждый продукт-менеджер. Самый главный из них звучит до боли просто:

Любые продукты делаются для решения проблем людей,

а зарабатывание денег и бизнес является логичной производной этого процесса, располагающейся на втором месте.

Не знаю, но почему-то многие продукт-менеджеры и их команды забывают об этом и начинают созидать и строить проекты, которые решают проблемы, которые они сами же и придумали, из-за чего получаются мало кому нужные сервисы, способные жить только на иссякающий в конечном счете поток денег инвесторов. Если вам от людей нужны только деньги, то целесообразнее посвятить свой путь карьере СРА-арбитражника, нежели пытаться вытянуть и заработать их через какие-либо онлайн-продукты.

В тоже время, главный вопрос, стоящий практически перед каждый онлайн-продуктом - что первичнее - большая база юзеров или прибыль? Я сейчас не говорю про компании типа Uber, в которых совершенно другая бизнес-логика, а про обычные стартапы, в которых работаем или участвуем мы с вами.

Мое мнение такое. Если фамилии ваших СЕО не Безос, Кук, Цукерберг или Пичай, то всё, о чем вы должны думать после привлечения и возврата юзеров - доходы. Оставьте в 2000-ых все эти сказки про "Сейчас наберем базу, а потом как МОНЕТИЗИРУЕМСЯ!". Это не работает ни у кого и уж точно не сработает у вас.

При таком подходе всегда есть большие риски:

а) потребность и необходимость в решениях вашего продукта может не вытянут готовность платить за них со стороны пользователей. Не начав монетизировать продукт с самого начала вы узнаете об этом только спустя __ лет, когда захотите это попробовать. И выяснится, что продукт, над которым вы работали все эти года просто нежизнеспособен в реалиях продуктовой экономики.

б) психологический фактор со стороны пользователи, когда им покажется, что все это время их использовали, а теперь решили заработать на них ("раньше было бесплатно, почему стало за деньги?")

Собственно, единственный вопрос, которым правильно задаваться с самого начала - почему мы не можем попросить платить деньги с самого начала? Если ваши ответы на этот вопрос кажутся вам размытыми, то просите. Хотите посчитать востребованность продукта - пользователь всегда голосует рублем (или долларом).

P.S. Любой продакт это на 50% продакт и на 50% предприниматель. И если вы не хотите, чтобы овнеры/инвесторы принуждали вас зарабатывать деньги, лучше пытаться начать это делать самостоятельно (и чем раньше, тем лучше).

Второй принцип, которому я призываю следовать своих коллег и знакомых – обязательное принятие того, что продукт, над которым вы работаете, является производной вас как продакт-менеджера и команды, которая его делает, ее ценностей и убеждений, а вы и ваша команда является неотъемлемой частью этого продукта.

Как бы это не звучало, но нет ничего хуже продукта и команды без общей цели, ценностей, убеждений. Так же как и с друзьями и близкими, тот самый огонь в глазах появляется только там, где люди искренне объединены общим взглядом и мировоззрением на какие-то вещи. Сплотившись, такая команда легче всего проходит испытания, выпадающие на участь любого бизнес-проекта, в котором участвует более одного человека. Поделюсь с вами интересным фактом на эту тему.

---

В далеком 1965 Брюс Тукман (Bruce Tuckman) проводил исследования в области теории групповой динамики и как итог - представил универсальную модель этапов развития любой команды или группы.

Согласно её, вначале команда формируется ради достижения общей цели, потом переживает шторминг (притирка, разногласия, конфликты), далее комнада и отношения нормализуются (растут чувства друг-друга внутри команды и формируются общие командные соглашения) и только потом команда начинает перформить и создавать. Применимо к любой команде/группе людей с общими целями.

---

В основе моего видения лежит рассмотрение всех этих этих вещей как нечто единого и целого, а продукт-менеджера как объекта, находящегося над ними. В первой версии книги было написано другое. Я говорил о том, что продакт должен находиться в центре всех процессов возглавлять их. Спустя почти 3 года с того момента мое мнение поменялось – отстранение, фокусировка и усердие, вот что не дает продакту утонуть в информационных потоках, которые окружают его и в которые он вовлечен в продукте.

Давайте вначале разберемся, что же такое product management. Wikipedia дает нам очень правильную и четкую формулировку этого слова.

Управление продуктом (продакт-менеджмент, продакт-менеджмент от англ. product management) — организационная функция, занимающаяся планированием или маркетингом продукта на всех стадиях его жизненного цикла.

Звучит криво. Перефразируем.

Управление продуктом (продукт-менеджмент, продакт-менеджмент от англ. product management) — непрерывный внутренний процесс в работе бизнеса, отвечающий за развитие и продвижение производимого этим бизнесом продукта или услуги.

Под управлением продуктом много вещей: менеджер, его команда, сам продукт и действия, которые происходят вместе с ними. Другими словами – продакт-менеджмент это постоянный процесс совершенствования всех направлений продукта и его работы. Именно это и отличает продакт-менеджера от проект-менеджера, с которым его часто путают - первый работает над продуктом как над чем-то общим и цельным, охватывая все процессы. Второй работает над узким направлением деятельности большого продукта, возглавляя и контролирую определенные процессы в виде технической разработки.

Соответствено, хороший продакт похож на футбольного тренера: он должен видеть, анализировать и выявлять таланты каждого члена команды и направлять всю команду и продукт к общей цели

За что отвечает продакт-менеджер в управлении продуктом?

Продакт отвечает за реализацию стратегии продукта. То есть за конечный продукт. Помни каждый день, что ты – тот единственный, кто всегда отвечает за всё. Хочешь отвечать за всё? Бери за всё ответственность!

Вот небольшой набор мои личных правил:

Не бойся брать ответственность. Кто-то же должен её брать, но в России никто не любит этого. Пусть это будешь ты. Это значит, что успех/провал продукта будет результатом ТВОЕЙ деятельности. Успешный продакт-менеджер в США это идеальная взлетная полоса для СЕО и радует, что  некоторые российские компании уже начинают это понимать.

Держи в голове то, что пока ты работаешь с продуктом, этот продукт — твой. Раз ты ответственный, то только ты (и немного инвесторы/СЕО) могут говорить тебе, куда смотреть. Конечное решение за продукт (любое) — за тобой. Всё просто — замкни схему принятия решений на себя и далее получай удовольствие от процессов. В противном случае, не бери полномочия и ответственность за это всё 🙂

Не позволяй навязывать чужие идеи и мысли (только если тебе об этом не сказали платящие пользователи или ты сам их не позаимстовал их у кого-то). В 90% случаев эти идеи оторваны от реальности и являются субъективным мнением нецелевой аудитории, которая просто решила поделиться своим "скромным и бесполезным мнением”.

Отдавай своему продукту всю душу, всё сознание, всю энергию и только потом всё своё время. Важно не перепутать последовательность.

Юзеры и их проблемы по-прежнему наше всё. Эпоха "мы точно знаем что изобретаем" прошла — рынком рулят решения вполне конкретных проблем, а не новые способы покормить кошку или социальная сеть (на этот случай держи всегда в голове понимание, что самая широкая сеть с максимально возможным DAU в мире - канализационная).

Пиши сторис так, как будто это твое прощальное завещание. Помни, что цельный план только в твоей голове. Команда, которая будет помогать реализовывать его, не умеет читать твои мысли и не видит всей картины. Причина и следствие, мистер Андерсон. Важно не просто умело писать сторис, но и рассказывать истинные причины и следствия принимаемых продактом решений. Команда должна знать, ПОЧЕМУ ты решил сделать именно это.

Помни, что встав на путь продакт-менеджера, ты лишь в начале пути. Твой опыт, знания, умения, могут быть применимы на любой должности — от разработчика до овнера собственного продукта. Каждым своим решением, фичей и продуктом ты должен совершенствовать себя, свой кругозор, свои знания и свой продукт. Успех только в этом, а не в везении.

Федор Овчинников, СЕО в Додо Пицце однажды сказал правильную фразу:

“Вот три главных вопроса для управления компанией на всех уровнях: 1) зачем мы существуем? 2) куда мы сейчас идем? 3) как мы поймем, что мы туда пришли?" Это миссия, цель и ключевые результаты. Для компании в целом, для каждой команды и каждого продукта. Всё. Всё остальное - гибко…”.

 

И если вы встали на путь менеджера продуктов, то вашей главной обязанностью станет именно непосредственное участие во множестве процессов, связанных с продуктом и его пользователями: планирование, разработка, дизайн, маркетинг, операционные вопросы и многое многое другое. Ваш ждут ошибки и баги сайта, кричащие от ужаса пользователи, неотвеченные письма, сорванные спринты и т.п. вещи. Эй, это была шутка! ))

Несмотря на то, что все озвученные выше моменты присущи процессу продакт-менеджмента, на самом деле, процесс управления продуктами весьма увлекателен и чрезвычайно занимателен: вы сможете общаться со множеством людей, с которыми искать, находить, придумывать и воплощать в реальность интересные идеи, которые могут приносить пользу другим людям.

Вы готовы к этому? Добро пожаловать в мир управления продуктами!

Идея продукта

Любой продукт, вне зависимости от своего предназначения и аудитории, становится таковым только из идеи, которая лежит в его основе, и превращается в продукт только тогда, когда находит своё техническое и бизнес-воплощение.

Именно поэтому мне не нравится фраза “идеи ничего не стоят” и больше по душе “идеи бесценны”. Это звучит более драйвово и заряжает истинным духом нематериальных ценностей, которые нужно сделать материальными. И раз так, то главная задача продукт-менеджера  — превращать нематериальные идеи в осязаемые вещи. Чем-то похоже на волшебство и, наверное, таковым и является, не правда ли?

Если сравнивать продукт с живым организмом (а именно таким объектом он и должен являться), то как и все живое в этом мире, продукт не появляется ниоткуда на пустом месте, а  его появлению на свет предшествует период зародыша (планирования), созревания (разработки), рождения (запуска MVP), младенчества (первые beta-версии), юности (стадия роста) и взрослой жизни (монетизация и генерация прибыли).

И как бы это не звучало печально, но вполне свойственные всему живому процессы связаны и со смертью - многие проекты умирают, причем на совершенно разных стадиях своей жизни. В этой книге я предлагаю пройти каждый из этапов и внимательно рассмотреть их особенности. Не будем терять времени и начнем!

Говоря о рождении и запуске продукта, я, конечно же, говорю о периоде подготовки и разработки.  Перед началом любой работы вам, как продукт-менеджеру будущего продукта, необходимо собрать всю информацию о группе людей, проблемы которых вы хотите решать с его помощью, а также указание этих самых проблем именно со стороны людей. Если вы умеете выхватывать детали, то обратили внимание, то я умышленно написал здесь ЛЮДИ, а не пользователи .

Для более четкого понимания проблемы необходимо постараться увидеть её глазами простого человека, а не пользователя какого-то будущего сайта или приложения

Более того, вторым важным словом является слово "проблема". Именно проблему должен решать продукт и именно она является самой первой и подлинной причиной рождения любого продукта. Возьмите любой, абсолютно любой известный вам продукт и вы поймете, что с помощью его решается конкретная проблема или потребность человека.

Любая идея это следствие решения конкретной проблемы человека/пользователя

Просто запомните этот порядок: “Проблема -> Идея -> Продукт”. Но несмотря на это, я знаю достаточно проектов, которые совершенно забыли об этом и начали свою жизнь прямиком с продукта. Многие из них закрылись после своего непродолжительного существования, некоторые еще живут, но лишь небольшая часть поняла эту простую истину, вернулась к истокам, смогла поменяться и теперь процветают.

Если задуматься, нам, как продактам, совершенно неважно кто есть наши потребители. Все эти портреты, ЦА, образы, герои. Всё это вытекает из другого. Важно то, ДЛЯ ЧЕГО все эти люди используют наши продукты.

Достаточно понять, чего хочет потребитель (или для решения какой своей проблемы он пользуется продуктом) и его портрет нарисуется сам собой.

Простые вещи лежат на поверхности, но их никто не хочет замечать и понимать. Просто ответьте для себя на следующие вопросы : "Что это за проблема? "Кто эти люди? Чем они занимаются? В чем их отличие от других людей? Как они приходят к этой проблеме и что прямо сейчас делают для её решения?"

Самая простая формула определения того, какие проблемы вы и ваш продукт решаете звучит.. именно так.

Люди пользуются вашим продуктом, чтобы ___________. Другими вариантами использования вашего продукта являются ________ и _________, но вашим продуктом, в первую очередь, всегда будут пользоваться для ________, потому что он ________ по сравнению с текущим решением проблемы.

Многие любят отталкиваться от целевой аудитории пользователей. Это правильный формат работы для маркетинга, но не для продакт-менеджера. Мы, в первую очередь, решаем проблемы людей, а не копаемся в том, кем они являются и какое у них хобби.

Не торопитесь быстрее запустить продукт и проверять первую же мысль, которая когда-то пришла в голову  руководителю проекта или бизнеса, который поставил вас на запуск —  в 99% случаев вашу идею никто не украдёт даже если такое ещё никто не придумал. Гораздо быстрее можно поверить в то, что такое уже когда-то придумали, но оно закрылось или было/есть непопулярно именно по причине спешки и невнимательности тех, кто подумал ровно также при начальной подготовке и разработке концепции будущего продукта.

Хотелось бы остановиться подробно на том, насколько важно продукт-менеджеру думать внимательно и рассудительно, ведь именно от того, КАК вы воспринимаете и работаете с информацией зависит то, как эффективно вы ее используете в своей работе.

Главная задача продукт-менеджера —  обрабатывать всю информацию о продукте и на основании нее строить дальнейшие решения.

Полезный пример с разбором аналитики продукта и его пользователей: "Product Benchmarks Report от MixPanel"

Приучите себя правильно работать с информацией, фильтровать её, конспектировать и сохранять наиболее важные и кажущиеся вам значимыми и интересным вещи, мысли и идеи. Сделайте Google Keep вашим постоянным помощником и хранилищем всех ваших идей, мыслей и заметок. И если вы только встаете на путь продуктового менеджера, то не надейтесь на записные книжки и выбросите их в помойное ведро - ежедневно вам придется работать с гигабайтами информации, связанной с различными вещами в интернете, а ваш мозг должен будет успевать их быстро обрабатывать.

Возвращаемся в реальность. Вы ответили на вопросы выше? А теперь подумайте, как эту может улучшить или упростить ваша "гениальная идея". Не просто “ааа, да через интернет это легче”, а именно какой конкретно этап и за счёт чего в разрезе тех людей, которых вы определили в качестве целевой аудитории, будет упрощен вашей идеей.

Человеческая психология весьма сложная штука, поэтому дополнительным усложняющим вопросом будет: "Вы уверены, что данная идея реально упростит решение проблемы настолько, что люди поменяют свои привычки и будут использовать именно её?". Имея ответы на эти вопросы мы можем прикинуть не только положительные, но и отрицательные стороны ваших улучшений и снова наложить их на текущую целевую аудиторию людей, которым вы хотите помочь.

Если все встаёт ровно и без сильных нестыковок, то только сейчас вы можете называть этих людей вашими будущими пользователями, а усовершенствованный способ решения их проблем (идею) будущим продуктом.

Продолжаем. Как и любой процесс, разработка и запуск состоит из этапа планирования, который в обязательном порядке должен включать в себя подготовку проектной документации, которая будет сопровождать ваш продукт на всех этапах его жизни. Главный вопрос, который мне задают мои друзья, знакомые и коллеги по отрасли — что должна в себя включать такая документация?

Кто-то говорит о техническом задании, кто-то о маркетинговых планах, третьи о финансовых показателях, юнит-экономике и бизнес-процессах. Дело в том, что прав каждый из них и все перечисленные документы нужны и содержат действительно важную для продукта информацию.

Но почему-то, когда настает пора, каждый из этих документов ведётся отдельно и пишется… без оглядки на другие. Что мы получаем в итоге? Кучу разбросанных по папкам документов, которые пишутся разными людьми, зачастую не видящих друг друга и, скорее всего, не видящих общую картину продукта. Это как одеяло, сшитое из разноцветных лоскутов ткани. Задача любого продукт-менеджера — всё таки сшить это одеяло максимально красиво и удобно.

На мой взгляд, наиболее распространённая причина неудачного запуска (сорванные дедлайны, увеличенные бюджеты, проваленные тестирования) и, даже, наверное, развития многих онлайн-продуктов  —  закрытость информации о самом продукте и невозможность ее получения от одних членов команды другими. В самом начале я не зря поделился принципами, на которых должна строиться любая работа. Без преувеличения скажу, что команда, и то, как она функционирует и живет — половина, а то и большая часть успеха любого продукта. И для ее максимально естественного и продуктивного существования в ней должны быть люди, которые:

1. объединены общими интересами;
2. имеют общие убеждения;
3. горят и стремятся их доказать.

Не буду сейчас вдаваться в детали тимбилдинга (об этом будет отдельный раздел ниже), но скажу, что именно закрытость информации о продукте даже для его команды вызывает множество недопониманий внутри нее. К чему это ведет? Например, отдел маркетинга, взаимодействующий напрямую с аудиторией и продающий ей продукт, никаким образом не пересекается со службой поддержки или аккаунт-менеджерами, которая занимается практически тем же самым (решением проблем пользователей), но работающими уже с текущей базой, и наоборот. В итоге, одни не знают, что, как и кому им продавать, а другие молчат и не корректируют работу первых. Помните, что любой продукт это множество связанных между собой процессов и элементов и чем меньше среди них будет пустых мест, тем проще и эффективнее может работать продукт.

Именно поэтому, совместное составление единого документа, объединяющего все ключевые моменты планирования, разработки, функционирования и развития продуктам всеми участниками этих процессов могут считаться залогом его успешного рождения и дальнейшего роста. Вы как продукт-менеджер должны включать и вовлекать команду в продукт и всё, что с ним связано, в противном случае, как вы будете делать это с пользователями?

Предлагаю выделить ключевые моменты, информацию по которым необходимо включать в такой документ, держать на контроле и делиться ею со всеми членами команды:

1. Продукт и пользователи
2. Команда
3. Развитие и продвижение
4. Мысли и идеи

Как вы видите, эти четыре простых раздела содержат в себе всю необходимую информацию и представлены в виде простой пошаговой инструкции, которая может быть применима практически к любому продукту, а каждый из пунктов может включать в себя любое количество подразделов, связанных с ним.

Опыт разработки и запуска различных проектов научил меня главному правилу  —  идти поступательно от самого лёгкого к самому тяжелому. Это не только экономит время и силы, но и помогает закладывать правильную и последовательную логику для любых процессов . Как писалось выше, продукты представлены множеством взаимосвязей с различными процессами и пользователями, поэтому видя их единой картиной перед своими глазами гораздо легче понимать как это всё должно работать. Давайте перейдём к непосредственному рассмотрению каждого из этих разделов.

Продукт и пользователи

Один из самых простых и понятных для всех разделов. Можете условно называть его интро, введением, описанием продукта  — как угодно. В этом разделе собирается и отражается вся информация по продукту: краткое описание, предназначение и проблемы, которые он решает, рынок, на котором он работает, его потенциальную и будущую аудиторию, её особенности, текущие и возможные бизнес-модели, и т.п. вещи.

В самом начале я бы хотел отметить один важный момент, который может звучать немного запутанно и, наверное, философски, поэтому заранее извиняюсь.

В основе всего лежит время. Вы должны всегда помнить, что нет каких-то постоянных утверждений или убеждений, на которых базируется то, каким образом вы, как продукт-менеджер, должны принимать свои решения. Наш мир движется, причем очень быстро, а вместе с ним движется всё то, что его наполняет, в том числе мы с вами и продукты, над которыми мы работаем, и пользователи, которые им пользуются, поэтому всегда помните, что любые решения нужно подстраивать под конкретное время и ситуацию, а не копировать их раз за разом.

Вернемся от обсуждения законов Вселенной к продукту и том, как движется и развивается он. Вот примерные стадии жизни любого продукта:

1. Этап разработки и запуска MVP
2. Этап роста пользовательской базы
3. Этап выхода на безубыточность
4. Этап генерации прибыли
5. Этап масштабирования прибыли

Я выделяю эти ключевые моменты, которые позволяют выстраивать развитие продукта, набор его функций и моменты, связанные с позиционированием и маркетингом в зависимости от его текущего этапа целей и потребностей продукта и которые накладывают отпечаток на то, как будет жить и развиваться ваш проект в текущий период времени. Обратите свое внимание  —  каждый из этих этапов отличается от другого, но является неотъемлемой частью предыдущего.

И именно поэтому, перед запуском любого продукта вы должны иметь хотя бы общее представление о том, каким может быть ваш продукт на каждом из этих этапов и насколько это реально и своевременно в заданный промежуток времени.

Прикиньте, во что может вырасти вас продукт, какие у него есть пути развития, но… не бегите сильно за мечтами —  с большей вероятностью всё будет совершенно по-другому. Рисуя общую картину и полностью погружаясь в процессы на этой стадии, вы сможете увидеть возможные подводные камни или моменты, которые смогут воспрепятствовать как реализации продукта, так и его развитию.

Постарайтесь сделать так, чтобы данный раздел был лёгок и понятен любому человеку настолько, что этот человек может быть даже со стороны. Не стоит наполнять документацию обилием терминов, технологий и прочих “умных слов”  —  уверяю, что написав их сейчас на бумаге вы не добавите ни грамма их реальной пользы для вашего будущего продукта. Что я имею ввиду под примером “умных слов”? Поделюсь с вами недавней цитатой одного моего знакомого:

“Главный потенциал для нас в том, что мы прицельно работаем над еще не стандартизированной частью нативной экосистемы: спонсорским контентом. Там большой простор для инноваций: начиная от кросс-канального размещения до персонализации контента”.

Я примерно понимаю что они имеет ввиду, но все эти термины разбиваются единственной фразой пользователя “Я ничего не понял, объясните еще раз”. Будьте проще и ближе к продукту и тем, кто будет читать этот документ. Не торопитесь и не преследуйте цели придать написанному солидности - я читал десятки презентаций "нулевых проектов" с десятками умных метрик и характеристик, про которые даже не слышал, но все эти проекты были успешно захоронены на кладбище мертвых стартапов, на котором оказался даже стартап Closedclub, который и являлся таковым. Формируя данный раздел вы, в первую очередь, систематизируете ваши мысли и идеи в некий единый и связанный сценарий, которое и ляжет в основу последующих разделов, решений и разработки.

Вторая немаловажная вещь. Постарайтесь сформулировать чёткое описание вашего продукта всего одним предложением. Всего одним предложением. Проблема многих проектов в том, что они сами не понимают, что они на самом деле делают и не могут сформулировать это даже при простейшем вопросе “эй, а о чем ваш проект?”. И если вы не можете дать ответ на этот вопрос одним предложением и начинаете разглагольствовать и приводить сравнения, то скорее всего, с вашим продуктом и его концептом что-то не так.Плавно переходим к тому, что же такое ваш продукт и каким он должен быть вначале.

Залог запуска любого успешного продукта — MVP (minimal valuable product)

— минимальный рабочий продукт, который содержит в себе ключевые функции и решающий именно те проблемы пользователя, которые лежат в основе его идеи. Это именно то, что у вас должно быть на старте и то, что укладывается в краткое описание вашего продукта. Вещь, на которую надо молиться и которая всегда должна успешно и стабильно работать.

Не стоить запихивать в MVP все кажущиеся вам нужными фишки и навороты. Не стоит сильно думать и фантазировать о том, как ваш продукт будет работать в будущем и куда он будет расширяться. Не стоит рисовать их в дизайне и пилить заранее “на будущее” на старте. Поверьте - в 99% случаев они не пригодятся вам. Повторю — да, в 99% случаев они не нужны. НЕ НУЖНЫ! По крайней мере, на начальном этапе.

Вообще, весьма полезно идти по пути дизайнерского мышления и позаимствовать и этих ребят технику умышленного ограничения, которая позволяет создать искусственные рамки и концентрироваться на четких вещах, делая их более продуманно и эффективно.

Я так усердно говорю это каждому своему другу, но каждый раз они мне рассказывают о том, что запуск их продукта был перенесен и “вот еще кое-что ОЧЕНЬ НУЖНОЕ допилим и выкатимся”. А ведь именно эти фишки и навороты отвлекают вас от самого главного и основного  —  быстрого запуска продукта и проверки вашей идеи, не говоря уже о том, что они забирают самое главное — время и силы вашей команды, которые всегда выражены их энергией и вашими деньгами и лишь размывается обилием лишних фич на старте.

Хотите отложить запуск продукта и потерять в три раза больше времени и денег — закопайтесь в фишках и улучшениях!

Не подумайте, что я преуменьшаю ценность идей и будущих фич  —  я лишь сдвигаю их в списке наиболее значимых приоритетов, важных для быстрого запуска вашего продукта. Конечно, идеи развивают этом мир! Именно и специально для таких случаев и предусмотрен самый последний раздел документации — “Мысли и идеи”, которые в обязательном порядке вы, как продукт-менеджер, должны записывать и постоянно анализировать на предмет востребованности пользователей и приоритетов разработки. От идей мы постепенно перешли к MVP и теперь поговорим о его разработке и запуске.

Как запускать продукты

Говоря о запуске продукта, в этом разделе мы разберем наиболее значимые этапы разработки продукта и его развития. Я предпочитаю разбивать этот раздел на ключевые подразделы, состоящие из самых распространённых направлений деятельности любого продукта:

1. Продукт и потребности пользователей
2. Дизайна и графики
3. Технический раздел
4. Раздел начального маркетинга

Как вы видите, это стандартные разделы, которые часто включаются в любое техническое задание на разработку сайта или бриф, столь необходимые и нужные любой продуктовой команде. Давайте изучим каждый из разделов.

Продукт и потребности

Итак, мы сформировали потребность в проблеме людей и вроде как нашли ее более удобный вариант решения. Что делать дальше? Далее необходимо прописать максимально подробно как и за счёт каких функций и механик будет решаться эта проблема для будущих пользователей. Помните я ранее писал про MVP? Мы снова пришли к пониманию того, что в основе первых версий продукта у нас должно лежать безукоризненное и более простое решение ключевой проблемы пользователей и только потом все то, что расширяет возможности продукта и предлагает его пользователям дополнительный сервис.

Для более ясного понимания процессов, разбейте решение проблемы вашим продуктом на пошаговые этапы, которые должен будет выполнить его пользователь, причём берите с самого начала: с условного источника рекламы, откуда пользователь узнает о вашем продукте, до момента когда он окончательно решит с помощью продукта свою проблему.

Указывайте всё: переходы по сайту, регистрацию, ключевые действия — вы должны видеть всю картинку и все пользовательские пути по сайту. Это позволит вам понять какой из этапов можно упростить ещё больше и сделать его более понятным для пользователя. Данный раздел также будет основной для раздела связанного с дизайном и технической реализацией и именно по нему будущие дизайнеры и разработчики будут оценивать фронт предстоящих работ и их объёмы.

Немаловажным моментом является и то, ради чего вы собственно и делаете продукт  —  зарабатывание денег. Многие проекты уделяют этому моменту весьма значительное место при запуске продукта и я с пониманием отношусь к их желанию спрогнозировать какие-то финансовые показатели. На текущем этапе это необходимо сделать, но, опять же, только с точки зрения основных и общих механик работы продукта и способов его монетизации.

В очередной раз отмечу, что ваш продукт должен решать ключевую проблему пользователя то на начальном этапе используйте такую же механику монетизации. Не думайте и не включайте в разработку дополнительные варианты монетизации - вы еще не проверили работает ли вообще решение проблемы, а уже хотите дополнительно зарабатывать на чем-то другом.

Пока не убежали вперед - как правильно определить цену за продукт? Сломано немало копий, написано множество статей относительно монетизации продукта и правильном ценообразовании, но я скажу лишь одну простую вещь  —  пробуйте всё то, что считаете нужным. Изучите сколько люди платят за решение в настоящее время, изучите цены конкурентов или продуктов из схожих областей, в общем, пробуйте разные цены, пробуйте и совмещайте форматы работы продукта, в общем, не бойтесь экспериментировать не только с функционалом продукта, но и с его деньгами  —  ценовые A/B-тесты как нельзя лучше покажут вам готовность ваших пользователей платить вам деньги и помогут вам найти наиболее выгодный формат. И нет ничего страшного в том, чтобы менять и совершенствовать модели монетизации продукта на всем пути его жизни. Идем к следующему шагу.

Раздел дизайна

Дизайн продукта стоит первее его разработки не просто так. Дизайн и визуальное воспроизведение является ключевым этапом взаимодействия пользователя с продуктом. И помимо того, что глаза являются одним из ключевых каналов получения информации из внешнего мира в мозг человека, они являются единственным каналом, с помощью которого человек взаимодействует с любым продуктом в интернете. Сочетание "картинка + текст" упрощает восприятие любой информации, её обработку нашим мозгом, а также помогает усваивать новую и запоминать старую. Именно поэтому в этом разделе документации аккумулируется вся информация, необходимая для разработки интерфейса для пользователей.

Более того  —  продумывая этот раздел вы в очередной раз вернётесь к разделу “Продукт и его работа” и в очередной раз наложите имеющиеся у вас идеи на возможные варианты их визуальной реализации. Таким образом вы последовательно и дважды отработаете возможные сценарии работы вашего будущего продукта и лишний раз проверите свои гипотезы и предположения уже на будущем продукте, которые будет представлен макетами.

Кто рисует интерфейс и дизайн? Тут есть два варианта - либо это делает дизайнер на постоянной основе, работающий в вашей команде, либо это… вы. Да, да, продакт-менеджер работает с продуктом и пользователями, а это идеально укладывается в то, с чем работает UX/UI-дизайнер. На мой взгляд, наиболее подходящим решением служит следующая механика:

1. Продакт-менеджер рисует будущий интерфейс (UI) работы продукта на основе его предположений и пользовательского опыта в виде прототипов.
2. И отдает такие прототипы на полноценную отрисовку web-дизайнеру.

Разница между UX/UI и веб-дизайном, на мой взгляд, в том, что UX/UI это то, как работает или может работать продукт, а веб-дизайн - как он выглядит.

Вот один из примеров, как работает разработка по Agile или Scrum в связке с разработкой дизайна и интерфейсов:

UX/UI-дизайнерам, которые рисуют прототипы с: lorem ipsum, рандомными данными и цифрами, одинаковыми аватарками, уготован отдельный круг ада, где все окружающее их будет именно таким, каким они его рисовали в своих макетах 🔥

Не стоит чересчур сильно углубляться в рисование иконок или выбору цветов - они вам сейчас не нужны. На данном этапе главное не переусердствовать, поэтому на начальной стадии можно использовать простые прототипы, которые можно отрисовать в той же Figma. Данный инструмент полюбился мне с самых первых дней его использования, под него есть куча видео-гайдов, а сам он позволит вам сконцентрироваться на главном —интерфейсе и том, как именно в нем будет работать ваш продукт, а не том, какого цвета будет его дизайн.

Одна из главных начальных ошибок любого интерфейса на начальном этапе  —  именно ковыряние в дизайне, его деталях и разборе мелочей в виде иллюстраций, размеров и прочих вещей, которые всегда приходят... со временем. Скурпулезное планирование дизайна и интерфейса практически не работает на начальных этапах запуска продуктов (хотя бы потому, что у вас нет статистики в виде цифр и данных, способных вам помочь в принятии тех или иных решений, связанных с эффективностью такого интерфейса) и может принести пользу только если вы работаете с очень опытным дизайнером, который съел немало собак на продуктовых интерфейсах.

Продолжим. Имея на руках готовые прототипы продукта, вы можете попробовать оживить его и перенести в онлайн. Все тот же Axure позволяет вам связывать страницы прототипа между собой ссылками и выгружать их как единое целое в виде статически работающего в интернете черно-белого html-сайта. Этого вполне хватит чтобы проверить как ваш будущий продукт может работать для пользователя и раз за разом проходить его путь для оптимизации этапов. Как вы заметили, мы уже во третий раз воспроизводим наши идеи в реальности и видим то, как они могут или не могут работать в будущем.

Работа любого продукт-менеджера - постоянно улучшать и оптимизировать процессы работы продукта

Документируйте каждую страницу сайта, документируйте её предназначение, её ключевые элементы и механику их работы, описывайте пользовательские пути по сайту и делайте это так, чтобы не открывая страницы прототипа было понятно, что на них размещено и как это работает - именно по такому пути пойдут ваши пользователи.

Получилось? Поздравляю - вы сделали большой шаг на пути грамотной разработки будущего продукта. Как я говорил ранее, мы наращиваем нагрузку и увеличиваем сложность постепенно — начиная с общей информации о продукте мы приходим к её видению в будущем интерфейсе продукта и теперь настало время её технической реализации!

Технический раздел

В этом разделе мы в очередной раз (я сбился уже со счета, но, вроде, четвертый) расписываем то, как будет работать наш продукт с точки зрения его технической реализации. Прошу вас серьезно отнестись к факту того, что вы раз за разом прогоняете один и тот же процесс по кругу - вы строите продукт, что практически равно постройке жилого дома, в котором будут жить живые люди, а значит, вы должны быть уверены не только в его правильно функционировании, но и его постройке на основании той информации, которая у вас есть.

Техническая реализация включает в себя абсолютное понимание всех механик работы продукта будущей командой технических разработчиков. Образно говоря, в этом разделе ваш программист должен кратко описать то, как работает каждая функция вашего продукта на языке тех технологий, которые он для этих целей выбрал. И если вы не программист и не обладаете достаточными навыками для того, чтобы собственноручно накодить ваш продукт, то, скорее всего, на этом этапе вам пора задуматься над тем, чтобы начать формировать вашу команду. Забегу немного вперед и подробно расскажу, как работает вся эта кухня веб-разработки.

Обычно команда разработчиков разделяемся на два направления — бэкэнд и фронтэнд разработка. Первый включает в себя все, на чем работает ваш продукт. Это движок продукта, базы данных и архитектура, ключевые скрипты и алгоритмы, обеспечивающие его работу и все то, что в прямом смысле слова скрыто от глаз пользователей. Фронтэнд это та часть сайта или приложения, которую видит пользователь и с которой он непосредственно работает и взаимодействует - динамический интерфейс, кнопки, формы и всё то, на что надо кликать.

Большинство проектов и команд разделяют эти два направления разработки и стараются не перекладывать на одного разработчика сразу две обязанности, но, в некоторых случаях, это вполне допустимо. Таких умелых программистов, способных работать сразу по двум направлениям, называют fullstack (полный набор) разработчиками. Иметь в штате такого специалиста здорово, но не стоит превращать его в рабочую лошадку, вешая на него все возможные и невозможные задачи по разработке. Вообще, любых разработчиков делят по четырём уровням.

Тестировщик. Самый первый уровень разработчика, главной обязанностью которого является либо написание автоматических тестов, которые будут автоматически “пробегаться” каждый раз перед очередным обновлением продукта, либо ручных, когда все тестирование проводится руками по написанному ранее сценарию.

Джуниор. Начинающий разработчик, способный читать и понимать чужой код на выбранном им языке программирования. Такие программисты хороши для проведения автоматического тестирования написанного более опытными программистами кода. Джуниоры весьма успешно обучаются и, в зависимости от желания, уже через год имеют все шансы перейти на следующую профессиональную ступень.

Мидл. Программист, способный писать код под те задачи, которые перед ним стоят. Данный процесс может сопровождаться переписыванием кода, периодическими ошибками и их отладкой. Именно этот этап является самым важным в жизни любого разработчика, т.к. именно в этот период он должен научиться логически мыслить, анализировать и прогнозировать наперёд то, что над чем он работает.

Сеньор. Если это настоящий сеньор, то этому парню все по плечу. Он будет долго думать, прикидывать и что-то писать на бумажке, но, в конечном счете, он способен реализовать то, что нужно вам и вашим пользователям качественно, практически без ошибок и относительно быстро. Эти парни часто задают вопросы (по крайней мере, должны это делать) и способны помочь вам в очередной раз разобраться в механике и сценариях работы вашего продукта, а также накидают с десяток новых и, зачастую, гениальных идей для его развития. Мечта любого менеджера, за которую приходится ощутимо доплачивать.

Тимлид. Повидавшие жизнь сеньоры, которые все меньше пишут код и все больше занимаются постановкой и контролем задач разработчиков уровнем ниже, т.е. выполняют управленческие и организационные функции.

Чтобы не вставать два раза, давайте сразу поделюсь своим опытом как отобрать нужного вам разработчика. На самом деле, то не сложно, даже если вы не разбираетесь в программировании. Например, я не разбираюсь в том, как работает Tornado или Docker, но я отчетливо слышу, когда кто-то пытается выдать мне желаемое за действительное. Уверен, что этот получится и у вас  —  будьте внимательны и спрашивайте кандидатов не о том, какие технологии они знают, а о том, ПОЧЕМУ он с ними работают и как они решают поставленные перед ними задачи.

Сильные и заинтересованные разработчики с неподдельным интересом и даже гордостью будут рассказывать вам о своих достижениях и проектах и о том, как они умело и с минимальными затратами решили поставленную перед ними задачу.

Лже-сеньоры или просто слабые разработчики будут дуть щеки, зачитывать резюме и рассказывать о том, как на них держался весь проект (но не понятно, за что именно они отвечали и что именно они реализовали) и как они из него ушли.

Не стесняйтесь рассказывать собеседнику о вашем будущем проекте — спросите как бы он выстроил процесс разработки той или иной функции или всего продукта в целом, а также какие подводные камни в этой реализации и сложности он видит. Из его ответов и просто хода рассуждения вы лучше узнаете разработчика как человека, с которым вам придется работать, так и разработчика, как специалиста в своей области.

Вообще, процесс поиска команды разработчиков очень увлекателен. Правда — это совсем не скучно и по зубам даже тем, кто имеет хотя бы минимальные познания втом, какие технологии могут использоваться для ваших задач. В чем увлекательность? Конечно же — в людях. Ища разработчиков вы можете познакомиться по истине с необычайными людьми. Например, как-то я искал senior python developer в один проект и случайно познакомился с российском разработчиком и, по совместительству, переводчиком книги о Python, на которой воспиталось и выросло не одно поколение джуниоров, мидлов и сеньоров в России. Это необычный человек (Руслан, привет!), который не только в совершенстве знает Питон, но и обладает кучей других интересных умений, например пайке плат и схем для лифтов :)

Возвращаемся к нашей технической разработке. Как и любой процесс, связанный с созиданием чего-то нового, разработка продукта делится на четкие этапы, содержащие конкретный список работ. В классической модели agile-разработки эти списки называются спринтами и содержат перечень работ (историй и тасков), которые должны быть выполнены в отведенные периоды времени.

Обычно, спринты формируются на совместном совещании команды разработчиков и менеджера продукта, где участники в разной последовательности определяют приоритет разработки сформированных ранее продуктовых идей, описанных в stories (пользовательских историях), оценивают трудовые и ресурсные затраты на их реализацию, устанавливают дедлайны, формируют из них задачи на разработку (tasks или таски) и, самое главное, назначают на них исполнителей.

В зависимости от сложности проекта и размеров команды разработчиков, спринты могут быть недельными, двухнедельными, месячными, полугодовыми и т.д. По окончанию спринта продукт-менеджер и тимлид подводят итоги прошедшей по спринту работы и выполненных задач.

Обычно, разработчиками используется два типа продуктов — боевой и разработческий, которые размещаются на двух разных серверах. Это делается для того, чтобы разработка продукта и его обновление сначала проходило и тестировалось на безопасном для реальных пользователей сервере (где их нет), и только после этого обновление уходило на боевой и его могли увидеть живые пользователи.

Иногда будет происходить ситуация, когда очередное обновление успешно пройдёт все этапы от разработческого сервера до боевого, но на последнем обнаружится, что фича некорректно работает в связке с живыми данными (например, на боевом сервере неправильно ранжируются большие объемы данных, которых нет на сервере разработчиков). Если ситуация критическая и ощутимо сказывается на работе пользователей с продуктом, то нет ничего страшного в том чтобы выкатить внеочередной фикс конкретно этой проблемы вне рамок очередного спринта (всегда так делаю).

Идём дальше. Как вы уже поняли, я являюсь пропагандистом подхода разработки по визуальному макету или прототипу, которая подразумевает начало технической реализации только после того, как на руках у команды появляется работающий интерфейсный прототип продукта или функции. Это позволит всем членам команды не изъясняться на пальцах, а вести процесс реализации основываясь на конкретных и наглядных макетах. Кстати, именно изъяснение на пальцах, а не документах и прототипах, и приводит к тому, что рано или поздно между участниками команды возникнет недопонимание. Поверьте, это всего лишь вопрос времени и любая, даже сама сработавшаяся команда, однажды придёт к тому, что обнаружит реализованную функцию или алгоритм не так, как это виделось ранее.

Сколько обычно занимает средняя разработка? Ответить на этот вопрос наверняка сложно, т.к на сроках сказывается сразу несколько факторов: и правильно написанное техническое задание с выбранным минимальным функционалом, и квалификация разработчиков и, в некоторых случаях, правильный выбранный стэк (набор) используемых разработчиками технологий.

Возможно следующим предложением я вызову бурю обсуждений, но разработав и запустив с нуля около десятка разных онлайн-продуктов, я могу с уверенностью сказать, что… два/три месяца ежедневной восьмичасовой разработки для это вполне приемлемый срок для двух программистов, чтобы по прошествии него вы, как продукт-менеджер, могли “потрогать” промежуточный и рабочий результат.

Обязательной стороной любой разработки является тестирование продукта, которое тоже можно поделить на две части  —  тестирование бэкэнда и тестирование фронта. Разные команды поступают по разному — кто-то сразу пишет автоматические тесты, кто то нанимает тестировщика, который пишет их за основную команду или вообще тестит рукам. В условиях допустимости бюджета и уже на третьей-четвёртой неделе разработки рекомендуется использовать как раз таки второй вариант, дабы не отвлекать основную команду от разработки ключевого функционала. Плюсом этого варианта также является то, что используя тестировщика вы знакомите его с кодом продукта и командой, что в будущем позволит вам расширить штат основной команды разработчиков именно этим сотрудником.

Что еще можно рассказать о разработке? Давайте лучше поделюсь мнениями разработчиков, с которыми мне приходилось работать и которые не раз подтверждались практикой.

Не гонитесь за популярными технологическими брендами. Использование .NET или Ruby не сделает ваш продукт лучше и популярнее. Единственное, на что это повлияет - скорость разработки и ресурсы, которые придётся в неё вложить. Это тоже самое, что гнаться за модой — на это нужен реальный вкус и много денег, но не факт, что вы будете выглядеть красиво.

Не раздувайте штат разработчиков. Увеличение команды разработчиков в два раза на начальном этапе не означает, что продукт будет готов в два раза быстрее. Скорее наоборот — чем больше “голов”, которые ещё не притерлись друг другу и продукту, тем больше путаницы, мнений, неразберихи и больше времени на их обучение.

Не раздувайте функционал. В очередной раз повторю, что главным подводным камнем любой разработки являются детали, в которых кроется дьявол (это поговорка придумана не спроста). Не пытайтесь запихнуть в ваш MVP кажущиеся вам крайне необходимыми фишки, делающие ваш продукт лучше. Быть и делаться лучше — задача последующих этапов развития, а не старта — сейчас вам, как продукт-менеджеру, надо сделать и зарелизить продукт, чтобы посмотреть как он работает.

Закладывайте запасное время. Никогда не будет лишним заложить на реализацию продукта, какой-то функции или спринта чуток лишнего времени, например 30% от реально заложенного срока. Уложитесь раньше - честь вам и хвала, за то, что зарелизили раньше срока. Просядете по срокам - всегда будет немного времени в запасе.

Команда продукта

Начну повествование этого раздела с того, что я никогда не любил HR-менеджеров как отдельную боевую единицу в штате it-проекта за их полную и тотальную безграмотность в области того, чем должны заниматься члены команды и какие вообще цели эта команда преследует.

Однажды я даже написал об этом заметку на VC.ru, которая вызвала много критики в мой адрес именно со стороны эйчаров. Кто придумал Facebook? Рыжий бунтарь-ботаник. Apple? Вегетарианец, который не любил мыться. Эти люди в совершенстве знали программирование и дизайн, обладали чутьем, внутренними принципами и были практически польностью асоциальны. Были ли у этих людей шансы пройти тот самый “человеческий фильтр”, которым так гордятся рекрутеры? Уверен, что нет.

Мне также понравилась концепция, которая давно сидит в моей голове и которую наконец-то озвучил глава всеми нами любимого Notion:

”We want the business to be as big as possible, but we want the team as small as possible" (“Мы хотим максимально большой бизнес с максимально маленькой командой”) —  Ivan Hzhao, CEO Notion

Поэтому, пока вы не тот самый Facebook или в вашем штате нет хотя бы 50 сотрудников, личный контакт с кандидатом с самого начала позволяет лучше чувствовать людей и избегать этого самого ненужного фильтра. Поэтому, любую работу, связанную с формированием команды продукта лучше брать на себя тому, кто с этой командой будет работать - продукт-менеджеру.

Начнем с главного (на самом деле, продолжим предыдущее). Золотое правило любого продукт-менеджера гласит:

Вы должны быть уверены в тех, с кем вы работаете

Но в ком вы должны быть уверены и из кого состоит среднестатистическая команда среднестатистического онлайн-проекта? Разберемся по порядку.

Продукт-менеджер. Вы — человек, который стоит во главе проекта и который отвечает за все. Да, вы не ослышались — за все: за разработку, за запуск, за маркетинг, за развитие и даже за customer service. Продукт-менеджер должен быть центром и в центре всего, что связано с продуктом. Вы должны отвечать за связь любого члена команды с продуктом. Вы должны быть связующим звеном между любыми участниками команды, которые, на самом деле, могу даже не пересекаться между собой. Это тот самый человек, который отвечает за то, как работает команда всего проекта в целом. Я не побоюсь ответственности, когда скажу, что продукт-менеджер это временно исполняющий обязанности СЕО компании, ведь на нем лежат все ключевые этапы работы проекта.

Команда разработки продукта. Как рассказывалось ранее, это тимлид, который отвечает за техническую сторону разработки и развития функциональности продукта. Он курирует и организует работу команды программистов, принимает участие в составлении с продукт-менеджером спринтов и отвечает за их правильное и своевременную реализацию. В команде может быть backend-разработчик -  “сердце” вашего проекта, человек, отвечающий за правильное функционирование внутренностей проекта — баз данных, подсчетов и т.п. вещей, и Frontend- разработчик, отвечающий за кнопочки, формочки и шрифты. Хорошим тоном считается иметь в команде отдельного тестировщика, из которого растить подмогу старшим братьям.

Маркетолог. Реклама, трафик, аналитика, сбор фидбэка с рекламы. Человек, который несет в массы ценности и убеждения вашего продукта и его команды и транслирует их целвой аудитории. Должен уметь чувствовать настроение людей, разбираться в покупательской психологии и уметь считать конверсии, стоимость привлечения пользователя и окупаемость рекламы.

• Продажи — это голос потенциальных клиентов.
• Поддержка — это голос существующих клиентов.
• Маркетинг — это голос рынка, конкурентной среды, он диктует нам, сколько вещей нужно и сколько они должны стоить.

Сапорт-менеджер или аккаунт-менеджер. Человек, напрямую работающий с пользователями и участвующий в осуществлении продуктом своих услуг и функций.

В разных продуктах и разных командах численность и штат таких сотрудников может разнится. Где-то есть отделы холодных продаж со своими начальниками, где-то сидят отдельные менеджеры, занимающиеся модерацией чего-либо и т.п.

Вообще, процесс построения команды последователен. Думаю, что не стоит объяснять, что нет абсолютно никакой необходимости нанимать с самого начала целые отделы сотрудников, особенно когда все внутренние процессы внутри команды и, продукта в целом, не выстроены. Каждый продукт уникален (только если вы зачем-то не копируете на 100% своего конкурента),  а значит, понимание того, как он должен работать и какие механики наиболее оптимальны, придут к вам со временем и по мере постепенного роста продукта, а также роста нагрузки на те направления, которые будут развиваться. Чувствуете, что процесс холодных продаж работает как часы, лиды закрываются, договора подписываются - смело нанимайте еще парочку продажников, смотрите как процесс будет вести себя с большим количеством участников и корректируйте его при необходимости.

За все время мне пришлось поработать с порядка 10 команд в разных областях IT.  На мой взгляд, ни одна из моделей не работает в чистом виде — у вас не получится держать себя и команду постоянно и в одном статусе, потому что если вы хотите, чтобы развивался продукт, то вместе с ним должны и будете развиваться и вы и сотрудники и рынок, на котором вы работаете (и кому его еще менять, как не вам).

Это значит, что команды и ее процессы будут трансформироваться, и, например, даже среди наставников всегда будут появляться авторитеты и главная задача — не дать свести этот авторитет в диктаторство.

Пока не забыл. Хорошим тоном для любого продукт-менеджера считается написание или, как минимум, участие в написании инструкций и сценариев работы, о которых я говорил выше, для других членов команды и всех процессов, которые затрагивают продукт. У вас есть есть пре-модерация контента - напишите сценарий и критерии для его оценки. Менеджер по холодным продажам - напишите сценарий контакта и упорядочите весь процесс продажи от контакта доподготовки документов и окончательного оказания услуги в пошаговый процесс с четким описанием каждого из этапов и свойственных ему действий со стороны сотрудника и пользователя.

Не пускайте всё на самотёк - благодаря этому вы сможете быть уверенными в том, что внутренняя кухня продукта работает и развивается именно так, как это видите и нужно вам и продукту. Ну, а еще по ним хорошо учить новичков и закреплять знания текущих участников.

Что еще можно добавить про команду? Пожалуй, я вновь повторю одну прописную истину любого продукт-менеджера:

умейте слушать

Да, ты - умный, но всегда есть люди умнее тебя. И главный навык, наверное, каждого успешного человека - общаться с теми, кто умнее тебя, слушать их и находить в этом нужную для тебя информацию, особенно если это те, кто окружает тебя в твоей же команде.

Продвижение продукта

Продукт запилен и оттестирован, а к его названию смело добавлен символ бета-версии? Поздравляем  - вы сделали это! Впереди вас ждёт ещё больше трудностей и невзгод! Настало время, когда вам нужно показать ваш продукт широкой аудитории и проверить, насколько ваши идеи и варианты решения проблемы подходят пользователям.

Никогда не свыкнусь с мыслью, что люди ненавидят прогресс. Вместо этого они предпочитают инерцию. Просто потому, что это легче и не требует от них никаких умственных затрат. И именно инерция удерживает их от покупки вашего продукта, даже если он представляет из себя более практичное и логичное решение.

С чего начать продвижение продукта? Раскрою небольшой секрет, сказав, что этим вопросом стоит начать задаваться где-то с середины пути разработки, когда у вас будет четкое понимание аудитории вашего продукта и проблем, которые он будет решать, а своевременный подход к этому этапу позволит вам начать первое живое тестирование сразу после запуска без ожиданий и простоев в его работе.

Уточню, что я не буду детально расписывать все виды маркетинговых активностей и указывать какие-то реальные кейсы — это сделано за меня на множестве различных маркетинговых блогах и изданиях.

Итак, вы только что запустились, а значит, что высока вероятность (я бы сказал, она очень высока) того, что в продукте что-то будет работать не так и вашим разработчикам придется прямо на ходу чинить эти проблемы.

Именно поэтому можно в очередной раз воспользоваться практикой умышленных ограничений, а именно начать продвижение продукта с малых маркетинговых активностей, которые позволят вам контролировать входящие объемы трафика, а их малая стоимость позволит вам легко пережить потерю трафика даже если вылезут какие-то ошибки, которые не позволят пользователям работать с продуктом. Поверьте, что это лучше, чем покупать статью в одном из ТОП-ых тематических изданий за 150 000 рублей и после ее выхода понять, что у вашего продукта почему-то сломалась ключевая функция и фиксить ее, когда на сайте одновременно 500 онлайн-пользователей.

В начале любых работ по маркетингу я предпочитаю начинать с самой первой составляющей  —  контентной части проекта, представленной статическими страницам, такими как справочник о вашем продукте и полезных статей, связанных с пользовательской проблемой, которую он решает. Попробую объяснить зачем и почему это можно делать в первую очередь:

1. Написание справочных гайдов в очередной раз проведёт вас, как продукт-менеджера (и пользователя), по пути работы вашего продукта и в очередной раз заставит вам подумать, все ли с ним в порядке и что еще можно улучшить.
2. Более того, вы сформируете полноценный справочник по работе с вашим продуктом, что избавит ваших сапортов (и вас) от обилия вопросов от пользователей.
3. Будущие пользователи, которые пойдут с рекламы, 100% будут ходить по вашему сайту и смогут прочитать материалы, связанные с тематикой вашего продукта, где вы можете показать свои компетенции, видение проблем и способы их решения. Это позволит пользователям проникнутся в тематику продукта и решаемой им проблемы, и вовлечет их в него, повышая уровень конверсии из посетителя в пользователя. Сайт проекта, на котором есть полезный контент изначально внушает больше доверия, чем сайт с отсутствием каких бы то не было статей и одной новостью в духе “ура, мы запустились!”.
4. Сео-продвижение. Без него никуда, особенно если ваш продукт рассчитан на массовый рынок. Тематические статьи, связанные с вашей темой и написанные правильным языком и содержащие правильные

Это четыре ключевых довода, которые объясняют необходимость обязательной работы с контентной частью продукта на начальном этапе и, без преувеличения, скажу, что являются базой и основой для будущего контент-маркетинга. Ниже я расскажу о том, каким образом можно выстроить продвижение вашего продукта другими способами.

Но начать я бы хотел с того, каким образом мы будем оценивать результативность продвижения и вообще маркетинга. Да, да, настал именно тот момент , когда необходимо считать конверсии и стоимость привлечения клиента. Точнее, считать за вас будет калькулятор (или, если есть возможность, то отдельный сотрудник в лице маркетолога), а вы лишь должны знать и понимать, что это за показатели и для чего они нужны.

Итак, конверсия. Термин довольно широкий и используется для выделения и окончательного подсчёта результативности того или иного действия. Конверсия в интернет-маркетинге — это отношение числа посетителей сайта, выполнивших на нём какие-либо целевые действия (покупку, регистрацию, подписку, посещение определённой страницы сайта, переход по рекламной ссылке), к общему числу посетителей сайта, выраженное в процентах.

Помните, в самом начале мы писали пошаговое выполнение пользователем действий с момента клика по рекламе до финального действия? Каждой из этих этапов можно обсчитывать отдельно и объединив их вместе в конусообразный график мы получим легендарную воронку продаж, отображающую весь трафик, проходящий через все этапы на сайте и показывающий, на каком из этих этапов у вас “отваливается” большее количество пользователей. С конверсией разобрались и теперь мы умеем оценивать и анализировать эффективность работы продукта и каждого из его этапов.

Помимо простой конверсии, которая связана с особенностями рекламы (объявления, таргетинг) и самим сайтом (удобство дизайна, УТП), в реальной жизни все всегда упирается в не менее реальные деньги. В перечисленных ниже способах вы увидите и платные варианты продвижения. Для таких случаев необходимо уметь также рассчитать стоимость привлечения пользователя (Customer Acquisition Cost или просто CAC) и видеть, какой канал привлечения пользователей наименее затратен и наиболее эффективен в плане вложения в него денежных средств.

Считается данная метрика весьма просто: достаточно взять стоимость вложений в рекламный канал и поделить его на количество приведенных с него платящих пользователей, которые выполнили целевое для вас действие. Ответом и будет стоимость пользователя, которого вы единоразово “покупаете”, вкладывая деньги в ту или иную рекламу.

Но давайте оставим подсчеты и не будем есть хлеб маркетологов и попробуем разобраться в основных типах маркетинговых активностей. Ниже я расположу наиболее распространенные каналы трафика, рассказывая о конкретных преимуществах того или иного формата привлечения пользователей в продукт.

Работа с изданиями. Канал, который даёт не только неплохой старт, но и позволяет оставаться на слуху, рассказывая на 80% о проблеме и на 20% о вашем продукте, который ее решает для вашей целевой аудитории. Их множество и практически в каждой тематике есть свои лидеры с хорошими объемами трафика. Есть несколько основных форматов продвижения продуктов через них:

• авторские/экспертные/образовательные бесплатные статьи;
• рекламные статьи, медийная реклама, спец. проекты и прочее.

Исходя из этого у вас есть два варианта — платить деньги за рекламные форматы, либо постараться придумать и написать что-то реально интересное и полезное для вашей целевой аудитории издания в авторской статье. И если с рекламой всё понятно, то с авторскими публикациями немного сложнее. Хотите я расскажу, чего хотят все журналы и издания?

1. уникальный, экспертный и интересный контент, который за счет себя привлечёт им трафик.

И если вы позиционируете свой продукт как экспертов в области решения проблем людей, то формат авторских публикаций подходит для вас лучшим образом. Странно, но именно эту прописную истину не хотят понять те, кто тратит десятки тысяч долларов на скучные рекламные статьи, которые собирают дай бог 10% от всего потенциала площадок и их целевых аудиторий.

Не стесняйтесь советоваться с редакцией такой площадки, почитайте комментарии последних 10 статей и понаблюдайте за настроением ей аудитории — найдя общий язык с ними и получив удачную публикацию вы можете привлечь ядро активнейших пользователей, которые дадут вам первую обратную связь и, возможно, первые деньги.

И всегда помните, что бренд и отношение к вашему продукту не формируются одной-двумя статьями на самых крутых площадках (но могут дать хороший толчок) — бренд и его концепция это отношение его создателей и команды к тому, каким они видят решение проблем людей (!) и, наверное, к миру в целом. И цель таких публикаций — рассказывать об этом видении, находя среди читателей таких публикаций тех, кто его разделяет.

Интеграции в контент сторонних сайтов. Оторву от сердца, но поделюсь этим источником с вами. Это выкуп упоминаний вашего продукта или ссылок на ваши сео-статьи на тематических сайтах, страницы которых вылезают в поисковиках по нужным вам и схожими с вашим продуктом ключевым словам. Думаю, что не стоит объяснять как работает данный канал — подобный формат позволяет вам:

1. На постоянной основе привлекать с таких площадок целевой трафик.
2. Одновременно с этим прокачивать сео для вашего сайта.

Такие интеграции стоят денег, но по сравнению с выкупом рекламных обзоров позволяют вам существенно экономить и выбирать страницы, на которых ваши рекламные упоминания будут размещаться.

Контекстная реклама. Именно она — классический канал покупного трафика жил, жив и будет жить пока люди будут искать информацию в поисковых сетях. Удобные инструменты для таргетинга позволят вам максимально приблизиться к той аудитории, которая вам нужна, а сам формат рекламы через интернет позволяет наглядно считать и оценивать эффективность от такой рекламы.

Плюсом является то, что если ваш продукт уникален и вы предлагаете что-то новое для рынка, то, скорее всего, конкуренция по нужным вам ключевым словам будет минимальнейшая, а значит и ставка по ней будет на весьма низком уровне. Поэтому можно попробовать поиграться и оценить трафик в разрезе стоимости единицы пользователя.

Холодные продажи. Вы можете меня засмеять, но эта штука со времён Холодной войны до сих пор работает, особенно если у вас есть на руках “чудесным образом” оказавшаяся клиентская база. Более того, данный формат позволяет вам поговорить с целевой аудиторией “лицом к лицу”, услышав не только, что она думает о данном способе продаж, но и о проблеме, которую пытается решить ваш продукт.

Социальные сети. Если рассматривать этот источник трафика в разрезе корпоративного аккаунта вашего продукта, то это скорее канал публичной коммуникации, позволяющий вам показать то, как работает ваш бренд, как он взаимодействует с пользователями, а не источник лидов или прямых продаж. Помните, что в социальных сетях сидят живые люди со своими интересами, а значит, что задача вашего продукта в соц. сетях — найти таких людей и разделить эти интересы с ними. Единственным исключением может служить контекстная реклама в соц. сетях. В этом плане идеально работает Вконтакте, позволяющий таргетироваться на кого угодно, вплоть до сообществ или официальных страниц ваших конкурентов.

Реферальная программа. Реферальные программы используют практически все крупные продукты, где есть завязка на деньги. Работает весьма просто — вы платите часть от своих прямых доходов с пользователей с теми, кто вам их приводит. Нет продаж — ничего не платите. Особенностью является то, что данный канал рекламы требует наличия хотя бы минимального, но программного обеспечения на стороне вашего продукта, которое могло бы не только отслеживать статистику реферальных продаж, но и показывать ее тем, кто будет поставлять вам такие продажи.

Ретаргетинг. Как вишенка на торте всех ваших рекламных активностей — эта штука реально помогает доводить начатое до конца. Не знаете что это такое - загуглите.

Всегда помните о том, что любое продвижение продукта это комплекс действий, включающий в себя не только покупку рекламы, но и внутренний маркетинг, который завязан на "дожимании" пользователя до нужной вам конверсии через email-тригеры или внутренние механики (в т.ч. игровые). Для этих целей я очень рекомендую использовать Intercom - не совру ни капли, если скажу, что после того, как вы проинтегрируете эту убийственную штуку из Сан-Франциско на свой сайт и для своих пользователей, за счет настраиваемых и гибких тригеров на любые события в вашем продукте (регистрация, отсутствие выполнения целевых действий, выполнение целевых действий и необходимость дальнейших) она может легко повысить общую конверсию сайта на 5-20%.

В самом начале я обещал не ссылаться на умные слова умных людей, но, пожалуй, нарушу это правило. Не помню кто, но он сказал примерно следующее:

любой продукт должен содержать то, что рассказывается о нем в рекламе

Другими словами, будьте честны с вашими будущими пользователями в рекламе и не обещайте им того, что не сможете дать.

ю">

Рост продукта

Переходим к дальнейшей стадии. Как расти и развивать свой продукт? Ответ на этот вопрос мы будем искать в разрезе процесса эффективного и правильного развития функциональности, а не в росте бюджетов на маркетинг и пользовательской базе.

Customer Development в работающем продукте

Что делать, когда продукт уже едет и вроде как более менее успешен по ряду показателей/KPI, но всё равно не дотягивает до каких-то целей или метрик? Поделюсь своим опытом.

Итак, customer development это процесс изучения/опросов/общения с вашими пользователями и формирование продуктовых гипотез и решений, основанных на полученной от них информации.

И вроде все просто – вы общаетесь с пользователями, они говорят вам, чего им не хватает в вашем продукте. Но не все так просто. Вот как это работает на практике.

1. Постановка цели

Перед началом каждого касдева обычно ставиться цель, для чего он делается. "Мы хотим лучше понять ценности нашего продукта", "Мы хотим увеличить продажи", "Мы хотим увеличить пользовательские активности" и т.п.

Именно конечная цель, ради которой он делается, и закладывает основы того, в каком ключе будут проходить дальнейшие действия.

2. Разработка вопросов

Один из частых этапов, на которых происходит затык. Что спрашивать? Я придерживаюсь подхода спрашивать о двух вещай: а) процессах; б) продукте, встроенном в процессы.

Это значит, что вы должны спрашивать не просто "Что вам нравится/не нравится в нашем продукте", но и "Что вам нравится/не нравится в том, чем вы занимаетесь".

Важно - не ограничивайте респондентов мышлением рамками вашего продукта и его функционалом. Ваша задача - сделать более простым решение пользовательских проблем (ПРОЦЕССЫ), а не продукт (продукт - всего лишь инструмент). Иногда это значит, что для решения проблемы может понадобиться совершенно другой подход/процесс и... продукт.

В качестве примера поделюсь с вами нашим старым опросником https://goo.gl/forms/PMTxCXyXqtlnTilf1 по EPICSTARS, который мы делали год назад с нашим продуктовым дизайнером (за что ему большое спасибо).

Исходя из вопросов определите, будете ли вы делать персональные интервью и если да, то через какой канал.

Не забывайте, что никто не хочет тратить свое время бесплатно – в качестве бонуса за их потраченное время выбирается материальное вознаграждение (для B2C сегмента может подойти бонус внутри продукта, для B2B - подарочный купон на Озоне/Амазоне или пополнение баланса телефона)

+ хорошим тоном считается предложить респонденту в конце опроса самому выбрать дату и время для интервью, если такое планируется.

3. Определение аудитории 

Следующим этапом определяется аудитория пользователей продукта, с которой вы будете общаться.

Я обычно беру два противоположных по отношению друг к другу сегмента - тех, кто УЖЕ делает то, что вам надо, и те, кто ЕЩЕ не делает то, что вам надо (цели). Как разновидность - опрашивать только тех пользователей, кто уже платит или не платит.

Противоположные мнения, противоположные свойства и показатели этих групп – всё это дает понимание картины под разными углами и делает результаты исследования более релевантными.

Обычно берется выборка из 300-500 пользователей (на самом деле, зависит от общего объема активной базы пользователей, наш СТО топит за то, чтобы выборка всегда была не менее 20% от общего числа), 10%-30% от которых доходят до финального интервью.

4. Аналитика

Далее следует процесс анализа информации. Можно выделить два типа получаемой информации:

– пользовательские сценарии (процессы и привычки)

– конкретные преимущества/недостатки/советы/идеи.

По первому типу информации следует сложная работа в виде отрисовки текущих пользовательских путей + карты переходов по сайту и выделении на них проблемных мест. Где больше проблемных мест/обрывов/отказов и т.п. - там нужно больше вашего внимания.

Со вторым типом информации чуть сложнее, особенно когда надо классифицировать все свалившиеся на вашу голову гениальные идеи от пользователей.

Для простоты мы разбиваем все полученные от респондентов идеи и преимущества по тому, на что они влияют в продукте.

Все выводится в отдельные столбцы, в каждом из которых и находится конкретная идея. Каждой идее можно ставить score, который складывать из а) частоты упоминания со стороны пользователя и б) потенциалу влияния на конкретный процесс в продукте.

Наверное, вы не раз слышали о таком термине как дорожная карта или roadmap. Эта штука позволяет продукт-менеджерам систематизировать всю поступающую о вашем продукте информацию, анализировать её с целью планирования дальнейшего развития в плане расширения функционала и формировать спринты с задачами, связанными с расширением функциональности продукта.

Несмотря на это, я бы предложил делить дорожные карты на два направления:

• Функциональная дорожная карта
• Маркетинговая дорожная карта

На самом деле, эти две вещи взаимосвязаны, поэтому давайте рассмотрим и разложим на столе каждую из этих колод по порядку.

Функциональная дорожная карта. Все, что вы выбрали и определили в качестве приоритетов для развития вашего продукта находит своё отражение именно в этой карте: фичи, обновления, запуск суб-продуктов (например, образовательного центра для пользователей) — все это находит своё отражение в функциональности продукта и напрямую связано с командой разработки, которая и будет это всё реализовывать.

Маркетинговая дорожная карта. Как понятно из названия, маркетинг это то, что и как мы продаём, поэтому данная карта содержит в себе поставленные перед проектом цели: рост клиентской базы, рост среднего чека и т.п вещи и способы их достижения. Данное направление связано с одноименными сотрудникам и целиков лежит на их плечах.

По уму, маркетинговая карта должна быть связана с функциональной и является ее продолжением. Запустили новую фичу? Используйте её в маркетинговых активностях, рассказывайте о том, как она решает очередную проблему текущим и будущим пользователям и показывайте необходимость её использования. Иначе зачем вы ее делали?

Какими бывают дорожные карты по продолжительности? Обычно они делятся в зависимости от текущего этапа проекта. Я делю дорожные карты на несколько типов, главное различие в которых — в их количествах и сроках их реализации. Всего их три:

• краткосрочные (от 1 недели до 1 месяца);
• среднесрочные (от 1 месяца до 6 месяцев);
• долгосрочные (от 6 месяцев до 1+ года).

Логика с ними простая простая. Если ваш проект еще не окупается, то строить планы более чем на 1 месяц  бессмысленно. Живите “текущим днем”, держите руку на пульсе продукта, получайте и изучайте обратную связь, оперативно закрывайте дыры/баги, фиксите и совершенствуйте свой продукт. Всё что вам нужно на текущем этапе — искать, находить и удовлетворять потребности ваших пользователей, которые должны платить за ваш продукт. Родмап забивается фичами, приоритет реализации которых постоянно перемешивается и меняется.

На текущем этапе в этом нет ничего страшного, поэтому не бойтесь экспериментировать и пробовать что-то, на что другие не смогли решиться — именно сейчас у вас еще есть для этого средства, возможности и место для маневра, и, возможно, именно это повысит спрос и интерес к вашему продукту.

Джеф Готельф из Respond задался вопросом - правильно ли опираться на такую метрику как NPS и предлагает вместо нее ответить на простой вопрос:

“Что именно делают довольные клиенты в вашем продукте?“.

 Ответ и подскажет вам какую конкретную метрику и функцию в продукте, которую и стоит качать.

Сделали хороший продукт? Юзеры довольны? Настало время подумать о деньгах и выходе на самоокупаемость. Тут хорошо сработает более среднесрочная перспектива и roadmaps от одного до шести месяцев. Представляя, что у нас идеальных продукт, который уже вылизан и имеет спрос от пользователей, на текущем этапе в родмап забиваются фичи, которые более связаны и соприкасаются с монетизацией пользователей и деньгами и менее связаны с запуском новых направлений фичей (т.к. мы уже нащупали и сделали то, что дало нам наше УТП и лояльность юзеров и успешно решает их проблемы).

Срока карт от одного до шести месяцев достаточно для того, чтобы не только чтобы грамотно спланировать и реализовать новый функционал, который позволит вам выстроить правильную модель монетизации, но и позволит продукту накопить необходимый объем данных, на основании которых можно делать какие-то выводы и принимать решения связанные с указанными выше факторами.

Когда продукт успешно работает, пользователи рады, а деньги у продукта уже есть, то необходимо их 1) сохранить 2) увеличить, поэтому долгосрочные родмапы сроком от 6 месяцев и свыше года могут позволить себе продукты, которые уже вышли на окупаемость и уже приносят прибыль. На этом этапе настало время стратегического планирования, более бизнесовых решений в виде выхода на новые рынки/страны, поглощений конкурентов или продуктов с целевой аудиторий, в общем, решений, которые требуют максимально взвешенной, детальной подготовки и планирования.

Внимание от самого продукта и его функционала больше смещается в сторону его эффективного управления (именно поэтому большие продукты медленнее растут) и масштабирования прибыли. Планирование на год(а) вперед — лучшее для этого решение.

Дорожные карты можно совмещать, разделять по направлениям продукта, вести их сразу несколько одновременно, например, один родмап на реализацию новых фич, другой на развитие программы работы с партнерами по реферальной программе, третий на SEO, четвертый на контент-маркетинг и т.п. Это позволит вам держать на виду все важные направления и своевременно принимать решения основываясь на текущем положении дел в продукте.

Если говорить о технологических дорожных картах, то очень часто встает вопрос о том, как правильно определять новые фичи для продукта. Важно понимать, что в основе любой новой фичи всегда должны лежать две цели, которые влияют на продукт и которые являются основными для его развития:

1. лояльность и(или) активность пользователей;
2. деньги пользователей.

Эти цели плотно взаимосвязаны между собой — чем более удовлетворены ваши пользователи, тем вам легче продать им продукт или услугу и заработать денег. Решения принимаются исходя из ваших текущих целей и KPI (ключевых метрик), по которым оценивается то или иное направление деятельности продукта.

Для разных стадий они разные: кто-то еще только наращивает пользовательскую базу, кто-то уже начинает монетизацию проекта, кто-то растет по прибыли и готовится к ежегодному отчету перед советом директоров. Но очень часто в голову продукт-менеджеров или членов команды приходят идеи, которые кажутся “очень крутыми и которые нужно скорее запилить”. Важно не попадаться в эту ловушку и для начала понять, действительно ли это так.

Можно следовать простому правилу и для более ясного понимания, соответствует ли фича текущим целям проекта, отвечаем на следующие вопросы:

• Новая фича принесет новых пользователей?
• Новая фича увеличит лояльность/активность текущих пользователей?
• Новая фича увеличит средний чек от текущих пользователей?

Ответы на эти три вопроса дадут вам понимание о том, насколько новая фича поможет в достижении поставленных перед вами и продуктом целях на конкретном этапе жизни вашего продукта.

Откуда брать идеи для фич? Вопрос простой и сложный одновременно. Есть два основных источника идей для расширения функционала продукта:

1. Голова продукт-менеджера, который преследует бизнес-цели.
2. Голова пользователя, который преследует свои цели.

Все, нет, АБСОЛЮТНО ВСЕ идеи в обязательном порядке должны записываться вами либо в таск-менеджере, либо в каком-то еще документе, разделяя их на идеи, которые идут от вас или команды и на идеи, которые идут от пользователей. И умение продукт-менеджера в том, чтобы балансировать между этими двумя целями и находить между ними золотую середину. И если с первым источником идей понятно, то со вторым есть несколько вариантов откуда их брать.

Ниже в тексте вы найдете упоминание такой онлайн-метрики как NPS, обозначающую уровень удовлетворенности пользователями вашим продуктом. Одновременно с ее замером вы также можете использовать простейшую форму-запрос “Что бы вы хотели, чтобы мы улучшили?”, позволяющую пользователям рассказать вам о том, что им кажется недоработанным в функционале вашего продукта.

По идеям от пользователей полезно вести учет не только самих идей, но и количество совпадений идей, когда разные пользователи говорят о необходимости одной и той же функции. Логично, что чем больше запросов на одну и ту же функцию от разных людей, то тем выше должен подниматься ее приоритет в общем списке тасков и дорожной карте.

Поделюсь еще одной мыслью, которую можно использовать при определении необходимости разработки той или иной функции, кажущейся вам крайне полезной и необходимой, а именно:

по-настоящему  хорошая идея должна отстояться

Достаточно развернуто сформулировать идею фичи в отдельной стори или документе, описав детально как она будет работать в продукте, и просто подождать… неделю, дав голове остынуть от эмоций, которые вы испытывали от внезапно озарившего вас “просветления”.

Эмоции часто берут верх над разумом, а недельная пауза позволит вам не только еще раз собраться с мыслями по поводу того, как эта функция может работать, но и вообще переосмыслить целесообразность ее реализации, которая по прошествии семи дней будет казаться вам уже не такой яркой, а на самом деле, не столь значимой и необходимой, как казалось во время “озарения”.

Идем далее. Поделюсь с вами еще одной практической фишкой, которая выручала меня много раз и которую я называю “Разработать с учётом...”  —  фразой, которую, на мой взгляд, должен использовать каждый продукт-менеджер в постановке задач для тимлида или команды разработки на новые фичи в продукте.

Работает она просто . Если вы ставите задачу на разработку новой фичи и вы, как менеджер, понимаете, что она по механике связана с другими будущими фичами в продукте, не поленитесь лишний раз обратить внимание коллег из разработки на это. Тем самым вы снизите вероятность того, что они запилят что-то новое, которое будет плохо работать или будет сложносовместимо с будущими разработками по пересекающимся функциям.

Объясню на примере. Допустим, ваш продукт дает пользователям доступ к базе данных какой-либо информации. Доступ к этой базе пользователь получает после выполнения определенного вами действия внутри продукта (лида), например, заполнения специального брифа. Пользователи жалуются, что у них нет возможности “пощупать” базу перед тем, как выполнять это действие и они не хотят тратить свое время на заполнение брифа до этого момента.

Вы, как “добренький PM”, решили пойти им навстречу и дать ограниченный доступ к первым 10 объектам из этой базы данных, чтобы пользователи могли посмотреть её примеры. Само собой, это надо пилить, а значит, надо формулировать стори и ставить задачи команде разработки.

Но вы знаете, что через пару недель в разработку уйдет уже другой спринт с платной подпиской на доступ к этой самой базе данных без обязательного заполнения пользователями брифа. Именно поэтому при постановке задачи на ограниченный доступ к первым 10 объектам было бы не лишним написать и обозначить разработчикам, что эту фичу нужно “Разработать с учетом” того, что через НН недель будет еще одна фича, связанная с платным доступом и которая по механике и коду будет затрагивать эту же область.

Зачем это делать? Вам повезло, если вы работаете с разработчиками, которые смотрят наперед и умеют кодить не только шаг за шагом, но и с расчетом на будущее. Если вам не повезло, то в обязательном порядке нужно обозначать, в каком формате будет работать та или иная функция и какие ее могут ждать изменения в будущем. Иначе костыли и велосипеды станут средствами передвижения для вашей команды и продукта. Не стесняйтесь рассказывать и делиться вашими планами на продукт и его функционал с тем, кто его пилит.

Юнит-экономика продуктов

Предлагаю поговорить о более сложных вещах, столкнувшись с которыми умирает и закрывается около 80% всех проектов. Итак, содержимое и функционирование любого продукта это пользователи и активности, которые они совершают внутри него. Для этого процесса есть вполне научных термин, который звучит как "юнит-экономика". Это совокупный процесс, состоящий из аналитики продукта и принимающихся на ее основе решений, который определяет, в каком из направлений или функций продукта есть больший (или меньший) финансовый смысл и выгода.

Юнит-экономика является важнейшим и единственным правильным способом оценки работы бизнеса. Один мой хороший знакомый спросил меня, в чем разница между этим термином и простой бухгалтерией, на что я ответил, что бухгалтер Татьяна Николаевна не сможет дать вам ответа на вопрос, связанный с тем, какая категория пользователей внутри продукта приносит больше денег, насколько чаще делают покупки повторные клиенты и за какие именно услуги. Поэтому юнит-экономика это скорее про цифры и статистику внутри продукта, причем часть из них совершенно не связана с деньгами.

Как и для маркетинговых активностей, для каждого типа активности пользователей есть собственные метрики, который продукт-менеджеры в обязательном порядке должны использовать для оценки эффективности работы продукта как бизнеса. Благодаря контролю этих метрик вы сможете держать на виду практически все, что происходит с продуктом и оценивать верность выбранного вами курса развития. Предлагаю выделить наиболее ключевые из них.

ARPU (Average Revenue Per User) - средняя выручка с пользователя. Обратите внимание, в расчёт берётся вся аудитория: и платящие, и неплатящие пользователи.

ARPU = (Ежемесячные доходы / пользователей)

Таким образом, ARPU – это показатель монетизационной эффективности проекта: чем он выше, тем больше дохода (не прибыли) приносит в среднем 1 пользователь.

ARPPU (Average Revenue Per Paying User) - показывает средний доход с одного платящего пользователя за месяц. Считается по простой формуле:

ARPPU = ежемесячный доход со пользователей / число платящих пользователей

Более строгая и четкая метрика, показывающая общий уровень доходности и продаж в разрезе платящих пользователей.

ALC (Average Lifetime of a Customer) — средняя продолжительность работы пользователя с вашим продуктом. Высчитывается по формуле:

ALC = 1 / churn rate.

Чем показатель выше, тем лучше для продукта.

CAC (Customer Acquisition Cost) - писали о нем ранее, это рекламная метрика, показывающая стоимость платного привлечения клиента (платящего пользователя). Для использования в подсчетах юнит-экономики, считается по формуле:

CAC = (бюджет на рекламу / количество привлеченных с нее платящих клиентов).

Если CAC будет равен 33% от пожизненной ценности вашего клиента, то это уже можно считать успехом.

COGS (Cost of goods sold) - ежемесячные переменные издержки на работу вашего продукта. То, без чего не может существовать ни одни продукт.

COGS = (хостинг + зарплата команды поддержки или аккаунтинга + всякие облачные решения типа почты/gitlab) / число платных клиентов

Важный момент в том, что подсчет COGS нужно включать только те расходы, без которых работа продукта была бы невозможной (т.е. не включая рекламные бюджеты, зарплату маркетологов и разработчиков и т.п. расходы).

LTV (Life time value) считается на основе ARPU. Это доход, который в среднем приносит один пользователь за настоящее или будущее время пользования нашим продуктом.

LTV = ARPU x ALC

AC (Average Check) или средний чек. Считается по формуле:

AC = ежемесячная выручка / транзакции

Есть и дополнительные метрики, которые участвуют в подсчете базовых и которые также могут сигнализировать вам об "изменении климата" внутри продукта, предупреждая вас об этом гораздо раньше, чем вы увидите это в деньгах.

CR (Churn Rate) - коэффициент "текучести" пользователей, который означает процент потери продуктом платящих за него клиентов. Считается по формуле

CR = (количество переставших платить / платящих пользователей).

Например, если из каждых 1000 ежемесячно платящих пользователей с каждым месяцем уходит 130, то месячный Churn rate для такого продукта составит 130/1000 = 0,13 или 13%. Чем показатель выше, тем хуже для продукта.

50% пользователей самых крупных фуд-стартапов США (Blue Apron и HelloFresh) отваливаются в первые два месяца пользования. Для инфы: в США очень развиты welcome-акции и приветственные купоны со скидками, поэтому за первый месяц пользователь обычно платит всего 20-40% от стоимости (в среднем это $60-$75 за 5 наборов на 2-ух человек) кастомизируемой подписки. Плюсуйте еще маркетинговый CAC от $10 до $20. Итого на первый заказ имеем от $70 до $90 минуса на пользователя.

DAU (Daily Active Users) или MAU (Monthly Active Users) — количество уникальных пользователей, зашедших в продукт хотя бы раз в течение суток или месяца соответственно. Хорошая внутренняя метрика по которой можно считать вовлеченность аудитории в продукт.

Хотите раскрою небольшой секрет? Вам не надо заучивать эти метрики так, чтобы они отлетали у вас от зубов. При работе над юнит-экономикой важно понять, ЧТО ИМЕННО выражает та или иная метрика и как эту цифру можно использовать для оценки эффективности конкретно вашего продукта.

Каким образом считать? Можно по-старинке в Excel, но минус этого способа будет в том, что вы сможете видеть статистику только за те периоды, когда будете руками вносить ее в табличку. Можно запилить простейший dashbord в админке вашего продукта и отслеживать статистику в разрезе каждого дня, что, конечно же, в разы эффективнее и позволит вам следить за аналитикой под большим увеличением.

Советы по продакт-менеджменту

В этом разделе я попробую собрать советы, которые не подходят под какую-то определенное направление деятельности продукта и связаны скорее с продукт-менеджером как специалистом, который с ним работает и от эффективной работы которого зависит функционирование всего проекта в целом.

Как говорилось ранее, работа продукт-менеджера состоит из сбора, систематизации и анализа поступающей информации. Это означает, что постоянное выстраивание и оптимизация процессов должна быть не только внутри продукта, но и внутри процессов работы самого продукт-менеджера. Когда вы знаете, что и как делать, вы не дергаете по каждой мелочи ваших сотрудников, а на полуавтомате совершаете действия, процесс которых выверен вами.

10 НЕ профессионального продакт-менеджера (источник: телеграм-канал @ruspm)

Общайся с пользователями раньше запуска своего продукта. Они расскажут тебе то, что им надо, а не то, что ты себе напридумывал.

Начинай маркетинг сразу же после MVP. Лучше - до запуска. Нет трафика - нет пользователей - нет продукта. Кому ты тогда нужен?

Отбрось A/B-тестирования. У тебя еще нет денег и юзеров - какие изменения ты собрался отслеживать?

Забей на дизайн. Выбирать наряды и одеваться дорого можно тогда, когда ты можешь себе это позволить.

Забей на юнит-тесты. Тут два варианта - либо у тебя будет запущенный и проверенный на жизнеспособность продукт с багами, либо никому не нужный программный код, покрытый тестами. Выбор за тобой.

Забей на личную жизнь. Продакт-менеджер стартапа работает 24/7 с редким перерывом на сон и кофе. Всё остальное неважно до тех пор, пока продукт не выйдет в плюс.

Не размывайте цели юзера. Он пришел к вам решить свою проблему, не придумывайте за него новых и не предлагайте их решения, пока он не останется удовлетворен решением начальной.

Не громоздите информацию. Информация ключевая для конкретного экрана/сценария пользователя и влияет более чем на 50% на принятие решения? Если да - показывайте ее. Если нет - информация не важна и ее можно скрыть за таб/кнопку/ссылку. Упрощайте всё до невозможности, люди устали и перенасыщены информацией.

Не уведомляйте экшенами о неважных событиях. Имею ввиду пуши/письма/смс и прочие агрессивные уведомления. Внимание и время юзера - самый ценный ресурс как для него, так и для вас. И в большинстве случаев, руководствуйтесь простым правилом - событие требует ответного действия юзера? Если нет, то, скорее всего, вам нем нет смысла уведомлять его об этом столь настойчивым способом. Далее вытекает следующее НЕ.

Не бомбите юзера по всем каналам связи. Вместо того, чтобы отсылать ему пуш, веб-уведомление, письмо, инапп, попробуйте определить канал, наиболее подходящий для юзера и работайте только с ним. В противном случае, угробите каждый из них, поэтому  использовать все каналы сразу стоит только в крайне редких случаях.

Не смешивайте юзеров. Даже в рамках одного продукта пользователи и их механики работы с ним могут различаться. Старайтесь анализировать их и разносить по разным типам - это влияет как на маркетинговые активности, так и на продукт в целом.

Не скрывайте контент/продукт за регистрацию. Самая бесячая всех пользователей штука, которая сразу ставит жирный минус в его начальное восприятие юзером. И вместо того, чтобы провести онбординг по живому контенту, мы сначала скрываем его за логин, потом проводим виртуальный тур по виртуальному продукту и только потом показываем реальный контент.

Зачем мы это делаем? Хер знает. Гораздо проще показать весь контент/продукт сразу с первого входа, начав  самостятельное обучение юзера на живом и реальном примере, тем самым вовлечь его и только когда он захочет начать работу с живым  контентом/продуктом, попросить пройти авторизацию. Всё же просто!

Не прячьте цены там, где можно их показать. Очень стремная привычка, особенно в b2b-продуктах. "Оставьте заявку и мы вам все посчитаем". Что считать-то? Так и скажите, что тупо оцените мою компанию по обороту/известности и выкатите под них свой прайс с соответствующей наценкой. Когда вижу такие развода сразу закрываю сайт. Хотите масштабировать прайс под клиента - сделайте публичный калькулятор на сайте.

Не думайте, что ваши "рекомендации" кому-то нужны. Тем более, когда вы не понимаете, как они должны работают. Стоит тебе купить вещь в любом интернет-магазине, как начинают приходить тонны спама о распродажах и уникальных скидках на коллекции.

Хотите чтобы юзер вернулся? Дайте мне купон на скидку = вашему CAC, я сам сохраню его и вернусь к вам когда сам решу.

Особенно меня улыбают еженедельные рекомендации туров/квартир/отелей, приходящие на почту каждую неделю. "Не хотите слетать в Вену за $200?" Конечно хочу, щас только кроксы с работы заберу и полетели! Неужели так сложно спросить когда у меня планируется следующий отпуск и подогнать самые сочные предложения именно под эти даты?

Не обманывайте юзера. "Сегодня купили 30 раз", "Остался 1 номер", "Смотрят 100 человек" (привет, Букинг). Да, психологические тригеры это ок, если это действительно так. Если эти данные берутся из воздуха или преувеличены для затравки юзера - вам точно заготовлено место в аду.

Не закрывайте глаза и уши на фидбек. Предугадывать желания юзеров тем более невозможно, не слыша и не воспринимая то, о чем они говорят открыто.

Как правильно ставить и реализовывать любые таски?

Разработка конкретной продуктовой функции практически на 100% связана с механикой, которая описывалась в самом начале этой книги и любая фича должна пройти свой путь от идеи до функции на сайте.

Приучите себя разбивать любой процесс на подпроцессы – это поможет вам быстрее подходить к выполнению любой задачи и трекать ее прогресс.

1. Формулировка пользовательской проблемы, которую решает фича.
2. Формулировка идеи, с помощью которой можно решить проблему.
3. Формулировка метрик для оценки результативности.
4. Интерфейсная реализация идеи.
5. Техническое формулирование и разработка.
6. Реализация функции на сайте.
7. Сбор статистики и съем метрик.

Благодаря этому простому и пошаговому механизму вы сможете раз за разом пройти весь процесс анализа проблемы и способа, который вы хотите использовать для ее решения.

И я не устану повторять, что главная проблема множества проектов – обилие фич, которые размывают ключевые задачи продукта, усложняют его интерфейс и подкидывают проблем ребятам из отдела тех. разработки, которым с каждой новой фичей приходится продумывать то, как она должна работать с остальным функционалом.

Какой таск-менеджер для it-команды лучше всего?

Конечно, это Notion. Простейший интерфейс и гибкий функционал, позволяющий сделать из нее даже CRM-систему для отдела продаж (используем на одном из проектов), убивает все имеющиеся на рынке аналоги, чтобы там про них не говорили их маркетологи.

Полезная статья: "Notion: полная организация работы компании и продукта с шаблонами"

Но есть важное уточнение. Notion хороша легкостью и быстротой отклика своего интерфейса, что отлично подходит для менеджеров, маркетологов и других сотрудников, главная задача которых состоит в том, чтобы быстро записать задачу и не менее быстро ее выполнить. Но мы пробовали внедрить ее в процессы технической разработки и у нас не получилось связать ее таски и конкретные бранчи из того же Gitlab, что так любят делать программисты, держа под контролем одновременно и описание задачи и ее реализацию в коде.

В какое время продуктивнее всего работать?

Не знаю как у других, но мой график работы никогда не был нормированным в формате “с __ до __”. Как говорилось ранее, работа продукт-менеджера связана с множеством направлений, которые связаны с еще большим множеством специфичных вещей, размазанных по времени.

По себе давно заметил, что первая половина рабочего дня (до 12:00 AM) — самая продуктивная в плане мыслительно-аналитического процесса. Именно поэтому я стараюсь не читать почту/газет/новостей/соц. сетей до 12:00, а всецело отдаюсь кружке крепкого чая и обдумыванию текущих проектных тасков “на подумать”.

Почему получается более продуктивно? Не знаю — наверное, мозг еще не засорен лишним информационным шумом, ненужными фактами, что позволяет направить мыслительный процесс строго в нужном направлении. Попробуйте просто изолировать свой мозг от чтения новостей в метро или бессмысленной проверки новостей на ФБ и сосредоточьтесь именно на задачах — увидите как сложные задачи перестану быть таковыми :)

Как не перегореть продукт-менеджеру?

Есть несколько способов избежать того, что называется «перегорел на работе», что очень часто встречается у продукт-менеджеров, которые сутками на пролет смотрят в монитор ноутбука, на котором меняются вкладки Slack, Asana, Gmail и интерфейса сайта, над которым они работают.

Во-первых, это умышленное ограничение себя от интернета и устройств, в которых он есть. Вы должны прервать поток цифровой информации, который идет в ваш мозг и дать ему возможность отдохнуть от цифр, проблем, user stories и всего того, что вам кажется важным, а вашему мозгу нужно хотя бы на время отключится от этого всего, чтобы дефрагментировать накопившиеся данные.

Полезная статья: "Ум, сознание, концентрация и потоки в работе продакт-менеджера"

Как бы банально это не звучало, но хорошо помогают активные увлечения, связанные с физическими нагрузками и свежим воздухом. Заставьте свой мозг переключиться на другой режим, разомните свои спины и дайте нагрузку на ноги и руки и вы заметите, как ваш организм скажет вам спасибо, а в мозгу появится много нового места для полезных идей.

Если нужно быстро отключиться от обилия информации и привести мозги в порядок, то достаточно сделать шаг в сторону с помощью ___запрещено к просмотру на территории РФ____. В сочетании с горячей ванной, эти штуки переводят ваше сознание в измененное состояние, научившись управлять которым вы сможете игнорировать некоторые вещи, на которые вы чересчур сильно обращали внимание будучи в трезвом состоянии (или не обращали на них внимание вообще).

Как и со всякими такими вещами, этими не стоит злоупотреблять и необходимо знать определенную меру. И да, не забудьте проконсультироваться с врачом или адвокатом перед применением данного совета.

Как не сжечь команду?

Не менее важным является и общий настрой и энергия команды, которая складывается из энергии каждого ее участника. Выбросьте в помойку все эти HR-тренинги и помните о том, что какие бы цели вы не ставили перед своей командой, они должны явно видеть, что:

1. Эти цели достигаются.
2. Эти цели приносят позитивный результат для продукта и пользователей.

Да, людей нужно благодарить (мне не нравится слово «хвалить», оно отдает детством), да в команде должны быть единомышленники и люди с общими убеждениями (но не обязательно интересами), но главное, ради чего работает команда и продукт в целом – решение конкретных задач. Покажите команды, что она успешно это делает и самооценка и самомотивация каждого из ее членов будет расти как на дрожжах без всяких лозунгов и транспорантов.

Как закрыть продукт? (взято с канала @ruspm)

Частая проблема, с которой сталкивается 90% всех проектов - "Продукт - говно”^ но почти все команды и овнеры таких продуктов не верят в это до последнего.

Как понять, принять это и главное, откуда взять силы и закрыть продукт? Попробуем разобраться.

Этап №1. Осознаем проблему или как доказать самому себе, что придуманный продукт говно и нахрен никому не сдался?

Начнем с самого простого. Для начала, попробуйте найти ответы на следующие вопросы (сверху вниз):

1. Достаточно ли пользователей из тех, кому мы показали рекламу, перешли по ней?

2. Достаточно ли пользователей из тех, кого мы привели на сайт, начали пользоваться продуктом?

3. Достаточно ли пользователей из тех, кто начал пользоваться продуктом продолжили им пользоваться?

4. Достаточно ли пользователей из тех, кто продолжают пользоваться продуктом совершили покупку?

5. Достаточно ли пользователей из тех, кто совершили покупку, совершают ее повторно?

Ответы на эти вопросы представляют из себя простейшую продуктовую воронку, где пользователь проходит каждый из этапов и на каждом из них сколько-то % отваливается и уходит.

Ваша задача как продакта - понять, критичен ли % отказов на каждом из этапов. Условно, если отваливается больше, чем 80% (грубая цифра) - стоит задуматься над тем, правильный ли продукт вы делаете.

Иные факторы: низкий спрос на проблему в поисковиках, узкая (мелкая) продуктовая ниша, низкий NPS и слабая обратная связь, низкий средний чек и низкое кол-во транзакций, низкие повторные продажи, длинный цикл сделки, много ручной работы вместо автоматизации процесса, размытые ответы при кастдеве, когда юзеры сами четко не могут сформулировать какую проблему они решают продуктом.

Всё это должно наводить вас на мысли о том, что вы давно занимаетесь не тем, чем можете.

Этап №2. Как принять тот факт, что ваш продукт не востребован, что его надо закрывать и как с этим жить дальше?

К сожалению, современные психология еще не запустила направление психиатрии для бизнесменов и стартаперов, поэтому придется выкручиваться самим (впрочем, как и всегда).

Собственно, примите те факты, что:

1) Да, вы потратили денег + месяцев или даже лет на то, что занимались "делом вашей жизни". Это правда и она никак не выходит из головы, когда начинаешь думать о "а может закрыть это всё уже… или не стоит, столько же сил/средств вбухали”.

2) Но переверните эту правду и зафиксируйте тот факт, что это было чрезвычайно полезно и интересно.

И, самое главное — за это время и за эти деньги этот продукт дал вам глубочайший опыт и экспертизу. Благодаря проделанной работе, вы и ваша команда научились многим вещам, которые не умели ранее. Вы выросли как специалист и как человек. Опыт - бесценен, но вы обрели его ценой вашего продукта. И это тоже правда, которая должна давать вам силы и уверенности в подобных решениях.

3) И есть еще одна правда. Если цифры говорят, что ваш продукт не востребован (по разным причинам:  недостаточность решения, слабый маркетинг/команда, молодой/неконтролируемый рынок), то всё это должно подводить вас и вашу команду к решению закрыть продукт.

Да, это больно и сложно. Но это нужно сделать, чтобы развиваться дальше.  И в этом нет ничего постыдного. Постыднее тянуть мертвую лошадь думая, что однажды она оживет и поскачет.

Не стоит сильно думать о том, что вы что-то потеряли - лучше думать о том, что вы пробрели и сможете использовать это в будущих продуктах.

Как эффективно созваниваться?

Работа продукт-менеджера связана с постоянными коммуникациями с членами команды, а, зачастую, и с внешним миром в лице пользователей. Обычно я заранее оговариваю продолжительность созвона, которая в идеальном случае никогда не должна превышать 30 минут.

Почему именно полчаса? Практическим путём я вывел, что за это время можно успеть обсудить практически любую, даже серьезную тему, а чёткие рамки разговора позволяют не отходить от повестки кола, сосредоточившись именно на ней, экономя тем самым ваши время и силы. Можете короче — супер!

Как проводить совещания?

Будь моя воля, я бы вообще их не проводил. Шучу конечно, но мое отношение к частым совещанием скептическое — 80% из них это пустая трата общего времени, которые участники могли бы потратить более эффективно, работая каждый над своим направлением. По собственному опыту скажу, что совещаться больше часа — непродуктивно, т.к уже на 40 минуте обсуждений у всех участников начинает закипать мозг. В совокупности с закрытым помещением и сниженной циркуляцией крови в теле в сидячем положении совещание начинает превращаться в палату для психических больных после приема успокоительных — бессмысленные блуждающие взгляды в поисках здравого смысла.

Но если вы чувствуете, что настало время обсудить какие-то вещи, где требуется “общий разум”, то в обязательном порядке готовьте повестку каждого совещания, строго следуйте ей, не уходя далеко в дебри «о, давайте обсудим заодно вот эту фичу». Обсуждать фичи можно очень долго, но длительность обсуждения без каких-то конкретных «якорей» и промежуточных результатов никак не связана с эффективностью ее реализации и применения.

Насчет «якорей». В обязательном порядке документируйте каждое решение по каждому пункту. Это позволит избежать путаницы в будущем когда всплывет вопрос: “кто/когда/почему это придумал/решил/заапрувил” вы всегда будете знать, каким образом и почему данное решение было принято.

Как искать “виноватых”?

Краеугольный камень множества команд. Чтобы там не говорили, но виноватые всегда есть. Главное запомнить простое правило:

цель поиска не в наказании виновного, а в понимании причин, которые к этому привели и указания внимания на эти причины для предотвращения их появления в будущем

Не нужно бичевать и громко обвинять других участников команды в их промахах, достаточно публично разобрать почему так случилось и как этого можно избежать в будущем. Совесть у виновного все равно есть и она скажет ему за вас слова “благодарности” своему хозяину.

Обратная связь и как с ней работать

Предлагаю рассмотреть одну из самых главных для всех продукт-менеджеров метрик — “Net Promoter Score (NPS)” или, по-русски, “Показателя лояльности клиентов”, которая позволяет вам узнать, насколько лояльны к вам и вашему продукту ваши клиенты и является удобным предлогом для сбора от них обратной связи. Этой метрикой пренебрегает множество проектов, но весьма внимательно относятся ТОПовые компании типа того же Uber или Microsoft.

Методология расчета Net Promoter Score основана на систематическом вопросе, который показывается всем пользователям продукта по прошествии какого-то времени его использования и их на ответе на единственный вопрос:

Насколько вероятно, что Вы порекомендуете нашу компанию/услугу/продукт другу или коллеге?

Пользователям предлагается разместить свой ответ на визуальной шкале от 0 до 10, где ответы клиентов классифицируются следующим образом:

• 0–6 = критики — неудовлетворенные клиенты, которые могут навредить вашему бренду, отзываясь о нем отрицательно;
• 7–8 = нейтралы — удовлетворенные, но равнодушные клиенты, которые могут изменить свои предпочтения в пользу конкурентов;
• 9–10 = промоутеры — лояльные клиенты, которые продолжат использовать ваш продукт и рекомендовать его другим.

Если говорить проще, то формула для расчета Net Promoter Score выглядит следующим образом:

NPS = (количество промоутеров — количество критиков) / (количество респондентов) X 100

Метрика помогает вам определиться с тем, как меняется настроение пользователей в зависимости от роста вашего продукта и его функционала и более ясно понимать совпадает ли ваше видение как продукт-менеджера с реальными потребностями ваших юзеров.

Помимо этого, я рекомендую использовать улучшенную метрику, которую мы однажды придумали с командой Эпик Клаба - LIVE NPS. В статье "Live NPS: что означает эта метрика и чем она лучше простого NPS" подробно раскрываются её реальные преимущества по сравнению с классической.

В качестве заключения

Эта книга, а вместе с ней и праздничные выходные, на которых я ее пишу, подходит к концу. Но это не значит, что подходит к концу ваш образовательный процесс. В качестве заключения я хотел бы поговорить об общих, но не менее важных и полезных вещах. Меня часто спрашивают, какими знаниями/навыками вообще должен обладать толковый продукт-менеджер и откуда их взять?

Сложный вопрос и не менее сложный путь, который необходимо пройти для того, чтобы найти на него ответ. Давайте попробуем подвести промежуточный итог этой книги и определится с тем, что же должен знать и уметь хороший продукт-менеджер в порядке значимости:

№ 1. Быть организатором. Не побоюсь этого слова, но продукт-менеджер это ключевой участник команды, который глобально организует весь механизм работы над продуктом от его создания до продажи пользователям. Поэтому, правильно выстроенный пошаговый процесс “от идеи до фичи”, в котором участвует более 1 человека, у него (и на каждом этапе: дизайн, разработка, маркетинг) должен работать как часы.

Логично, что вы должны иметь хотя бы базовое представление о том, как каждый из проходимых идеей этапов работает: развёрнутое формулирование идеи, обсуждение, принятие взвешенного решения, постановка продуманных задач, контроль и поддержка их исполнения, проверка предварительного и конченого результата, дальнейшее сопровождение — именно с этим работает продакт-менеджер (а не генерацией сотен космических идей, как считают некоторые).

Гуглите, читайте и изучайте все, что попадется под руку о: проект-менеджмент, product management, teamwork, командная работа, дедлайн, agile, scrum, UX, прототипирование, Asana, Jira, slack

№2. Быть исследователем и аналитиком. Мало делать смелые предположения, “чувствовать” пользователей, их потребности — нужно уметь их подтверждать цифрами статистики продукта для определения их важности и актуальности как ДО о этапа внедрения, так и ПОСЛЕ него для подтверждения и фиксации выполненных работ.

Мало регистраций/активностей/покупок? В 80% случаев причина продукте, его УТП, сайте, в конце концов, и только в 20% в “плохих/жадных/бедных пользователях”. Ваша задача как РМ заключается в том, чтобы своевременно анализировать это, и не менее своевременно устранять такие причины.

Делайте предположения, после чего пробуйте решение(я), снова снимайте статистику, ищите закономерности и сравнивайте и так пока не будете довольны результатом. “Через тернии к звёздам!”

Гуглить и изучать: интернет-аналитика, ROI, CAC, ARPU, воронка продаж, a/b-тестирования, конверсия, Google Analytics, Яндекс.Вебвизор, user feedback

№ 3. Быть продажником/бизнесменом. Зачем, спросите вы? Любой продажник ответит вам, что все в этом мире ради денег. Продукт-менеджер на этот вопрос ответит, что все ради любви (пользователей). Я же согласен с обоими. Можно петь много песен про любовь и пользователей, но я/вы/мы/наши продукты работаем ради денег. Думайте, что приносит или может приносить деньги, ПОЧЕМУ люди их платят и КАК и за счёт ЧЕГО вы и ваш продукт может помочь им расстаться с ними более непринуждённо.

Гуглить и изучать: психология покупателей, монетизация, ценообразование, юнит-экономика, родажи, средний чек, дополнительные продажи, SMM, Google Adwords, Яндекс.Директ, SEO, бренд, CTR, CPM, CPA.

№ 4. Обладать “чуйкой”. Назовём это врожденной интуицией на верные решения, но первое слово мне нравится больше. Кто ей обладает, понял о чем я. Кто нет — надеюсь, что у вас все впереди.Прислушивайтесь к внутреннему голосу, приучайтесь думать и делать выводы самостоятельно, наблюдать и анализировать. Ключ к успеху — в том, чтобы объединить интуицию и аналитику и от обеих брать лучшее.

Эти четыре столпа, на которых держится любой продукт/стартап/бизнес, называйте их как хотите, и если вы отвечаете за их развитие, то вы должны разбираться в таких вещах. Разберётесь в них — сможете накладывать эти знания практически на любом интернет-проект, с которым вам придётся работать как продукт-менеджеру.

И никогда не останавливайтесь на пути совершенствования себя и своих продуктов. Развивая себя, вы развиваете их, и наоборот!

Благодарю вас за ваше время и внимание. Всем роста и процветания!

Послесловие

Вам понравилась книга? Здорово, значит в России будет больше успешных и по-настоящему полезных продуктов, и, несмотря на то, будут ли они решать мелкие и большие проблемы, главное - они будут помогать людям.

Я не планирую остановится на достигнутом и, по наличию свободного времени, продолжу работу над расширенным изданием данного пособия. Если у вас есть какие-то вопросы, связанные с продукт-менеджментом и ответы на которые вы не можете найти, то вы можете прислать их мне на канал @ruspm и я постараюсь найти на них ответ.

Кстати, по поводу ответов. Я хочу попросить своих друзей и знакомых помочь мне в этом и пригласить их в качестве экспертов каждого в своей области именно для ответов на такие вопросы. Список всех экспертов будет вынесен в самом начале расширенного издания пособия с указанием компаний, где они работают, и ссылок на них. Поэтому, если у вас или ваших знакомых есть желание принять участие - welcome на @ruspm и давайте вместе делать отрасль российского product management лучше и эффективнее!

Возвращаясь к этой книге. Как вы могли заметить - она бесплатная. Как можно сказать спасибо ее автору?

Способ №1. Вы  также можете поделиться ссылкой на нее со своими друзьями и коллегами в социальных сетях.

Оставайтесь на связи. Полезные советы и интересные мысли также всегда доступны на телеграм-канале @ruspm.