Архив недели
Понедельник
Привет! Я Никита Таныгин, занимаюсь продуктом в копенгагенском почти-не-стартапе airtame.com. ex-SEMrush (правда, там я занимался тестированием).
На этой неделе расскажу про то, как мы делаем B2B продукты на стыке hardware и software и радуемся жизни
В продукте я недавно (пару лет), у меня неплохой технический бэкграунд, который местами очень помогает при разработке технически сложного продукта (правда, бывает что в других местах он мешает)
Расписание
[ПН] Хардварные продукты: как делать девайсы, связанные околопродуктовые риски
[ВТ] Операционная система как продукт
[СР] Аналитика в гибридных продуктах
[ЧТ] Про жизнь в Копенгагене
[ПТ] Remote работа и ноумадинг при разработке хардвара
[СБ] Технический долг
[ВС] ?
Точно не буду писать о том, как правильно спросить маму, как проводить эксперименты, как считать результаты A/B тесты и прочий growth-hacking. В моем продукте это пока не самые востребованные инструменты, плюс на эти темы не писал только ленивый.
Про продукт
Немножко расскажу про продукт, чтобы дать контекст. Airtame — это девайс, который вставляется в HDMI-порт экрана, подключается к WiFi, и, как мозговой слизняк из Футурамы, захватывает контроль над тем, что будет показывать экран.
Главные кейсы, в которые умеет Airtame, это беспроводный кроссплатформенный мирроринг и digital signage. Простите за баззворды, сейчас все объясню :)
Мирроринг — это возможность real-time пошарить экран своего лаптопа или телефона, чтобы показать слайды с красивыми графиками и помочь эффективнее провести встречу;
а еще учитель может показать ученикам в школе видео про коалу, а ученики могут по очереди пошарить свой экран и продемонстрировать домашнее задание. Наш главный конкурент — HDMI-кабель. Есть нативное приложение для 4х платформ (Windows, Mac, ChromeOS и Linux), а также поддержка
нативных протоколов (Airplay, Google Cast, Miracast).
Digital signage — умное словосочетание, которое подразумевает возможность крутить различные нескучные обои по расписанию (показывать дашборды, расписание самолетов, презентации, меню на ланч и прочий контекстуальный контент).
Наш рынок — B2B SMB/Education, Северная Америка и Европа, UK, Австралия и прочие страны, которые могут позволить себе заплатить 500 баксов за умную приставку для телека. К сожалению, СНГ совсем не целевая аудитория, поэтому никакой рекламы :)
Что веселого есть с технической точки зрения: собственный мирроринг для каждой оси на C++ (который везде написан по-разному), поддержка нативных протоколов вроде Airplay, технологии с большим влиянием окружения вроде HDMI/WiFi, и кастомный Linux на борту.
А еще есть облачная консоль управления, которая позволяет менеджить девайсы удаленно. Если у пользователя 1000 девайсов, это сильно облегчает жизнь ответственным за то, чтобы девайс всегда работал и показывал правильный контент
Естественно, компания зарабатывает деньги на продаже девайсов + аксессуаров (PoE адаптеры, кабеля). Но еще есть отдельная ветка — классные штуки, которые доступны только платно по SaaS модели.
Тред #1
Я занимаюсь развитием операционной системы (под ней понимаем софт, что живет на девайсе), и с недавних пор отвечаю за облачную консоль управления. Я не занимаюсь именно хардваром, им рулят другие крутые люди с бОльшим количеством нервных клеток. Попробую рассказать, что там как
Тред про отличия хардварных продуктах
Сходу запощу клише — hardware is hard; это область не для слабых с кучей рисков, которых нет в других областях. Ко всему, что может пойти не так с software, добавляются прелести физического мира
В мире hardware чтобы продать что-нибудь ненужное, нужно сначала это самое ненужное сделать. А это значит: закупить компоненты, собрать, упаковать. Каждая из частей процесса это отдельная зона компетенций с кучей возможных проблем.
Запуск устройства в серийное производство — это серьезный upfront investment (нужно как минимум закупить компоненты и оплатить сборку). Есть разные варианты с отложенными платежами, но они доступны только игрокам с репутацией и объемами.
В свое время Airtame преодолел эту проблему просто — краудфандинг. Это была очень удачная кампания на кикстартере, заодно и market fit провалидировали (правда, потом он изменился).
Важная часть это supply chain — sourcing компонентов, логистика и сборка.
Риски в supply chain весьма разнообразны — от "какой-то компонент перестанут производить навсегда" и "Тесла скупила все WiFi модули, поэтому новые уже стоят в 3 раза дороже и отгружаются только огромными партиями"
Туда же – недавний инцидент с Суэцким каналом, и компоненты плохого качества, которые очень сложно найти проактивно
При этом компонент компоненту рознь. Например, мы используем определенный WiFi модуль, и не можем просто взять любой другой, потому что драйвера и совместимость;
и потому что стабильный WiFi на новом модуле это полгода работы
Периодически приходится придумать, как все эти проблемы разрулить, и оставить цену прежней. Люди вряд ли оценят, если iPhone вдруг станет на 200 баксов дороже, просто потому что у Apple проблемы с supply chain
Поиск компонентов (sourcing) — это непрекращающийся процесс. Какие-то компоненты уходят, какие-то приходят, появляются альтернативы. Высший пилотаж — передоговориться с поставщиками или найти выходы на более дешевые компоненты, и увеличить маржу с продажи устройства из ничего
К сожалению, COVID в недалеком прошлом и ситуация на рынке полупроводников в настоящем заставляет грустить абсолютно всех, но мы держимся
Следующая веселая штука — сборка. Airtame собирают в Швеции. Это (внезапно) дает нам хорошее преимущество в европейских продажах, для клиентов из Северной Европы и Германии важно, где собраны девайсы
Производство — отдельный риск, потому что это узкое место, которое очень тяжело и дорого сменить (а в контексте конкретного продукта может быть невозможно). Есть manufacturer завтра обанкротится, это ваша проблема
Fun fact — когда мы выбирали, где размещать производство для текущего поколения девайсов, одной из опций были Филиппины. Помимо прочих вещей, поводом не выбрать эту страну стали риски по тайфунам
Я был на производстве несколько раз, и всегда радуюсь, как ребенок, когда робот побольше делает роботов поменьше (и поглупее) :)
Важная часть производства — QC и sanity checks. Пользователям нравится, когда девайсы работают из коробки. Поэтому, конечно же, есть процесс проверки
В нем помогает тестовая станция, в которую вставляют девайс и прогоняют на нем реальные кейсы (запуститься, показать картинку, проверить WiFi). Время = деньги (платим за минуты). А значит, нужно за минимальное время проверить как можно больше всего
Упаковка — отдельная важная тема, потому что она не просто должна стоить дешево, но еще и быть красивой, функциональной и экологичной. Все это важно для бренда, и упаковка такая же часть продукта, как сам девайс или софт
Неправильно спроектированная упаковка потенциально результирует в пользователя, который получит мятую коробку и пожеванные внутренности (а в плохом раскладе еще и поврежденный девайс). Так лучше не делать, даже в B2B первое впечатление очень важно
Ладно, хватит про околопродукт, давайте расскажу про то, как компании дойти до того, чтобы у производителя было что производить. Я буду очень упрощать, на самом деле все описанное чуть-чуть сложнее
Тред #2
Тред про то, как делают девайсы
После того, как придумали, а что, собственно делать, появляется 2 трека — физический девайс (собственно, hardware), и software, который на нем бегает и поддерживает жизнь
Execution по hardware — это интересная задача, которая требует крутого проджект менеджера. Там реально нужны ninja skills по контролю кучи людей (в том числе партнеров и поставщиков), заэстимейтам всех фазы разработки, а потом смэтчить software и hardware
Любое замедление и отклонение от плана — это потенциальное попадание компании на деньги (например, потому что нечего продавать, или потому что закоммитились на мощности производителя, которые из-за задержек не используются)
Все начинается с дизайна борды (платы). Примерно сразу же встает выбор между "делать быстро, но не очень кастомно", и "долго и дорого, ЗАТО СВОЕ". (Single Board Computer vs System on a Chip)
SBC это борда с компонентами, которую кто-то уже сделал. Опционально типовую SBC допилят под вас, и это точно будет быстрее, чем спроектировать свое с нуля (time to market!). Хороший пример SBC — Raspberry Pi. Плюс в том, что SBC уже производят, и добрая часть проблем уже решена
SoC дает максимальную гибкость, но требует серьезной экспертизы в не только в проектировании плат, но и в умении просчитывать "а что же будет дальше" при принятии технических решений. У каждого варианта есть плюсы и минусы, но в целом это гибкость против тупой надежности
Если нет полноценной in-house команды проектировщиков hardware, лучше выбирать SBC. Конечно же, у нас этой самой команды не было (но была экспертиза CTO и пары человек, которые имеют скиллы и в этой области).
Конечно же, мы выбрали SoC. Ощущения от процесса незабываемые, некоторые из них очень не хочется повторять никогда. Но было весело :)
Стоило выбрать SoC хотя бы потому, что это красиво!
Важнейшая часть разработки — промышленный дизайн. Это очень важная часть продукта, которая прямо влияет на бренд и пользовательский опыт. А еще она очень плотно интегрирована с hardware и помогает (либо мешает) ему.
Отличный пример — охлаждение. Можно сделать красивый компактный дизайн, который не учитывает нагрев борды, и не дает воздуху уходить, и троттлит девайс. То же самое касается прочности кейса и всей конструкции (не круто разваливаться на куски от падения с метра).
Важно понимать, что все принятые решения по предыдущим пунктам (особенно плохие) с вами навсегда. Недостаточно яркий LED, плохо прожимающаяся кнопка резета, корпус, который на определенных сценариях разогревается до 90 градусов.
В этом, как мне кажется, главное отличие hardware от чистых software продуктов. Плохие технические решения в условных веб-сервисах стоят денег бизнесу и нервов разработчикам, но как правило не пробиваются в материальный мир и не ощущаются юзерами физически.
Конечно, можно быть как Apple, и объяснять что все окей и вообще вы holding it wrong. Но, скорее всего, вы не Apple ¯_(ツ)_/¯
Многие косяки можно пытаться чинить софтварно. Но это применимо далеко не для всех продуктов, и обычно все равно получается херня. Кейс Boeing 737 MAX и из ничего троттлящий Macbook на i9 — яркие примеры решения хардварных проблем софтварными способами.
Но давайте представим, что мы знаем, какая (в светлом будущем) будет борда. В этом случае все приличные партнеры предоставляют development kit, где борда не такая же, но на той же архитектуре и похожая, а еще живая и рабочая. А это значит, что можно начать писать для нее софт.
До определенного момента разработчки работают с dev бордой и пишут под нее. Потом есть стадия bring up, когда первые экземпляры живых плат готовы, и нужно на них запустить софт. Конечно, сначала ничего не работает, но потом медленно начинает.
Как правило, у борды есть несколько итераций (spins) разработки. Отличаются они в основном наборов компонентов, и добавлением некоторых компонентов на поздних стадиях. Условный Ethernet порт могут выбрать ставить последним, если так почему-то проще
Про software я расскажу в другой день, потому что операционка, которая бегает на девайсах, это отдельная большая тема. Там куча вариантов в зависимости от бизнес-потребностей. Как правило, software на девайсе Linux/Android-based
Еще бывает, что бегает RTOS, но (к сожалению) с таким поработать пока не удалось
А пока давайте представим, что есть и дизайн, и борда готова, и софт работает. Время выпускать?
А вот и нет, сначала сертификация. В зависимости от того, что умеет продукт, она может быть сложной или очень сложной.
Сертификация — это злой процесс. На бумаге он выглядит просто — заключаешь контракт с теми, кто занимается сертификацией (certification house), платишь деньги, пьешь чай, а они все делают за тебя.
К сожалению, в реальном мире так не работает; в зависимости от компетенций certification house какие-то части могут длиться 3 месяца вместо обещанных 2 недель, скоуп постоянно растягивается, находятся проблемы, которые мешают сертификации, и нужно все больше денег
В случае беспроводных продуктов необходима отдельная сертификация для US (FCC) и Европы (она попроще).
Про ужасы сертификации я мог бы писать неделю, но просто скажу, что на это нужно закладывать кучу внутренних ресурсов, потому что в один прекрасный день половина команды разработки может начать писать тестовые скрипты, или тюнить software так, чтобы сертификаторы в принципе
могли что-то проверить. И лучше умножать сроки не на 3.14, а примерно так на 10.
Тред #3
Главный нюанс в том, чтобы правильно дружить проектовую работу (hardware) с продуктовой историей (требования к девайсам и последующее развитие софта). Потому что девайс делается один раз, и со временем обрастает дополнительными чисто софтверными возможностями
Но прикол в том, что софтверные возможности все равно диктуются возможностями hardware. Возможность добавить определенную ценность в продукт частенько завязана на конкретную технологию
Если сравнить Airtame 2 сейчас и 2 года назад, он научился:
- в 3 нативных протокола (Airplay, Google Cast, Miracast)
- контроль энергопотребления экранов через HDMI-CEC
- полноценный браузер, который может нормально играть видосы
- интеграции (например c Youtube/Google Slides)
Все вышеперечисленное завязано на возможности железа: где-то упирается в проц/память (как правило, это video playback и любые сайтики), где-то в специфику WiFi модуля (для Miracast нужен wifi-p2p мод, который доступен не во всех модулях)
Соответственно, тут как раз начинается продуктовая деятельность — нужно развивать софт на девайсе как продукт, принимая в расчет возможные ограничения
Что, писать еще про хардвар?
🤔
73.0% Пиши еще🤔
27.0% Please don'tИз-за этого хорошие стратегические решения очень важны, потому что пивотнуться будет не так просто. Если возможности девайса уже не укладываются в то, что ожидает рынок, придется сделать новый :)
Тред #4
Вторник
Всем привет :) Сегодня очень занятой день, но обязательно напишу попозже, а пока небольшой опрос. Про что интереснее читать?
🤔
48.2% ОС как продукт🤔
51.8% HW и B2B спецификаПоскольку результаты голосования почти равные, я постараюсь рассказать про обе темы
Тред про ОС как продукт
1/ Окей, поехали :) Операционная система (ОС) — это то, что бегает на девайсах. За редкими исключениями это что-то Linux/Android-based, но сильно кастомизированное под собственные нужды
2/ Получается, мы просто взяли готовый linux дистрибутив, поменяли название, обозвали его своей операционной системой и радуемся? Зачем об этом рассказывать, и вообще продуктовая ли это задача?
3/ Смотрите, тут неоднозначно. В основе почти всего на рынке действительно есть какой-то дистрибутив, который написан кучей крутых людей и уже менеджит бОльшую часть вещей. Но дальше начинаются нюансы ;)
4/ Хочу рассмотреть реальный пример для WiFi, потому что эта функциональность вроде как коммодити, и в 2021 году почти любой ноутбук и дистрибутив умеет законнектиться к вайфаю
5/ Открытые вопросы для WiFi:
- предположим, девайс умеет в WiFi; какие конкретно протоколы безопасности он должен поддерживать (WPA2, WPA-EAP)? Какие сегменты юзеров мы потеряем, если не будет поддержки enterprise security?
- должен ли юзер иметь возможность задать статические настройки сети, или будем поддерживать только условный DHCP?
- девайс не может приконнектиться к WiFi; что увидит юзер на экране? Есть ли что-то, что девайс в такой ситуации должен сделать без участия юзера?
- должен ли девайс помнить несколько беспроводных сетей? и автоматически приконнектиться к сети А, если сеть Б недоступна, но в текущих настройках была явно выбрана именно сеть Б?
Все перечисленное — маленькая часть сценариев, построенных только вокруг WiFi. Каждый из них сильно зависит от бизнес контекста. Например, мы не поддерживаем статические настройки сети, потому что вменяемые крупные кастомеры обычно не вбивают айпишники для сотен девайсов вручную
6/ Если мы хотим показать приложению или облаку статус WiFi соединения, то нужно вменяемое API (а значит, нужно собрать требования и придумать его так, чтобы в будущем не было мучительно больно). API предоставляется ОС, оно такая же часть продукта, как и все остальное
7/ Визуальная коммуникация (то, что пользователь видит на экране) — тоже часть операционной системы, которая пилится в тесной коллаборации с дизайнерами. Информация на экране, переходы состояний, success/failure messages и прочие красивости
8/ То, как работает LED — тоже визуальная коммуникация. Airtame показывает разный цвет для разных статусов (белый — idle, синий — streaming, медленно мигающий зеленый — update), и так далее. Естественно, этим тоже управляет ОС
9/ В целом, функциональность ОС можно поделить на:
- core внутренние функции, без которой девайс вообще не может существовать (точка доступа, networking, updater, factory reset, recovery, логика работы с HDMI). Это очень жирный и сложный кусок
- API, которое помогает consumer’ам (application/Cloud) запрашивать или аплоадить настройки, получать текущий статус разных компонентов, забирать логи
- браузер + обвязка из плагинов, которые отвечают за то, чтобы показывать контент
- все для streaming'а
10/ При этом одни и те же юзкейсы даже для такой монументальной и базовой штуки, как ОС, можно придумать неправильно. Мой любимый пример, как делать не надо — updater.
11/ Изначально для апдейтера придумали чисто B2C-шную логику — дефолтный autoupdate on, сразу устанавливать все новые обновления, при этом показывать на экране процентики и в это время не давать ничего сделать с устройством
12/ Идея так-то хорошая и правильная:
- юзер всегда будет получать последнюю версию прошивки (а значит, получит все то добро, которые мы хотим нанести)
- на время апдейта девайс будет заблокирован для внешнего воздействия, чтобы минизировать риски того, что что-то пойдет не так
13/ Проблема в том, что у девайса несколько типов юзеров с конфликтом интересов.
Учитель, который использует девайс для мирроринга каждый день во время уроков, не будет обновлять девайс. Он вообще не думает про апдейт, ему нужно нажать кнопку и начать показывать урок
Более того, автоапдейт посреди дня легко может сорвать урок (потому что в зависимости от загруженности CDN, локальной сети школы и сигнала WiFi он может занять 10-15 минут)
В итоге админы стали отключать автоапдейты. Это немножко помогло, но админы в школах в основном в то же время, что и учителя, и часто не могли пушить апдейты руками из-за пересечения во времени. Поэтому некоторые девайсы оставались без апдейтов длительное время.
14/ Вывод — даже простой базовый кейс, который уже сделан в куче других продуктов, очень легко сделать через жопу :)
15/ Веселье с операционкой начинается, если продуктов в линейке становится больше одного, и делают они похожее, но хардварный стек (и возможности) отличаются от девайса к девайсу. Нужно красиво прятать под капотом кучу сложности, чтобы пользователь не почувствовал разницу
16/ Самое сложнодостижимое в операционной системе — стабильность. В случае с девайсами это очень критично :) зависшую программу перезагрузят, в глючащем зуме пересоздадут звонок. А девайс, который отвалился от сети, полезут резетить руками в 5-метровый потолок конференс холла
17/ Главная проблема в том, что ОС это очень сложная система, и самые злые проблемы по стабильности очень тяжело найти в in-house тестировании или в beta программе. На помощь частично приходит аналитика, но в целом это вечная борьба
18/ В остальном процесс работы над ОС не сильно отличается от других продуктов: стратегия -> цели -> приоритизация -> проработка темы/метрики -> декомпозиция -> итерации -> execution -> аналитика -> доставка
Тред #5
Окей, хватит про операционные системы :) попробую рассказать про что-нибудь бизнесовое
Среда
Тред про hardware и B2B
1/ По модели продажа hardware бизнес аккаунтам это классический high touch sales; сейлы и аккаунт менеджеры очень важны и вообще ваши лучшие друзья :)
Покупка нескольких сотен девайсов ценой в XXX долларов — это инвестиция (ваш кэп)
2/ Поэтому цикл сделки очень долгий, год(ы) — это норма. Компаниям, которые хотят завязать свои процессы на что-то новое, нужна уверенность в том, что это самое новое работает. Поэтому все начинается с демо-юнитов и пилотов
3/ Основная функция девайса — беспроводной real-time mirroring. Она сильно зависит от того, как настроена сеть, сколько траффика по ней летает, как дружат сегменты сети. Как правило, с этим нужна интенсивная помощь, эту задачу решает customer success
4/ У нас есть специальные Sales Engineers, которые круто умеют в сеть и смежные области, но одновременно умеют общаться с юзерами и помогают в решении экзотических проблем и настройке любого оборудования
5/ Неправильный роутинг у юзера, из-за которого некорректно работает наш девайс — наша проблема и наши потери :) поэтому мы делаем все, чтобы максимально быстро и эффективно развернуть удачный пилот
6/ Естественно, чем больше кастомер, тем больше разных требований по всем фронтам. В основном всех интересует:
- аудит безопасности
- вообще все про безопасность, про это всегда куча вопросов
- где хранятся данные (особенно в EU)
7/ Одна из главных проблем для покупателей больших объемов — как быстро раздеплоиться :) Unboxing + начальная настройка одного девайса занимает 3-5 минут, но на больших объемах становится долго
8/ Для таких случаев есть отдельное хардварное решение, которое ускоряет весь процесс раз в 5 точно :) Без него всем жилось бы сильно тяжелее
Тред #6
Всем привет! Сегодня я планировал рассказать про аналитику, но это будет довольно технический рассказ, а они, судя по всему, тяжело заходят. Может ну его и расскажу про то, чего мы не делаем в продукте и нормально себя чувствуем? :)
🤔
68.8% Аналитика🤔
31.2% Продуктовые практики1/ Итак, аналитика :)
Мне кажется, что аналитика — это то немногое, что в том или ином виде есть в любом продукте. Без аналитики жить грустновато (хотя легко сделать аналитику так, что лучше бы ее не было совсем)
2/ Очень упрощенно аналитика состоит из:
- [1] понять, какие данные собирать
- [2] собрать и отправить их в какой-то data lake
- [3] сделать select * from data и радоваться жизни
3/ Наверняка чуваки из серьезных компаний проклянут меня за такие упрощения и будут правы, потому что между 1, 2 и 3 частенько пропасть и человекомесяцы на постройку мостов :)
Я упростил для контекста, расскажу про 1 применительно к эмбеду и гибридным продуктам, и немножко про 3
3/ В веб-сервисах и мобилках со сбором все несложно — есть куча готовых тулов с интеграциями, которые позволяют быстро настроить вообще все что угодно и наблюдать за юзерами со всех возможных углов, делать хитмапы и записывать сессии
4/ Если данные не хочется хранить, то их можно засылать напрямую в GA, MixPanel, FullStory, Amplitude и радоваться жизни (за бабло, конечно).
Но твой продукт это девайс + приложение + облако, и это собирается в непрерывный пользовательский опыт, местами бывает интересно
5/ Проблема 1, есть вот такой флоу:
- юзер открывает приложение
- нажимает кнопку
- кнопка инициирует шеринг контента на девайс
- девайс начинает шарить экран
Мы хотим трекать факт конца стриминга и metadata сессии.
Внимание, вопрос: кто в этом случае должен отправлять event?
6/ Предыдущий вопрос, как и почти все в IT не имеет правильного ответа, и можно делать все что угодно. Если данные отправляет только app, тогда:
- если стриминг прервался по network timeout, мы не узнаем о том, что об этой ситуации думает девайс, потому что на нем сессия могла умереть по любой другой причине (e.g. его ребутнули); мы никогда не замапим эти ребуты на network timeouts и будем думать, что стабильность хромает
- если app крашнулось во время сессии, то мы скорее всего поймаем краш репорт, но ничего не узнаем про саму стриминговую сессию
- не узнаем метаданные девайса (прошивку, платформу, etc.)
7/ Если же данные отправляет только девайс, то мы теряем из виду метаданные приложения (OS, версию приложения, и кучу полезных OS-specific данных)
8/ Получается, что для полноты картины надо либо сделать так, чтобы данные двух участников сессии шарились и отправлялись каким-то одним участником, либо отправлять 2 ивента от лица разных участников и соединять их между собой на будущее
9/ Проблема 2: нет готовых инструментов для сбора. Мы не можем взять JS интеграцию от GA/MixPanel, у нас абсолютно другая природа продукта и стек.
Сам по себе сбор — это просто что-то, что по триггеру положит JSON куда-нибудь в интернет.
Но, как обычно, есть нюансы
10/ Например, мы хотим считать, сколько раз девайс ребутнули.
Проблема в том, что просто триггернув event после команды ребута, легко отправить его в момент, когда ребут в самом разгаре, и доступа в интернет уже нет. Любое решение усложняет логику и его надо написать
Это все можно сделать и решить, и не то чтобы сложно, но не это приходит бесплатно (как бОльшая часть существующих решений аналитики на рынке)
11/ Но есть и то, что упрощает жизнь — девайсы не веб приложения, у них намного меньше контролов и состояний (а следовательно меньше событий, которые полезно анализировать)
Подход такой:
- маленькое количество ивентов с кучей метаданных
12/ Среди прочего мы трекаем boot/reboot/factory reset, стриминговые события, update (success/failure) + раз в день засылаем keep alive, чтобы считать, сколько чего находится онлайн
13/ Самое важное — аналитика по стримингу, особенно по сессиям с плохой оценкой от пользователя, или по сессиям, которые не завершились по инициативе пользователя
Второе самое важное — update failures, потому что они могут доставить юзеру ОЧЕНЬ много боли
14/ Все это жило своей жизнью и жило хорошо; а потом в уравнение добавилась облачная панель управления :) поэтому сейчас мы перестраиваем платформу, чтобы например дать возможность CS проактивно связаться с юзерами, у которых проблемы со стримингом, падают рейты или слабый сигнал
Тред #7
Тред вредных советов про аналитику
1/ Вообще забейте на GDPR и compliance; серьезно, ну кому вы нужны, кто придет к вам с аудитом? А придут — ну что они там найдут?
2/ Обязательно попросите разработчиков чтобы отправляли все данные, которые могут отправить. Вообще все! Хранилища данных нынче дешевые, big data в моде, а с тем, что вы хотите вытащить из этих данных будете разбираться уже потом
3/ В качестве расширения к 2/ — динамически меняйте структуру данных на лету. Еще лучше — поменяйте названия полей без обратной совместимости и никому об этом не говорите. Пускай BI гадает, почему в commercial reports стали прилетать нули :)
4/ Фильтровать ивенты на стороне сервера — лишняя работа и пустая трата времени. Клиент всегда знает, что отправить, и не может ошибаться. А уж девайс на экспериментальной прошивке точно не отправит миллион запросов в prod DB, силенок не хватит!
5/ Не шарьте ваши дашборды ни с кем. Кто владеет информацией, владеет миром, а остальные как-нибудь сами разберутся. В крайнем случае пришлите страждущим скриншоты .csv выгрузки
На тему аналитики написана кучей вещей, но мне очень нравится конкретно вот эта статья. К сожалению, я прочитал ее уже после того, как мы сделали примерно половину ошибок из нее. Крайне рекомендую
reforge.com/blog/why-most-…
Еще мы делим всю аналитику на 2 большие части: пользовательскую (про сценарии и юзеров) и BI (про все, что связано с баблом). Такое разделение может показаться странным, но у него есть хорошая причина — BI это огромный кусок
Пользовательская аналитика — это website, девайсы, app, облачная панель и еще пара вещей
В BI стекаются все данные, связанные с прямыми продажами, Salesforce, партнерами, подписками и вообще всем, что касается денег
Сейчас будет шок контент — продакты не отвечают за деньги (напрямую), за деньги отвечает коммерческая команда и финансы, поэтому и дашборды не наши
Ответов на "а почему так" довольно много, но главные — другой подход к ведению бизнеса, и очень сложная атрибуция. В продукте с циклом сделки в месяцы/годы довольно непросто понять, что конкретно повлияло на деньги.
(а когда показалось, что наконец-то понял, пришел ковид); за время ковида ты нафигачил кучу ценности, но никто ничего не покупал, а когда снова стали покупать — поди разбери, почему они купили именно это
6/ Ах да, самое главное — проверяют данные на сходимость только слабаки. Ну и что, что в app 30к успешных стриминговых сессий, а у девайса только 25к. Не надо менжеваться по мелочам. NPS же не падает, и деньги льются — все нормально будет
Тред #8
вообще когда я смотрю на ютубе лекции из серии "с вами Джонни Ноксвилл, и сейчас мы посчитаем юнит-экономику любого бизнеса на коленке, потому что уже сделали это для 1000 других", мне становится грустно от собственной никчемности
а потом я вспоминаю, что это интернет
я искренне желаю удачи хотя бы примерно посчитать юнит-экономику для high touch sales бизнеса, где от первого касания до продажи могут пройти месяцы, постоянно меняется COGS и еще есть партнеры :)
можно начать с того, чтобы предложить, как для такого бизнеса считать CAC немного точнее чем "ммм ну это все расходы на маркетинг, сейлс и саппорт деленные на временной интервал"
Тред #9
Четверг
Всем большое спасибо за крутые вопросы! Конечно все, что я расписал — это очень нишевая история, и наверняка подойдет далеко не всем (ну кроме .csv в скриншотах, это есть везде)
Завтра по плану рассказ про Данию и Копенгаген.
Что интересно?
🤔
36.0% Нюансы в работе(RU vs DK)🤔
37.6% Деньги, налоги, 300кк🤔
26.4% Релокация и переездЗавтра по плану рассказ про Данию и Копенгаген. Что интересно?
Всем добрый вечер! Сегодня в Копенгагене дождь, поэтому начнем пораньше :)
В опросе победило бабло (как обычно), поэтому начнем с него. Расскажу про зарплаты, про налоги и примерные расходы. Я буду писать цифры в датских кронах и рублях по курсу twitter.com/produnderhood/…
Тред про бабло
1/ Но сперва немножко контекста. Во всей Дании живет ~5 млн человек, в Копенгагене 800к, а с агломерациями примерно 1,2 млн
По меркам РФ Копен — это мелкий город, ни разу не Питер и не Москва
2/ При этом во всех возможных рейтингах из года в год Копенгаген стабильно попадает в 20 самых дорогих городов и в топ 10 самых дорогих городов Европы.
Поэтому, прежде чем порадоваться за высокие ЗП, помните, что еще есть высокий cost of living и налоги :)
3/ Я бы сказал, что нормальная ЗП продуктовика с опытом где-то 60к DKK (или 727к рублей). Это совсем не верх рынка, но выше медианы, хотя далеко не все компании готовы платить даже это
4/ Стоит ли говорить, что эту вкусную цифру можно увидеть только один раз — в квитанции об оплате, потому что это gross
Налоговая шкала прогрессивная, и уходит от 38% до 56% (top SKAT)
Если Х денег, которые тэксятся по обычно ставке, а все, что выше, тэксится по top SKAT
5/ Для простоты можно посчитать так:
после налогов с исходных 60k DKK на руках останется примерно 36k DKK (727 -> 436к рублей); это то, что прилетит на карту в первый день месяца
6/ Дальше нужно заплатить аренду, и тут все очень сильно варьируется (потому что кто-то снимет комнату и будет ок, а кому-то нужно 100 метров, кто-то готов коммьютить из пригорода Копена, а кто-то хочет жить рядом с любимой барной улицей)
7/ Я бы сказал, что для пришельца, который никого не знает и не может намутить себе вкусные варианты типа rent-controlled apartment:
- нормальная квартира будет стоить от ~12к DKK (145к рублей)
- комната ~5k+ DKK (60к рублей)
Можно дешевле, но нужно искать
8/ А искать есть время далеко не всегда, плюс рынок до ковида был крайне жесткий и хорошие квартиры улетали за часы; сейчас полегче, но безумие возвращается
9/ И естественно вы заплатите первый/последний месяц и депозит. Если очень повезет, то депозит будет 1 месяц, но скорее всего не повезет. Я платил за 3 месяца (то есть суммарно 5 аренд). А еще с высокой вероятностью нужно купить мебель, потому что квартира пуста
10/ В общем, если решите переехать в Копенгаген, лучше начинать копить прямо сейчас :)
11/ В итоге мы отнимаем 12 от 36 и получаем 24k DKK (~290к рублей) чистых денег, на которые можно наслаждаться жизнтю
12/ Давай поймем, как потратить эти деньги
В Копене очень дорого все, что включают любой труд человека. Несколько примеров:
- капучино 38 DKK/460р, дешман, совсем как в Кофемании!
- доставка еды — 350 DKK/4200р, заказать на 2 поке боулы/thai food, или 3 пиццы
- 0.5 крафтового пивка — 70 DKK/850р
- поесть вдвоем в кафе — 450 DKK/5500р
- сходить в нормальный ресторан (с вином) — 1000DKK/12000р
- хорошая еда на 3-4 дня (много белка + organic) — 500 DKK/6000р
- поездка в метро — 15 DKK/180р, я усредняю, стоимость в/вне час пик разная
- one-way поездка на электричке за город минут за 20 — 50 DKK/600р
- мужская стрижка (не у арабов) 350 DKK/4200р
- аренда сап-серфа/MTB на часок — 300 DKK/3600р
13/ В общем, денег на одного хватит вполне и будет очень комфортно; если вас двое, но работает только один человек, то будет очень напряжно (потому что не предполагается, что кто-то может не работать)
14/ Если вы привыкли заказывать доставочку каждый день и не умеете готовить, вам будет очень очень больно :)
Тред #10
Тред про прочие налоги
1/ С подоходным разобрались — у вас откусят сходу где-то 40-45%, если вы доберетесь до уровня, в котором начнут откусывать больше — ваша жизнь уже удалась
Веселье в том, что кроме подоходного, есть еще куча вещей, за которые вы заплатите ;)
2/ Media license tax — если у вас дома есть любой экран/девайс с интернетом/радио, то вы должны платить этот налог; 690 DKK/8,3к рублей в год (в 2021 его понизили в 3 раза по сравнению с предыдущим)
3/ Pension contribution — на пенсию в Дании нужно копить самостоятельно. Идея в том, что вы платите вместе с работодателем (например, он платит 4% от вашей ЗП, а вы докладываете 2% из кармана)
Можно больше, и эти деньги не облагаются налогом
Правда, есть большое НО — если вы решите покинуть страну и забрать накопленные деньги с собой, то заплатите за это удовольствие 60% (что охренеть как много и даже выше чем top SKAT)
4/ Вы инвестируете в ценные бумаги и зарабатываете? Отлично, нужно поделиться.
Если заработали до 55k DKK/666к рублей в год, налог 27%
Все, что сверху — 42%
5/ С non-stock investments (bonds, ETF и золотом) ситуация из года в год меняется
Последнее, что я помню:
<= 43k DKK в год — ~38%
больше — 42%
И да, вы не можете купить американские ETF
6/ VAT
25%. Если вы захотите заказать витамины на iHerb или что угодно из non-EU — заплатите 25% VAT и ~100 DKK/1200р фиксы за растаможку
7/ Тачка
Я просто оставлю это здесь :)
25% of DKK 65,000, 85% of DKK 65,000-202,200 and 150% of the rest.
Да-да, хотите новую бэху — заплатите сверху 150%.
8/ Церковный налог — 0.87%
9/ И последнее — negative interest rate; это не совсем налог, потому что как бы можно выбрать его не платить
Если у вас на депозите лежит больше определенной суммы (в разных банках по-разному, но примерно > 1 млн рублей), то банк берет 0.75% годовых за хранение
Тред #11
С абродандерхудом на сегодня закончил, дальше попробую рассказать про то, как работается в датской компании, особенности коммуникации и work life balance
Тред про то, как работается в датской компании
1/ Я считаю коммуникацию, убеждение и умение найти общий язык с людьми важнейшими навыками продакта
Для этого кроме умения строить осмысленные предложения пригодится понимать культурные особенности людей
2/ Про это написано довольно много, есть книжка The Cultural Map и много мемасов про то, как кто-то из UK говорит вам что-то вроде "I almost agree", что по факту значит "I completely disagree and you probably are an idiot"
3/ Но языковая коммуникация — это только часть уравнения; еще есть вещи вроде эмоциональности, склонности к открытым конфликтам, типов принятия решений, отношение к work vs life и еще куча мелочей, которые варьируются от культуры к культуре
4/ В моей компании куча народу из разных стран, датчан там не большинство (я думаю, где-то треть); у нас много ремоута (было и до ковида), и куча людей в North America (US+Canada)
Но фаундеры из DK, и именно они задают тон того, как и что работает внутри
5/ Датчане очень direct чуваки, и это прекрасно. По сравнению даже с соседними шведами мне сильно проще находить общий язык; меньше разговоров о погоде и ни о чем, больше фидбека по делу, прямее фразы, меньше пассивной агрессии
6/ При этом прямота другая, чем в СНГ. Наверное, самое важное, чему я тут научился — можно быть разговаривать очень прямо и по делу, и при этом быть веселым, доброжелательным и вежливым
Никаких "ну ты даешь, смотри, как просто это на самом деле делается, давай покажу"
7/ Еще меня крайне радует отсутствие зацикленности на политкорректности
Можно шутить про что угодно, и скорее всего все посмеются, или откроют новые грани черного юмора
У меня был шведский коллега из Мальмо, который только устроился и отработал неделю
В конце недели мы пошли в барчик завершить его onboarding, пили, веселились, шутили
В конце вечера спросили его — ну что, как дела?
А он говорит — все круто, но за первую шутку, которую я услышал, в моей шведской компании вас бы уволили вот прям сразу
Похожее было с US чуваками, которые просили моего французского коллегу не делать french jokes, потому что кто-то может подать в суд
Короче, никакой политкорректности, ура! Возможно, в компаниях побольше дела построже, но сами датчане говорят, что они очень relaxed в этом плане
8/ Work-life balance ооочень сильно смещен в сторону life
Личные дела и дети всегда в приоритете; нужно уйти раньше — никто не будет спрашивать "а можно ли", а просто поставит перед фактом
Овертайм — а это что? :)
Рабочая неделя — 37.5 часов
9/ Никто не боится потерять работу, потому что очень хороший safety net, страховка от безработицы
С одной стороны, это лишает негативной мотивации, и часто отражается на качестве сервиса. Официанты могут 3 раза забыть ваш заказ и вообще не парятся
10/ С другой стороны те, кто работает в IT индустрии, в основном делают это ради фана;
а когда базовые потребности закрыты, тебе что-то нравится, ты хочешь становиться в этом лучше и делаешь это без напряга — крутых результатов добиться проще
Например, в моей компании сейчас работает чувак, которому деньги в принципе не нужны, потому что он был одним из ранних employee Zendesk
Он не работал несколько лет и играл в гольф; потом ему надоело, сейчас работает простым инженером и ему в кайф, с ним очень приятно работать
11/ Конечно, есть и особенности, которые принять тяжеловато
Один из них — для решения часто нужно, чтобы был консенсус и все согласились :)
Исторически общество сложилось из крестьян и рыбаков, поэтому решения принимала община и вообще рулит hivemind
12/ Первое время я искренне не понимал, зачем мы в принципе обсуждаем какие-то вещи (вроде нечего обсуждать, бери и делай)
и зачем нам нужно мнение вон того парня, который вообще никак за результат не отвечает
13/ Плюс в определенные моменты, когда в другом месте кто-то взял бы инициативу на себя и просто сказал бы "мы будем делать вот так, всем работать", тут обсуждение продолжится и растянется еще на 5-7 митингов
14/ А как известно нет хуже способа принять решения, чем начать искать компромисс там, где он изначально был не нужен
Но в итоге eastern europeans конечно же балансят эту ситуацию (особенно в разработке), и в общем и целом жить можно
15/ Еще одна особенность — датчане могут быть дружелюбными, но в то же время холодными и закрытыми
Лично мне пофиг, потому что я сам такой и понимаю причины; но чуваки из Латинской Америки очень страдали, потому что им бы со всеми подружиться, а тут стена льда
16/ Последнее, что хочу упомянуть в этом треде — законы Янте, или "ты не лучше других"
В РФ и US очень сильно достигаторство. Сдохни, но сделай, get rich or die trying, покажи всем вокруг, на что ты способен (желательно рассекая на ролсройсе)
17/ В Дании сильна идея о том, что люди равны, и не надо выпендриваться
Поэтому ролексы, гелик и мокасины Гуччи скорее всего не оценят, произведут они ровно обратное впечатление
Желание поработать 12 часов каждый день тоже не оценят
18/ Ну и налоговая шкала очень сильно способствует уравниванию людей, чо уж там
Мне кажется, что это не хорошо и не плохо, это просто иначе; люди просто понтуются другими вещами — жизнью в конкретном районе, яхтами, очень дорогой мебелью (которая выглядит очень просто)
Тред #12
Тред про то, что (помимо крутых навыков построения продуктов) вот прям необходимо для того, чтобы расти и заколачивать 300кк
Пишу про Данию, но это применимо к любой стране западнее Польши
1/ Идеальный английский
Я много слышу в IT сообществе про то, что мол английский переоценен, и так поймут, и вообще половина людей не нейтивы и все у них в порядке
И это как бы так, но не совсем :) В продукте половина работы это убеждать других людей, язык — инструмент
Пятница
Проблемы с языком вполне можно простить разработчику до сеньора, дальше нельзя
Продакту, кмк, нельзя никакому, потому что одна из ежедневных задач это максимально ясно и красиво рассказывать, что делать, и почему
Если не хватает словарного запаса, он не растет выше среднего, есть сильный акцент — вы сможете работать, но промоутить будут не вас, а вон того чувака со сладким британским/американским акцентом
Так что язык это важно, не забивайте :)
Я видел своими глазами, как очень крутую и трудоспособную девушку сначала не промоутили, а потом еще и наняли ей менеджера с правильным акцентом (а потом уволили через время, потому что он ничего не делал)
2/ Самопрезентация
Тут все просто — каждая сделанная штука заслуживает того, чтобы правильно о ней рассказать. Хорошо (но молча) делать дело на дистанции хуже, чем хорошо делать дело и рассказывать о том, как ты его сделал
Я не знаю, как сейчас, но 5 лет назад в СНГ было некое пренебрежение к тому, чтобы красиво рассказать про результаты своей работы. Мол, че тут рассказывать, все просто же, вообще ничего не стоило, всего-то 2 дня потратили
Но в среде, где строить свой имидж для других (любых чуваков из Western Europe/North America) это естественная активность, которая делается на автомате и не стоит ничего, в проигрыше остаются как те, кто этого не делает
как раз те*
Лично у меня огромные проблемы именно с этим навыком.
Неумение красиво упаковать и подать информацию мешает мне как продакту эффективно коммуницировать наверх и продавать идеи, потому что тут привыкли к абсолютно другому уровне продажи идей
Поэтому часто приходится находить внешнюю помощь из тех, кто это делать умеет, и перепаковывать результаты ресерчей и проектирования фичей так, чтобы они были понятны и вызывали желание в них вложиться
Ну и приходится учиться вписывать в эту коммуникацию встроенный лейтмотив про то, как все было непросто, но мы справились, и какая команда молодцы
3/ Оптимизм
Этому, наверное, научиться нельзя, и возможно неверное списывать на менталитет, потому что и в РФ куча оптимистов :)
Но это важная штуковина, которая реально помогает в создании продуктов, и к которой условные датчане сильно более склонны
Продолжительное время в любом обсуждении я невольно ловил себя на мысли что я (и часто мои немногочисленные русскоговорящие коллеги) расписывают, почему что-то НЕ полетит :) а мои датские коллеги уверены во всем и всегда
Например, предлагается хак вместо полноценного технического решения
И первая реакция — посмеяться и забыть, потому что it can't possibly work
А в итоге оказывается, что мало того, что оно work, так еще и юзеры довольны и не видят разницы
Или в качестве основного прогноза выбирается настолько оптимистичный сценарий, что звучит он примерно так же реалистично как книги про Гарри Поттера
и, в итоге, именно он и сбывается
4/ НИКОГДА НЕ НОЙТЕ
Это стоит сделать правилом по жизни; но если в СНГ принято выслушать и подставить плечо, то в Дании никому не интересно слушать про ваши неурядицы
вас конечно вежливо выслушают, но при этом сильно удивятся
в общем, нытье — для close friends и психотерапевта
5/ Поставьте четкую границу между работой и жизнью
Скорее всего, если вы не фаундер стартапа/не ценный сотрудник с хорошим опционом — не стоит отвечать на е-мейлы в 3 часа ночи и фигачить по 80 часов в неделю
Как минимум, это никто не оценит, и в приличном месте скорее спросят "а зачем ты так"
Как максимум — тихо решат, что наверное в России принято работать много и бесплатно, и в будущем будут требовать именно такого отношения
Тред #13
@produnderhood При этом, когда я работал в датской компании, сами датчане говорили что им в Дании нравится и никуда из неё они не собираются. Вероятно, они видят что получают за свои налоги :)
все так, датчане любят Данию :)
вот только датчане, которые смогли вылезти из middle class и разбогатеть, про это забывают и быстренько переезжают в Швейцарию :) twitter.com/starkyru/statu…
Всем хорошей пятницы!
Про что поговорим сегодня?
🤔
53.3% Remote работа🤔
46.7% Продуктовые практикиОкей, победила удаленочка
Сегодня расскажу про свой опыт удаленки и работы из путешествий, remote-first компанию и немножко про процессы
Сразу небольшой опрос — понятно, что ковид отправил по домам всех, а к чему пришли после ковида?
🤔
56.6% Full remote🤔
11.8% Только офис🤔
31.5% 1-2 дня из домаТред про удаленную работу
1/ Мой первый опыт удаленной работы — 2014 год, когда меня полностью удаленно наняли, и я впервые увидел своих коллег примерно через полгода
С тех пор я завел трактор в офис, вернулся в РФ на удаленку и завел другой трактор в офис заново
2/ Я работал как из нормального home office, так и из путешествий; возвращал из небытия сервачки сидя с 3g на скамейке на мелком тайском острове, менял 5 стран за месяц, в общем, веселого было много
3/ Пишу эту маленькую предысторию потому, что за эти годы у меня сформировался четкий взгляд на удаленку как явление
конечно же это мой личный bias (как и все, изложенное на неделе), и совсем не претендует на объективность :)
4/ Мне кажется, что глобально в IT есть 2 разных режима работы:
генерация нового и подготовка
воплощение в жизнь этого самого нового
Вот для 2. удаленка, кмк, подходит отлично; для 1. скорее не подходит совсем
5/ Конечно, есть оговорки — есть хорошие условия для работы из дома, нет совсем маленьких детей
Но в целом лично я очень продуктивно работаю вне офиса, если понятно что делать
Ресерчи, работа с требованиями, работа с данными, роадмапы, стратегия, и все, что исключает общение
6/ Проблемы начинаются со звонками
любое общение в meet/zoom очень сильно высасывает силы; есть ощущение, что общение в таком формате дается намного сложнее, чем вживую
7/ За 2021 год выяснилось, что я такой не один, а самые сложные звонки — это если в обсуждении участвует 4+ человек
Ну и конечно же чем дольше, тем сложнее
8/ Еще мы заметили, что есть градация
Удаленнообсудить как дела — изи
Рассказать новости и получить фидбек — норм
Донести радикально новую информацию — сложнее, и сложность растет с кол-вом участников
Вместе скоупить что-то сложное и неформализуемое — ultra hard
9/ При этом вся компания изначально была (и будет) remote-first
Разработчики не только в Копенгагене, но еще много где, есть офисы в США, и еще другие люди в разных точках земного шара
Мы решили, что конкретно продуктовая команда физически будет в Копенгагене
10/ Причины следующие:
Несмотря на кучу классных бонусов, которые дает remote (доступ к глобальному рынку и крутым людям где угодно), 2021 год показал, что брейнстормить лучше вместе, делать это удаленно ресурсоемко и накладно;
эпизодически это окей, но на постоянной основе нет
еще одна причина — напомню, что мы делаем девайсы, и зависим от физического мира
прототипы, HW лаборатория, миллион разных экранов, разные wifi сети, 3d принтеры — это все крайне сложно заменить в home office
опять же, временно прожить можно, долго — будут проблемы
сейчам мы балансим работу поровну, пару дней из дома, еще пару удаленно
но на всех встречах, на которых решается что-то средне важности и выше, стараемся быть физически
я знаю, что даже в Копене мы не одиноки в таком решении, и многие компании (Apple и Netflix как ярчайшие примеры) не готовы к полной удаленке для определенных ролей
поэтому я совсем не верю в радужную историю про то, что скоро абсолютно все (даже в IT) будут на полном ремоуте и наступит коммунизм
точнее, для тех, кто работает с кодом (и до определенного уровня принятия решений) ремоут более возможен
в продукте, скорее, нет
10/ Хотя, судя по последним новостям и слухам, удаленку со временем сделают сложнее жадные государства
уже сейчас активно обсуждают, как же снять денег с условного чувака из Румынии, который работает как контрактор на Данию, но платит налоги в Румынии :)
11/ Еще один момент, из-за которого мне не нравится идея полной удаленки — ты говорящая голова в зуме, и мимо проходит почти вся неформальная жизнь
То есть конечно можно быть прям вообще везде, читать и писать во все чаты и быть проактивным
Но это все равно не то :)
Суббота
12/ Вне офиса есть очень смутное представление о том, кто вчера всю ночь бухал и сегодня не в состоянии принимать нормальные решения, кто с кем дружит, с кем можно пойти выпить кофе и заодно обсудить возможные решение текущих проблем
И я сейчас не про политику, а про здоровые неформальные связи и человеческие отношения. Если вы хотите играть в политику на удаленке, то абсолютно любой человек on-site вас сожрет и выплюнет
13/ В мою текущую компанию меня нанимали как Head of Quality, и я 1.5 года на удаленке строил процессы, нанимал людей, общался со всеми и узнавал за продукт, делал автоматизацию
Я не смог бы сделать НИЧЕГО из этого, если бы не приезжал каждый месяц в первое время
14/ Короче, если хочется круглый год серфить на Бали и быть совсем непривязанным, но при этом расти в профессии и ответственности, мне кажется, что лучше все же писать код
15/ Я знаю офигенный обратный пример, в котором моя хорошая знакомая полгода работала Agile-coach’ем с Бали и умудрялась консалтить кучу людей и проводить митинги на десятки через Зум и Миро
могу только сказать, что лично мне до таких высот не добраться никогда :)
Тред #14
Расскажите, как вам вообще удаленная работа конкретно в продукте? Стало лучше, стало хуже?
А я на сегодня все;
завтра с утра расскажу про договоренности, правила и процессы, которые помогают нам эффективно работать удаленно, не терять информацию и вообще успевать все и везде (ну почти)
К сожалению, тред с утра не вышел, потому что день пошел не по плану, но обязательно распишу позже
Воскресенье
В общем, к сожалению, тред про ремоут не сложился :(
Я его писал и так, и эдак — слишком много информации, некоторая из которой мне кажется прям супер common sense, да и вообще не пишется. Поэтому не буду мучать себя и других
Вместо этого напишу маленький тред про полезную штуку, которую мы используем в продуктовом процессе, и еще расскажу, какие околопродуктовые блоги нравятся мне (и, возможно, понравятся вам)
Тред про то, как мы работаем с пользовательским фидбеком
1/ Когда я читаю инфу про продуктоведение на русском, у меня создается ощущение, что нет бога кроме кастдева и Замесина пророка его (no pun intended, очень уважаю то, что делает Иван)
2/ У нас сложилось как-то иначе
С одной стороны, для пользовательских интервью и UX ресерча у нас есть отдельный человек, который занимается только этим (плюс все продакты разговаривают с пользователями), и мы искренне считаем, что общение это нужно и важно
3/ С другой стороны, в нашем процессе результаты user interview никогда не являются определяющими, плюс не менее важные вещи мы узнаем из кучи других источников
4/ Источники:
- мнение продуктовой команды
- мнение маркетинга/сейлзов
- заметки по user interview
- фидбек из NPS опросов
- фидбек от юзеров с PoC
- саппорт тикеты
- баги от юзеров
- инфа по сделкам (passed/failed)
- новости по рынку и конкурентам
- оценки стриминговых сессий
5/ Вся инфа выше — некислый объем разрозненной информации, которая генерится и меняется каждый день
Проблема была в том, как засунуть все эти замечательные вещи куда-то, чтобы можно было:
а) постпроцессить
б) хранить всю историю
6/ В итоге для сбора фидбека мы используем Productboard; это довольно классная тула, которая позволяет лить в одно место фидбек из кучи каналов (Slack, Jira, Intercom, любые e-mail, пайплайны в Salesforce)
7/ В Productboard очень крутой процесс обработки фидбека — каждый пользовательский инсайт можно тегнуть и прилепить в фиче, плюс можно различать по тому, откуда прилетел фидбек (внутренний или внешний)
8/ Интеграция с Salesforce позволяет сегментировать клиентов по любым кастомным полям (например, сектор рынка и страна), чтобы четко выделить вертикали, в которых мы работаем, и сравнивать, как отличаются (или совпадают) инсайты
9/ Мы ввели простое правило — если есть фидбек, который должен быть принят к сведению, он идет в Productboard.
С точки зрения процесса это очень просто — есть плагины для браузера и интеграции со всеми тулами. Если фидбек в PB не улетел, значит фидбека и не было 🙂
10/ В итоге на дистанции мы очень многое можем сказать про каждую фичу — кто и что просил, с какой частотой, каков реальный уровень боли каждого конкретного реквеста, какие сегменты что хотят, идет ли фидбек от юзера или напрямую от Sales/CS
11/ Потом все идеи можно разложить по весам (количество фидбека + compound value всех отдельных кусочков фидбека по шкале от -2 до +2), так что если есть любители построить что-то вроде RICE — точно останетесь довольны
12/ Поскольку Productboard умеет еще и в roadmapping, получается очень удобное комбо для собрать фидбек + построить что-то на его основе
Единственное, что мы туда не прикрутили, это quantified метрики (типа NPS оценок и рейтингов), потому что не влезает в общую картину
13/ Процесс такой — весь фидбек сначала летит в общий пул
Дальше раз в неделю можно пройтись, прочитать фидбек, ничего не делать с бесполезными сообщениями, и замапить на идеи полезные
14/ Естественно бывает фидбек, который необходимо обсудить раньше, чем пока продакты доберутся до продактборда
Для этого у нас есть каналы вроде #^productname-feedback, в которые летит все, о чем стоит узнать за часы, а не за дни
15/ Дальше по куску фидбека либо сразу идет какой-то action (с обязательным тикетом в Jira по завершению дискуссии в треде), либо он летит в Productboard
16/ Мой любимый источник фидбека — это саппорт тикеты. Поверьте, вы нигде не узнаете столько нового о своем продукте и о жизни в целом :)
17/ Еще одна штука, которую я успешно абьюзил — общение с юзерами по e-mail
В нашем сегменте есть 2 особенности:
У тех людей, которые могут сказать что-то полезное, мало времени
Мы не про "а что бы такого еще отресерчить и продать", у бизнеса есть конкретные проблемы
18/ Поэтому, когда примерно понятна проблема, и есть Х способов ее решить, я делал так:
- смотрел, кто оставлял фидбек
- собирал пул контактов
- проверял с Sales/AM, что чуваки адекватные и с ними можно общаться
- засылал контактам письма (что-то вроде "добрый день, мы почти знакомы через $username; у меня есть 7 конкретных вопросов, расскажите что да как; если хотите лично, можем и лично, но лучше бы нет")
19/ В результате 80% людей писали крутые структурированные ответы на вопросы (что мега круто и сразу превращается в actionable feedback)
Были люди, которые писали чепуху, но очень небольшое кол-во людей настояло на встретиться и поговорить
20/ Я уверен, что если мы шейпим идею с высоким уровнем неопределенности, такой вариант не проканает
Но если какая-то определенность уже есть, и нужно подтвердить/опровергнуть какие-то конкретные вещи, можно сэкономить кучу времени на интервью и превращению их в текст
Понедельник
21/ Ну и конечно, фидбек не значит ничего. Если что-то просят очень много, но оно не влезает в стратегию, то сколько бы не просили — мы не будем этого делать :)
22/ Естественно, верно и обратное. Если постоянно льется большое количество фидбека, который тематически связан, но мы с ним почему-то ничего не делаем — стоит задуматься, что мы стратегически делаем не так. Правда, о последнем лучше регулярно задумываться раз в 3 месяца :)
Тред #15
Что ж, неделя закончилась. В заключение хочу посоветовать околопродуктовые блоги и людей, которые я регулярно читаю и считаю полезными
1/ mironov.com — классный блог про B2B;
вот, к примеру, крутецкая статья про хардкорный B2B vs B2C mironov.com/ent/
2/ reforge.com — ниже постил статью про аналитику от них же; у этих ребят классный контент про продукт на большой диапазон тем, и по отзывам отличные курсы (правда, очень дорого, гопрактис там даже рядом не стоял по ценнику)
3/ about.gitlab.com/company/ Gitlab Handbook. Искренне удивляюсь, как вообще чуваки смогли выложить в паблик кучу инфы про все свои процессы. Как минимум раздел про продукт заслуживает хорошего вдумчивого чтения
4/ Блог gibsonbiddle.medium.com бывшего VP чего-то там в Netflix. Нравится подача и инфа по делу
5/ gopractice.ru, конечно (блог)
6/ antonz.ru
@nalgeon один из самых крутых и грамотных людей, с которыми мне посчастливилось что-то сделать вместе
контент всегда топовый (правда, местами более технический, чем обычно нравится продуктовикам)
Тред #16
Твиттера у меня нет, но есть
- Instagram (doehalozanosi), там можно смотреть Данию изнутри
- TG at@angelooooook
Еще, по законам тестирования спроса, я сделал канал t.me/lovedeathdevic…
Он пустой, но если было интересно — ставьте колокольчик и вот это все
Пока! :)
