Продукт-менеджемент: от идеи до продукта (2019). UE Calc — калькулятор юнит-экономики стартапа Что такое юнит экономика

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

• Исключительные права: Миролюбов Владимир.
• Издание: №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 economics) термин сравнительно новый и набирающий популярность. Чтобы лучше разобраться с принципами юнит экономики и понять формулы, которые используются в расчетах, стоит начать с самого начала и ответить на вопрос, как развивались экономика стартапов.

Определение юнит экономики

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

Юнит экономика (unit economics ) – метод, экономического моделирования, используемый для определения прибыльности бизнес-модели, путем оценки прибыльности единицы товара или одного клиента. Как правило, применяется для оценки прибыльности бизнес-идеи стартапа. Бизнес может быть успешным только если отдельная единица товара или услуги будет прибыльной.

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

Истоки юнит экономики

Истоки юнит экономики лежат в микроэкономике и управленческом учете.

Бизнес должен приносить прибыль — это принцип предпринимательства. Одна из базовых формул микроэкономики — формула прибыли:

Прибыль = Маржинальная прибыль – Постоянные затраты.

В свою очередь,

Маржинальная прибыль = Выручка – Переменные затраты

Прибыль = Выручка – Переменные затраты – Постоянные затраты.

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

Эти три формулы дают понимание всем дальнейшим расчетам в юнит экономике.

Чтобы бизнес был прибыльным маржинальная прибыль должна быть выше постоянных затрат.

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

Маржинальная прибыль 1 товара = Цена(1) – Себестоимость(1)

Маржинальная прибыль = число проданных товаров х (цена (1) – себестоимость (1))

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

Economics of One Unit

Одновременно с началом активного роста IT-рынка (вспомним пузырь dot-комов) началась эра предпринимательства. С 1995 по 2010 число предпринимателей в США увеличилось более чем в 15 раз. Одновременно с ростом числа предпринимателей бурно стали развиваться учебные программы для них.

Прибыль (или убыток) от продажи 1 товар = цена(1) – себестоимость(1)

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

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

Расчет точки безубыточности достаточно простой.

Число продаж = постоянные затраты / Прибыль(1)

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

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

Фримиум бизнес-модель.

Следующим шагом развития идей юнит-экономики стала экономика фримиум проектов.

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

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

Базовой идеей оценки прибыльности проектов построенных на freemium модели стало соотнесение прибыли от привлеченного клиента за весь период использования продукта (LTV) и суммарных затрат на его привлечение.

Прибыль = доход с клиента – расходы на привлечение.

Известная картинка с весами прибыльности и затрат была опубликована в 2009 году.

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

LTV — Пожизненная ценность клиента. – life-time value (LTV). Это прибыль, которую средний пользователь приносит проекту за все время, пока является покупателем.

CAC – Средние затраты на привлечение пользователя.

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

1. Трекшн-карта - фокусируемся на действиях, которые ведут к цели

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

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

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

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

2. HADI-циклы - ускоряем темп команды

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

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

Hypothesis, Action, Data, Insights - Гипотеза, Действия для ее реализации, Данные или измерение, Выводы . На основе выводов завершенного HADI-цикла гипотеза корректируется (либо выдвигается новая), и начинается следующий виток цикла. Неделя - оптимальный срок для коротких итераций: за неделю каждая команда быстро проверяет несколько гипотез и определяет, какие из них работают, а какие нужно отбросить и не тратить ресурсы. Пример удачного HADI-цикла и подтвержденной гипотезы от команды из 6-го Акселератора "Турбодилер":

За три месяца команда протестировала 50 (!) гипотез и заслуженно считается одной из самых быстрых команд за все наборы. Итогом стал рост месячной выручки почти в 9 раз относительно начального уровня. Именно HADI-циклы помогают быстрее продвигаться по трекшн-карте к масштабированию, это подтверждает и история "Турбодилера". Как использовать HADI-циклы, выпускник заочного Акселератора Carrot Quest. Выпускник 4-го Акселератора, основатель сервиса Wikium вот называет HADI-циклы о сновной причиной роста выручки в 8 раз.

3. Customer Development - разговаривайте с клиентами

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

