Архив недели
Понедельник
Привет! Я Антон Куликов — директор по продуктам Selectel. На этой неделе поговорим о рациональном управлении продуктами, невозможности коммуникации и продуктивных конфликтах.
План на неделю:
ПН, 14.09 — расскажу про облака, серверы и дата-центры: что и на каком этапе жизни проекта вам подойдет лучше всего.
ВТ, 15.09 — обсудим неочевидного кандидата в главные метрики для менеджера продукта — уровень уверенности.
План на неделю:
СР, 16.09 — попробую убедить вас в том, что метрики не так важны, как вопросы, которые вы сами себе задаете.
ЧТ, 17.09 — заведу любимую пластинку про невозможность коммуникации (как с командой, так и с клиентами).
ПТ, 18.09 — предложу по новому посмотреть на конфликты и то, как с их помощью развивать команды, процессы, продукты.
СБ, 19.09 — пока еще не решил ;)
ВС, 20.09 — буду постить ссылки на истории успеха наших клиентов — потому все-таки именно в этом наш главный результат...
Поехали: продукты для it-инфраструктуры начинаются с аренды стоек в дата-центре и в своем развитии добрались уже до бессерверных Функций в облаках. Сегодня расскажу когда и что выгоднее брать.
Функции (#FaaS) это serverless-продукт. Сервера нет, а польза остается. Платите только за пользу.
#FaaS Функции отлично подходят для проверки прототипа: загружаете код, настраиваете способы запуска, получаете результат — за тестовый сервер при этом платить не нужно (дешевле).
#FaaS Функции вам так же понадобятся когда ваш продукт потребует быстрого масштабирования, здесь оно случится (в любую сторону) без вашего вмешательства.
#FaaS Если функции будут работать постоянно (много вызовов, замена виртуалке), то это будет дороже чем арендовать сервер, но перечитайте предыдущий твит ;)
Рядом с функциями работают управляемые базы данных — #DBaaS. Этот сервис обеспечивает настройку и бэкапирование ваших Postgress, MySQL, Mongo, Redis и любых других БД.
#DBaaS пригодится командам, которые не хотят думать о том, как самостояльно обеспечивать их настройку и сохранность. Обязательное требование — трехкратная репликация, nice to have — откат до любого момента в истории.
Managed #Kubernetes — для тех кто нанял себе администратора, а тот не хочет тратить время на разворачивание кубера руками. Как и в других managed-сервисах, провайдер тут отвечает за работоспособность, а админу остается только решать сколько подов запустить под мастер-нодами.
Виртуальные серверы и сети вокруг них, включая балансировщик, объектное хранилище, CDN, хостинг dns-записей, мониторинг доступности — базовые составные части Облака. Если решите жить в облаках, убедитесь, что у вашего провайдера есть весь необходимый набор. #cloud
Облачная платформа подходит для любых проектов и задач, но особенно хорошо заходит командам, которые пока (исторически) или совсем (идеологически) не готовы самостоятельно лезть на уровень железа. #cloud
Если ваши админы и программисты готовы самостоятельно настраивать, поддерживать и выжимать все соки из железной инфраструктуры, то выделенные серверы — ваш выбор. Заодно сэкономите денег. #baremetal #servers
Для ребят, которые уже готовы инвестировать в собственное железо, есть колокейшн: приносите свое оборудование и арендуете под него один юнит, всю стойку или целый этаж в дата-центре. #colocation
Наконец, тем, кому нужно правильно хранить важные персональные данные клиентов, приходится брать серверы в аттестованных Облаках или ставить свое оборудование в специальных сегментах дата-центров. #152fz
В целом, на рынке уже сложился набор продуктов подходящих под конкретные задачи проектов на любой стадии, от тестирования MVP до выхода на IPO. Вам остается только выбрать провайдера, вместе с которым вы сможете пройти весь этот путь ;)
Если вам нужна будет помощь с выбором или решите потестировать что-то из наших услуг — пишите в ТГ @SelectelTgbot (там на самом деле человек отвечает) — ребята подскажут и помогут.
Что вы используете для своих проектов?
Вторник
Ок, вчера все было достаточно однозначно... сегодня попробую поразжигать про рациональное управление продуктами.
Сначала дисклеймер: дальше будет намеренная проблематизация.
Если вас что-то заденет, то именно для этого я и пишу.
При этом я сам в разной степени «грешен» по всем пунктам, именно поэтому я думаю, что могу о них писать.
Начнем с тезисов (буду рад если вы меня переубедите):
— продуктовый подход должен быть самым рациональным и научным из всех, но слишком часто превращается в хорошо оснащенный карго-культ
— менеджеры продуктов должны принимать решения, но многие просто не знают как это делать
— менеджеры продуктов должны следить за метриками, но часто они либо не знают, что с этими показаниями делать, либо думают, что можно на основе этих показаний можно что-то решать
Карго-культ это «проверять гипотезы через эксперимент», по большому счету не зная, ни что такое гипотеза, ни что значит проверять, ни при чем тут эксперимент.
Карго-культ это «мониторить метрики», не понимая как эти данные получаются и что с ними на самом деле нужно делать.
Карго-культ это «принимать решения», не зная, как на самом на самом деле это происходит.
Уже узнали себя? )
Теперь тезисы-2 (буду рад если поможете мне их уточнить):
✓ Главный инструмент менеджера продукта — научный подход.
✓ Главное содержание работы менеджера продукта
— строить систему знаний о продукте.
✓ Главная метрика для менеджера продукта — уровень уверенности в конкретном представлении (шире, уровень соответствие модели той реальности, которую она описывает).
✓ Решения это просто «educated guesses» — обоснованные предположения. Не больше, но и не меньше.
✓ При принятии решений главные задачи менеджер продукта:
а) включать «медленное» мышление;
б) не давать себе скатываться в воспроизводство простых паттернов и следование легким эвристикам;
в) не выдавать одно за другое.
Про что интересно?
Среда
Научный метод это способ эмпирического получения знаний. Берем исходную, принципиально опровержимую, модель и с помощью серии наблюдений и экспериментов изо всех сил пытаемся найти ее границы, понять, где она ломается, в каких условиях не работает. (Поппер)
Таким образом, с каждой проверкой, с каждым новым свидетельством, по чуть-чуть увеличиваем уровень уверенности в том, что модель действительно описывает какой-то кусок реальности. (Байес)
Если сама модель при этом обладает прогностической ценностью, — бинго! — мы получили знание. Из набора таких моделей можно строить систему знаний о продукте.
Теперь про проблемы. Первая опасность тут в том, что нам естественным образом хочется думать, что знание булево по своей природе: «true|false», «знание есть или знания нет», а на самом деле оно всегда вероятностно.
«99,8 % [уверенности в том] что сервер не упадет дольше чем на полтора часа в месяц» и всего «0,2 % [уверенности в том] что Коля поймет эту цифру правильно, когда будет этот сервер покупать» (пример намеренно искажен)
Про научный метод, уровень уверенности и рациональное управление продуктами (все сообщения в одном трэде):
Научный метод это способ эмпирического получения знаний. Берем исходную, принципиально опровержимую, модель и с помощью серии наблюдений и экспериментов изо всех сил пытаемся найти ее границы, понять, где она ломается, в каких условиях не работает. (Поппер)
Таким образом, с каждой проверкой, с каждым новым свидетельством, по чуть-чуть увеличиваем уровень уверенности в том, что модель действительно описывает какой-то кусок реальности. (Байес)
Если сама модель при этом обладает прогностической ценностью, — бинго! — мы получили знание. Из набора таких моделей можно строить систему знаний о продукте.
Теперь про проблемы. Первая опасность тут в том, что нам естественным образом хочется думать, что знание булево по своей природе: «true|false», «знание есть или знания нет», а на самом деле оно всегда вероятностно.
«99,8 % [уверенности в том] что сервер не упадет дольше чем на 1,5 часа в месяц» и всего «0,2 % [уверенности в том] что Коля поймет эту цифру правильно, когда будет этот сервер покупать» (пример намеренно искажен)
Вторая проблема в том, что если мы провели один эксперимент и получили свидетельства в пользу того, что наша гипотеза верна, — то мы, конечно, молодцы. Но если мы при этом думаем, что получили настоящее знание, то возможно мы немного поторопились.
Если мы прошли сквозь темную комнату с завязанными глазами — мы узнали только то, что через нее можно таким способом пройти. Но первое знание о том, что в этой комнате, оказывается, есть какая-то мебель, мы получим только когда расшибем свою коленку о первый попавшийся стул.
Наконец фундаментальная проблема заключается в том, что мы имеем дело с постоянно меняющимися людьми, живущими в постоянно меняющихся обстоятельствах. Поэтому соблюсти критерии научности и произвести настоящее объективное знание нам ой как трудно.
Поэтому надо честно признаться: даже если мы стремимся использовать научный метод, наши исследования и эксперименты намного ближе к психологии (с ее кризисом воспроизводимости), чем к медицине (с ее многоэтапным двойным слепым рандомизированным методом). Про физику вовсе молчу.
— Но если на подлинную научность знаний претендовать не приходится, то всё расходимся?
— Нет, конечно! Продолжаем работать и берем из научного метода то, что можно к нашим реалиям приложить: байесовский метод.
Тогда рациональным методом управления продуктами будет следующий: формируем систему знаний, в которой каждому нашему «представлению» присвоен «уровень нашей уверенности» в том, что оно описывает реальный мир.
После этого фиксируем, что мы можем сделать, чтобы этот уровень увеличить, каких свидетельств нам не хватает. Но на этом не останавливаемся. Обязательно фиксируем, какие свидетельства нам позволят понять, что это знание к реальности не имеет отношения. И начинаем их получать.
И тогда, через некоторое время, вместо «клиенты не понимают, что значит SLA — 99,8 %» в системе знаний о продукте появляется намного более длинная запись:
«[Набор свидетельств] позволяет нам с [определенной степенью уверенности] утверждать, что [определенные] клиенты не понимают смысла процентного значения SLA, и мы продолжим уточнять это утверждение с помощью [набора воспроизводимых в течение длительного времени действий]»
По мере появления новых свидетельств такое знание будет дробиться: «Айтишники понимают», «Бухгалтеры нет» и т.д. Но, по крайней мере, в такой формулировке мы не будем выдавать свое мнение за факт жизни. И всегда будем знать, как мы к нему пришли и что нам дальше с ним делать.
Научный метод — единственный способ получения объективного знания. В управлении продуктами такой уровень зачастую недостижим. Поэтому пользуемся байесовским методом и строим систему знаний из вероятностных моделей, обладающих прогностической ценностью.
Ок, сегодня будет тема попроще — как могут вредить метрики ;)
Самая простая ошибка: «после не значит вследствие». Сделали что-то в продукте — изменилась метрика — засчитали себе win. Подкрутили еще — метрика просела — lose. Можно ли на этом основании делать какие-то выводы? Кажется, что «да», а на самом деле «пока не понятно».
В самой первой главе в Симулятора (@oleg_gpio) есть пара хороших задач про понимание, где причинно-следственная связь, а где только возможная корреляция. По мне так очень недооцененное знание, особенно в приложении к работе с метриками.
Связанная ошибка — считать, что изменения метрики что-то подтверждают. Мне кажется, что они всего лишь дают довольно слабые дополнительные свидетельства.
В первом случае вы себя убеждаете в собственной правоте (подкрепляете иллюзии). Во втором — продолжаете осторожно повышать уровень уверенности в том, что проверяемая модель описывает реальность. Для первой задачи обычно хватает одного наблюдения, для второй точно нужна их серия.
Третья ловушка — слишком внимательно смотреть на метрики и слишком сильно реагировать на их изменения. Довольно очевидно, как это может привести к переключению в исключительно реактивный режим.
Просело количество новых посетителей на сайте, начали думать как поправить рекламу; упал средний чек, начали думать про апсейл; увеличился отток, начали думать, какую новую фичу запилить, чтобы она повысила ретеншен.
Все это время уровень конверсии из регистрации в платящих клиентов никак не менялся, поэтому про него и не думали.
Задачи, которые кажутся срочными, легко и естественно вытесняют задачи, которые на самом деле являются важными. Так устроен наш мозг — он с радостью реагирует на актуальные стимулы, тут же забывая о более далекой перспективе.
Проактивный режим, на мой взгляд, включается, только когда мы начинаем регулярно задавать себе вопросы про будущее.
В таком режиме, к вопросу «Сколько новых клиентов пришло в прошлом месяце?» добавляется не только вопрос «Что нам сделать чтобы привести больше клиентов в следующем?», но и такие вопросы как «Где у нас основные точки для роста?» и «Чем мы сейчас не занимаемся, а стоило бы?»
«Закопавшись в операционке, забыли про стратегию», — ровно об этом. Слишком пристальное наблюдение за метриками легко провоцирует первое и вполне может вытеснять второе.
Обо всем этом можно было бы и не писать, но метрики настолько полезная штука, что лишний раз вспомнить/проговорить потенциальные риски, которые с ними связаны, — кажется никогда не повредит.
Четверг
Трэд про коммуникацию, которой все постоянно занимаются, не смотря на то что она практически невозможна.
Менеджер продукта — профессиональный коммуникатор.
Систему знаний о продукте невозможно создать без коммуникации с другими людьми; система знаний не нужна, если ее составляющие невозможно в процессе коммуникации передать другим людям.
Качественная коммуникация со всеми кто работает с продуктом (клиенты, команда, стейкхолдеры и т.д.) — ответственность менеджера.
Главное что мы должны понимать — успех коммуникации случается вопреки множеству предпосылок (то есть это практически чудо).
Против коммуникации: сложности на пути доставки сообщения; разные словари и разный опыт участников; несовпадающий контекст; плохие коммуникативные навыки; разные результаты интерпретации и т.д. и т.п.
В итоге понимание случается так редко, что мы привыкаем этого не замечать.
Культура при этом дает нам кучу способов сделать вид, что коммуникация случилась и демотивирует демонстрацию обратного.
Сказать: «Я не понял, повторите, пожалуйста», — социально намного менее приемлемо, чем покивать, когда на самом деле ничего не понятно.
Менеджер продукта, результаты которого зависят от успеха множества разных ситуаций коммуникации, — должен помнить об этом (понимание — чудо, всем проще сделать вид) и делать все, чтобы такие ситуации не оставались для него незамеченными.
Иначе раз за разом будет получаться одно и тоже: мы не поняли клиента, команда не поняла нас, стейкхолдеры вообще ничего не поняли, а время и деньги потрачены, продукт сделан и результата нет.
Для начала нам всем нужно выработать у себя привычку оценивать успех каждой ситуации коммуникации:
— по-настоящему расстраиваться (но не сдаваться), когда взаимопонимания не случилось;
— по-настоящему радоваться, когда понимание произошло.
После этого менеджер продукта должен осознать, что понимание проблем коммуникации и способов их преодоления — это сфера его профессиональной компетентности.
Этому нужно учиться также как исследованиям, аналитике и всему остальному.
А дальше все просто:
Нужно всего лишь понимать разницу между разными режимами и способами коммуникации; уметь договариваться о понятиях; синхронизировать опыт и контекст участников; уметь слушать и слышать; хорошо формулировать свои сообщения; фиксировать результаты и оценивать успех коммуникации...
И тогда шансы на то что успешная коммуникация будет случаться все чаще и чаще — немного повысятся.
Не больше, но и не меньше )
Пятница
Продуктивные конфликты — лучший способ узнать что-то новое и разрешить настоящие противоречия. (трэд)
Пока у вас есть только довольные клиенты, пока в команде все хорошо, а у стейкхолдеров нет к вам вопросов — все ок.
Вот только все это лишь слабые свидетельства в пользу того, что все действительно идет как надо.
О чем-то важном в таком режиме вы рискуете не узнать никогда.
К сожалению, общество с малых лет приучает нас «жить дружно», поощряет идти на компромиссы, избегать конфликтов. Маркирует конфликтное поведение в целом как нежелательное — развивает в нас конфликтофобию.
Худшее, что может делать менеджер продукта это избегать конфликтов или пытаться их «гасить».
Попытки «разруливать» (обычно в чью-то пользу) обычно тоже приводят к плохим результатам, т.к. основываются на представлении о том, что конфликт это что-то нежелательное, плохое.
⚡️ Конфликт это единственный эффективный способ удерживать противоречие в процессе его разрешения.
Этим он и отличается от подавленного недовольства, деструктивной конфронтации или разрыва отношений.
Менеджер продукта должен уметь использовать конфликтные ситуации продуктивно.
Для начала нужно уметь разделять: материал конфликта (кто что сказал, что сделал), предмет (противоречие, по поводу которого все это происходит) и наши переживания обо всем этом.
Как только от слов и переживаний мы опускаемся на уровень базового противоречия — возникает польза.
Менеджер продукта в отношениях со стейкхолдерами, командой и клиентами должен уметь за эмоциями и словами видеть предмет конфликта — что с чем на самом деле сталкивается.
Как правило, конфликты возникают там где не сбываются ожидания или нарушается автономность участников.
И то и другое провоцирует сильнейшую естественную реакцию, которая канализируется либо в скрытое недовольство, либо в конфликтное поведение. Второе — намного лучше.
Возникший, проявленный конфликт это шанс на то чтобы разрешить создавшее его противоречие, понять важные для людей границы, уточнить взаимные ожидания.
Менеджер продукта, который умеет добираться до предмета конфликта, резко повышает свои шансы на успех коммуникации и получение нового знания.
Первый шаг к на пути к этому — изменить свое отношение — сменить конфликтофобию, на конфликтофилию ))
Суббота
Сегодня попробую предложить вам задачи: ситуации, для решения которых не будет лишним перечитать трэды предыдущих дней.
Посмотрим, как пойдет )
🧐 Вы добавили в онбоардинг дополнительный шаг и итоговая конверсия в соотв. ветке эксперимента снизилась на X %.
❓Как вы оцените этот результат? Почему?
🧐 Вы решили проверить гипотезу: «Форма, разбитая на несколько шагов, будет работать лучше, чем форма на одном экране».
❓Как будете действовать?
🧐 На встрече с тремя другими фаундерами вы решаете, что пора развивать новое направление в вашем продукте.
❓С чего начнёте?
🧐 Сотрудник службы поддержи пишет вам в телеграм вопрос о том, как работает новая фича продукта.
❓ Как вы ему ответите, что сделаете после?
🧐 Руководитель юридического отдела предлагает вам встретиться, чтобы обсудить изменения в законодательстве, затрагиващие ваш продукт.
❓Сразу назначите встречу?
🧐 Ваш коллега-продакт присылает вам письмо с перечнем вещей, которые на его взгляд можно улучшить в вашем продукте.
❓ Как поступите в этой ситуации?
Понедельник
Продуктивные конфликты — лучший способ узнать что-то новое и разрешить настоящие противоречия. (трэд)
Мета-трэд за неделю:
— тезисы о профессии twitter.com/produnderhood/…
— рациональное управление продуктами twitter.com/produnderhood/…
— метрики и их риски twitter.com/produnderhood/…
— невозможность коммуникации twitter.com/produnderhood/…
— продуктивные конфликты twitter.com/produnderhood/…
🙏🖖