Расчет юнит экономики в формулах. Юнит экономика

"Наконец-то понял, что такое unit-экономика!", воскликнул я сегодня сам себе. Не спешите закрывать статью, если вы уже знаете, что это. Я понял про unit-экономику для МОЕГО проекта, и, надеюсь, эта информация поможет и другим. Спасибо приятелю Коле, который зашел сегодня к нам в офис поболтать о жизни и натолкнул на эти мысли.

Итак, когда говорят о unit-экономике, то ставят такой вопрос: "Сколько вам стоит привлечение одного клиента?". Я несколько лет не мог на него ответить. И это меня очень смущало. Наша команда доросла до 12 человек, а ответить на такой простой и нужный вопрос я почему-то не мог.

Так вот, какая тут unit-экономика? Не известно! Сколько стоит один клиент? Не понятно! Можно конечно посчитать затраты на написание статьи, публикацию, привлечение аудитории… Мы это делаем и знаем, что одна статья нам стоит примерно 3-5 человеко-недель работы квалифицированного программиста. Но это же не ответ на вопрос: "Сколько стоит один клиент?".

Однако после сегодняшнего визита Коли мы с коллегой обсуждали в очередной раз этот вопрос. И поняли, что вопрос то неправильный! На самом деле вопрос должен звучать так: "Вот это направление, которым вы ребята занимаетесь, оно прибыльно или убыточно?" Именно на этот вопрос важно знать ответ. Но это не всегда получается, поэтому иногда вопрос формулируется как "сколько стоит привлечение клиента?" или "сколько денег приносит один клиент?". Давайте разберемся на примерах из нашего бизнеса.

Итак, основное наше направление – анализатор кода PVS-Studio. Убыточно оно или прибыльно? Как ответить на этот вопрос? Очень просто. Берем доходы за прошлый год. Берем расходы за прошлый год. Если разница нас устраивает, то направление прибыльно. Нам не важно знать, сколько стоит один клиент по PVS-Studio, если мы его привлекаем с помощью статей. Нам важно знать, что в целом направление прибыльное и мы все делаем правильно.

Другой пример. В составе PVS-Studio есть наиболее популярная версия для среды Microsoft Visual Studio и менее популярная версия для среды Embarcadero RAD Studio. Вопросов по Embarcadero RAD Studio в поддержке почти нет. Версия эта почти не продается. Расходы на ее поддержку и развитие больше, чем доходы. Поэтому поддержка Embarcadero RAD Studio в нашем инструменте как направление не выгодна. И недавно мы убили это направление. Неосознанно посчитав ту самую unit-экономику.

Еще пример. У нас есть более простая версия нашего продукта CppCat. Там другая ценовая и лицензионная политика. Персональная лицензия стоит $250 (сравните с €5000 за PVS-Studio). Мы посчитали сколько продукт принес за прошлый год, посчитали расходы. И приняли решение его убить в скором времени. Unit-экономика не сошлась. Почему же сразу его не убить? Потому что это стоит денег: переделка сайта, письма пользователям, вопросы текущих клиентов… Но убьем в ближайшее время.

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

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

Почему же тогда все спрашивают "сколько стоит клиент?" и "сколько денег приносит клиент?" особенно у начинающих команд? Очень просто. У них нет истории. И у них нет понятного им маркетинга. А для нас и маркетинг понятен (как привлекать пользователей) и история доходов/расходов за прошлый год понятна. Поэтому нам важно контролировать вопрос "прибыльно ли направление?", а не "сколько стоит/приносит клиент?".

А если команда 3 месяца только что-то делает и пусть даже имеет 10 продаж, то да, единственный вопрос, который ей можно задать – это "сколько стоит/приносит клиент?".

Генеральный директор

В закладки

Меня зовут Даниил Ханин, мне 37 лет. Я занимаюсь бизнесом в интернете с 1998 года, и моя последняя разработка - калькулятор для рассчёта юнит-экономики стартапов UE Calc .

Описание

UE Calc - простой сервис для быстрого поиска и проверки бизнес-модели на устойчивость. Для этого используется математический аппарат и теория ограничений Голдратта.

Интерфейс UE Calc

Как это работает

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

• ​ Ожидаемое количество посетителей сайта нашего проекта - UA (user acquisition).

• ​ Ожидаемая конверсия в первую оплату - С1.

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

• Средний чек, ожидаемая плата клиента сервису - Average price. ​
• Себестоимость товара - COGS (Cost of good sold).
• Дополнительная себестоимость первой продажи - 1sCOGS (First sale COGS).

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

• Ожидаемое среднее количество покупок от одного клиента - APC (Average payment count).

• Стоимость привлечения одного пользователя - CPA (Cost per acquisition).

Теперь введём ожидаемые значения в калькулятор.

Как видите, калькулятор автоматически посчитал Gross Profit («грязную» прибыль), и она получилась отрицательной. Оказалось, что наш бизнес убыточен. Давайте посмотрим, при каких метриках проект станет прибыльным: для этого воспользуемся анализатором (инструмент «А»).

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

