Ценовое репозициорирование
Рынок – это динамичная среда и его возможности со временем тоже меняются. Если продукт не может выжать из текущего состояния рынка весь потенциал получения прибыли, а предпосылки для этого имеются, можно сделать репозиционированние. При выводе новых продуктов на рынок компания чаще всего не обладает всей необходимой информацией об эластичности спроса на данную категорию продукта. Но для перезапуска зрелых продуктов требуемая информация может найтись в отделе продаж, который знает все о прошедших сделках, предоставленных скидках, за что клиенты готовы и за что не готовы платить.
Репозиционирование по цене «сверху вниз» можно провести относительно легко, путем снижения издержек, оптимизации процессов, цепочек поставок и других мер. Но приведет ли это к значительному росту объемов продаж, а главное итоговой прибыли?
Гораздо интереснее и сложнее репозиционирование по цене «снизу вверх». Как правило это требует сильных изменений на уровне R&D, в качестве, дизайне, сопутствующих услугах и маркетинге для изменения восприятия продукта клиентами. Эти изменения могут быть затратны, но при прочих равных данный подход оказывается лучшим для показателей прибыли, нежели первый вариант.
У меня был удавшийся кейс по данной теме, связанный с измерительными приборами несколько лет назад. Измерительная техника - весьма консервативная категория продуктов с продолжительным жизненным циклом и ограниченным объемом рынка. В ней хорошо работают классические подходы. Предлагаю опрос для прогрева мозга в начале недели. Свой ответ напишу через пару дней.
@aheadofthepack
Рынок – это динамичная среда и его возможности со временем тоже меняются. Если продукт не может выжать из текущего состояния рынка весь потенциал получения прибыли, а предпосылки для этого имеются, можно сделать репозиционированние. При выводе новых продуктов на рынок компания чаще всего не обладает всей необходимой информацией об эластичности спроса на данную категорию продукта. Но для перезапуска зрелых продуктов требуемая информация может найтись в отделе продаж, который знает все о прошедших сделках, предоставленных скидках, за что клиенты готовы и за что не готовы платить.
Репозиционирование по цене «сверху вниз» можно провести относительно легко, путем снижения издержек, оптимизации процессов, цепочек поставок и других мер. Но приведет ли это к значительному росту объемов продаж, а главное итоговой прибыли?
Гораздо интереснее и сложнее репозиционирование по цене «снизу вверх». Как правило это требует сильных изменений на уровне R&D, в качестве, дизайне, сопутствующих услугах и маркетинге для изменения восприятия продукта клиентами. Эти изменения могут быть затратны, но при прочих равных данный подход оказывается лучшим для показателей прибыли, нежели первый вариант.
У меня был удавшийся кейс по данной теме, связанный с измерительными приборами несколько лет назад. Измерительная техника - весьма консервативная категория продуктов с продолжительным жизненным циклом и ограниченным объемом рынка. В ней хорошо работают классические подходы. Предлагаю опрос для прогрева мозга в начале недели. Свой ответ напишу через пару дней.
@aheadofthepack
На шаг впереди via @vote
Что поменяли в продукте прежде всего, чтобы реализовать ценовое репозиционировние «снизу вверх»?
anonymous poll
Разработали новые товары-дополнители, аксессуары – 46
👍👍👍👍👍👍👍 36%
Разработали новые убойные функции и фичи – 43
👍👍👍👍👍👍👍 33%
Улучшили дизайн, качество, потребительские свойства – 28
👍👍👍👍 22%
Улучшили техническую поддержку, пользовательскую документацию, курсы обучения пользователей – 12
👍👍 9%
👥 129 people voted so far.
anonymous poll
Разработали новые товары-дополнители, аксессуары – 46
👍👍👍👍👍👍👍 36%
Разработали новые убойные функции и фичи – 43
👍👍👍👍👍👍👍 33%
Улучшили дизайн, качество, потребительские свойства – 28
👍👍👍👍 22%
Улучшили техническую поддержку, пользовательскую документацию, курсы обучения пользователей – 12
👍👍 9%
👥 129 people voted so far.
Как продать старый продукт в новой упаковке и увеличить маржинальность?
Продолжение предыдущего поста о ценовом репозициорирование
Расскажу об удавшемся кейсе по репозиционированию измерительного оборудования. Измерительная техника - консервативная категория продуктов с продолжительным жизненным циклом и ограниченным объемом рынка. Для нее хорошо работают классические подходы.
Основная цель репозициорирования по цене «снизу вверх» состояла в перемещении линейки зрелых продуктов в более дорогую ценовую категорию. Одновременно с этим появлялась возможность выхода продукта на заграничный рынок.
Было сгенерировано много вариантов, что можно предпринять для «переупаковки» продукта, и не сделать ли все заново. 🤪 Выбрать нужный для построения Roadmap на тот момент помогла скорее интуиция. История умалчивает, что было бы, если пошли другим путем. Однако для выбранного направления имеются разумные обоснования.
Итак, стоит подумать над гипотезой, что для рынка B2B конечные потребители – это те же люди, что и в B2C с тем же представлением о товарах и услугах. Все вроде бы выглядит просто. За разные свойства продукта клиент готов доплачивать разную цену. Для максимизации прибыли логично концентрироваться на наименее затратных нововведениях, при реализации которых добавленная стоимость будет наибольшей. Не забыв правило Парето, введем понятие эффективности свойств. Атрибуты эффективности, влияющие на стоимость, разделим на базовые атрибуты и атрибуты привлекательности.
За базовый требования к продукту неискушенный клиент как правило не готов платить больше, чем средняя цена на рынке. К примеру, никто не требует от семейного седана разгона до 100 км/ч за 3 секунды. Да, да такие функции являются именно базовыми атрибутами. Они должны просто быть, работать хорошо и не вызывать разочарование у клиента. Пользователь будет сильно недоволен, если тот же семейный седан не сможет загруженный въехать на горку из-за нехватки мощности или ПО будет вылетать с ошибкой после каждого обращения к базе данных. Стоит ли выжимать из базовых атрибутов максимум? Относительно новых функций происходит то же самое. Будут ли функции оценены по достоинству или же это незначительные фишки, не выделяющие продукт? Являются ли они дополнительной ценностью? Неизвестно.
Как же обстоят дела с атрибутами привлекательности? Как правило именно они могут создать дополнительную ценность, которая будет оправдывать большую цену и увеличивать маржинальность. Дизайн, современные подходы и новшества, повышенное требование к качеству, бренд – эти атрибуты действительно могут хорошо монетизироваться.
Что же сделали мы? Подход был комплексный:
🔹 Прежде всего сделали рестайлинг, подобрав новые решения для корпуса. Новый дизайн корпус не отличался от западных аналогов-конкурентов.
🔹 Поработали с пользователями по UX, разобравшись с их болями по интерфейсу и меню. Даже небольшие изменения помогли улучшить удобство использования.
🔹 Сильно потрудились над качеством. Перелопатили Backlog с багами и отрефакторили самые закостыленные и глючные части. Помимо описанного ручного тестирования ввели автоматизацию тестирования с полным покрытием. Автоматизировали все, до чего технически смогли дотянуться руки специалиста по тестированию, реализовали Monkey testing. При этом продукт предшественник ограничили только багфиксом critical и major дефектов, а период обновления его релизов уменьшили.
🔹 Сильно улучшили потребительские свойства перейдя на емкий и современный аккумуляторный элемент. Время жизни устройства на одном заряде возросло, а время зарядки снизилось. Прокачали память.
Стали ли наращивать новый функционал в переупакованном продукте? Да, но уже на втором этапе после старта маркетинговой кампании и продаж. Вы скажете: «Ну так это же просто переупаковка!». Да, именно так. И как показывает практика, это работает! Продукт стал восприниматься по-другому. Его стоимость значительно возросла.
@aheadofthepack
Продолжение предыдущего поста о ценовом репозициорирование
Расскажу об удавшемся кейсе по репозиционированию измерительного оборудования. Измерительная техника - консервативная категория продуктов с продолжительным жизненным циклом и ограниченным объемом рынка. Для нее хорошо работают классические подходы.
Основная цель репозициорирования по цене «снизу вверх» состояла в перемещении линейки зрелых продуктов в более дорогую ценовую категорию. Одновременно с этим появлялась возможность выхода продукта на заграничный рынок.
Было сгенерировано много вариантов, что можно предпринять для «переупаковки» продукта, и не сделать ли все заново. 🤪 Выбрать нужный для построения Roadmap на тот момент помогла скорее интуиция. История умалчивает, что было бы, если пошли другим путем. Однако для выбранного направления имеются разумные обоснования.
Итак, стоит подумать над гипотезой, что для рынка B2B конечные потребители – это те же люди, что и в B2C с тем же представлением о товарах и услугах. Все вроде бы выглядит просто. За разные свойства продукта клиент готов доплачивать разную цену. Для максимизации прибыли логично концентрироваться на наименее затратных нововведениях, при реализации которых добавленная стоимость будет наибольшей. Не забыв правило Парето, введем понятие эффективности свойств. Атрибуты эффективности, влияющие на стоимость, разделим на базовые атрибуты и атрибуты привлекательности.
За базовый требования к продукту неискушенный клиент как правило не готов платить больше, чем средняя цена на рынке. К примеру, никто не требует от семейного седана разгона до 100 км/ч за 3 секунды. Да, да такие функции являются именно базовыми атрибутами. Они должны просто быть, работать хорошо и не вызывать разочарование у клиента. Пользователь будет сильно недоволен, если тот же семейный седан не сможет загруженный въехать на горку из-за нехватки мощности или ПО будет вылетать с ошибкой после каждого обращения к базе данных. Стоит ли выжимать из базовых атрибутов максимум? Относительно новых функций происходит то же самое. Будут ли функции оценены по достоинству или же это незначительные фишки, не выделяющие продукт? Являются ли они дополнительной ценностью? Неизвестно.
Как же обстоят дела с атрибутами привлекательности? Как правило именно они могут создать дополнительную ценность, которая будет оправдывать большую цену и увеличивать маржинальность. Дизайн, современные подходы и новшества, повышенное требование к качеству, бренд – эти атрибуты действительно могут хорошо монетизироваться.
Что же сделали мы? Подход был комплексный:
🔹 Прежде всего сделали рестайлинг, подобрав новые решения для корпуса. Новый дизайн корпус не отличался от западных аналогов-конкурентов.
🔹 Поработали с пользователями по UX, разобравшись с их болями по интерфейсу и меню. Даже небольшие изменения помогли улучшить удобство использования.
🔹 Сильно потрудились над качеством. Перелопатили Backlog с багами и отрефакторили самые закостыленные и глючные части. Помимо описанного ручного тестирования ввели автоматизацию тестирования с полным покрытием. Автоматизировали все, до чего технически смогли дотянуться руки специалиста по тестированию, реализовали Monkey testing. При этом продукт предшественник ограничили только багфиксом critical и major дефектов, а период обновления его релизов уменьшили.
🔹 Сильно улучшили потребительские свойства перейдя на емкий и современный аккумуляторный элемент. Время жизни устройства на одном заряде возросло, а время зарядки снизилось. Прокачали память.
Стали ли наращивать новый функционал в переупакованном продукте? Да, но уже на втором этапе после старта маркетинговой кампании и продаж. Вы скажете: «Ну так это же просто переупаковка!». Да, именно так. И как показывает практика, это работает! Продукт стал восприниматься по-другому. Его стоимость значительно возросла.
@aheadofthepack
Telegram
На шаг впереди
Ценовое репозициорирование
Рынок – это динамичная среда и его возможности со временем тоже меняются. Если продукт не может выжать из текущего состояния рынка весь потенциал получения прибыли, а предпосылки для этого имеются, можно сделать репозиционированние.…
Рынок – это динамичная среда и его возможности со временем тоже меняются. Если продукт не может выжать из текущего состояния рынка весь потенциал получения прибыли, а предпосылки для этого имеются, можно сделать репозиционированние.…
One way ticket
Пандемия ускоряет процессы, которые и так давно шли в IT. Все больше компаний понимают, что долговременные изменения в ежедневной работе избежать не удастся. Удаленка и территориально распределенные команды становятся нормой. Что же нужно для такой трансформации?
Процессы и инструменты
Компании, вовремя внедрившие процессы и инструменты для удаленной работы выглядят казалось бы «на коне». Наконец появляется возможность отказаться от устаревших оффлайновых KPI, такие как 40 списанных часов в неделю, или прихода к 10:00 в офис и сосредоточится на значимых результатах в соответствии с выбранной методологией управления. Но диджитализация - первая часть возможного успеха.
Адаптивная команда
Вторая не менее важная составляющая - это команда. Далеко не все работники способны работать удаленно. У одних не адаптировано домашнее рабочее место, или его в принципе невозможно организовать. Другие не могут самоорганизоваться и мотивироваться в удаленных условиях. Третьи не дружат с инструментарием удаленной работы без постоянной поддержки. Причем не все проблемы решаемы в принципе за какой-то обозримый период времени.
Долгосрочный план и ценности
Единственный разумный подход - первоначально разработать стратегический план найма нужных людей, которые могут и хотят работать в удаленном формате. Если копать глубже, смотреть надо на единые ценности работников и компании. Разбираться с имеющимися «неподходящими» кадрами, переобучать и мотивировать выйдет дорого. В период изменений пострадают не только прибыль, но и все работники из-за нарушения общей атмосферы компании.
Правила меняются на ходу
Уже видно, как крупные современные корпорации быстро приняли новые правила игры и заблаговременно начали адаптацию. Все или часть сотрудников в них уже переведена на удаленную работу. Не беда, что происходит снижение показателей в период адаптации. В долгосрочной перспективе с учетом нестабильности снижаются проектные и продуктовые риски. Работники воспринимают изменения как заботу о них. В среднесрочной перспективе такие компании еще сильнее начнут высасывать качественные адаптивные кадры с рынка.
Другие компании цепляются за старые принципы: командная работа в тесном физическом контакте в опенспейсе или офисной комнате, митинги в переговорной, частые встречи с заказчиками, партнерами и клиентами оффлайн. Однако уже сейчас такие компании испытывают ряд проблем.
Компании не способные адаптироваться к удаленке могу проиграть конкурентную борьбу не только во внутренней эффективности, но и в борьбе за кадры.
Полезные инструменты
Кто еще не понял, куда стремится мир IT? Пока есть время можно изучить некоторые полезные SaaS сервисы для совместной удаленной работы. Надеюсь, что вы уже работаете с ними:
✔️Визуальные доски с шаблонами Miro Mural
✔️Системы управления проектами YouTrack Trello Jira
✔️Мессенджеры для командной работы Slack MS Teams
✔️Системы контроля версий Github Bitbucket
✔️и, конечно же конференции Zoom
@aheadofthepack
Пандемия ускоряет процессы, которые и так давно шли в IT. Все больше компаний понимают, что долговременные изменения в ежедневной работе избежать не удастся. Удаленка и территориально распределенные команды становятся нормой. Что же нужно для такой трансформации?
Процессы и инструменты
Компании, вовремя внедрившие процессы и инструменты для удаленной работы выглядят казалось бы «на коне». Наконец появляется возможность отказаться от устаревших оффлайновых KPI, такие как 40 списанных часов в неделю, или прихода к 10:00 в офис и сосредоточится на значимых результатах в соответствии с выбранной методологией управления. Но диджитализация - первая часть возможного успеха.
Адаптивная команда
Вторая не менее важная составляющая - это команда. Далеко не все работники способны работать удаленно. У одних не адаптировано домашнее рабочее место, или его в принципе невозможно организовать. Другие не могут самоорганизоваться и мотивироваться в удаленных условиях. Третьи не дружат с инструментарием удаленной работы без постоянной поддержки. Причем не все проблемы решаемы в принципе за какой-то обозримый период времени.
Долгосрочный план и ценности
Единственный разумный подход - первоначально разработать стратегический план найма нужных людей, которые могут и хотят работать в удаленном формате. Если копать глубже, смотреть надо на единые ценности работников и компании. Разбираться с имеющимися «неподходящими» кадрами, переобучать и мотивировать выйдет дорого. В период изменений пострадают не только прибыль, но и все работники из-за нарушения общей атмосферы компании.
Правила меняются на ходу
Уже видно, как крупные современные корпорации быстро приняли новые правила игры и заблаговременно начали адаптацию. Все или часть сотрудников в них уже переведена на удаленную работу. Не беда, что происходит снижение показателей в период адаптации. В долгосрочной перспективе с учетом нестабильности снижаются проектные и продуктовые риски. Работники воспринимают изменения как заботу о них. В среднесрочной перспективе такие компании еще сильнее начнут высасывать качественные адаптивные кадры с рынка.
Другие компании цепляются за старые принципы: командная работа в тесном физическом контакте в опенспейсе или офисной комнате, митинги в переговорной, частые встречи с заказчиками, партнерами и клиентами оффлайн. Однако уже сейчас такие компании испытывают ряд проблем.
Компании не способные адаптироваться к удаленке могу проиграть конкурентную борьбу не только во внутренней эффективности, но и в борьбе за кадры.
Полезные инструменты
Кто еще не понял, куда стремится мир IT? Пока есть время можно изучить некоторые полезные SaaS сервисы для совместной удаленной работы. Надеюсь, что вы уже работаете с ними:
✔️Визуальные доски с шаблонами Miro Mural
✔️Системы управления проектами YouTrack Trello Jira
✔️Мессенджеры для командной работы Slack MS Teams
✔️Системы контроля версий Github Bitbucket
✔️и, конечно же конференции Zoom
@aheadofthepack
Miro
AI Innovation Workspace | Miro
Speed up product development from ideation to launch. Align teams, break tool silos, and ship what customers need in one AI-powered visual platform.
Два подхода к чтению книг
В большинстве мест работы я стараюсь проводить мероприятия по обучению, мотивации самообучения и собираю обратную связь по этому направлению. В одной из книг была озвучена классная мысль: «Лучше обучить сотрудника, и он покинет фирму, чем не обучить и он останется». Всегда стоит о ней вспоминать.
В прошлом году проводил анкетирование среди сотрудников. В анкете поднимались вопросы связанные с каналами получения новых знаний, планированием обучения, достижением результатов, и ценностями.
Вот как выглядел один из прямых вопросов анкеты: «Сколько книг читали сотрудники и сколько книг в итоге было прочитано до конца?». Имелась в виду только техническая и бизнес литература. Полученные данные привели меня к неожиданным заключениям. Оказалось, что в отличие от менеджеров и тимлидов, разработчики и тестировщики в подавляющем количестве случаев не дочитывают книги до конца. Не думаю, что разработчики склонны не завершать работу. По крайней мере в остальных рабочих моментах такой проблемы не просматривается. Используя опыт работы программистом, объяснить этот факт я могу лишь иной потребностью в чтении литературы. Изучение книг программистами увязано с проблемой решения конкретной специфической задачи. Потребность же менеджеров связана с необходимостью постоянного повышения квалификации и систематизации знаний. При этом прочтение одной главы из книги не решает всех вопросов.
Менеджерам разного уровня изучать приходится гораздо больше и шире, чем остальным сотрудникам. Чтобы просто не отставать на месте приходится перелопачивать большие стопки книг и проходить массу курсов.
@aheadofthepack
В большинстве мест работы я стараюсь проводить мероприятия по обучению, мотивации самообучения и собираю обратную связь по этому направлению. В одной из книг была озвучена классная мысль: «Лучше обучить сотрудника, и он покинет фирму, чем не обучить и он останется». Всегда стоит о ней вспоминать.
В прошлом году проводил анкетирование среди сотрудников. В анкете поднимались вопросы связанные с каналами получения новых знаний, планированием обучения, достижением результатов, и ценностями.
Вот как выглядел один из прямых вопросов анкеты: «Сколько книг читали сотрудники и сколько книг в итоге было прочитано до конца?». Имелась в виду только техническая и бизнес литература. Полученные данные привели меня к неожиданным заключениям. Оказалось, что в отличие от менеджеров и тимлидов, разработчики и тестировщики в подавляющем количестве случаев не дочитывают книги до конца. Не думаю, что разработчики склонны не завершать работу. По крайней мере в остальных рабочих моментах такой проблемы не просматривается. Используя опыт работы программистом, объяснить этот факт я могу лишь иной потребностью в чтении литературы. Изучение книг программистами увязано с проблемой решения конкретной специфической задачи. Потребность же менеджеров связана с необходимостью постоянного повышения квалификации и систематизации знаний. При этом прочтение одной главы из книги не решает всех вопросов.
Менеджерам разного уровня изучать приходится гораздо больше и шире, чем остальным сотрудникам. Чтобы просто не отставать на месте приходится перелопачивать большие стопки книг и проходить массу курсов.
@aheadofthepack
Польза должностной инструкции
В фирме появляется задача по разработке должностных инструкций. На одного из руководителей падает эта «почетная обязанность». Как вынести пользу из этой формальной задачи?
Для начала стоит озадачится вопросом какая преследуется цель создания такого регламентирующего документа? Возможно, это инициатива высшего руководства для наведения общего порядка во всех документах. В другом случае - HR-служб для использования в процессе поиска кадров. В редких случаях процесс инициируется линейными менеджерами с целью наладить процесс развития команды разработчиков.
Как правило исполнитель тратит 5 минут на гугление примеров и скачивает чужой шаблон с авторскими ошибками и особенностями той другой организации. В другом случае автор пишет «отсебятину» вводя собственную терминологию и систему, рождая инструкцию в творческих муках. Формально задача вроде бы решена, все довольны, не так ли?
Я тоже одно время ломал голову над задачкой, пока не нашел другой, правильный подход. IEEE разработала документ – 📚 Software Engineering Competency Model (SWECOM). 👉Далее...
@aheadofthepack
В фирме появляется задача по разработке должностных инструкций. На одного из руководителей падает эта «почетная обязанность». Как вынести пользу из этой формальной задачи?
Для начала стоит озадачится вопросом какая преследуется цель создания такого регламентирующего документа? Возможно, это инициатива высшего руководства для наведения общего порядка во всех документах. В другом случае - HR-служб для использования в процессе поиска кадров. В редких случаях процесс инициируется линейными менеджерами с целью наладить процесс развития команды разработчиков.
Как правило исполнитель тратит 5 минут на гугление примеров и скачивает чужой шаблон с авторскими ошибками и особенностями той другой организации. В другом случае автор пишет «отсебятину» вводя собственную терминологию и систему, рождая инструкцию в творческих муках. Формально задача вроде бы решена, все довольны, не так ли?
Я тоже одно время ломал голову над задачкой, пока не нашел другой, правильный подход. IEEE разработала документ – 📚 Software Engineering Competency Model (SWECOM). 👉Далее...
@aheadofthepack
Teletype
Польза должностной инструкции
В фирме появляется задача по разработке должностных инструкций. На одного из руководителей падает эта «почетная обязанность». Как...
Продуктовая и проектная диверсификация
Любой стартап стартует с одного проекта или продукта в варианте MVP. Исходя из статистики 70-90% запусков терпят неудачу в силу массы причин. Почему? Срабатывают риски, которые не удалось или было невозможно оценить на входе. Большинство предпринимателей понимают это, но вместе с тем, будучи оптимистами, не отказываются от такой затей, т к и выгода в случае успеха может быть немалой.
Допустим запуск прошел успешно. 🚀 Появился один ключевой заказчик для проектов, либо продукт попал свою целевую нишу. Менеджмент компании, решает, что ухватили чёрта за хвост и пора делить бенефиты. Как правило в этот момент или чуть позже срабатывают риски. 🎲
Самый действенный, но не единственный способ минимизации рисков – портфельная диверсификация. В теории, если мы набираем в портфель различные проекты или расширяем линейку продуктов, корреляция рисков между которыми незначительна, интегральный риск уменьшается при возможном снижении общей маржинальности. Но важно помнить, что наивно подходить к диверсификации не получится. Если, к примеру, все продукты в портфеле относятся к одной отрасли (телеком, нефтедобыча, и т д) для них действуют общие отраслевые риски. Корреляция вероятности наступления рисков между отдельными продуктами высока. При проблемах в отрасли портфель будет отрабатывать синхронно. Так было в одной компании, в которой я работал. Системные риски также не снижаются методом диверсификации.
Лучший подход - посмотреть, как последовательно провести диверсификацию по отраслям, по направлениям, географически. А также не забывать о размерах проектов и объемах продаж отдельных продуктов, чтобы не создавались значительные перекосы. Проведя аналогии с финансовой сферой, стоит также пойти дальше и учитывать отдельные рисковые факторы, к примеру, для расчёта объемов вложений в отдельные продукты.
Диверсификация необходима. При проблемах в одном из продуктов или проектов весь портфель пострадает не так значительно, сохраняя устойчивость компании.
@aheadofthepack
Любой стартап стартует с одного проекта или продукта в варианте MVP. Исходя из статистики 70-90% запусков терпят неудачу в силу массы причин. Почему? Срабатывают риски, которые не удалось или было невозможно оценить на входе. Большинство предпринимателей понимают это, но вместе с тем, будучи оптимистами, не отказываются от такой затей, т к и выгода в случае успеха может быть немалой.
Допустим запуск прошел успешно. 🚀 Появился один ключевой заказчик для проектов, либо продукт попал свою целевую нишу. Менеджмент компании, решает, что ухватили чёрта за хвост и пора делить бенефиты. Как правило в этот момент или чуть позже срабатывают риски. 🎲
Самый действенный, но не единственный способ минимизации рисков – портфельная диверсификация. В теории, если мы набираем в портфель различные проекты или расширяем линейку продуктов, корреляция рисков между которыми незначительна, интегральный риск уменьшается при возможном снижении общей маржинальности. Но важно помнить, что наивно подходить к диверсификации не получится. Если, к примеру, все продукты в портфеле относятся к одной отрасли (телеком, нефтедобыча, и т д) для них действуют общие отраслевые риски. Корреляция вероятности наступления рисков между отдельными продуктами высока. При проблемах в отрасли портфель будет отрабатывать синхронно. Так было в одной компании, в которой я работал. Системные риски также не снижаются методом диверсификации.
Лучший подход - посмотреть, как последовательно провести диверсификацию по отраслям, по направлениям, географически. А также не забывать о размерах проектов и объемах продаж отдельных продуктов, чтобы не создавались значительные перекосы. Проведя аналогии с финансовой сферой, стоит также пойти дальше и учитывать отдельные рисковые факторы, к примеру, для расчёта объемов вложений в отдельные продукты.
Диверсификация необходима. При проблемах в одном из продуктов или проектов весь портфель пострадает не так значительно, сохраняя устойчивость компании.
@aheadofthepack
Возврат к средней величине
При улучшении процессов разработки происходит иногда значительные изменения. А большинство разработчиков, да и людей в целом, изменения не любят. Новые правила, новые подходы, новые инструменты вызывают дискомфорт.
Я много раз замечал, что если пустить поддержание нововведений на самотек, то со временем все деградирует и возвращается в предыдущее состояние процессов. Иногда это происходит быстро, если привычки еще не успели выработаться или медленнее, если принятые изменения системные. Так или иначе, без постоянной подталкивающей силы происходит обратный откат.
Вы видите это в числах, если внедрены "показометры" производительности, KPI или что-либо еще. Как пример, метрика Velocity в методологии Scrum.
Можно заметить, как при необходимой выборке и временном отрезке, значения сначала могут идти вниз из-за процесса адаптации. Потом становятся выше предыдущего среднего, если изменения были положительные. Но в отсутствии стимулов начинают сползать к средней величине, которая была до внедрения изменений.
Новые изменения должны принять все участники процесса разработки. А локальные лидеры мнений не только поддерживать эти изменения, но драйвить остальных участников. Без этого работа менеджера над улучшениями будет больше напоминать работу Сизифа.
@aheadofthepack
При улучшении процессов разработки происходит иногда значительные изменения. А большинство разработчиков, да и людей в целом, изменения не любят. Новые правила, новые подходы, новые инструменты вызывают дискомфорт.
Я много раз замечал, что если пустить поддержание нововведений на самотек, то со временем все деградирует и возвращается в предыдущее состояние процессов. Иногда это происходит быстро, если привычки еще не успели выработаться или медленнее, если принятые изменения системные. Так или иначе, без постоянной подталкивающей силы происходит обратный откат.
Вы видите это в числах, если внедрены "показометры" производительности, KPI или что-либо еще. Как пример, метрика Velocity в методологии Scrum.
Можно заметить, как при необходимой выборке и временном отрезке, значения сначала могут идти вниз из-за процесса адаптации. Потом становятся выше предыдущего среднего, если изменения были положительные. Но в отсутствии стимулов начинают сползать к средней величине, которая была до внедрения изменений.
Новые изменения должны принять все участники процесса разработки. А локальные лидеры мнений не только поддерживать эти изменения, но драйвить остальных участников. Без этого работа менеджера над улучшениями будет больше напоминать работу Сизифа.
@aheadofthepack
Зацикленность на технологиях
Как же часто встречаются организации, разрабатывающие продукт и при этом зацикленные на технологиях. Компании обладают набором компетенции, экспертами в технических областях, изученным технологический стеком. Эти технологии нравятся команде, их хочется исследовать глубже и применять везде.
Менеджеры начинают убеждать себя и команду в смысле выбранного технического решения. Вместо изучения проблем клиентов и различных групп пользователей они варятся в собственном соку. Иногда техническое решение продвигается от внутренних пользователей. Его начинают усложнять и наращивать, придумывая новые фичи, строя архитектуру с большим запасом на универсальность и последующие расширения.
Решение становится основной целью. Под него начинают придумывать потребности на рынке, искать конкурентов. Иногда их находят, закрепляя для себя правильность выбора.
Идет стереотипный сценарий - заводится проект, выделяется бюджет, рисуется план. Прототипы либо не разрабатываются вовсе, либо создаются и тестируются на внутренних же пользователях, предлагавших решение. Круг замыкается. Месяцами, а иногда и годами, разрабатывается "монолитный" законченный продукт, который интегрируется с кучей других систем. Решает ли он чужие проблемы? Продается ли он?
@aheadofthepack
Как же часто встречаются организации, разрабатывающие продукт и при этом зацикленные на технологиях. Компании обладают набором компетенции, экспертами в технических областях, изученным технологический стеком. Эти технологии нравятся команде, их хочется исследовать глубже и применять везде.
Менеджеры начинают убеждать себя и команду в смысле выбранного технического решения. Вместо изучения проблем клиентов и различных групп пользователей они варятся в собственном соку. Иногда техническое решение продвигается от внутренних пользователей. Его начинают усложнять и наращивать, придумывая новые фичи, строя архитектуру с большим запасом на универсальность и последующие расширения.
Решение становится основной целью. Под него начинают придумывать потребности на рынке, искать конкурентов. Иногда их находят, закрепляя для себя правильность выбора.
Идет стереотипный сценарий - заводится проект, выделяется бюджет, рисуется план. Прототипы либо не разрабатываются вовсе, либо создаются и тестируются на внутренних же пользователях, предлагавших решение. Круг замыкается. Месяцами, а иногда и годами, разрабатывается "монолитный" законченный продукт, который интегрируется с кучей других систем. Решает ли он чужие проблемы? Продается ли он?
@aheadofthepack
Forwarded from Analyst Marathon
Сегодня у нас видеопредставление спикера!
Александр Кузовлев
Руководитель проектов,
ВА\SA аналитик в Третий Пин – агентство разработки электроники и встроенных систем на заказ, – рассказал про свое выступление 17 декабря 2020 года на Аналитическом марафоне #3:
https://youtu.be/zFHXM_6AFOs
Александр Кузовлев
Руководитель проектов,
ВА\SA аналитик в Третий Пин – агентство разработки электроники и встроенных систем на заказ, – рассказал про свое выступление 17 декабря 2020 года на Аналитическом марафоне #3:
https://youtu.be/zFHXM_6AFOs
YouTube
Александр Кузовлев про свое выступление на Analyst Marathon #3
Тема: Польза и вред от техдолга в аналитике
Что назвать долгом в аналитике?
Кейсы с примерами технического долга
Фундаментальные причины появления технического долга
Частные причины возникновения долгов
Как долг превратить в пользу?
Как идентифицировать…
Что назвать долгом в аналитике?
Кейсы с примерами технического долга
Фундаментальные причины появления технического долга
Частные причины возникновения долгов
Как долг превратить в пользу?
Как идентифицировать…
Причем тут Маслоу?
Все, помнят пирамиду потребностей А. Маслоу. Однако я не часто встречаю ее упоминание при генерации и проверке новых идей для продуктов. Может быть зря?
Удовлетворение потребностей – это главное правило жизнеспособности любого продукта. Логика подсказывает, что для увеличения охвата в B2C, продукт проще строить вокруг нижних примитивных потребностей. Так больше шансов удачно масштабироваться, даже несмотря на то, что поляна занята гораздо плотнее.
Придумывать концепты вокруг проблемы личностного совершенствования – идея благородная. Но много ли найдется пользователей? Практика показывает, что людей, достигающих верхних уровней пирамиды, не так и много. К тому же сами потребности пятого уровня таковы, что люди сильнее всего отличаются друг от друга. Поэтому придумать унифицированное продуктовое решение будет не так просто.
@aheadofthepack
Все, помнят пирамиду потребностей А. Маслоу. Однако я не часто встречаю ее упоминание при генерации и проверке новых идей для продуктов. Может быть зря?
Удовлетворение потребностей – это главное правило жизнеспособности любого продукта. Логика подсказывает, что для увеличения охвата в B2C, продукт проще строить вокруг нижних примитивных потребностей. Так больше шансов удачно масштабироваться, даже несмотря на то, что поляна занята гораздо плотнее.
Придумывать концепты вокруг проблемы личностного совершенствования – идея благородная. Но много ли найдется пользователей? Практика показывает, что людей, достигающих верхних уровней пирамиды, не так и много. К тому же сами потребности пятого уровня таковы, что люди сильнее всего отличаются друг от друга. Поэтому придумать унифицированное продуктовое решение будет не так просто.
@aheadofthepack
Встреча совсем скоро
Я буду выступать на Третьем Аналитическом марафоне 17 декабря с докладом «Польза и вред от технического долга в аналитике». Несмотря на плотный график и яростные попытки вирусов подорвать приготовления, все сделано, и встреча состоится послезавтра.
Я подниму тему, с которой все сталкивались не единожды, и которая не раз приводила в уныние не одну команду разработки. Все мы сталкивались с ситуацией, когда надо срочно ускоряться, разрабатывать спецификации, писать код, выпускать релизы. Начальство говорит: «Давай, давай»! Но сделать ничего быстро не получается. Груз накопившихся в разработке проблем давит на плечи. И мы занимаемся переделкой ранее сделанной работы. Нас настиг Техдолг 💣
Почему же я акцентирую внимание именно на долге в аналитике? Возьмем любой сколь-либо кроткий цикл разработки, состоящий из выявления требований, имплементации, проверки качества и т д. Если сравнить стоимости ошибок и проблем в этой цепочке, то именно аналитика может стать самым дорогим звеном. Из практики получено, что вовремя не выявленные проблемы в требованиях могут быть на порядок дороже локальных проблем на последних этапах цепочки. Следуя принципам работы с рисками, именно этому направлению мы должны уделять особое внимание и выставлять максимальные приоритеты.
На марафоне будут еще 7 крутых спикеров с докладами о разных аспектах работы аналитиков: о процессах интеграции информационных систем, о дашбордах и визуализации данных, о различиях между проектом и продуктом, и о карьере аналитика. Будет интересно.
@aheadofthepack
Я буду выступать на Третьем Аналитическом марафоне 17 декабря с докладом «Польза и вред от технического долга в аналитике». Несмотря на плотный график и яростные попытки вирусов подорвать приготовления, все сделано, и встреча состоится послезавтра.
Я подниму тему, с которой все сталкивались не единожды, и которая не раз приводила в уныние не одну команду разработки. Все мы сталкивались с ситуацией, когда надо срочно ускоряться, разрабатывать спецификации, писать код, выпускать релизы. Начальство говорит: «Давай, давай»! Но сделать ничего быстро не получается. Груз накопившихся в разработке проблем давит на плечи. И мы занимаемся переделкой ранее сделанной работы. Нас настиг Техдолг 💣
Почему же я акцентирую внимание именно на долге в аналитике? Возьмем любой сколь-либо кроткий цикл разработки, состоящий из выявления требований, имплементации, проверки качества и т д. Если сравнить стоимости ошибок и проблем в этой цепочке, то именно аналитика может стать самым дорогим звеном. Из практики получено, что вовремя не выявленные проблемы в требованиях могут быть на порядок дороже локальных проблем на последних этапах цепочки. Следуя принципам работы с рисками, именно этому направлению мы должны уделять особое внимание и выставлять максимальные приоритеты.
На марафоне будут еще 7 крутых спикеров с докладами о разных аспектах работы аналитиков: о процессах интеграции информационных систем, о дашбордах и визуализации данных, о различиях между проектом и продуктом, и о карьере аналитика. Будет интересно.
@aheadofthepack
analyst-marathon.timepad.ru
ANALYST MARATHON #3. Онлайн-конференция. Видеозапись / События на TimePad.ru
Analyst Marathon — это образовательное онлайн-мероприятие для BA/SA-аналитиков.
Первая часть конференции посвящена процессам интеграции информационных систем в банковской сфере.
Во второй части речь пойдет о дашбордах и визуализации данных, проблеме…
Первая часть конференции посвящена процессам интеграции информационных систем в банковской сфере.
Во второй части речь пойдет о дашбордах и визуализации данных, проблеме…
Ощущения не менее важны функциональности
Популярным инструментом Канбан-доской пользуются все больше и больше команд. В одной из прошлых компаний наша переговорка со стеклянными стенами была увешена десятками если не сотнями разноцветных стикеров. Общую картину разработки можно было оценить быстро – одним взглядом. Но как же было неудобно поддерживать этот физический инструмент. То маркеры не пишут, то стикеры нужного цвета не закуплены, то обнаружится разработчик с «медицинским подчерком», то начинается внезапный стикеропад. Муторное это дело. Сейчас же постоянно кто-то на удалёнке, поэтому нашли аналогичный виртуальный инструмент и перешли на него.
В двух из инструментов для создания визуальных досок, о которых писал ранее, есть шаблоны Kanban Framework. Все бы хорошо, да задачи визуализированы не как стикеры, а как прямоугольники. Да еще и заливки фона цветом нет. Ну какой же это стикер? Издалека даже и не понятно, чем это лучше обычного списка задач с фильтром по статусам, который и так есть в любой системе управления задачами. Что сразу же заметили разработчики - нет того ощущения, что с реальной доской со стикерами. Их не хочется пощупать, поперетаскивать по полю туда-сюда, сгруппировать.
Проблема UX решилась рисованием своей собственной доски в том же инструменте с нормальными объектами типа стикер. Теми самыми разноцветными квадратиками, отбрасывающими тень на доску непроклеенным краем. Эх этот ламповый UX… Странно, что разработчики инструмента так не чувствуют.
@aheadofthepack
Популярным инструментом Канбан-доской пользуются все больше и больше команд. В одной из прошлых компаний наша переговорка со стеклянными стенами была увешена десятками если не сотнями разноцветных стикеров. Общую картину разработки можно было оценить быстро – одним взглядом. Но как же было неудобно поддерживать этот физический инструмент. То маркеры не пишут, то стикеры нужного цвета не закуплены, то обнаружится разработчик с «медицинским подчерком», то начинается внезапный стикеропад. Муторное это дело. Сейчас же постоянно кто-то на удалёнке, поэтому нашли аналогичный виртуальный инструмент и перешли на него.
В двух из инструментов для создания визуальных досок, о которых писал ранее, есть шаблоны Kanban Framework. Все бы хорошо, да задачи визуализированы не как стикеры, а как прямоугольники. Да еще и заливки фона цветом нет. Ну какой же это стикер? Издалека даже и не понятно, чем это лучше обычного списка задач с фильтром по статусам, который и так есть в любой системе управления задачами. Что сразу же заметили разработчики - нет того ощущения, что с реальной доской со стикерами. Их не хочется пощупать, поперетаскивать по полю туда-сюда, сгруппировать.
Проблема UX решилась рисованием своей собственной доски в том же инструменте с нормальными объектами типа стикер. Теми самыми разноцветными квадратиками, отбрасывающими тень на доску непроклеенным краем. Эх этот ламповый UX… Странно, что разработчики инструмента так не чувствуют.
@aheadofthepack
Telegram
На шаг впереди
One way ticket
Пандемия ускоряет процессы, которые и так давно шли в IT. Все больше компаний понимают, что долговременные изменения в ежедневной работе избежать не удастся. Удаленка и территориально распределенные команды становятся нормой. Что же нужно…
Пандемия ускоряет процессы, которые и так давно шли в IT. Все больше компаний понимают, что долговременные изменения в ежедневной работе избежать не удастся. Удаленка и территориально распределенные команды становятся нормой. Что же нужно…
Писать в стол не модно
Несколько лет назад, когда внедрял в фирме очередной Agile-подход, меня сильно беспокоили показатели эффективности и различные измеряемые параметры. Я начал экспериментировать с KPI, и параллельно изучал соответствующую литературу. На тот момент о KPI было написано и обмусолено немало, а вот про метрики для гибких методологий писали не так много. В русскоязычном сегменте материалы не находились.
Тогда я начал сам писать статью, чтобы проверить гипотезы, получить фидбек, понять, как думают другие. Статья была объемная, и я уж думал, через какой же ресурс ее опубликовать, чтобы собрать больше релевантных данных. Но одновременно, я был уверен не во всем материале, искал дополнительные доказательства, что-то дописывал. Потом даже выслал статью на рецензию, скорректировал и дооформил позицию.
И что в итоге? Заигравшись в этом интересном процессе, я начал утрачивает интерес к своему произведению. А потом и вовсе кинул статью "в стол" никуда в итоге не опубликовав.
Замечаю, что у некоторых также происходит и с продуктами. Прототип продукта пилится "для себя", многократно доделывается и улучшается, при этом до пользователя промежуточный результат не доставляется. Цикла обратной связи не происходит. Все время кажется, что можно еще что-то улучшить до показа. А вдруг не оценят, не поймут, закидают помидорами?
Не стоит забывать принцип, что ошибаться нужно быстро. Он работает, не только для тестирования новых продуктов, но и новых идей.
@aheadofthepack
Несколько лет назад, когда внедрял в фирме очередной Agile-подход, меня сильно беспокоили показатели эффективности и различные измеряемые параметры. Я начал экспериментировать с KPI, и параллельно изучал соответствующую литературу. На тот момент о KPI было написано и обмусолено немало, а вот про метрики для гибких методологий писали не так много. В русскоязычном сегменте материалы не находились.
Тогда я начал сам писать статью, чтобы проверить гипотезы, получить фидбек, понять, как думают другие. Статья была объемная, и я уж думал, через какой же ресурс ее опубликовать, чтобы собрать больше релевантных данных. Но одновременно, я был уверен не во всем материале, искал дополнительные доказательства, что-то дописывал. Потом даже выслал статью на рецензию, скорректировал и дооформил позицию.
И что в итоге? Заигравшись в этом интересном процессе, я начал утрачивает интерес к своему произведению. А потом и вовсе кинул статью "в стол" никуда в итоге не опубликовав.
Замечаю, что у некоторых также происходит и с продуктами. Прототип продукта пилится "для себя", многократно доделывается и улучшается, при этом до пользователя промежуточный результат не доставляется. Цикла обратной связи не происходит. Все время кажется, что можно еще что-то улучшить до показа. А вдруг не оценят, не поймут, закидают помидорами?
Не стоит забывать принцип, что ошибаться нужно быстро. Он работает, не только для тестирования новых продуктов, но и новых идей.
@aheadofthepack
Меняющиеся походы самообучения
Думаю, мало кто решится поспорить, что в текущем стремительном мире непрерывное обучение специалистов и менеджеров должно быть заложено как обязательный процесс. Как без этого создавать что-то новое?
Прошедший 2020 год, проведенный в адаптации к самоизоляции должен был способствовать и подталкивать к самообучению. Количество возможностей старых онлайн-сервисов росло за счет новых курсов. Появились новые платные и бесплатные образовательные мероприятия. У работников сферы IT высвобождалось время за счет сокращения перемещения из дома на работу и обратно. Казалось бы, все предпосылки на лицо.
Но теория разошлась с практикой. Даже по своему опыту могу сказать, что чуть было не сорвал выполнение собственного плана на обучение. На удивление под конец года помогла череда хворобы, когда за месяц в режиме нон-стоп осилил несколько только что купленных книжек и лекционный курс. Что же еще полезного можно делать сидя на больничном.
Ну а что остальные? Раз в год провожу опрос в компаниях, где работаю для сбора данных о качественных и количественных оценках обучения. Средняя температура по больнице иногда годится чтобы понимать, что нужно что-то менять.
Еще до проведения опроса заглянул в исследование Медиапотребление в России 2020, которое провела Delloite. Если покопаться, в нем можно найти, что за последний год охват чтения печатных книг снизился на 14%, а электронных не вырос. Рискну экстраполировать эту печальную тенденцию и на остальные области получения фундаментальных знаний.
Даже не смотря на малую выборку, этот тренд был заметен и у нас в фирме. По сравнению с 2019, в 2020 году читать стали меньше. При этом значительно меньше стали дочитывать книги до конца. Из-за чего это происходит писал в прошлом году в посте Два подхода к чтению книг. Однако не все так печально. Айтишники начали больше времени тратить на участие в легких формах обучения: семинарах, конференциях, митапах. Теперь понятно куда уходило время, и что делать EdTech-компаниям и предпринимателям. ;-) Хотя я считаю, что такие формы обучения прогрессивны, но недостаточны. Их крайне желательно подкреплять чем-то еще из классической тяжелой артиллерии.
@aheadofthepack
Думаю, мало кто решится поспорить, что в текущем стремительном мире непрерывное обучение специалистов и менеджеров должно быть заложено как обязательный процесс. Как без этого создавать что-то новое?
Прошедший 2020 год, проведенный в адаптации к самоизоляции должен был способствовать и подталкивать к самообучению. Количество возможностей старых онлайн-сервисов росло за счет новых курсов. Появились новые платные и бесплатные образовательные мероприятия. У работников сферы IT высвобождалось время за счет сокращения перемещения из дома на работу и обратно. Казалось бы, все предпосылки на лицо.
Но теория разошлась с практикой. Даже по своему опыту могу сказать, что чуть было не сорвал выполнение собственного плана на обучение. На удивление под конец года помогла череда хворобы, когда за месяц в режиме нон-стоп осилил несколько только что купленных книжек и лекционный курс. Что же еще полезного можно делать сидя на больничном.
Ну а что остальные? Раз в год провожу опрос в компаниях, где работаю для сбора данных о качественных и количественных оценках обучения. Средняя температура по больнице иногда годится чтобы понимать, что нужно что-то менять.
Еще до проведения опроса заглянул в исследование Медиапотребление в России 2020, которое провела Delloite. Если покопаться, в нем можно найти, что за последний год охват чтения печатных книг снизился на 14%, а электронных не вырос. Рискну экстраполировать эту печальную тенденцию и на остальные области получения фундаментальных знаний.
Даже не смотря на малую выборку, этот тренд был заметен и у нас в фирме. По сравнению с 2019, в 2020 году читать стали меньше. При этом значительно меньше стали дочитывать книги до конца. Из-за чего это происходит писал в прошлом году в посте Два подхода к чтению книг. Однако не все так печально. Айтишники начали больше времени тратить на участие в легких формах обучения: семинарах, конференциях, митапах. Теперь понятно куда уходило время, и что делать EdTech-компаниям и предпринимателям. ;-) Хотя я считаю, что такие формы обучения прогрессивны, но недостаточны. Их крайне желательно подкреплять чем-то еще из классической тяжелой артиллерии.
@aheadofthepack
Обещать - не значит жениться!
Казалось бы, понятия продукт и проект давно изучены и определены. Но до сих пор в работе встречаюсь с тем, что многие путают и сравнивают эти понятия.
Часто сравнение происходит в контексте бюджета и сроков. Например, смотря на спецификацию продукта горе эксперт заявляет, что может повторить это быстрее, потратив гораздо меньше. Хотя конкурирующая фирма, создавая данный продукт уже потратила в разы больше. Обещать, конечно, хорошо, а сможет ли он на самом деле сделать продукт за обозначенный бюджет?
Давайте посмотрим откуда берется такое непонимание и разница в расчетах?
Возможно дело в «проектном мышлении». Проектное мышление пропускает массу вопросов, не входящих в перечень задач:
✔️Сколько стоил непрерывный маркетинг продукта, исследования рынка конкурентов на протяжении его жизненного цикла?
✔️Сколько стоили неудавшиеся эксперименты и проверки гипотез?
✔️Сколько стоила цепь непрерывных улучшений продукта после получения обратной связи от пользователей?
✔️Сколько стоила поддержка клиентов, как только продукт прошел в продакшн?
✔️ Сколько стоила дистрибьюция и продажи?
✔️…
Как правило эти вопросы при сравнении упускаются из виду, т к проект – это всего лишь временное предприятие с конечной достижимой и заранее определенной целью.
На старте продуктовой разработки нет такой «реперной точки», обозначенной в будущем, в которой можно собраться и сказать: «Все молодцы! Мы хорошо поработали. Продукт сдан. Расходимся».
Когда-то в будущем действительно наступит момент, в котором расчеты и прогнозы покажут, что действительно пора принимать решение о сворачивании поддержки и вывода продукта из цикла разработки и производства. Но наперед эта точка заведомо неизвестна, как и неизвестны все развилки, которые приведут продукт в эту точку. Соответственно в разработке продукта заранее неизвестно сколько средств будет потрачено на это все. Именно поэтому, если взять бюджетный срез всех продуктовых активностей и приравнять это к проектному бюджету ничего хорошего не выйдет.
@aheadofthepack
Казалось бы, понятия продукт и проект давно изучены и определены. Но до сих пор в работе встречаюсь с тем, что многие путают и сравнивают эти понятия.
Часто сравнение происходит в контексте бюджета и сроков. Например, смотря на спецификацию продукта горе эксперт заявляет, что может повторить это быстрее, потратив гораздо меньше. Хотя конкурирующая фирма, создавая данный продукт уже потратила в разы больше. Обещать, конечно, хорошо, а сможет ли он на самом деле сделать продукт за обозначенный бюджет?
Давайте посмотрим откуда берется такое непонимание и разница в расчетах?
Возможно дело в «проектном мышлении». Проектное мышление пропускает массу вопросов, не входящих в перечень задач:
✔️Сколько стоил непрерывный маркетинг продукта, исследования рынка конкурентов на протяжении его жизненного цикла?
✔️Сколько стоили неудавшиеся эксперименты и проверки гипотез?
✔️Сколько стоила цепь непрерывных улучшений продукта после получения обратной связи от пользователей?
✔️Сколько стоила поддержка клиентов, как только продукт прошел в продакшн?
✔️ Сколько стоила дистрибьюция и продажи?
✔️…
Как правило эти вопросы при сравнении упускаются из виду, т к проект – это всего лишь временное предприятие с конечной достижимой и заранее определенной целью.
На старте продуктовой разработки нет такой «реперной точки», обозначенной в будущем, в которой можно собраться и сказать: «Все молодцы! Мы хорошо поработали. Продукт сдан. Расходимся».
Когда-то в будущем действительно наступит момент, в котором расчеты и прогнозы покажут, что действительно пора принимать решение о сворачивании поддержки и вывода продукта из цикла разработки и производства. Но наперед эта точка заведомо неизвестна, как и неизвестны все развилки, которые приведут продукт в эту точку. Соответственно в разработке продукта заранее неизвестно сколько средств будет потрачено на это все. Именно поэтому, если взять бюджетный срез всех продуктовых активностей и приравнять это к проектному бюджету ничего хорошего не выйдет.
@aheadofthepack
Бег за Лидером
Вы смотрели соревнование по легкой атлетике по бегу на средние дистанции?
Из общей массы участников выделяется группа лидеров, которая отрывается вперед. Один бегун бежит вперед, рассекая воздух. Ему труднее всего. Остальные идут сзади в потоке, экономия усилия. Лидеру крайне сложно правильно рассчитать свои силы среди равных конкурентов. Как правило на определенном этапе его поглотит и обгонит почти вся лидирующая группа. Часто такое происходит на последнем финишном круге. Тот, кто лидировал на середине дистанции, может даже не войти и в тройку на финишной черте.
Аллегория взята неспроста. Также происходит и в бизнесе, и в разработке продуктов в условиях жесткой конкуренции. Следовать за удачными решениями конкурентов достаточно легко с экономической точки зрения. Бюджет на исследования можно с успехом минимизировать. Если поступать еще умнее - перенаправлять денежные потоки и усилия в другие продуктовые активности. Именно так и получается обгонять конкурентов на поворотах.
Можно ли оставаться лидером на протяжении длительного периода в конкретных условиях? Да, возможно имея уникальное преимущество. Но это уже другая история.
@aheadofthepack
Вы смотрели соревнование по легкой атлетике по бегу на средние дистанции?
Из общей массы участников выделяется группа лидеров, которая отрывается вперед. Один бегун бежит вперед, рассекая воздух. Ему труднее всего. Остальные идут сзади в потоке, экономия усилия. Лидеру крайне сложно правильно рассчитать свои силы среди равных конкурентов. Как правило на определенном этапе его поглотит и обгонит почти вся лидирующая группа. Часто такое происходит на последнем финишном круге. Тот, кто лидировал на середине дистанции, может даже не войти и в тройку на финишной черте.
Аллегория взята неспроста. Также происходит и в бизнесе, и в разработке продуктов в условиях жесткой конкуренции. Следовать за удачными решениями конкурентов достаточно легко с экономической точки зрения. Бюджет на исследования можно с успехом минимизировать. Если поступать еще умнее - перенаправлять денежные потоки и усилия в другие продуктовые активности. Именно так и получается обгонять конкурентов на поворотах.
Можно ли оставаться лидером на протяжении длительного периода в конкретных условиях? Да, возможно имея уникальное преимущество. Но это уже другая история.
@aheadofthepack
Минимальные продукты
Сегодня займемся продуктовой археологии. Давайте посмотрим как понятие минимального продукта описывают авторы-визионеры.
С концепцией - Минимально жизнеспособный продукт (MVP) сталкивалось, наверное, большинство, кто изучал или применял продуктовый маркетинг. Формулирование первоначального определения приписывают Фрэнку Робинсону. Позднее идею подхватил и популяризировал Эрик Рис и его термин мне нравится больше. MVP - версия нового продукта, которая позволяет команде собрать как можно больше проверенной информации о клиентах с наименьшими усилиями. У MVP существуют и «близкие родственники». 😊
Роман Пихлер описывает термин - Минимально функциональный продукт, т е продукт, имеющий небольшое количество функций, которые призваны удовлетворить избранные потребности клиентов. Роман адепт фреймворка Scrum и его книги по этой теме не сложно найти в оригинале и переводе. Функциональность продукта формирует Scrum-команда. Действительно, в таких командах чистого маркетолога как правило нет, а его обязанности частично переходят к роли Scrum Product Owner (владельца продукта). Подход приоритезации с точки зрения функциональности является традиционным подходом, который описывает как будет выглядеть и работать продукт.
В книге Романа приведена ссылки на более ранние работы Марка Денна и Джейн Клиленд-Хуан. В них предложен похожий термин Минимальная коммерчески ценная функциональность, который обозначает наименьшую функциональность, способную все же создать ценность для покупателя.
Еще одно интересное определение - Минимальный привлекательный продукт (Minimum Loveable Product, MLP). Концепцию придумал Кэт Нуун, введя понятие продукта, который будет не только решать проблемы пользователей, но и устанавливать с ними эмоциональную связь. В предложенной концепции на передовую выходят не просто важные функции, или те, за которые пользователь готов заплатить, а опыт пользования. Это может быть дизайн, эстетика, удобство использования, например скорость работы или плавность изменения экранов. Пользователь уже имеет опыт с похожими альтернативами и минимальной функциональностью его уже так просто не зацепить. MLP позволят дифференцировать продукт на уже занятом рынке.
Как видно каждый смотрит на концепцию под своим углом.
@aheadofthepack
Сегодня займемся продуктовой археологии. Давайте посмотрим как понятие минимального продукта описывают авторы-визионеры.
С концепцией - Минимально жизнеспособный продукт (MVP) сталкивалось, наверное, большинство, кто изучал или применял продуктовый маркетинг. Формулирование первоначального определения приписывают Фрэнку Робинсону. Позднее идею подхватил и популяризировал Эрик Рис и его термин мне нравится больше. MVP - версия нового продукта, которая позволяет команде собрать как можно больше проверенной информации о клиентах с наименьшими усилиями. У MVP существуют и «близкие родственники». 😊
Роман Пихлер описывает термин - Минимально функциональный продукт, т е продукт, имеющий небольшое количество функций, которые призваны удовлетворить избранные потребности клиентов. Роман адепт фреймворка Scrum и его книги по этой теме не сложно найти в оригинале и переводе. Функциональность продукта формирует Scrum-команда. Действительно, в таких командах чистого маркетолога как правило нет, а его обязанности частично переходят к роли Scrum Product Owner (владельца продукта). Подход приоритезации с точки зрения функциональности является традиционным подходом, который описывает как будет выглядеть и работать продукт.
В книге Романа приведена ссылки на более ранние работы Марка Денна и Джейн Клиленд-Хуан. В них предложен похожий термин Минимальная коммерчески ценная функциональность, который обозначает наименьшую функциональность, способную все же создать ценность для покупателя.
Еще одно интересное определение - Минимальный привлекательный продукт (Minimum Loveable Product, MLP). Концепцию придумал Кэт Нуун, введя понятие продукта, который будет не только решать проблемы пользователей, но и устанавливать с ними эмоциональную связь. В предложенной концепции на передовую выходят не просто важные функции, или те, за которые пользователь готов заплатить, а опыт пользования. Это может быть дизайн, эстетика, удобство использования, например скорость работы или плавность изменения экранов. Пользователь уже имеет опыт с похожими альтернативами и минимальной функциональностью его уже так просто не зацепить. MLP позволят дифференцировать продукт на уже занятом рынке.
Как видно каждый смотрит на концепцию под своим углом.
@aheadofthepack
Минимальные продукты (продолжение)
Хочу поделиться подборкой новых и раритетных, но вместе с тем полезных книг по описанным концепциям минимальных продуктов, о которых я писал в предыдущем посте.
Если вам интересно, вы можете сами покопать в них информацию по описанию данного вида прототипов. Большую часть из них я читал полностью и ранее, но мне было не скучно углубится в них еще раз по данной теме.
📚 Марти Каган «Вдохновленные»
📚 Скотт Хёрф «Как создать продукт, который полюбят»
📚 Роман Пихлер «Управление продуктом в Scrum»
📚 Марка Денна и Джейн Клиленд-Хуан «Software by Numbers»
📚 Эрик Рис «Бизнес с нуля. Метод Lean Startup для быстрого тестирования идей и выбора бизнес-модели»
Если кто-то может дополнить мою подборку, прошу в комментарии.
Хочу поделиться подборкой новых и раритетных, но вместе с тем полезных книг по описанным концепциям минимальных продуктов, о которых я писал в предыдущем посте.
Если вам интересно, вы можете сами покопать в них информацию по описанию данного вида прототипов. Большую часть из них я читал полностью и ранее, но мне было не скучно углубится в них еще раз по данной теме.
📚 Марти Каган «Вдохновленные»
📚 Скотт Хёрф «Как создать продукт, который полюбят»
📚 Роман Пихлер «Управление продуктом в Scrum»
📚 Марка Денна и Джейн Клиленд-Хуан «Software by Numbers»
📚 Эрик Рис «Бизнес с нуля. Метод Lean Startup для быстрого тестирования идей и выбора бизнес-модели»
Если кто-то может дополнить мою подборку, прошу в комментарии.
Telegram
На шаг впереди
Минимальные продукты
Сегодня займемся продуктовой археологии. Давайте посмотрим как понятие минимального продукта описывают авторы-визионеры.
С концепцией - Минимально жизнеспособный продукт (MVP) сталкивалось, наверное, большинство, кто изучал или применял…
Сегодня займемся продуктовой археологии. Давайте посмотрим как понятие минимального продукта описывают авторы-визионеры.
С концепцией - Минимально жизнеспособный продукт (MVP) сталкивалось, наверное, большинство, кто изучал или применял…
Режим управленческого автопилотирования
Кто ездит на работу за рулем машины, наверное, знает, что большую часть известной дороги водитель находится в режиме «автопилота». В скором будущем эту функцию надеюсь заберет реальный автопилот, но пока имею в виду «автопилоте» в голове. Если повседневная манера вождения не агрессивна и лишена дополнительного стресс-адреналина, мало кто смотрит на знаки, расположенные вдоль известного маршрута. Между прочем именно поэтому, бывает попадаем на доброго дядю полицейского, притаившегося на дороге с односторонним движением, которая стала таковой на прошлой неделе. Еще реже бывалые водители вспоминают книжку с правилами дорожного движения.
Однако мозг опытного водителя хорошо помним какую полосу движения лучше выбрать в этот час, чтобы с большей вероятностью доехать быстрее и не уткнутся в пробку. Мозг работает в режиме автопилота экономя нашу энергию для более полезных вещей.
Тоже самое происходит и в продуктом или проектом управлении. Действия в стандартных ситуациях часто совершаются на автопилоте. А что, если замедлиться и спросить себя: «Почему было принято такое решение в конкретной ситуации?» Впадаешь в ступор: «Как почему?» Это первое решение, которое пришло в голову. Мозг мгновенно предложил его на основании предыдущего опыта решения схожих задач. У нас уже выработался некоторый паттерн принятия решений. Для большинства всплывающих задач это здравый подход. Неспроста постоянно появляются шаблонизированные фреймфорки, подходы и методы. Они помогают работать паттернами, выработанным не на собственной шкуре, а позаимствовав чужой обкатанный опыт.
Всегда ли годится подход работы на «автопилоте»? Конечно же нет! Как с управлением машиной можно попасть в аварию или влететь на штраф, так же и в управлении в любой нестандартной ситуации могут возникнуть проблемы.
Режим «автопилот» работать не будет если:
✔️ Необходимо виртуозно разрулить проект в нестандартных условиях с ограниченным лимитом времени-денег-ресурсов
✔️ Меняется технологический стек
✔️ На порядок увеличивается масштаб чего-либо
✔️ Если суммарные риски начинают превышать выработанные контролируемые значения
✔️и т д.
В итоге основная задача – это понять в какой ситуации сейчас находимся: в стандартной или не стандартной.
@aheadofthepack
Кто ездит на работу за рулем машины, наверное, знает, что большую часть известной дороги водитель находится в режиме «автопилота». В скором будущем эту функцию надеюсь заберет реальный автопилот, но пока имею в виду «автопилоте» в голове. Если повседневная манера вождения не агрессивна и лишена дополнительного стресс-адреналина, мало кто смотрит на знаки, расположенные вдоль известного маршрута. Между прочем именно поэтому, бывает попадаем на доброго дядю полицейского, притаившегося на дороге с односторонним движением, которая стала таковой на прошлой неделе. Еще реже бывалые водители вспоминают книжку с правилами дорожного движения.
Однако мозг опытного водителя хорошо помним какую полосу движения лучше выбрать в этот час, чтобы с большей вероятностью доехать быстрее и не уткнутся в пробку. Мозг работает в режиме автопилота экономя нашу энергию для более полезных вещей.
Тоже самое происходит и в продуктом или проектом управлении. Действия в стандартных ситуациях часто совершаются на автопилоте. А что, если замедлиться и спросить себя: «Почему было принято такое решение в конкретной ситуации?» Впадаешь в ступор: «Как почему?» Это первое решение, которое пришло в голову. Мозг мгновенно предложил его на основании предыдущего опыта решения схожих задач. У нас уже выработался некоторый паттерн принятия решений. Для большинства всплывающих задач это здравый подход. Неспроста постоянно появляются шаблонизированные фреймфорки, подходы и методы. Они помогают работать паттернами, выработанным не на собственной шкуре, а позаимствовав чужой обкатанный опыт.
Всегда ли годится подход работы на «автопилоте»? Конечно же нет! Как с управлением машиной можно попасть в аварию или влететь на штраф, так же и в управлении в любой нестандартной ситуации могут возникнуть проблемы.
Режим «автопилот» работать не будет если:
✔️ Необходимо виртуозно разрулить проект в нестандартных условиях с ограниченным лимитом времени-денег-ресурсов
✔️ Меняется технологический стек
✔️ На порядок увеличивается масштаб чего-либо
✔️ Если суммарные риски начинают превышать выработанные контролируемые значения
✔️и т д.
В итоге основная задача – это понять в какой ситуации сейчас находимся: в стандартной или не стандартной.
@aheadofthepack
Политика Открытых ушей
Политика открытых дверей - распространённая практика донесения обратной связи по восходящей линии в организации. Большинство компаний с демократичным подходом к управлению не забывают о ней.
Но кроме обратной связи должен быть и второй вектор – действие на эту обратную связь. Участливое выслушивание, не приводящее ни к каким результатам, делает концепцию открытых дверей бессмысленной. Поэтому добавим и второе немного ироничное измерение - Политику открытых ушей.
👉 Подробнее в статье на vc
Политика открытых дверей - распространённая практика донесения обратной связи по восходящей линии в организации. Большинство компаний с демократичным подходом к управлению не забывают о ней.
Но кроме обратной связи должен быть и второй вектор – действие на эту обратную связь. Участливое выслушивание, не приводящее ни к каким результатам, делает концепцию открытых дверей бессмысленной. Поэтому добавим и второе немного ироничное измерение - Политику открытых ушей.
👉 Подробнее в статье на vc