Юнит-экономика

Дел у менеджеров по продукту всегда больше, чем ресурсов. Новые задачи приходят со всех сторон от дизайнеров до маркетологов и CEO. Но если брать в работу все подряд, есть риск получить на выходе не то, что нужно для развития проекта, а то, что было по фану кому-то из коллег. Так, сооснователь KISSmetrics Хитен Ша признался, что его компания потеряла позиции на рынке именно из-за ошибок приоритизации. Как только у него появлялись новые идеи, подчиненные должны были бросить все и начать работу над ними. О вдумчивом распределении сил речь тогда не шла. Пока команда пыталась успеть за руководителем, конкуренты захватывали рынок и выпускали новые продукты.

Расскажем, как не допустить такого развития событий с помощью простых методик для приоритизации гипотез. Вообще говоря, эту тему часто поднимают на профильных конференциях и семинарах. Так, Мэтт Билотти, менеджер продукта в Drift, интерактивной маркетинговой платформы, которая заняла шестое место в рейтинге самых быстрорастущих компаний по версии Deloitte, поделился на Epic Growth SEASONS своим взглядом на то, как можно приоритизировать гипотезы на основе юнит-экономики. Он объяснил, в чем преимущества подхода и как его можно использовать в работе.

Источник: unsplash.com

Метод оценки задач ICE и его соседи

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

Такой метод оценки называется ICE влияние (Impact), уверенность (Confidence), усилия (Effort). Он был придуман Шоном Эллисом, автором термина Growth Hacking. Преимущество подхода в его простоте: чтобы оценить задачу, достаточно присвоить значения от одного до десяти для каждого из факторов и вычислить ICE Score:

ICE Score = Impact*Confidence*Effort.

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

В отличие от него, так называемый RICE охват (Reach), влияние (Impact), уверенность в оценке (Confidence), трудозатраты (Effort) более сбалансирован.

RICE Score = (Reach*Impact*Confidence) / Effort.

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

• 3 массовое влияние;

• 2 высокое;

• 1 среднее;

• 0,5 низкое;

• 0,25 минимальное.

Оценка фактора уверенности всегда вызывает много вопросов. Если остальные показатели можно оценить достаточно точно, то как оценить уверенность? И как снизить субъективное влияние в процессе утверждения приоритетов? Можно использовать диаграмму Итамара Гилада, бывшего продакта в Google и Microsoft. На ней можно увидеть описание типичных фактов, на основе которых обычно рассчитывают значения параметра Confidence (личное мнение, экспертная оценка, идея коллеги, фича конкурента, результаты UX исследований, данные на основе интервью и др.). Предположим, ваша уверенность в успехе фичи основана на мнении кого-то из членов команды или личном мнении. Оценка этого фактора в таком случае будет около нуля.

Гипотезы, основанные на данных маркетинговых исследований, запросах пользователей, результатах юзабилити тестов получат низкий уровень уверенности (от 1 до 3). Если же вы, расставляя приоритеты задачам, делаете выводы на основе длительных исследований поведения пользователей, результатов запуска MVP, A/B-тестов и других достоверных данных, уровень уверенности может быть средним (от 3 до 7).

Источник: unsplash.com

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

• D delight;

• H hard to copy;

• M margin.

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

Источник: unsplash.com

В блоге Ducalis.io мы нашли классную схему, в которой можно выбрать фреймворк для приоритизации исходя из запросов конкретно вашей команды. Помимо уже известных ICE, RICE, DHM, есть и другие подходы: REAN метод (Reach, Engage, Activate, Nurture), приоритизация на основе North Star метрики, матрица усилий (Effort Matrix), AARRR скоринг и др.

Альтернативный подход

Если возвращаться к команде Drift, то Мэтт Билотти говорит, что отказ от ICE стал возможным благодаря поиску альтернатив. В этом ему помог Дариус Контрактор, который в течение четырех лет развивал Dropbox, руководил отделом роста в Facebook Messenger, а теперь работает Head of Growth в Airtable. Он рассказал Мэтту про подход EVELYN.

Шаблон EVELYN bit.ly/evelyn-airtable

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

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

UA число привлеченных пользователей

Marketing costs затраты на маркетинг

C1 конверсия в первую покупку

Buyers количество покупателей

AvP средний чек

ARPC средний доход на клиента (без учета маркетинговых затрат)

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

ARPPU доход с платящего пользователя за вычетом издержек

CAC стоимость привлечения клиента.

CPA стоимость одного привлеченного пользователя в начало воронки и др.

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

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

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

метрика, на которую вы хотите повлиять (в денежном выражении) (a);

