Architec.Ton is a ecosystem on the TON chain with non-custodial wallet, swap, apps catalog and launchpad.
Main app: @architec_ton_bot
Our Chat: @architec_ton
EU Channel: @architecton_eu
Twitter: x.com/architec_ton
Support: @architecton_support
Last updated 2 weeks, 3 days ago
Канал для поиска исполнителей для разных задач и организации мини конкурсов
Last updated 1 month ago
ТОП-1 причина, почему организационная структура в продукте у вас неэффективна
Давайте представим, что вы — глава какого-нибудь маркетплейса. У вас есть набор важных проблем, которые нужно решить, направления роста и т.д. Под это вы как-то эволюционно собрали структуру продуктовых команд... и работаете так уже 3 года.
Пусть у вас есть кластеры: Buyers, Sellers, Trust and Safety, Монетизация, команды мессенджера, CRM и т.д.
—————
Теперь давайте перенесёмся на эти 3 года вперёд...
❓Как на самом деле происходит планирование и постановка OKR?
Кластеры и команды внутри своих зон ответственности ищут зоны роста, приоритизируют их, выбирают самые важные инициативы и ставят их в OKR.
А теперь представьте, что:
➡️ Эффект от инициатив Buyers и команды мессенджера стал нулевым (всё, что можно было оптимизировать, уже сделано, сейчас "пришиваем рюшечки").
➡️ А вот в Sellers и TnS обнаружилось "непаханное поле" (или просто инициативы в этих зонах дают результаты на порядок выше).
💡Вы можете сказать:
"Пусть тогда кластер покупателей (Buyers) берёт инициативы кластера продавцов (Sellers)."
❌А вот и не сработает!
Текущая структура сама по себе накладывает ограничения — не только ресурсные, но и психологические.
❓Какие такие психологические ограничения?
➡️ Глава кластера Покупатели сам не захочет, чтобы ему помогали в его зоне ответственности, и, скорее всего, будет препятствовать этому.
➡️ Глава кластера Продавцы не захочет лезть в чужую область, так как отвечает за совершенно другие метрики.
—————
Что с этим всем делать делать?
1️⃣ Оргструктура должна всегда соответствовать текущим вызовам и направлениям роста компании. Для этого у вас должна быть стратегия! 🤓
2️⃣ Не готовьте стратегию как аппликацию стратегий подразделений компании. Это порочная практика. С таким подходом вы путаете причину и следствие ("старая структура" начинает влиять на "новую стратегию")
3️⃣ Ежегодно задавайтесь вопросом: "Идеальна ли текущая структура для реализации нашей стратегии?"
❗️Не бойтесь менять оргструктуру под текущие потребности. Структура — это инструмент, а не догма. Она не высекается в камне один раз и навсегда.
Важный аспект требований к базовому функционалу продукта, о котором часто забывают... или на который часто "забивают"...
Когда вы в последний раз слышали что-то о "атрибутах производительности", "технических характеристиках" или "проверке на соответствие нефункциональным требованиям"?
Порой наталкиваешься на то, что в некоторых продуктах есть явные проблемы с:
- быстродействием
- скоростью отклика элементов интерфейса
- устойчивостью к сбоям
- пропускной способностью системы.
—————
Представьте себе, если бы Google выдавал результаты каждого поиска за 5–6 секунд для 5% пользователей. Это просто немыслимо.
Для тебя, как для пользователя, это возмутительно. Ты не понимаешь, почему команды игнорируют такие важные аспекты базового функционала.
А причины, как правило, стандартные:
1️⃣ Продакт-менеджер считает, что за эти части системы отвечает техлид, хед инжиниринга или СТО.
Технические специалисты думают иначе: "У нас проблем нет, а если и есть, и они влияют на бизнес, пусть продакт-менеджер придёт и убедит нас, что эти проблемы существуют и их решение принесёт бизнес-вэлью."
2️⃣ Предыдущий фактор усиливает то, что технический перформанс продуктов и отдельных фичей часто измеряют и мониторят технари с помощью Grafana, Prometheus, New Relic...
Однако:
➡️ Часто мониторинг просто отсутствует: "Нет мониторинга — нет проблем."
➡️ Продакты считают эти метрики вторичными.
➡️ Не так уж просто правильно измерять, например, отклик элементов интерфейса (обычно всё сводится к: "Ну на бэкенде у нас запрос отрабатывает быстро").
➡️ Продакт-менеджер не может достоверно проверить корректность настроенных измерений (он лишь представитель выборки, а данные часто отображаются либо медианные, либо для определённой квантили).
3️⃣ Все эти проблемы усугубляются тем, что команда зачастую не ощущает себя командой и не принимает общей ответственности (см пороки команды по Ленсиони - вплоть до Безразличия к общему результату).
—————
*❓ Что же делать?*
1️⃣ Если ты этого ещё не сделал, проверь, отслеживаете ли вы основные аспекты перформанса продукта и базовых фичей.
2️⃣ Узнай, как происходит трекинг и что означают все эти цифры.
3️⃣ Проверь, есть ли у функционала проблемы в аспектах производительности (например, обрати внимание на 90-ю квантиль).
4️⃣ И, самое главное: строй эффективную команду! Команду, члены которой требовательны к себе и к коллегам. Команду, которая не боится конструктивных конфликтов. Команду, сосредоточенную на общих целях, а не на личных амбициях.
📕Как минимум, предложи каждому члену команды прочитать "Пять пороков команды" Патрика Ленсиони.
🧑🏻🎨 Пикассо ужинал в одном из ресторанов, и к нему подошла женщина. Она его узнала и попросила нарисовать что-нибудь прямо сейчас, в ресторане. Пикассо взял карандаш, салфетку и сделал набросок городского пейзажа. Когда женщина протянула руку в надежде получить рисунок, художник сказал:
"Он стоит десять тысяч долларов!"
"Но вы потратили на это десять минут!" — возразила женщина.
"Я потратил на это 50 лет!" — ответил художник.
—————
Когда коллеги, ментии или знакомые задают мне вопросы, связанные с продакт-менеджментом, я обычно довольно быстро нахожу в голове ответ. Ответ, который мне лично кажется капитанским и слишком очевидным... Неожиданно для себя я неизменно слышу: "Ого, вот это круто. Точно надо сделать именно так, даже не подумал(-а) об этом. Где ты этому научился?"
❓И правда, "где?" ❓
Всё дело в той самой насмотренности, в количестве кейсов, которые ты пропустил через себя. Нейроны принимают на вход информацию, обучаются — и вот у тебя уже есть улучшенная AI-модель для принятия решений и получения ответов на широкий спектр вопросов.
—————
При этом нейроны обучаются решать не все задачи сразу, а по областям: в разных кейсах и на разных уровнях. Для продакт-менеджера этот набор областей огромен.
❗️Поэтому я верю в то, что СРО, хед продукта или лид продукта НЕ могут быть хорошими руководителями, если они НЕ поработали достаточное время продакт-менеджером (хотя бы 4–5 лет). Они не обучили свои нейронки, не съели достаточно говна" на линейной менеджерской позиции. Есть и те руководители продактов, кто никогда не работал продакт-менеджером — пришли из консалтинга, маркетинга...
При этом проблемы будут возникать в обе стороны:
⬆️Снизу вверх. У подчинённых не будет уважения к решениям, которые принимает такой руководитель (особенно если он даже "миддла-то по скиллам не закрыл").
⬇️Сверху вниз. Такие руководители, не понимая, как и что работает, будут просто экспериментировать с людьми, процессами и продуктами. Очевидно, что для какой-то доли "пациентов" всё закончится неудачно.
—————
Вот вам старый добрый анекдот про такие "эксперименты" 😆
Приходит министр сельского хозяйства к М. С. Горбачёву.
— Михаил Сергеевич, беда, в стране куры дохнут.
— Ничего страшного, нарисуйте перед каждой курицей жёлтый круг.
Министр пожал плечами и ушёл. Через две недели приходит:
— Михаил Сергеевич, всё равно дохнут.
— Впишите в жёлтый круг зелёный квадрат.
Министр снова пожал плечами и ушёл. Через неделю возвращается:
— Михаил Сергеевич, дохнут ведь, совсем мало осталось.
— Впишите в зелёный квадрат красный треугольник.
Проходит месяц, встречает Горбачёв министра и спрашивает:
— А что же вы не заходите, не рассказываете, как там куры?
— Да понимаете, Михаил Сергеевич, все сдохли.
— Ах, как жаль, у меня ещё столько идей!
"Тварь ли я дрожащая или право имею..." 🪓
Ранее у меня был пост о болезни под названием "Нам нужно больше фичей!"
В нём я описал несколько факторов, которые приводят к этой проблеме.
—————
Если вы хотите изменить что-то в сложившейся системе, первый вопрос, на который нужно найти ответ:
❓"За что я реально отвечаю и какие полномочия у меня есть?"
Возможны несколько ситуаций:
1️⃣ Вы отвечаете за метрики (и с вас спрашивают за метрики), а решения принимаете сами:
- Вы согласовываете цели в метриках, которых нужно достичь за определённый период.
- Вы можете собирать информацию и вводные от стейкхолдеров, членов команды и т.д., но решение принимаете самостоятельно.
- Полная ответственность лежит на вас. Это значит, что вас могут уволить за недостижение целей (и с этим правилом игры нужно смириться).
2️⃣ Вы не отвечаете за метрики, вам говорят, что делать:
- Поздравляю — вы просто "фича-фабрика". Вы скорее проектный менеджер, чем продакт.
- Для многих это нормально, так как ответственность ограничивается только сроками поставки фичей на прод (и даже эта ответственность размазана на всю команду).
- Вы собираете информацию от стейкхолдеров, упаковываете её в ТЗ и выполняете задачу "в лучшем виде".
3️⃣ Вы отвечаете за метрики, но вам говорят, что делать:
- Эта ситуация часто начинается с фазы 1: "Мы нанимали сильного продакта, который должен приносить вэлью, улучшать метрики... Скажи, что нам делать — ты же профессионал!"
- Затем наступает фаза 2: "Я не согласен! Это делать не нужно. Делай другие фичи. Не спорь со мной — я тебя нанимал."
- И, наконец, фаза 3 - заключительная: "А что это с метриками всё плохо? Кто это наделал? Какие-то бесполезные фичи ты запускал! Ты не справляешься с работой."
—————
Как понять, какая ситуация у вас?
➡️ Откровенно поговорите с начальником или начальником начальника, а также со стейкхолдерами. Важно говорить открыто и подробно, используя понятный и приземлённый язык.
➡️ Проанализируйте историю взаимодействия: соответствовали ли договорённости реальной работе?
➡️ Учтите: если у вас нет инсайдеров в компании, то вероятность понять ситуацию на этапе собеседования есть, но она не слишком высока.
—————
Что делать, когда вы поняли, по каким правилам играете?
1️⃣2️⃣ Если это вариант 1 или 2, определите, устраивают ли вас эти правила. Некоторым продакт-менеджерам нравится первый вариант, другим подходит второй (по сути, это проектный менеджер с тайтлом "продакт").
3️⃣ Если это вариант 3, то у меня для вас плохие новости — фаза 3 может наступить в любой момент. Будьте готовы.
Почему болезнь "Нам нужно больше фичей!" прогрессирует?
Я очень часто сталкиваюсь с командами и компаниями, где существует непреодолимая тяга добавлять всё больше и больше фичей, не дорабатывая старые и не выделяя основные, на которых нужен фокус.
—————
Но если посмотреть на лидеров своих рынков *💪 *, то это те компании, которые хорошо реализовали базовый набор функций и долгое время фокусировались именно на нём:
➡️ Zoom — стабильность звонков, а не дизайн или дополнительные функции для командной работы.
➡️ Google (поисковик) — быстрая выдача релевантных результатов, а не смена фона главной страницы, игры, пасхалки, дудлы и т.д.
➡️ Telegram — быстрая отправка текстовых сообщений, безопасность, кроссплатформенность, а не видеозвонки и трансляция экрана (кстати, эти фичи у них до сих пор работают убого, так же как и каждый второй аудиозвонок уходит в пустоту).
Второстепенные функции добавляют удобство и развлечения, но их отключение почти не повлияет на основные продуктовые метрики. А вот если есть проблемы в базовом функционале, то, считай, существование продукта под большим вопросом.
—————
❓ Вы мне скажете: "Ну всё вроде логично. При этом хеды продуктов и топ-менеджеры — умные люди. Они этого не понимают?"
Есть несколько факторов, почему всё происходит нелогично:
0️⃣ Слабый продакт менеджер/продакт менеджмент.
1️⃣ C-level смотрят на конкурентов. Они хотят паритет с ними. Никто не задумывается о том, что конкретная фича приносит вашему конкуренту (может быть, она даже вызывает отрицательный рост?).
2️⃣ В компаниях больше принято хвалить за запуск новых фичей, чем за "починку или доработку" старых. У продукта больше шансов "публично маркетировать" свою работу над новой фичей, чем копаться в том, что уже есть. Тем более: "Ну исправил ты метрики старого, хоть и базового функционала. Ну ок, сам виноват, что было говно MVP на проде".
3️⃣ Предыдущий пункт подкрепляется тем, что мало кто из топов действительно понимает, что такое аналитика, метрики, цифры, и умеет анализировать влияние изменений или хотя бы слушать аналитиков.
4️⃣ Часто маркетингу нужны новые запуски, чтобы было что продвигать вовне.
5️⃣ Ну и, наконец, есть так называемая ловушка MVP: "Ты же можешь запустить фичу быстро, в урезанном формате? У вас это называется MVP, да? Так, месяц? Ну давай быстренько за месяц запустим!" А что дальше? Правильно — на проде у вас остаётся обрубок какого-то дополнительного функционала.
Товарищи продакты, сегодня-завтра присядьте и проанализируйте:
☑️ Хорошо ли работает основной функционал вашего продукта?
☑️ Не занимаетесь ли вы просто клепанием фичей?
—————
А еще будет отдельный пост, который вам поможет начать разбираться со сложившейся ситуацией...
История про главный навык продакт менеджера...
(на базе старого доброго анекдота; внимание: юмор специфичен)
—————
Директор по продукту сервиса по уборке квартир собрал своих новичков-продактов и решил провести обучение в бою. Посадил всех в авто и поехал проверять один из заказов. После того, как в квартире все было убрано, группа продактов в бахилах вошла внутрь. Директор по продукту поднял крышку унитаза, провел пальцем по чаше унитаза и облизал.
Директор: "Продакты, что самое главное в нашей работе?"
Один из продактов: "Обеспечивать высокое качество для клиента, комититься на CSAT. Мы должны понимать, что наша шкура в игре! Наш слоган "Мы создаем идеальную чистоту."
С этими словами продакт подходит к унитазу, засовывает поглубже руку, со скрежетом проводит пальцем по чаше и облизывает.
Директор: "Хмммм, вообще-то я имел ввиду, что самое главное - это внимание к деталям. Я провел по унитазу одним пальцем, а облизал другой."
—————
Товарищи продакты, будьте внимательны к деталям, плееез.
Самая странная причина отказа после собеседования за всю мою жизнь…
Это было лет 5 назад. Я дошёл до финала при отборе в огромную компанию на довольно высокую должность. Нужно было руководить командой из более чем 200 человек.
К финалу необходимо было подготовить презентацию со стратегией развития продукта. Финальная встреча прошла отлично, на все вопросы я отвечал чётко — как мне самому показалось 😉
Затем молчание от HR на неделю. Ну, это нормально — поведение среднестатистического HR 🙈
После того как я немного попинговал HR, получил ответ:
“Руководитель сказал, что вы подозрительно хорошо были готовы к интервью. Поэтому отказ.”
Про такое я на тот момент ещё ни разу не слышал))
❓А вы сталкивались со “странными” причинами отказов? ❓
Пишите в комментариях ➡️
Мне многие продакты задают вопрос: "Как мне развиваться?"
Дело в том, что после получения базовых знаний по продакт- и проджект-менеджменту и при наличии постоянной практики вы, казалось бы, достигли пика 🏔
Но я уже писал в одном из постов, что продакт-менеджер — это человек универсальный, или полимат. Самый известный полимат в истории — это, конечно, Леонардо да Винчи. Он был художником, инженером, астрономом, философом, анатомом, математиком, скульптором, архитектором, гражданским инженером, дипломатом, физиком, физиологом, ботаником, химиком, зоологом...
Один из подходов к обучению, который я активно практиковал, будучи уже сеньор-продактом, — это изучение смежных областей. План развития я составлял поквартально.
Выбираем область для изучения:
UX/UI-дизайн
Аналитика
Маркетинг
Финансы
ML
Технологии и т. д.
Ищем источники знаний:
книги (обычно выбирал 4–6 книг);
статьи (читал по вечерам);
* эксперты в области (сотрудники вашей компании, знакомые, знакомые знакомых).
Важно выделять на это развитие не менее 8 часов в неделю. Также учитесь на практике: чем больше вы взаимодействуете с другими функциями, тем быстрее растете в их области.
—————
У вас может возникнуть закономерный вопрос:
"Так у меня в команде всегда будет аналитик. Зачем мне глубоко разбираться в аналитике?"
То же самое можно сказать про маркетинг, технологии, дизайн...
Я могу привести несколько аргументов "за":
Во-первых, вы не будете задавать глупых вопросов или говорить ерунду :)
Далее. Чем лучше вы понимаете область собеседника, тем эффективнее будет работать интерфейс взаимодействия.
Вы сможете отсекать дичь, которую вам пытаются "втереть". За свою карьеру я столько раз слышал, мягко говоря, странные вещи про A/B-тесты от аналитиков... А порой я даже предлагал технарям идеи, которые оказывались, как выяснялось, довольно неплохими.
Наконец, в некоторых ситуациях вам, возможно, придется временно заменить отсутствующую роль в команде. И если вы сможете закрыть хотя бы часть задач — вы молодец (полимат)! 🚀
Планируешь запуск новой фичи? Обязательно подумай про следующие 3 разреза. А еще лучше подробно опиши их.
(в рамках стратегии запуска фичи)
—————
Целевая аудитория для нового функционала
Для каких пользователей продукта ты создаешь этот функционал? Опиши сегмент. Это новые пользователи или те, кто давно в продукте? Соцдем, гео. Пользующиеся бесплатной версией, платники, премиум?
Сколько таких пользователей? Доля от всей базы пользователей, доля от DAU, доля от платящих.
* В каком в целом Use Case пользователи будут использовать фичу?
Ценность для пользователей
Какую проблему решим для пользователей? Насколько проблема "сильная" и распространенная?
Как часто пользователи будут использовать фичу?
* На какие пользовательские метрики повлияет эта фича?
Ценность для бизнеса
На какие бизнесовые метрики повлияет эта фича? Насколько сильно потенциально может их сдвинуть?
Как эта фича укладывается в стратегию развития бизнеса?
Architec.Ton is a ecosystem on the TON chain with non-custodial wallet, swap, apps catalog and launchpad.
Main app: @architec_ton_bot
Our Chat: @architec_ton
EU Channel: @architecton_eu
Twitter: x.com/architec_ton
Support: @architecton_support
Last updated 2 weeks, 3 days ago
Канал для поиска исполнителей для разных задач и организации мини конкурсов
Last updated 1 month ago