#ФФДД2Д | Считаем в деньгах процесс внутреннего продукта когда ты дизайнер
Дизайнеру важно понимать метрики продукта
многа букаф, ниасилил: дизайнеру важно понимать и использовать метрики для создания лучших решений и карьерного роста
Подробнее почему, что это дает и показывает:
- Твоя ценность для бизнеса повышается
- Потому что твои дизайн-решения начнут влиять на бизнес
- Потому что ты сменишь мышление с макетов на ценность/выгоду продукта или отдельного в нем процесса, который проектируешь
- Потому что это откроет тебе возможность к более высокой оплате труда
- Твоя работа объективно оценивается
- Потому что ты увидишь это и в деньгах, и во влиянии на пользователей
- Потому что метрики это не сложно (обещаю🌚)
- Твоя работа объективно обосновывается
Буквально пиньята: продукт шатают (пользователи жалуются, не покупают, не пользуются), а тебе/команде как будто закрыли глаза (не смотрите метрики), затем вас раскручивают (появляются «я так думаю» и «я лучше знаю»), и вы пытаетесь попасть палкой (фичами) по своему продукту в надежде получить конфетки (деньги от пользователей / другие цели)
Что такое метрика?
многа букаф, ниасилил: метрика – это чиселка, которая отражает качественную или количественную характеристику продукта, пользователя и бизнеса, в котором:
- Метрики есть всегда, причём в любой бизнес-модели (b2c, b2b, b2g и т.д), поэтому изучи/почитай про бизнес-модель своего продукта
- Метрики есть всегда в том числе во внутренних продуктах
- Да, у каждого продукта/бизнеса свои метрики, так как есть разные методы продавать/продвигать продукт, поэтому изучи/почитай про это
- Метрики надо знать, хотя бы основные по юнит-экономике
- За метриками надо присматривать: качественные+количественные способы исследований = база, которую никто не отменяет
- Дизайнеры всегда влияют на метрики
- Метрики всегда являются бутылочным горлышком (узким местом) в наших продуктах, верим ли мы в это и хотим ли мы того или нет
Поэтому внедрим первый термин: метрика. Метрика (любая) – качественный или количественный показатель, который показывает ту или иную характеристику продукта, пользователя или бизнеса.
На метрики смотрят по разному и относятся к ним также, поскольку есть:
- разные бизнес-модели (b2c, b2b, b2g и т.д)
- разные отрасли (fintech, edtech, healthtech, e-commerce и т.д)
- разные продукты по сценариям, процессам и банально визуалу
- разные способы распространения (платно, бесплатно, freemium и т.д)
- и т.д
Это понятно, а если нет, то гуглите по пунктам и изучайте свои продукты и компании, в которых работаете, так как это как минимум интересно. Как уже писал выше, относятся к метрикам по разному и вот 2 популярных подхода:
- Data-driven подход: сначала цифры, а потом на их основе принимают решения. Команда выбирает метрики и считает показатели. Полученные числа - первое, на что команда смотрит, решая, куда двигаться дальше
- Data-informed подход: метрики частично влияют на принятые решения. Показатели - это важно, но не главное в этом подходе. На них можно ориентироваться в одном случае и не учитывать в другом
Что из этого хорошо/плохо - каждый бизнес и команды выбирают сами. Но 100% смотреть только на цифры и только на них = закрыть глаза на пользователей и их проблемы, а значит игнорировать качественные данные и методы исследования, что является очень плохой практикой потому, что наши продукты покупают люди, используют люди, принимают решения в них люди, а не машины/боты и т.д.
Далее я начну внедрять пару метрик и затрону простую мысль: у любого бизнеса есть расходы на продукт и команду. Расходы могут быть масштабируемыми, а могут быть ограничены сверху, то есть немасштабируемыми (фиксированными). В этом сейчас кратко разберемся...
Расходы, продукт и дизайнер
- То есть бизнес через продукт дает что-то пользователям на входе, что приводит к первым продажам и бизнес получает покупателя
- Покупатель (платящий пользователь) совершает платежи по какой-то модели и приносит компании прибыль со временем, или уходит, если продукт не закрывает цели или, наоборот, закрыл и больше не нужен
- Во внутренних продуктах пользователя не привлекают из какого-то рекламного канала, он ничего не покупает. Однако, его нанимают на работу или он нанимает на работу продукт, который должен решать что-то, и это что-то конвертируется в деньги только через экономию на процессе, расходов на него и т.д. - вот об этом будем говорить
- Пользователи в любом случае приносят прибыль, а компания несет всегда масштабируемые (Fix Cost) и немасштабируемые расходы (Cogs)
Модель любого продукта: на входе юзеры, а на выходе деньги, то есть продукт должен их активировать в то, что мы проектируем как дизайнеры: сценарии.
Сценарий это не экран, а последовательность экранов, то есть наш пользователь в продукте взаимодействует с их последовательностью. Наша задача не пилить фичи, а проектировать сценарии, в которые пользователь будет активироваться, получая ценность/выгоду от него и конвертироваться в платящего пользователя (покупателя/клиента).
В рамках нашей темы про внутренний продукт ситуация немного другая: пользователя нанимают на работу, то есть он не выбирает его, не привлекается из рекламного канала и т.д.
Однако, он вкладывает свои время и силы в работу, которая должна быть выполнена. В рамках сценариев внутренних продуктов они должны быть короче, понятнее, эффективнее, быстрее или вообще автоматизированы. Потому что работать нам всем надо и качественно, и быстро, потому что экономя на процессе = экономия в деньгах - отсюда и пойдет про деньги-дребеденьги.
Расходы
Для всех бизнес-моделей нужны пользователи, которых привлекают откуда-то. Мы делаем им продажу, или закрываем какую-то боль/процесс/сценарий, то есть любой продукт устроен одинаково: на вход подаются пользователи -> на выходе получаются деньги и всегда при этом пользователь приносит выручку, а бизнес несет масштабируемые расходы. Но сперва про самое простое...
Немасштабируемые расходы
Это всё, что можно ограничить каким-то пределом сверху: зарплаты, аренда офиса, кофе и конфетки в офис и т.д. Это называется Fix Costs...
Fix Costs
Фиксированные расходы (немасштабируемые) - это нас мало интересует, но это все расходы, которые не будут масштабироваться, иначе их нужно записывать в COGS (далее) - эта информация для справки и понадобится позже, а пока что закрепили-запомнили
Вот то, что нам на самом деле интересно и то, что нельзя ограничить сверху...
Масштабируемые расходы
Чтобы понять и ощутить разницу от немасштабируемых задайся вопросом: если продажи или расходы на процесс вырастут в 100, 200 или даже в 300 раз, то как вырастет статья расходов?
Если такие расходы нельзя ограничить сверху и рост расходов кратный: требуется больше людей и/или стоимость, например, доставки растет - это масштабируемые расходы или COGS...
COGS (Cost of Goods Sold)
Это обслуживание клиента после 1й продажи на время его жизни: себестоимость, доставка, упаковка, расходы на обслуживание клиента после продажи, онбординг, комиссия платежным системам, премии (если премия выдается за каждую продажу), налоги, расходы на сервера, зарплаты сотрудников, которые масштабируются вместе с ростом продаж или расходов на процесс и т.д.
Короче, это расходы, которые терпит бизнес и их нельзя ограничить сверху каким-то фиксированным пределом при росте продаж/затратах на процесс
- Если в облачном хранилище нагрузка вырастет на сервера и хранилища в 100 раз, надо ли закладывать сюда расходы на них? Да!
- Если в skyeng в 100 раз больше учеников придет, нужно ли больше преподавателей? Да!
- Если в Я.Лавка вырастут заказы в 100 раз, то нужно ли больше курьеров? Да!
- и т.д
Внутренний продукт и ты в таком дизайнер
многа букаф, ниасилил: делаем cjm/ujm/service blueprint -> картируем продукт с помощью любого артефакта. Замеряем время на каждый этап. Степень детализации и точности замеряйте как удобно или можете. Любая чиселка отличная от нуля -> круто. Распределите время на каждого участника процесса и найдите где узкое место. Поделите зарплаты на время узкого места и получится стоимость 1 прохода по процессу. Выдвигайте гипотезы как это исправить -> проверьте гипотезу -> оцените результаты -> примите продуктовое решение -> вы великолепны!
С этого момента и дальше я попробую убрать мифы о невозможности влияния на метрики, пользователей, сценарии в рамках внутренних продуктов, когда ты в таком дизайнер.
Также держи в голове или обращайся ко всему, что было выше написано: всегда на входе в продукт пользователь, а на выходе денежки.
Также держи в голове, что любой продукт всегда делится на этапы, за которыми можно наблюдать, которые можно анализировать и получать чиселки = метрики!
Во внутренних продуктах чиселки (метрики) разными бывают, поэтому мы тут сделаем фокус только на самой простой метрике: время.
Почему время?
Если говорить за дизайн, то чаще всего смотрят в тех же юзабилити-тестах на время выполнения задания, помимо всяких справился/не справился с заданием, количество ошибок и т.д. То есть это мы сами можем проверить, проведя коридорку или более точно замерить на юзабилити-тесте время на этап/задание/сценарий, которые мы с вами проектируем.
Также время проще всего отследить и замерить через системы аналитики или банально логов событий в системе. И внимание: за время платят зарплату... опа...
Произошел инсайт? Нам даже примерных значений зарплат хватит, которые можно посмотреть на hh.ru например. Круто если инсайт был, а сейчас о том как же этапы в продукте визуализировать...
Методы картирования и визуализации сценариев
Как же классно, что есть CJM/UJM, Service blueprint, user flow и другие артефакты для картирования/визуализации чего бы то ни было, по которым мы можем увидеть общую картинку продукта в разрезе по сегментам и этапам или взять конкретный этап и посчитать его. Я опущу про то, что это за артефакты такие, так как есть всё в интернетах - статьи/видео и т.д.
Определяем что есть масштабируемый расход в нашем продукте
Итак, мы работаем в компании и играем за дизайнера. У компании есть продукт. Продукт - это платформа по процессу управления инцидентами (incident management process). Это доменная область моего продукта, а чтобы дальше не нарушать NDA я вам больше ничего не скажу 🙊🙈🙉
Вот и получается что есть уже продукт, дающий какой-то сервис/услугу, решая/закрывая какую-то боль/сценарий - это все проектируется нами (командой), на которую бизнес выделяет бюджет. То есть есть Fix Cost - это помним-поняли-приняли и это не интересно, но закрепили, что такие траты есть -> на нас с вами.
Так как это внутренний продукт, у нас есть сотрудники службы поддержки, которые нашим продуктом пользуются: работают над инцидентами и т.д.
Давай используем наши знания выше, задав себе вопрос про масштабируемые расходы: если в нашей компании будет в 100 раз больше инцидентов, то нужно ли больше специалистов поддержки? Да!
То есть COGS - это наши расходы на зарплаты сотрудников, которые масштабируются вместе с ростом количества инцидентов.
Это значит, что если мы, как дизайнеры, будем видеть этапы (из cjm/ujm и т.д) и понимать как наши продуктовые решения влияют на пользователей, а также зная зарплаты (знать не надо, но прикинуть «на коленке» посмотрев на hh мы можем), то мы можем понять:
- Что дизайн-артефакты не создаются чтобы их просто создавать -> они должны помогать нам в принятии решений
- Что наши дизайн-решения влияют на пользователей, через время, которое они тратят на наши сценарии, которые мы проектируем.
- Пользователи могут застревать в каких-то тупиковых сценариях
- Пользователи могут не понимать иконку, текст, иллюстрации, состояние блока/элемента.
- Пользователи могут даже не увидеть и не знать о каких-то возможностях потому, что мы фичи сделали (фичизм) и не показали, и не объяснили их ценность/выгоду (не активировали)
- Что наши решения влияют на время, которое тратят пользователи, а значит мы видим буквально в деньгах как внутренний продукт помогает бизнесу экономить на процессе. В данном случае мы играем в продукте по управлению инцидентами.
Раскладываем пасьянс на этапы продукт
Этапы ниже в табличке, равно как и время, которое нам понадобится позже.
Где взять эти шаги? Ответ прост – не забывайте что вы не одни: почитайте документацию проекта, другие артефакты, спросите у своего менеджера и других стейкхолдеров. Попробуйте пройти самостоятельно путь в продукте и распишите этапы (dogfooding). Пообщайтесь с аналитиком на предмет наличия данных из системы аналитики для сегментации пользователей, данных их поведения. Также наблюдайте за своими пользователями и проводите интервью: jtbd-интервью, глубинное -> применяйте то, что знаете, не гонитесь за серебрянными пулями в виде разных фреймворков, если не понимаете их.
Внимательные увидят, что этапы сформулированы в виде job stories. Разумеется, упрощенно, чтобы не нарушить 🚨NDA🚨. Вам же никто не мешает оформить в виде user stories или написать словами, а сейчас самое время поговорить..
И в мыслях даже не вмещается, чтобы было когда-нибудь время, когда никакого времени не было. — Цицерон
Размечаем время или что за 0,1? 0,25? 0,1? 0,5?
Цифры будут с округлением, поэтому в конце статьи будет ссылка на табличку с шаблоном, чтобы самостоятельно потыкать
Дальше я просто добавил время на табличку. Формат визуализации как уже сказал может быть любым, это можно встроить в любой артефакт.
Ловите саму суть: каждый этап занимает у сотрудников (ролей в процессе) время, которое оплачивается бизнесом. Напоминаю, что:
Если становится в 100 раз больше инцидентов в компании, то нужно ли нам больше людей? Да!
Люди в этом процессе масштабируемые издержки, а любой интерфейс, который их блокирует – это минное поле, по которому пользователи идут к заветному целевому действию для бизнеса (или банально к покупке товара/подписки/бананов - шучу, людей... учу, ну вы поняли короче - это наш COGS)
Теперь затронем из таблички «время, мин», «время, макс», «время, средн», «количество циклов согласования» - что это, как считается и т.д.
Как посчитано «Время, мин» и «Время, макс» подробно указаны в таблице
Да, снова цифры не реальны, потому, что 🚨NDA🚨, но принцип понятен! Далее:
Строчка «Количество циклов согласований»: например, на колонке «согласование сроков», таких циклов может быть пару, то есть роль Х идет к другой роли и спросит «когда починим?». Ему не ответили, потому что обед. Затем роль Х снова тратит время (+1 цикл) и еще раз и т.д - суть ясна, думаю
Так вот, циклы всё портят. Дальше нам нужно вывести среднее время, исходя из «мин», «макс» времени и количества циклов.
Уточню на всякий случай: берите мин/макс время в целом за все роли, то есть если одна роль говорит одно время, другая роль другое на этап - берите бОльшее, если нет точных данных, кроме слов сотрудников
Чуть точнее конечно это замерить будет через юзабилити-тесты или систему аналитики подрубить
Как посчитано «Время, средн» подробно указано в таблице
Пользователи в продукте
Вот пользователи попали к нам. Вот они что-то делают в наших внутренних продуктах. У пользователей могут быть определенные роли. Дальше опять же не сложно: надо соотнести каждую роль на каждом этапе со средним временем на каждый этап в продукте. Получится так:
Где деньги?
Все просто: каждая роль - это сотрудник, который тратит время (работает) на каждом этапе всего процесса. На работе люди получают зарплату, которую нам не надо знать точно, так как это и 🚨NDA🚨, и неэтично, но мы узнаем
Колонка «зп в месяц» - это легкая чиселка: можно взять из головы или пойти на любую доску объявлений с указанными зарплатами и добавить +40%, чтобы получилось честно - с налогами - для бизнеса считаем же
Дополнительно: указана не настоящая зарплата, а также учтите тот факт, что для бОльшей точности вам нужно знать время которое тратит человек на решение, думаю, это понятно что не целый месяц работы сотрудника занимает работа над одним инцидентом. Эта деталь NDA, поэтому понимаем-принимаем и считаем часы людей по факту далее в финале
Далее нужно понять почему указано 1 в «людей в команде». По 2 причинам:
- Один инцидент обрабатывает один человек в рамках кейса - масштабируемый юнит -> инцидент. Без деталей - 🚨NDA🚨
- Юнит-экономика - ее основная идея связана с масштабированием (помним что-то такое да?). Так вот бизнесу хорошо бы понимать какие есть расходы, связанные с процессом обработки инцидентов в компании, которые, разумеется, напрямую связаны с сотрудниками:
- потому что они работают над этим, а мы платим им зарплаты
- и каждую роль нельзя игнорировать -> продакта/дизайнера/разработчика/тестировщика, которые будут исправлять «проблемки», которые несет инцидент за собой
- Уточню, что продакт/дизайнер/разработчик/тестировщик - это не моего продукта команда, а те люди, чья часть сломалась, грубо говоря и их служба поддержка дергает, чтобы понять когда эта команда починит
В общем, когда провели визуализацию процесса по этапам, получили время на каждый этап, прикинули количество людей по ролям на этап, а также получив примерную информацию по зарплатам, мы можем посчитать себестоимость нашего процесса, а затем выдвигать гипотезы, создавать и тестировать и принимать уже взвешенное продуктовое решение.
Продуктовые решения и дизайнер
Закончим нашу табличку и разберем оставшиеся части:
Колонка «раб. часов в месяц» - простая чиселка: примерно сколько работают люди? Явно же не 100% - не 8 часов в день. У нас у всех есть митинги, всякие командные активности, ретроспективы и прочее. То есть ну никак не выходит ни у кого по честному чистой работы на 8 часов - это нормально. Я указал 128 часов в месяц, то есть 32 часа в неделю.
«часов на инцидент» - это сумма чиселок в строчку тех самые 0,2+0,2 и тд на весь процесс в рамках одной роли. Обратите сразу внимание, что у службы поддержки выходит 4 часа на один инцидент!
«пропускная способность» считается как:
(«людей в команде» * «раб. часов в месяц») / «часов на инцидент»
Нам это важно, чтобы понимать где узкое место в процессе по теории ограничений. Тут невооруженным глазом видно, что это служба поддержки. Ничего удивительно, согласитесь, продукт же про это в целом.
Как мы это понимаем? 1*128/4 = 36 - у вас будет другое число, разумеется, так как в таблице работает округление для упрощения.
Разумеется в моем продукте все немного сложнее, больше ролей, но сам факт - мы нашли узкое место. Теперь надо подумать: как поменять процесс, чтобы пропускная способность расширилась.
Почему зарплату службы поддержки оставили целиком? По теории ограничений необходимо оптимизировать использование узкого места, так как его работа напрямую влияет на всю систему. Узкое звено тут разумеется служба поддержки, которая участвует во всем процессе и дробить не нужно
Чтобы это лучше понимать «узкие места» почитайте книгу "Цель" Элияху Голдрата, которая посвящена теории ограничений. Написана в формате бизнес-романа, то есть ее просто читать 😁
Наконец, имея банк зарплат, мы делим его на узкое место:
COGS = 76 795/36 = 2 145 ₽ стоит спроектированный процесс в нашем продукте для нашей компании. Кажется немного? Но это же один инцидент! Представьте что их десятки, а сотни, тысячи, десятки тысяч каждый год? Больно стало? То-то же и это надо как-то поправить и при этом быстро, и дешево 🌚
После «пу-пу-пу», увидя даже такие грубые цифры на коленке, я вернулся к табличке (по сути это наш cjm) я покрутил/подвигал/подумал над этапами и тем, как сократить эти этапы и/или ускорить узкое звено - службу поддержки.
Моя гипотеза была следующей: если мы переместим уведомления сотрудников/клиентов вперед на этап создания инцидента, то сократим время создания инцидента на n% и т.д. - тут ничего уникального, классическое построение гипотезы «если сделаем Х, то будет Y...»
Как я ее вывел? На основе jtbd интервью я выделил одну работу, которая привела меня к гипотезе, что надо вытаскивать вперед уведомления (1) вперед к форме создания инцидента (2)
Я предложил эту гипотезу + дизайн решение + объяснил свои ожидания по сокращению времени/расходов (табличка). Затем это запустили и результат был. Дабы не нарушать 🚨NDA🚨: скорость создания инцидентов с информированиями стало быстрее первоначальных ожиданий в 20%, а вот насколько это уже секретики.
И вот она суть: когда делаем даже внутренний продукт, наша задача разобраться с процессом, автоматизировать работу, на которую мы нанимаем людей и посмотреть расходы на процесс. Это запускает в мозгах процесс генерации гипотез, которые проверяются на коридорках, юзабилити- а/б-тестах и у тебя под рукой теперь еще чиселки (пускай на коленке), но не просто слова «я считаю это будет удобнее пользователю» и ты избавляешься от фраз «специфика внутреннего продукта, сами понимаете, метрик нет, какие уж тут метрики».
Это заставляет также избавиться от «фичеризма», так как фичи это зло, как плохая инъекция, которая отдаляет продукт от цели: сделать процесс быстрее и сократить расходы, или банально чтобы пользователь продукта что-то купил или оплатил подписку.
Устраивайтесь в Т-Банк, чтобы узнать и делать крутые продукты с нами!