📐💰 А как часто вы замеряете как перформят ваши фичи после релиза?
Очень многие компании грешат штампованием фичей, а на аналитику до и после никто не смотрит. Вот и получается, что потратили условные $10.000, а за год заработали около $3000. То есть инвестируете - инвестируете как организация в команды инженерки, а на выхлопе оно даже не окупается (и это только инженерка, маркетинг и продажи тоже кучу денег стоят).
И вот когда начинаются проблемы с деньгами, обычно только тогда организации начинают думать про оптимизации, про "эффективную" работу. Можно оптимизировать инжиниринг и бесконечно улучшать разные метрики, но если у вас от продактов приходит нечто, не очень-то и нужное клиентам, то и выхлоп после релиза будет никакой.
Последний год мы переходили в Metamap.com на рельсы продуктового подхода, уходя от паттерна feature factory. Где-то было плохо, где-то получше, но основная табличка и инструменты из этого поста родились благодаря этому опыту.
Самое забавное, что сейчас при консалтинге другой компании, мы идем по тем же шагам и сталкиваемся с теми же антипаттернами - вот, к примеру, фича которую выкатили клиентам несколько месяцев назад была тыкнута клиентами буквально пару раз, и так и не используется.
https://vc.ru/s/proddev/867747-hvatit-zavalivat-polzovateley-novymi-fichami-nachnite-uzhe-schitat-roi
Очень многие компании грешат штампованием фичей, а на аналитику до и после никто не смотрит. Вот и получается, что потратили условные $10.000, а за год заработали около $3000. То есть инвестируете - инвестируете как организация в команды инженерки, а на выхлопе оно даже не окупается (и это только инженерка, маркетинг и продажи тоже кучу денег стоят).
И вот когда начинаются проблемы с деньгами, обычно только тогда организации начинают думать про оптимизации, про "эффективную" работу. Можно оптимизировать инжиниринг и бесконечно улучшать разные метрики, но если у вас от продактов приходит нечто, не очень-то и нужное клиентам, то и выхлоп после релиза будет никакой.
Последний год мы переходили в Metamap.com на рельсы продуктового подхода, уходя от паттерна feature factory. Где-то было плохо, где-то получше, но основная табличка и инструменты из этого поста родились благодаря этому опыту.
Самое забавное, что сейчас при консалтинге другой компании, мы идем по тем же шагам и сталкиваемся с теми же антипаттернами - вот, к примеру, фича которую выкатили клиентам несколько месяцев назад была тыкнута клиентами буквально пару раз, и так и не используется.
https://vc.ru/s/proddev/867747-hvatit-zavalivat-polzovateley-novymi-fichami-nachnite-uzhe-schitat-roi
Please open Telegram to view this post
VIEW IN TELEGRAM
vc.ru
Как перестать заваливать пользователей новыми фичами и начать считать приблизительный ROI? — Marat Kiniabulatov на vc.ru
Стартап-индустрия в 2022–2023 годах, мягко говоря, оказалась между молотом и наковальней. С одной стороны, многие бизнесы начали сжиматься (а ставки центробанков расти), с другой — венчурные фонды почти перестали инвестировать. Начались сокращения, стартапы…
👍3🔥1
Не ждали? А вот оно, возвращение в тг-канал с громким заголовком:
"Как Product Ops и метрики потока сократили время разработки фичей в 4 раза"
Хочу поделиться интересным кейсом, как выстроенные процессы операционной работы над продуктовм (Product Ops) помогли нам в Metamap в 2022-2023 сократить время реализации фичей с 244 до 93 дней.
В чем была проблема?
Классическая ситуация: продажники обещают клиентам новые функции, инженеры не успевают их реализовать, приоритеты постоянно меняются, короче - все недовольные и злые.
Если измерить время реализации большинства фичей - оно достигало 8 месяцев! Для стартапа с ограниченным финансированием это катастрофа (я пару лет назад писал что наступила венчурная зима).
Чего мы сделали: выстроили процесс Product Ops через метрики потока:
1️⃣ Провели STATIK*-воркшоп
STATIK-это стандартный инструмент внедрения Kanban. Это фактически несколько этапов, на которых мы рисуем наш e2e процесс, смотрим на бутылочные горлышки, обсуждаем текущую картину (и в идеале To Be картину).
Я будучи Product Ops-лидом провел воркшоп, собрав вместе отделы продаж, продукта и разработки. Мы совместно составили карту реального рабочего процесса от рождения идеи до замера её эффективности на проде. Ну и выявили узкие места, разумеется.
2️⃣ Создание единого источника правды
Для трекера / тикетной системы мы выбрали Jira Product Discovery - тогда еще сырой и в beta-версии, он уже умел интегрироваться с кучей инструментов и давал возможность сделать ICE/RICE.
Так, все запросы на фичи оказались собраны в одном месте с интеграцией с Salesforce, Gong (система звонков и продаж), HubSpot. Это обеспечило полную прозрачность для всех отделов: тыкаешь в Idea / Feature Request в жире - видишь сколько денег принесет идея, какие клиенты её хотят, какой горизонт прогноза прибыли.
3️⃣ С боем и кровью договорились про правила приоритизации
Правило "3×3":
1. функция продвигается только если её запросили 3+ активных клиента,
2. с ожидаемым ARR (Annual Recurring Revenue - ожидаемая прибыль, которая повторяется каждый год) выше порогового значения
3. Фича прямо связана с ключевыми метриками продукта (от которых у нас построены цели на год+).
4️⃣ Визуализировали ключевые метрики потока
• Пропускная способность (Throughput): количество реализованных фичей в месяц
• Время цикла (Cycle Time): с целью не более 90 дней
• Ограничение WIP: не более 2 фичей на команду одновременно
Почесали репу, посмотрели на данные исторически:
Инженерная команда могла обработать только 1/4 поступающих запросов, и визуализация этого факта помогла обосновать необходимость жестких правил приоритизации.
В итоге получилось вот что:
✅ Время выполнения сократилось в 2,6 раза (до 93 дней)
✅ 76% выпущенных фичей напрямую связаны с ключевыми метриками (было ниже 40%)
✅ Продажники перестали обещать нереализуемые сроки (ведь мы потом смотрели на данные и проверяли прогнозы)
✅ Выросло доверие между отделами (это, наверное, стало самым классным инструментом синергии внутри компании)
Итого, вот вам рецептик:
1. Интегрируйте системы для создания единой картины (CRM + тикет-система)
2. Визуализируйте метрики потока для всех отделов — это устраняет эмоции и домыслы
3. Внедряйте строгую дисциплину приоритизации
4. Обязательно измеряйте результат после внедрения фичей
Если ваша команда страдает от затянутых сроков разработки и конфликтов между отделами, внедрение Product Ops-подходов с фокусом на метрики потока может стать решением проблемы. Тут у Анвара есть целый пост про книжку про Product Operations.
"Как Product Ops и метрики потока сократили время разработки фичей в 4 раза"
Хочу поделиться интересным кейсом, как выстроенные процессы операционной работы над продуктовм (Product Ops) помогли нам в Metamap в 2022-2023 сократить время реализации фичей с 244 до 93 дней.
В чем была проблема?
Классическая ситуация: продажники обещают клиентам новые функции, инженеры не успевают их реализовать, приоритеты постоянно меняются, короче - все недовольные и злые.
Если измерить время реализации большинства фичей - оно достигало 8 месяцев! Для стартапа с ограниченным финансированием это катастрофа (я пару лет назад писал что наступила венчурная зима).
Чего мы сделали: выстроили процесс Product Ops через метрики потока:
1️⃣ Провели STATIK*-воркшоп
STATIK-это стандартный инструмент внедрения Kanban. Это фактически несколько этапов, на которых мы рисуем наш e2e процесс, смотрим на бутылочные горлышки, обсуждаем текущую картину (и в идеале To Be картину).
Я будучи Product Ops-лидом провел воркшоп, собрав вместе отделы продаж, продукта и разработки. Мы совместно составили карту реального рабочего процесса от рождения идеи до замера её эффективности на проде. Ну и выявили узкие места, разумеется.
2️⃣ Создание единого источника правды
Для трекера / тикетной системы мы выбрали Jira Product Discovery - тогда еще сырой и в beta-версии, он уже умел интегрироваться с кучей инструментов и давал возможность сделать ICE/RICE.
Так, все запросы на фичи оказались собраны в одном месте с интеграцией с Salesforce, Gong (система звонков и продаж), HubSpot. Это обеспечило полную прозрачность для всех отделов: тыкаешь в Idea / Feature Request в жире - видишь сколько денег принесет идея, какие клиенты её хотят, какой горизонт прогноза прибыли.
3️⃣ С боем и кровью договорились про правила приоритизации
Правило "3×3":
1. функция продвигается только если её запросили 3+ активных клиента,
2. с ожидаемым ARR (Annual Recurring Revenue - ожидаемая прибыль, которая повторяется каждый год) выше порогового значения
3. Фича прямо связана с ключевыми метриками продукта (от которых у нас построены цели на год+).
4️⃣ Визуализировали ключевые метрики потока
• Пропускная способность (Throughput): количество реализованных фичей в месяц
• Время цикла (Cycle Time): с целью не более 90 дней
• Ограничение WIP: не более 2 фичей на команду одновременно
Почесали репу, посмотрели на данные исторически:
Инженерная команда могла обработать только 1/4 поступающих запросов, и визуализация этого факта помогла обосновать необходимость жестких правил приоритизации.
В итоге получилось вот что:
✅ Время выполнения сократилось в 2,6 раза (до 93 дней)
✅ 76% выпущенных фичей напрямую связаны с ключевыми метриками (было ниже 40%)
✅ Продажники перестали обещать нереализуемые сроки (ведь мы потом смотрели на данные и проверяли прогнозы)
✅ Выросло доверие между отделами (это, наверное, стало самым классным инструментом синергии внутри компании)
Итого, вот вам рецептик:
1. Интегрируйте системы для создания единой картины (CRM + тикет-система)
2. Визуализируйте метрики потока для всех отделов — это устраняет эмоции и домыслы
3. Внедряйте строгую дисциплину приоритизации
4. Обязательно измеряйте результат после внедрения фичей
Если ваша команда страдает от затянутых сроков разработки и конфликтов между отделами, внедрение Product Ops-подходов с фокусом на метрики потока может стать решением проблемы. Тут у Анвара есть целый пост про книжку про Product Operations.
🔥9❤1
🤟️️ Всем хаумы ("привет" на башкирском)
Меня зовут Марат. Я занимаюсь оптимизацией процессов и data-driven изменениями в АйТи и всех смежных с ним областях.
Я работаю в крупном финтехе Agile-коучем (linkedin), отвечаю за эффективную работу и взаимодействие на периметре 45 команд. До этого я работал как Program Management Lead, Delivery Lead, COO в SaaS в разных индустрия.
В этом блоге я делюсь кейсами и своей экспертизой по:
✅ Фасилитации
- Как провести сессию на 90 человек и не получить на выходе список банальностей?
- Правила подготовки к фасилитационной сессии через 5П
- Броуновское движение + Бинго: как за 15 минут познакомить 90 человек
- Фасилитация технически сложного воркшопа в душном простратстве: Context Engineering на 50 человек
🔮 Прогнозирование, метрики потока
- Какие инструменты мониторинга и визуализации метрик есть, и где прочитать книжки по метрикам?
- Холиварим про Story Points: инструмент планирования или источник проблем?
- База по метрикам потока: Throughput, Cycle Time, Aging
- Throughput: о чем метрика, какие временные промежутки использовать | как анализировать срезы по типам работы, почему Throughput универсальнее SP, паттерны метрики
- Lead Time: база, 50 и 85 перцентили и их паттерны | анализ срезов Lead Time по типам задач
- Кто такой этот ваш Time to Market, и как он соотносится с Lead Time, Cycle Time?
- Friday-funday: Нестандартные и упоротые метрики
🏗 Product Operations
- Уходим от заваливания пользователей фичами (feature factory) к оптимальной поставке
- Как операционализировать Discovery, выстроить pipeline фичей, сбалансировать разработку с продажами и маркетингом и сократить time to market
🤖AI
- Как AI потенциально замедляет разработчиков
📚Книжечки
- Мой микро-обзор на Radical Product Thinking (Radica Dutt) и актуальность в 2025
- Built to Last (Jim Collins, Kerry Porras) - исследование компаний, которые успешно живут десятилетями и инновируют
Context Engineering
Зачем он нам | Техники работы с контекстом | шпаргалка: когда что применять / План фасилитации воркшопа по теме
➕ Еще у меня есть:
- свой коворкинг (ufaitcoworking.ru)
- я основатель сообщества (@AgileUfa)
- мой инструмент для анализа метрик: predictable.team
- мой блог на английском (kiniabulatov.com)
Меня зовут Марат. Я занимаюсь оптимизацией процессов и data-driven изменениями в АйТи и всех смежных с ним областях.
Я работаю в крупном финтехе Agile-коучем (linkedin), отвечаю за эффективную работу и взаимодействие на периметре 45 команд. До этого я работал как Program Management Lead, Delivery Lead, COO в SaaS в разных индустрия.
В этом блоге я делюсь кейсами и своей экспертизой по:
✅ Фасилитации
- Как провести сессию на 90 человек и не получить на выходе список банальностей?
- Правила подготовки к фасилитационной сессии через 5П
- Броуновское движение + Бинго: как за 15 минут познакомить 90 человек
- Фасилитация технически сложного воркшопа в душном простратстве: Context Engineering на 50 человек
🔮 Прогнозирование, метрики потока
- Какие инструменты мониторинга и визуализации метрик есть, и где прочитать книжки по метрикам?
- Холиварим про Story Points: инструмент планирования или источник проблем?
- База по метрикам потока: Throughput, Cycle Time, Aging
- Throughput: о чем метрика, какие временные промежутки использовать | как анализировать срезы по типам работы, почему Throughput универсальнее SP, паттерны метрики
- Lead Time: база, 50 и 85 перцентили и их паттерны | анализ срезов Lead Time по типам задач
- Кто такой этот ваш Time to Market, и как он соотносится с Lead Time, Cycle Time?
- Friday-funday: Нестандартные и упоротые метрики
🏗 Product Operations
- Уходим от заваливания пользователей фичами (feature factory) к оптимальной поставке
- Как операционализировать Discovery, выстроить pipeline фичей, сбалансировать разработку с продажами и маркетингом и сократить time to market
🤖AI
- Как AI потенциально замедляет разработчиков
📚Книжечки
- Мой микро-обзор на Radical Product Thinking (Radica Dutt) и актуальность в 2025
- Built to Last (Jim Collins, Kerry Porras) - исследование компаний, которые успешно живут десятилетями и инновируют
Context Engineering
Зачем он нам | Техники работы с контекстом | шпаргалка: когда что применять / План фасилитации воркшопа по теме
- свой коворкинг (ufaitcoworking.ru)
- я основатель сообщества (@AgileUfa)
- мой инструмент для анализа метрик: predictable.team
- мой блог на английском (kiniabulatov.com)
Please open Telegram to view this post
VIEW IN TELEGRAM
Telegram
Marat @ Predictable.Team
🛠️ Инструменты мониторинга метрик команды и что почитать по теме.
⠪⢑⣀⢨⠉ ⠸⠅⣂⡌⠡⠜⢔⠢ ⠪⠑⠸⠒⠦⠡ ⠊⠋⠓⡌⢌ ⢂⠰⡠⠲⠤⠇⡉⡑⡑ ⠖⠉⡘⣐⠱⡊⡉⡑ ⠲⠣⢆⠉ ⠃⢌⡉ ⣄⣁⡒⢐⢠⢆
⡅ ⠌⠙⢑⡆⡃ ⡌⡄⡡⢄ ⡊⡨⣄⠑⢁⠊⠨⢨ ⡆⠒⠨⠘⠒⣐
⡂ ⠉⠓⠇⢌⡢ ⡅⠕ ⢅⠃⡡⢒⠊⢊⠊⢃
🕵️♂️ Где смотреть на метрики вашей команды
- Jira: без плагинов посмотреть…
⠪⢑⣀⢨⠉ ⠸⠅⣂⡌⠡⠜⢔⠢ ⠪⠑⠸⠒⠦⠡ ⠊⠋⠓⡌⢌ ⢂⠰⡠⠲⠤⠇⡉⡑⡑ ⠖⠉⡘⣐⠱⡊⡉⡑ ⠲⠣⢆⠉ ⠃⢌⡉ ⣄⣁⡒⢐⢠⢆
⡅ ⠌⠙⢑⡆⡃ ⡌⡄⡡⢄ ⡊⡨⣄⠑⢁⠊⠨⢨ ⡆⠒⠨⠘⠒⣐
⡂ ⠉⠓⠇⢌⡢ ⡅⠕ ⢅⠃⡡⢒⠊⢊⠊⢃
🕵️♂️ Где смотреть на метрики вашей команды
- Jira: без плагинов посмотреть…
🔥5
Я вот уже 7 лет веду воркшопы по оценке задач в стори поинтах, и вот тут такие наблюдения:
🔍 Что показывает практика:
- Только 20% команд эффективно используют Story Points после обучения (при замере через три месяца).
- Чем крупнее компании (сейчас в моем отделе 400+ разработчиков) - тем меньше команд применяют SP. А те кто применяет, применяют их кто в лес, кто по-дрова.
- В FAANG-компаниях Story Points используют редко (и вроде бы не умирают). Кроме того, в скраме нет никаких упоминаний о Story Points, это пришло от одного из авторов XP (Рона Джефриза, как поправил меня Андрей из enabling.team) и за это уже извинились.
⚡Основные проблемы для меня со Story Points:
- Требуют постоянной поддержки — без слежки за командой скрам-мастером, команды быстро теряют навык, эталонные шкалы протухают.
- Не всегда отражают реальность — задача в 3 SP может затянуться, а в 8 SP — решиться быстро.
- Сложно масштабировать — каждая команда "калибрует" оценки по-своему.
Story Points + flow-метрики (Cycle Time, Пропускная Способность (Throughput), Состаривание (Aging)) могут давать сопоставимую точность прогнозов.
Только flow-метрики.
💡 Короче говоря: SP отлично работают для внутреннего планирования команды, но для долгосрочных прогнозов стоит рассмотреть метрики потока и прогнозирование через симуляцию Монте-Карло.
🤔 А как у вас в команде? Используете Story Points или пробовали другие подходы к планированию? Поделитесь опытом!
Пост на хабре | в личном блоге
Please open Telegram to view this post
VIEW IN TELEGRAM
👍2
Как провести сессию на 90 человек и не получить на выходе список банальностей?
Делюсь свежим кейсом: большая встреча, 4 отдела, стратегический проект. Задача: познакомить и собрать риски.
Что сработало на ура, а где мы поймали антипаттерн «за всё хорошее, против всего плохого»? И главное — почему это произошло.
Внутри статьи — честный рассказ о граблях фасилитатора и о том, как на них не наступать: https://teletype.in/@kiniabulatov/facilitate-90-ppl
А вы себя на мысли ловили, что встреча вроде прошла успешно, но осталось ощущение, что «могли бы копнуть глубже»? Делитесь в комментах! 👇
Делюсь свежим кейсом: большая встреча, 4 отдела, стратегический проект. Задача: познакомить и собрать риски.
Что сработало на ура, а где мы поймали антипаттерн «за всё хорошее, против всего плохого»? И главное — почему это произошло.
Внутри статьи — честный рассказ о граблях фасилитатора и о том, как на них не наступать: https://teletype.in/@kiniabulatov/facilitate-90-ppl
А вы себя на мысли ловили, что встреча вроде прошла успешно, но осталось ощущение, что «могли бы копнуть глубже»? Делитесь в комментах! 👇
Teletype
🙃 Про фасилитацию (познакомить и выявить риски) на 90 человек и где я мог бы сделать (ощутимо) лучше.
Немного про фасилитацию (неотъемлемая часть моей работы).
👍4🔥1
🧵 Вдогонку про Pre-Mortem по страт проекту на 90 человек. Я недокрутил саму подготовку, потому что делал фасилитацию на коленке (на то были причины, но зато появился материал для поста ;) (тут подробный разбор где недокрутил).
База: Подготовка это 80% работы. Для этого мы используем правила "5 П", прорабатывая который мы предвосхищаем95% всех проблем во время фасилитации.
🎯 Поставленная цель
• Какую проблему решаем и почему сейчас?
• Спросить не только заказчика, но и других стейкхолдеров
📜 Продукт (результат)
• Что конкретно получим на выходе?
• Не «обсудили риски», а «топ-3 риска с вот такущими планами митигации и когда уже начинать будем»
🤼♂️ Приглашённые люди
• Кто будет? Сколько человек?
• Какой у них опыт, взаимоотношения и уровень доверия?
❓ Проблемы
• Что может вызвать споры и конфликты?
📊 Процесс
• Временные ресурсы, формат (очно/онлайн)
• Флипчарты, стикеры, маркеры, права в фигме или миро — что нужно?
🔥 Preheat (бонус-пункт)
Письмо участникам за неделю: «Подумайте заранее о 2-3 конкретных рисках». Без этого люди приходят «холодными» и начинают с нуля. Такая вот "лидогенерация" нормальных ответов.
Главное правило: чем сложнее задача для группы, тем больше времени на подготовку.
🏥 По ссылке разбор, где я недоготовился по 5П 🙂
База: Подготовка это 80% работы. Для этого мы используем правила "5 П", прорабатывая который мы предвосхищаем
🎯 Поставленная цель
• Какую проблему решаем и почему сейчас?
• Спросить не только заказчика, но и других стейкхолдеров
📜 Продукт (результат)
• Что конкретно получим на выходе?
• Не «обсудили риски», а «топ-3 риска с вот такущими планами митигации и когда уже начинать будем»
🤼♂️ Приглашённые люди
• Кто будет? Сколько человек?
• Какой у них опыт, взаимоотношения и уровень доверия?
• Что может вызвать споры и конфликты?
📊 Процесс
• Временные ресурсы, формат (очно/онлайн)
• Флипчарты, стикеры, маркеры, права в фигме или миро — что нужно?
🔥 Preheat (бонус-пункт)
Письмо участникам за неделю: «Подумайте заранее о 2-3 конкретных рисках». Без этого люди приходят «холодными» и начинают с нуля. Такая вот "лидогенерация" нормальных ответов.
Главное правило: чем сложнее задача для группы, тем больше времени на подготовку.
🏥 По ссылке разбор, где я недоготовился по 5П 🙂
Please open Telegram to view this post
VIEW IN TELEGRAM
👍6❤1🔥1
Минутка оффтопа про AI.
Мы тут все думаем, что ИИ нас ускоряет (таким гуманитариям как я это точно сильно помогает создавать прототипы).
Но на деле, если говорить про реализацию решений в продакшне все иначе: компания METR взяла небольшую выборку из 16 опытных разработчиков, использование ИИ снизило их скорость выполнения работы (наш любимый Lead Time) на19%.
Подробнее тут: https://habr.com/ru/news/927436/
Мы тут все думаем, что ИИ нас ускоряет (таким гуманитариям как я это точно сильно помогает создавать прототипы).
Но на деле, если говорить про реализацию решений в продакшне все иначе: компания METR взяла небольшую выборку из 16 опытных разработчиков, использование ИИ снизило их скорость выполнения работы (наш любимый Lead Time) на
Подробнее тут: https://habr.com/ru/news/927436/
Хабр
ИИ-инструменты замедляют опытных разработчиков: результаты исследования METR
Разработчики работали на 19% медленнее с ИИ, чем без него, хотя сами они считали, что ускорились на 20%. Ожидаемое ускорение против наблюдаемого замедления работы у опытных разработчиков при...
👍2🔥1
⚛️ Броуновское движение + Бинго: как за 15 минут познакомить 90 человек
Представьте: 90 человек в зале, все из разных отделов, которые работают над одним страт проектом. И нужно их быстро "растопить". "Представьтесь по кругу" — тут точно не подойдет (будет долго и нудно).
Есть классный инструмент: Броуновское движение (к которому можно добавить бинго-карточки для геймификации).
Как итог, за 15-20 минут люди 4 раза знакомятся с незнакомыми людьми, да еще и получают призы. Стоит это буквально 0 денег (ну или 3к рублей, если вы хотите купить красивые беджики и🍯 баночку мёда в подарок).
Короче говоря: энергия взлетает, люди смеются, а знакомств происходит много одновременно.
Полный разбор с инструкцией, скриптом и шаблоном бинго — в статье:
https://teletype.in/@kiniabulatov/brown-movement-technique
Представьте: 90 человек в зале, все из разных отделов, которые работают над одним страт проектом. И нужно их быстро "растопить". "Представьтесь по кругу" — тут точно не подойдет (будет долго и нудно).
Есть классный инструмент: Броуновское движение (к которому можно добавить бинго-карточки для геймификации).
Как итог, за 15-20 минут люди 4 раза знакомятся с незнакомыми людьми, да еще и получают призы. Стоит это буквально 0 денег (ну или 3к рублей, если вы хотите купить красивые беджики и
Короче говоря: энергия взлетает, люди смеются, а знакомств происходит много одновременно.
Полный разбор с инструкцией, скриптом и шаблоном бинго — в статье:
https://teletype.in/@kiniabulatov/brown-movement-technique
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥8
Друзья, для следующих постов хотите: (реагируйте)
-🔥 Почитать про кейсы метрик и эффективности команд
-👍 Фасилитацию (как сделать встречи эффективными)
-👏 Обучение и тренинги
- что-то еще (в комментариях)
-
-
-
- что-то еще (в комментариях)
Please open Telegram to view this post
VIEW IN TELEGRAM
👍9🔥6⚡1👏1🙏1🥱1
В последние три месяца добрался до своего списка литературы и прочел две давно лежавшие на полочке книги.
📚 Built to Last (EN, RU) и Radical Product Thinking (EN) - это два разных взгляда на создание продуктов. В одном случае организации как продукта. Вторая книга - именно про продукт в его классическом понимании.
🏗 В «Built to Last» - большое исследование того, как строить компанию, которая выдержит испытание временем. Там даже основная метафора - как не определять время (продукт), а уметь строить часы, которые переживут тебя самого. Больше внимания уделяется культуре, ценностям и постоянному улучшению, а вот резкие революционные прорывы поощряются в меньшей степени.
📈 С другой стороны, «Radical Product Thinking» больше про подчинение продукта строгим метрикам и ориентацию на быстрые, ощутимые результаты, суперфокус. То есть там подход более жёсткий, сфокусированный на эффективности и достижении конкретных целей. Там есть рабочая тетрадка и алгоритмы и таблица для работы с достижением целей продукта.
🤯 На контрасте читать очень интересно, потому что сначала соглашаешься и строишь в голове фрейм под одну книгу, а потом вторая его подвергает сильной критике. А потом понимаешь что это про два аспекта одного и того же.
Так как прочел последовательно, сделаю небольшой разбор относительно друг-друга в постах ниже. 👇
📚 Built to Last (EN, RU) и Radical Product Thinking (EN) - это два разных взгляда на создание продуктов. В одном случае организации как продукта. Вторая книга - именно про продукт в его классическом понимании.
🏗 В «Built to Last» - большое исследование того, как строить компанию, которая выдержит испытание временем. Там даже основная метафора - как не определять время (продукт), а уметь строить часы, которые переживут тебя самого. Больше внимания уделяется культуре, ценностям и постоянному улучшению, а вот резкие революционные прорывы поощряются в меньшей степени.
Так как прочел последовательно, сделаю небольшой разбор относительно друг-друга в постах ниже. 👇
Please open Telegram to view this post
VIEW IN TELEGRAM
👍3❤1👎1🤬1