В Акселераторе мы отчаянно боремся с “галлюцинациями” основателей (это когда вы делаете продукт, основываясь на своих собственных представлениях). И всеми силами “заставляем” стартапы пойти и поговорить со своими клиентами. Основной способ выявлять потребности пользователя - это проблемные и решенческие интервью. О правилах проведения проблемного интервью не так давно писали наши друзья из #tceh, а сама методология, основные принципы CustDev’а и готовые скрипты интервью для b2b и b2c-продуктов есть . Главное, что нужно запомнить: цель проблемных интервью - не продавать продукт (пара продаж “на харизме” фаундера погоды бизнесу не сделают), а задавать правильные вопросы и слушать, на что жалуется клиент. Основатели часто сразу начинают говорить о решении проблемы, когда клиент ещё не осознал, о какой его боли идёт речь.

Небольшая подсказка, как правильно задавать вопросы, из методички ФРИИ:

FYI: без проведения Customer Development мы категорически не рекомендуем использовать какой-либо из перечисленных инструментов.

4. Фокус на клиентском сегменте, который принесет максимум дохода в кратчайшие сроки

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

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

В Акселераторе у команды есть три месяца, чтобы максимально вырасти, и решение всегда одно - фокусировка на одном клиентском сегменте. Клиентский сегмент - это не только социально-демографические (“женщины 20-40 лет” для b2c) или размерные (“большие компании от 1000 сотрудников” для b2b) характеристики клиентов, но и ключевой дифференциатор, и типичный многоразовый кейс использования продукта.

По каким критериям выбирается сегмент:

• вы поняли, что есть острая “боль” клиента в этом сегменте - и это подтверждено во время проблемного интервью;
• клиент готов платить за решение проблемы больше, чем клиенты из других сегментов - это подтверждено первыми продажами/предзаказами;
• у команды уже есть готовый продукт под этот клиентский сегмент, либо по нему требуются косметические доработки;
• вы понимаете, из каких каналов вы сможете взять, скажем, 50 клиентов (если вы b2b) или первые 100 000 пользователей (в массовом b2c);
• у вас есть экспертиза в понимании, как решить проблему клиента, и экспертиза по основным каналам привлечения (либо уже есть выходы на ЛПР, если это сложный b2b-продукт).

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

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

5. SPACE-модель - вы отгружаете готовый продукт, либо разрабатываете сложное решение

Для понимания, на каком рынке и по каким правилам вы продаёте, мы раскладываем бизнес-модель стартапа в S.P.A.C.E.-модели (Supplier - вы как поставщик продукта, Product - ваш продукт, Average Revenue Per User - средний чек, Customer - количество потенциальных клиентов, Evaluation - принятие решения о покупке). Основа выглядит так:

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

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

Если ваш стартап не попадает на одну “орбиту” модели, значит есть потенциальная угроза: компания при масштабировании может стать неуправляемой - либо возникнет проблема с долгой обработкой одного заказа на массовом рынке, либо сегмент окажется слишком узким, а средний чек - низким. Тогда лучше заранее определить правила игры и скорректировать стратегию. Инструмент также помогает определить статистически значимое количество продаж для вашего продукта, чтобы переходить ко следующему этапу развития бизнеса, об этом мы писали , а Павел Черкашин - . А вот еще пример использования SPACE-модели. Инструмент был разработан экспертами RIS Ventures, и в их числе - нынешним маркетологом Акселератора.

6. Формула расчета юнит-экономики - определяем ключевую метрику

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

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

К этой формуле стоит добавить еще одну: ARPU = ARPPU x C1

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

7. Теория ограничений Голдратта - поиск узких мест как точек для кратного роста

Вы, наверное, уже устали слушать, как важно фокусироваться, чтобы прийти к цели. Чаще команд волнует другой вопрос: как выбрать те волшебные 20% усилий , которые дадут 80% результата ? Кроме трекшн-карты в Акселераторе мы используем для этого Теорию ограничений Элияху Голдратта. В основе этой теории - поиск и управление ключевым ограничением системы, которое предопределяет успех и эффективность всей системы в целом. Задача руководителя - выявлять это ограничение и управлять им для увеличения скорости генерации прибыли. ТОС описана в книге “Цель” Элияху Голдратта на примере реального производственного бизнеса, но ее можно использовать и в стартапах, и в проектном бизнесе.

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

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

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

Реальный кейс на эту тему: у команды 5-го Акселератора Timeviewer (системы учета рабочего времени) на входе была классическая воронка продаж:

Обращение клиента - отправили КП - согласовали КП - выставили счет - оплата - отгрузка.