Очевидно, что не все варианты приводят к целевому значению Gross Profit. Например, так как экономика изначально отрицательная, то изменение количества пользователей не может сделать ее положительной. Точно так же, меняя 1sCOGS до нуля, мы не получим положительную экономику, так как этот показатель уже равен нулю. Таким образом, у нас остается всего пять вариантов: изменение конверсии, среднего чека, себестоимости продажи, количества покупок на клиента и стоимости привлечения пользователя.

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

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

Теперь взглянем на самый первый вариант, изменение UA до семи с половиной миллионов посетителей. Этот вариант выглядит нереалистично, ведь он позволяет нам достичь требуемого значения Gross Profit лишь ценой столь сильного увеличения количества посетителей по сравнению с изначальным - 15 тысяч. Кроме того, оборот от работы с таким объемом посетителей окажется равен 274,4 миллионам, при этом Gross Profit составит всего-навсего 500 тысяч. Теперь проверим эффективность такой работы, для этого в расширенном меню выберем инструмент ROI.

Видим, что ROI нашей модели оказался больше 100% (экономика сходится), но при этом остается всё же крайне низким - 100,51%, кроме того, значение Gross profit margin имеет еще меньшее значение (0,18%). Таким образом, этот вариант нас также не устраивает. У нас остается только три варианта: изменение конверсии, среднего чека и числа сделок на одного клиента.

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

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

Написать

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

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

Что такое product-management? Кто такой продукт-менеджер и чем он должен заниматься? Как превратить идею в голове в осязаемый пользователями продукт? Как правильно планировать, запускать и развивать онлайн-проекты? Как считать юнит-экономику и как формировать команду? Ответы на эти и многие другие вопросы вы сможете найти в этой книге, посвященной продукт-менедженту.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Приучите себя правильно работать с информацией, фильтровать её, конспектировать и сохранять наиболее важные и кажущиеся вам значимыми и интересным вещи, мысли и идеи. Сделайте 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 это то, как работает или может работать продукт, а веб-дизайн – как он выглядит.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Сделали хороший продукт? Юзеры довольны? Настало время подумать о деньгах и выходе на самоокупаемость. Тут хорошо сработает более среднесрочная перспектива и 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) - средняя продолжительность работы пользователя с вашим продуктом. Высчитывается по формуле:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Юнит (unit)-экономика - это расчет прибыли или убытка в расчете на одного клиента. Благодаря такому расчету мы разбираемся: «Что вы продаете?», «С какой маржой?», «Сколько стоит привлечение клиентов?», «Компания на этой сделке зарабатывает или теряет?». Это главный инструмент в арсенале интернет-маркетологов. Данный расчет показывает: есть ли финансовый смысл в вашей компании, ее расширении и где находится точка безубыточности.
В доходах юнит-экономики учитывается выручка, полученная в среднем от одного пользователя. В расходах - переменные расходы, которые необходимы для выполнения заказа клиента. Далее из выручки вычитаются переменные расходы и получается прибыль.

Итак, детально рассмотрим показатели, по которым производится расчет unit-экономики.

• CAC (Customer аcquisition сost) или CPA (Cost per acquisition) - стоимость привлечения одного клиента, который платит компании деньги.
• CAC Payback - период времени, в течение которого прибыль от клиента начинает покрывать расходы на его привлечение.
• АРС - среднее количество покупок
• Revenue — доход, который мы получаем в когорте. Вычисляется по формуле:
  Revenue = UA x (ARPU — CPA — ARC) .
• ARPU (Average revenue per user) - средний доход с привлеченного пользователя. Рассчитывается по формуле: ARPU = ARPPU x C1
• ARPPU — доход с одного платящего клиента за время жизни когорты. Важно понимать, что это не доход от клиента за месяц, даже если мы собираем месячные когорты.
  ARPPU = (Av.Price — COGS) x APC — BRC x (APC-1) — 1sCOGS

где 1sCOGS это затраты на первую продажу, когда например, вы платите премию менеджеру с первой продажи 10%. Или например, вы дарите клиенту настройку и потом берете подписку, вот затраты на настройку это и есть 1sCOGS .

• Av.Price — средний чек в интернет-магазине. Приэтом, специально для интернет-магазина важно рассматривать эту величину как составную и вычисляемую по формуле: Av.Price = AGPrice x AGCount .
• AGPrice — средняя цена товара в интернет-магазине, который покупается клиентами
• AGCount — среднее число товаров в корзине интернет-магазине.
• COGS (Cost of goods sold) - переменные издержки.
• ARC — средние затраты на удержание клиента, вычисляется по формуле ARC = RC x C1 / Buyers = RC / UA, где UA — число привлеченных пользователей в когорте. RC — бюджет на удержание пользователей, ваши затраты на email маркетинг, персонализацию и тп.
• LTV (Life time value) - показатель, по которому видно, сколько дохода приносит один клиент за все время пользования нашим продуктом.

С помощью различных методик, в частности -с помощью unit-экономики наводим порядок в маркетинге.

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

Появились вопросы? Пишите в комментариях.
Также вы можете

© «Центр Деловых Инициатив», при полном или частичном копировании материала ссылка на первоисточник обязательна.