во сколько раз эксперимент может увеличить эту метрику (b);

вероятность, что гипотеза сработает, в процентном выражении (c);

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

Вот так выглядит формула:

Value per Day = (a * b * c) / d.

Из презентации Мэтта Билотти на Epic Growth SEASONS

Например, метрика влияния ARPU, или средний доход с пользователя, составляет $1. Вы должны определить, во сколько раз эксперимент увеличит вашу метрику. Например, вы предполагаете, что ARPU станет не $1, а $20. Значит, opportunity size будет равен двадцати.

Предположим, вы уверены в успехе на 70%. Значит умножайте на 0,7. Если на реализацию идеи вам понадобится два дня, то полученное произведение цифр нужно разделить на два. Итого получаем: Value per Day = ($1*20*0,7)/2 = $7.

Таким образом, Value per Day метрика отражает, сколько дохода фича может сгенерировать за N потраченных на ее реализацию рабочих дней. Так как в нашем примере Value per Day составил семь долларов, а эксперимент занял два дня, ежемесячно фича будет генерировать доход в четырнадцать долларов ($7*2) до тех пор, пока метрика влияния не изменятся (в ходе новых экспериментов, например).

Источник: unsplash.com

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

Полезные источники по теме

Выступление Мэтта на Epic Growth SEASONS

Фреймворки по приоритизации задачЕще один список фреймворков для управления продуктами

Первоисточник RICE фреймворка в блоге Intercom

DHM подход к приоритизации гипотез от Netflix

Блог Даниила Ханина о юнит-экономике

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

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

Если коротко:

Юнит-экономика характеризует, сколько бизнес зарабатывает или теряет на одном юните.

Юнит это базовая единица, генерирующая доход, и у каждого бизнеса она своя.

Как посчитать юнит-экономику

1. Определить юнит.

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

Вот и всё, этого достаточно.

Дальше несколько деталей для иллюстрации.

Что такое юнит

Зависит от бизнеса. Не ищите общих правил и не смотрите на других. Ориентируйтесь на здравый смысл и особенности именно вашего бизнеса.

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

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

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

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

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

Так юнит предмет сделки или клиент?

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

1. Юнит предмет сделки.

2. Юнит клиент: покупатель или пользователь.

Подход 1. Юнит предмет сделки

В этом случае расчет юнит-экономики сводится к расчету маржинальной прибыли. Маржинальная прибыль разница между выручкой от продажи единицы продукции и затратами на производство/закупку и продажу этой единицы. Так мы понимаем:прибыльно ли продаем один юнит?

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

Подход 2. Юнит клиент

В таком случае юнит-экономика отношение прибыли, которую принесет клиент за все время, к стоимости привлечения этого клиента. То есть здесь речь об LTV (lifetime value, пожизненная ценность клиента) и CAC (customer acquisition cost, стоимость привлечения клиента). Так мы понимаем:приносит ли клиент прибыли больше, чем мы тратим на его привлечение?

В клиентской модели мы хотим понять: пожизненная прибыль от клиента больше затрат на его привлечение?

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

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

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

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

Считаем расходы и доходы, связанные с юнитом

Вне зависимости от подхода, в расходы включаем все затраты, напрямую ассоциированные с юнитом. В доходы выручку, которую он нам принес.

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

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

Это что касается расходов. А с доходами вроде все понятно, расписывать не буду.

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

В общем, открываете Эксель и вносите тудавсе расходы и доходы бизнеса на один юнит. Вот это и есть юнит-экономика. Все просто.

То есть речь о постоянных и переменных затратах?

Действительно, в расчет принимаем переменные затраты, то есть те, которые изменяются в зависимости от объема производства и реализации.

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

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

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

А как же ARPU, ARPA, MRR, ARR, ACV, AOV, COGS и прочие умные слова, которыми кишат статьи о юнит-экономике?

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

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

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

Но стоит помнить некоторые нюансы расчета юнит-экономики:

• Экономика разная для разных каналов и сегментов.Запросто может произойти (и, как правило, происходит), что на трафике из Фейсбука сходится, а из Директа нет. То же самое касается клиентских сегментов: с одними все хорошо, с другими не очень.

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

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

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

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

Зачем это все

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

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

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

Самое главное

Помним, что задача рассчитать доходы и расходы, связанные с одним юнитом, и сделать это в целях масштабирования.

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

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

Итого

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

• Не особенно переживайте о терминах, если считаете для себя.

• Не усложняйте. Если откинуть универсальные калькуляторы с терминологическими спорами и просто посчитать, станет понятно: юнит-экономика это просто.