Немного продакт
Александр Штейн, Head of Product B2B SaaS в Deeplay · 25.09
📈📈📈 Сколько дашбордов нужно продакту?
От места к месту работы вижу две тенденции в построении продуктовых дашбордов: ◦ Либо есть один даш, который содержит все возможные графики, алерты на них и пояснения; ◦ Либо есть бесконечно много дашбордов, каждый содержит по одному графику и все пояснения к нему;
Чаще всего выбор между первой и второй моделью обуславливается на уровне "у нас так принято", и никто - особенно в корпорациях - не поддерживает изменения существующей структуры отображения данных ради здравого смысла.
Предположим, что мы пришли на продукт, где ещё нет дашбордов / они есть, но у нас есть полная свобода их настроить под себя. Так сколько их нужно сделать и чем руководствоваться?
Ниже я напишу несколько правил, которыми сам руководствовался, выстраивая визуализации данных в нескольких компаниях: 1. Необходим дашборд основных метрик. На нём должен быть график отображения north-star метрики + минимальное количество метрик, однозначно показывающих состояние продукта. Для технической части можно вывести агрегированный график соответствия SLA, для каналов привлечения - соотношение поток/план и так далее; 1.1 Важно: на каждый смысловой домен продукта стоит ограничиться одной метрикой, которая просто показывает "всё хорошо/всё плохо"; 2. Далее нужны дашборды, раскрывающие компоненты каждой из ключевых метрик; 2.1 Для примера: наша ключевая метрика - объём трафика. На подробном дашборде этой метрики есть разбивка по ресурсам, характер трафика и пр. - при чём в динамике, чтобы у нас работал аппарат принятия решений от изменений в продукте; 2.2 Важно: иногда дашборды не нужны. К примеру, для раскрытия технического состояния продукта лучше может подходить status page - при условии, что он отражает реальный уровень здоровья компонентов продукта и хранит исторические данные об инцидентах; 3. Если у каждой сабметрики есть отдельные компоненты - не стесняйтесь выделить ей ещё один самостоятельный дашборд, чтобы смотреть и понимать, из чего она формируется;
Чем удобен этот подход? 1. В первую очередь - легко масштабировать. На ранних этапах у вас будет минимум дашбордов, а когда продукт станет комплекснее - не придётся смотреть на тысячу досок, чтобы найти нужную метрику (или искать её на одной огромной панели) 2. Во вторую очередь - здравый смысл. Команда продукта мыслит уровнями иерархии: на верхнем слое - деньги, ниже - состояния продуктовых доменов, ещё ниже - элементы реализации каждого домена. Когда дашборды соответствуют смыслам - легко понять, где искать нужные данные;
📝 Пишите в комментариях, какие принципы для визуализации продуктовых данных используете вы
P. S. Не забывайте оставлять ❤️😃
Делитесь этим постом с коллегами по продуктовой работе и аналитике данных, чтобы узнать больше о методах организации дашбордов
#hardskills #данные #визуализация #немногопродактРоза Ларина
· 25.09
Как раз думаю, с какой стороны подступиться к дэшбордам 🧐
ответить
Саг Саг
· 25.09
Как говаривал тов.Тинькофф: "Это не rocket science!". Сделайте для продуктовой команды свой Даш, а для стейков - оставьте их детище, пусть рефлексируют на него.
ответить
еще контент автора
еще контент автора
Немного продакт
Александр Штейн, Head of Product B2B SaaS в Deeplay · 25.09
войдите, чтобы увидеть
и подписаться на интересных профи