В Акселераторе команда “расшила” свою воронку с помощью Ильи Красинского, посчитав конверсию на каждом этапе: клиенты застревали на стадии согласования КП, 94% клиентов отваливалось. Соответственно, конверсия в переход на следующий этап составляла всего 6%. Кроме того, клиенты долго принимали решение - средний срок сделки составлял 1,5-2 мес. Команда провела Customer development, выяснила, что ценностное предложение не цепляет клиентов и доработала его на основе обратной связи от них. В результате средний цикл сделки сократился до 1 месяца (включая период тестирования), а конверсия в переход к этапу “выставили счет” выросла до 44%. "Узкое место" удалось расширить. Кроме того, в результате CustDev’a выяснилось, что менеджеры по продажам в компании были без ИТ-бэкграунда и не могли ответить на технические вопросы клиентов на всех этапах воронки. Это была еще одна причина столь плохой конверсии. Чтобы исправить ситуацию, в компанию наняли новых менеджеров по продажам.

В результате после акселерации суммарная выручка компании выросла с 300-400 тысяч рублей до 5,5 млн рублей, заработанных за последние полтора месяца Акселератора. Плюс еще 1,7 миллиона дошли до компании месяц спустя.

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

____________________________________________________

Материал подготовлен командой Акселератора ФРИИ.

Акселератор ФРИИ - это программа ускоренного развития бизнеса с возможностью получения инвестиций для интернет-компаний от стадии готового продукта до стадии месячной выручки около 5 млн руб. С 2013 года в программе уже поучаствовало более 170 команд, с компаниями работают более 160 экспертов.

UPD Прием заявок в 8-ой Акселератор окончен, но уже можно подать заявку в следующий набор. Теперь каждый проект получает skype-консультацию эксперта ФРИИ, который даст развернутую обратную связь и объяснит, что нужно доработать, чтобы повысить шансы пройти отбор. Ближе к дедлайну по набору вы сможете обновить заявку.

Интернет-предприниматель, с 1998 года. Специализируюсь на запуске проектов, в области электронной-коммерции, рекламы, big-data.

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

Эксперт ВШЭ, ФРИИ, часто выступаю экспертом на различных start-up мероприятиях России.

Лекция по экономике

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

В рамках сотрудничества с ФРИИ, ВШЭ, Нетологией и GenS, я прочитал более 100 лекций для различных инкубаторов и акселераторов России, Белоруссии и Черногории, в Москве, Санкт-Петербурге, Новосибирске, Екатеринбурге, Челябинске, Нижнем Новгороде, Воронеже, Ростове-на-Дону, Краснодаре, Томске, Перми, Калининграде, Улан-Удэ, Кирове, Петрозаводске, Владивостоке, Красноярске, Минске, Тивате (Черногория). А так же читал эту лекцию для корпроративных программ в МТС, Билайн, Сбербанк, Газпром Digital, КРОК, iiko и д.р.

Резюме

2017-н.в.	ueCalc	Калькулятор юнит-экономики. CEO, founder
2014-н.в.	Rentmania	Площадка по аренде вещей. ментор, инвестор
2013-2018	МеХа	группа компаний, созданная на основе агентства Вебреклама и студии Avaj, первое в регионе полноцикловое digital агентство. учредитель, инвестор.
2012-2014	Crossss	сервис персонализации интернет-сайтов. Комплексные решения по персонализации интернет-магазинов: товарные рекомендации, онлайн-мерчендайзинг, адаптивный контент, персонализация и триггеризации email-маркетинга. CEO, co-founder
2005-2013	Вебреклама	первое и крупнейшее интерент-рекламное агентство Томской области, создание рынка интернет-рекламы в регионе. Создание всех технологий интернет-рекламы в городе с нуля. CEO, founder, инвестор
1998-2005	Freelance	разработка баннеров для разных заказчиков

Проекты

Краткий список проектов, к которым я имею отношение.

• Калькулятор юнит-экономики ueCalc , быстрый способ проверки своей бизнес модели, поиска узких мест.
• Симулятор Startup"а , простой симулятор стартапа, построй бизнес с нуля до IPO
• Крупнейшая онлайн-площадка аренды Rentmania
• Smart cross-seling SaaS for ecommerce Crossss
• Рекламное агентство

В закладки

Меня зовут Даниил Ханин, мне 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 на бесплатное пользование калькулятором в течение всего периода бета-тестирования.

Написать