​🚀 О продуктовом маркетинге

Каждый раз, когда я смотрю на выстраивание маркетинга в продуктовой компании, это напоминает мне работу отечественных коммунальных служб: сначала положим асфальт, а потом можно приступать к прокладке канализации.

Смысл маркетинга не в том, чтобы прийти в компанию, где есть продукт, и пытаться его продать. Надо делать так, чтобы маркетинг, то есть продажи и работа с рынком, были частью продукта с самого начала. Узнать, что же нужно людям, исследовать их потребности. Ставить гипотезы на MVP. Собирать обратную связь. И все это в процессе разработки, а не после, когда уже куча времени потрачена.  

Иначе весь маркетинг сводится к изготовлению оберточной бумаги. Быть может, красивой, но обычно абсолютно бесполезной.

​🔺 Ликбез: упорство и упертость

В менеджменте есть два разных качества — упорство и упертость.

Упорство — это когда без геймификации, дополнительной мотивации и прочей фигни команда может работать над задачами. Строить и проверять гипотезы, искать новые пути решения.

Упертость — когда команда раз за разом пытается оживить дохлую лошадь. Заставить работать идею, когда очевидно, что идея не работает.  

Очень часто эти два качества путают. Хотя нормальному менеджеру различить их просто: упорные команды выглядят усталыми и много работают, но глаза людей не потухли. Упертые команды выглядят так же, но огонька энергии и здравого смысла у людей не осталось. Если сами отличить не можете, потому что тоже попали в ловушку упертости, попросите кого-нибудь со стороны понаблюдать за работой. И все станет ясно.

Ваша команда должна быть максимально упорной и минимально упертой.

​🏹 Об управлении ожиданиями

Один из моих менеджеров проектов как-то объяснял начинающему аналитику, зачем нужно планировать свою работу. И зачем делиться этими планами, управлять ожиданиями других членов команды. Да, иногда и такое приходится объяснять, молодежь нынче та еще.

"Вот представь, сидишь ты в очереди к врачу или в какое-нибудь госучереждение. И единственное, что ты знаешь — что ты в очереди. Даже если она электронная, у тебя есть только номерок. Может, твоя очередь подойдет минут через десять, а может — через три часа. Ты жутко мучаешься от этого.
Другое дело — если ты уверен, что в ближайшие три часа тебя точно не вызовут. Ты можешь планировать свое время — пойти в кафе, побродить в парке, сгонять в магазин. Ты чувствуешь, что можешь управлять своими действиями.

Вот поэтому важно и планировать, и делиться планами".

Лучше и не объяснить.

​🎨 Спрашивали — отвечаем 24

“Я дизайнер по образованию, а с недавних пор стал арт-директором в небольшой компании. И у меня есть вопрос, касающийся управления рисками.
Давайте представим себе такую ситуацию: проджект-менеджер давно работает со своей командой, и процесс идёт хорошо. Но однажды кто-то из спецов срывает сроки.

— Что случилось? — спрашивает менеджер.
— Мы взялись за задачу как обычно, — отвечают дизайнеры / программисты / маркетологи, — но потом нам не понравилось то, что получается, и мы стали переделывать. Всех предупредили, что не укладываемся к дедлайну, но сейчас не готовы назвать дату окончания наших творческих поисков.

Что в этом случае должен сделать ПМ? Через месяц релиз, а ещё нужно всё собрать и протестировать”.

На всякий случай: арт-директор и РМ — разные роли. Первый отвечает за дизайн продукта. Второй — за сроки, бюджет и скоуп проекта. Совмещать эти роли в одном человеке — зло. Уж очень разные у них цели.  

РМу нужно:
1. Спросить себя, а точно ли он РМ? В проекте с жестким дедлайном исполнители позволяют себе делать какие-то задачи без его одобрения, меняют скоуп, да еще и нарушают сроки, а он об этом узнает последним. Серьезно? Друг мой, соберись и начни уже быть менеджером.

2. Запретить навсегда критерий “дизайн не нравится”. Это слишком субъективно, а мы тут проект делаем и деньги хотим заработать. Должны быть критерии “дизайн решает задачу клиента” и “дизайн соответствует требованиям”. Дизайн — не искусство. Это такая же обычная работа, как любая другая. Печь пирожки, создавать код, проводить маркетинговое исследование, писать текст, делать дизайн. Хотите искусства — идите в художники. Дизайнер не творит абстрактную красоту и не делает то, что ему вздумается, а решает задачу клиента. Так же и с любой другой профессией. Разраб, которому вдруг не нравится код, просто не подумал хорошенько, когда его писал. Это не про искусство, это про профессионализм. Не нравится? Делай так, чтобы нравилось.  

3. Ввести короткие итерации. Прошло три дня — покажите, что вы сделали. Все гибкие проектные подходы существуют ровно для того, чтобы менять продукт на лету и не обнаружить через месяц, что “результат не нравится”. Спринты, приоритизация беклога, танцы у белой доски. Вот это вот все.

4. Управлять рисками. Это уже  менеджмент по-взрослому. Вести реестр рисков, оценивать их регулярно, составить план по управлению каждым. Придется многому научиться, но в долгосрочной перспективе оно окупится.

5. В описанной ситуации — остановить все работы по переделке того, что “не нравится”. Проверить, можно ли использовать уже созданное, чтобы успеть к дедлайну. Ставить задачи на ближайшие три дня, с ежедневным контролем прогресса. Ввалить исполнителям за несогласованные с РМом работы.    

Творческий поиск — это очень классно, когда он происходит за счет кого-то другого. Но стоит задержать дизайнеру зарплату из-за того, что бухгалтер ушел в творческий поиск и ищет новые смыслы в квартальной отчетности, — сразу дизайнер начинает понимать что-то о жизни и делает меньше глупостей.

​🌋 Подлинная мотивация

Удивительно, как много компаний до сих пор пытаются мотивировать сотрудников “большими идеями”.

“Мы меняем мир! Давай делать это вместе! Внеси свой вклад!”

Это работает только с особо романтичными барышнями и иногда — со вчерашними студентами.  

Это бал лицемерия: ни одна компания не хочет менять мир, но точно хочет прибыли.

Мотивировать надо не лозунгами, а измеримыми экономическими величинами. Говорить надо не об изменении мира, а о деньгах. Если вы об этом не говорите, скорее всего, у вашего продукта не сходится юнит-экономика.

Изменения мира могут быть только побочным эффектом от работы. Делать это целью? Нет, спасибо.

🧬 Тренажер для менеджеров и не только 1-118

Вы управляете проектом длиной восемь месяцев по созданию системы для государственного заказчика. Четыре месяца уже позади.  

Вы соблюдаете почти все внутренние плановые сроки: одну веху прошли с недельным опозданием, но знаете, как догнать. Управление рисками у вас в проекте на высоте.  

С заказчиком у вас отличные отношения, он доверяет вам, что в подобных проектах встречается не так уж и часто. “Побольше бы таких вендоров!”, — любит говорить он.

Однажды утром к вам пришел один из ведущих разработчиков и предложил интересное решение: если использовать в проекте современную продвинутую технологию ABCD, то можно сократить время разработки на месяц.

Вы не первый год знаете этого разраба, он настоящий профессионал, и обычно все его предложения технически хороши.

Комментарии к задачке, как обычно, послезавтра)

"Заботиться о сотрудниках важнее, чем о клиентах. Если вы заботитесь о ваших сотрудниках, они сами будут заботиться о ваших клиентах. А ваши клиенты будут заботиться о ваших акционерах".
Ричард Брэнсон

Именно. Клиентский сервис начинается с заботы о сотрудниках.

​🦈 Комментарии к задачке 1-118

Вариант А плох. Согласиться на предложение разраба и добавить новую технологию в середине проекта — огромный риск. Но даже если представить, что сроки удалось сократить, нормальный менеджер должен спросить себя: “А что произойдет с бюджетом? Качеством? Составом задач?” Менеджер управляет всеми этими параметрами, не только сроками.    

Вариант В — не менеджерский. Посоветоваться с руководителем, воспринимая его как более опытного человека, можно. Но не нужно перегружать его проблемами, за решение которых платят вам. Бегать с каждой задачей наверх — плохая практика.  

Вариант С не лишен смысла: вы отказываетесь, не желая рисковать и стараясь сохранить гладкий график выполнения проекта. Но вы упускаете возможность завершить работы раньше и выглядеть еще лучше в глазах стейкхолдеров. Годится как вариант для не очень опытного РМа, но не подходит профи.  

Выбирать вариант D и советоваться с заказчиком нельзя ни при каких обстоятельствах. Клиенты добрые, пока все идет хорошо. Как только начинаются проблемы, клиенты демонстрируют волчий оскал и кроют вас матом на всех встречах. Клиенты — негодные советчики.

Так же обстоит дело и с командой. Команда нужна чтобы делать проектные задачи, искать красивые решения технических проблем. Но команда не рулит проектом и не принимает управленческих решений. Отвечает за проект менеджер, и никто другой.      

Так что верный вариант — Е. Сначала анализируем последствия внедрения технологии, а только потом принимаем решение. Тем более, у вас в проекте управление рисками на высоте. )    

В реальной проектной жизни подобные истории встречаются сплошь и рядом. Я видел много ситуаций, когда менеджер загорался идеей разраба и навлекал беду на свой проект.    

Не принимайте необдуманных решений. Тот факт, что разработчик до сих пор не ошибался, означает, что его идея заслуживает внимания и ваших дальнейших усилий. Не более того.

​​🎡 Спрашивали — отвечаем 25

“Сергей, привет!
Регулярно читаю ваш канал об управлении проектами, очень нравится, спасибо за него большое!

В работе у меня сейчас возник новый для меня кейс: делаем важный продукт для B2C, в команде 3 разработчика, один из которых аутстафер. До сдачи осталось около месяца, разрабы загружены полностью, но впритык-впритык с небольшим запасом успеваем. Аутстафер на удалёнке, работает из другого города. Неделю назад у него родился ребёнок и, несмотря на его заверения, что он всё будет успевать, видим регресс в его производительности. (Заранее о том, что у него будет ребёнок, нас никто не предупредил). Часть задач дольше обозначенного срока находятся в работе, джиру почти перестал актуализировать. По хорошему, надо было бы его заменить на другого (аутстаф же, и это же предложил его аутстаф-руководитель), но реальность нашей компании такова, что новому аутстаферу будут около месяца делать все необходимые доступы + время на погружение в проект. Над проектом навис риск срыва сроков.

Что делать в такой ситуации?”

Для начала стоит разобраться, это минутная слабость аутстаффера, или он поплыл основательно. Спокойно и дружелюбно поговорите с ним, укажите на косяки в работе, подробно разберите каждый. Ваша цель — успешно завершить проект, а не доказать, что человек плохой.

Дайте ему задачу на пару дней, остальные уберите. Через день спросите, как идет. Как сделает эту, дайте следующую. Требуйте соблюдения правил и следования процессам. Должен в jira что-то заполнить — проверяйте каждый день, что заполнил. Если ситуация наладилась, то увеличивайте паузы между точками контроля. Если нет — ничего уже не сделать на такой короткой дистанции, отпустите ситуацию. Пусть человек работает так, как может.  

Параллельно сделайте все, чтобы его задачи были не на критическом пути. Передайте самые болезненные темы другим людям. Режьте скоуп. Начинайте разговаривать с клиентом, чтобы морально подготовить его к возможному срыву сроков.    

На будущее: надо управлять рисками. Когда работаешь с внешними исполнителями, риск того, что они внезапно перестанут нормально работать, один из главных. А теперь он материализовался и стал уже не риском, а проблемой. С проблемами иметь дело сложнее, чем с рисками.

Если бы у вас был реестр рисков, вы бы его просто открыли и прочитали, что делать, когда аутстаффер отваливается.  

Но готов спорить, что открывать вам нечего. )

​📈 Что менеджеру нужно знать об отображении данных

Мы часто делаем презентации и отчеты с данными: ростом числа клиентов, динамикой выручки, расходом бюджета проекта, сегментацией пользователей продукта.

Для этого мы используем графики и диаграммы.

Исследования показывают, что человек неодинаково воспринимает объекты разных типов. Некоторые ему понятны сразу, он не тратит сил на их обработку. Другие требуют усиленного внимания и анализа.

Если наша цель — упростить восприятие, сэкономить аналитические ресурсы слушателей, то стоит соблюдать несколько правил.

=> Быстрее всего люди обрабатывают положение точки на прямой. Поэтому двумерные объекты — самые удобные для восприятия.
Где мы сейчас в проекте? А, вот линия времени, вот границы спринта, вот дата окончания. Все понятно.

=> Люди быстро обрабатывают длину линий и расположение объектов на плоскости. Это хорошая новость для любителей гистограмм и линейных графиков. Человек сразу понимает, какой столбик диаграммы длиннее. И какая точка выше остальных на точечной диаграмме. Точки и линии — это хорошо.

=> Людям трудно обрабатывать площадь или величину угла. Разница между целой пиццей и половинкой еще понятна, но на глаз трудно различить треть и четверть. Круговые и кольцевые диаграммы, закрашенные секторы кругов и тому подобное — это плохо.

=> Любые 3D-объекты под запретом. Трехмерность на плоскости — гарантированное искажение и объекта, и его восприятия.

=> Цвет не может быть самостоятельным способом выделения объектов, потому что у человека нет предустановленных связей цвета и количества. Синее больше красного? Или красное больше? Цвет работает только вместе с другими способами выделения: все точки над прямой коричневые, а под ней — зеленые.

В общем, все просто: надо отображать данные точками, линиями и их положением на плоскости. Круги, кольца и объемные объекты — не использовать.

​🍭 Нерешаемые задачи

Рано или поздно опытный менеджер приходит к важному выводу: не все проблемы можно решить.

Мир устроен так. Около 80% всех проблем в бизнесе можно решить управленческими способами. Договориться с людьми. Спланировать и проконтролировать исполнение. Предусмотреть риски. Сделать правильный договор. Нанять хороших людей. Организовать процесс. Написать, позвонить. Эскалировать.    

Процентов пятнадцать проблем можно решить за счет улучшений и автоматизации. Внедрить полезный инструмент. Заменить человека алгоритмом.

Но есть последние пять процентов проблем. Их решить нельзя. Совсем нельзя. Никак.

Не надо тратить силы и время на их решение. Не надо вливать в эти попытки деньги. Просто принять и двигаться дальше.

Путь к осознанию этого факта долог, но именно он отличает настоящего менеджера от всех прочих.

​🐒 Опыт Ганса

Каждый раз, когда мне пытаются подсунуть очередного эксперта “экс-Яндекс, экс-Сбер, экс-Мэйлру”, я представляю, как на сцену провинциального дома культуры выходит конферансье и говорит:

— А теперь перед вами выступит Ганс Шульц, участник первой и второй мировых войн! Ганс расскажет, как правильно воевать и побеждать!

Ганса я готов слушать только чтобы расширить список историй из цикла “так делать не надо”.

А если про победы, мы лучше кого-нибудь еще послушаем.

​​🪵 Владельческий подход

Нет ничего глупее, чем пытаться развить у сотрудников "владельческий подход" к работе. Каких только способов не придумывали собственники бизнесов для этого, и ни один не работает.

Особенно забавно наблюдать, как собственнические ценности пытаются привить в крупных компаниях с неимоверно длинной иерархической управленческой системой. И жуткой бюрократией.

— Вы должны мыслить как владельцы, хозяева нашего бизнеса!
— А можно мне завтра на час позже прийти?
— И не мечтай!

Единственный способ заставить сотрудника думать и действовать как собственник — сделать его собственником.

И даже это не всегда помогает. Мало поделиться с сотрудником долей, надо ведь, чтобы он начал работать как собственник. А это просто не всем дано.

Нет, люди не умеют решать проблемы на высоком уровне. Нет, люди не могут сами решить, чем им заниматься. Нет, люди не могут работать по 15 часов в день без выходных.

Хотите, чтобы ваша команда смотрела на чужой бизнес, как на свой? Без шансов.

​👤 Корпоративные ценности

Полно компаний, которые в первом пункте своей "миссии" заявляют: "Люди — наш главный актив".

Актив — часть бухгалтерского баланса, отражающая состав и стоимость имущества организации. В принципах МСФО написано, что активы — это ресурсы, контролируемые компанией в результате прошлых событий, от которых компания ожидает экономической выгоды в будущем.

Ни одно из этих утверждений к сотрудникам компании применять не следует.  
Сотрудники — не актив. Это живые люди, с которыми вы работаете.

Можно начать миссию со слов: “Мы понимаем разницу между активами и людьми. И не путаем их никогда”.

Но так, конечно, ни один маркетолог-стратег не напишет.

​☎️ Коммуникации by default

Самое клевое — когда есть правила коммуникаций, которым все следуют по умолчанию.

Например, провел менеджер совещание в zoom и трем десяткам участников разослал протокол. Плохая практика: менеджер в ответ получил 30 писем со словами «Согласовано, замечаний нет». Хорошая практика: участник молчит, пока у него нет замечаний. Если к определенному времени ни от кого комментариев по делу не пришло, протокол автоматически считается согласованным.

Или попросил менеджера коллега-продавец оценить стоимость доработки софтины для клиента. Менеджер все сделал, отправил коллеге оценку. Для него и команды это обычная задача. Плохая практика: коллега в ответ пишет «спасибо огромное!» Хорошая практика: коллега благодарен по умолчанию, лишних писем нет.
А если коллега совсем не может от отправки «спасибо» отказаться, то пусть хотя бы пишет не в ответ на каждое письмо.

Или написал менеджер письмо с задачей сотруднику и больше ничего не спрашивает. Плохая практика: сотрудник отвечает: «Задачу принял!» И все. Зачем? Почта/Jira и так нормально работают. Если задачу правильно поставили, не надо подтверждать ее получение. Хорошая практика: сотрудник менеджеру лишних писем не пишет, а вопросы задает только по существу.

Придумать и использовать в команде правила коммуникаций по умолчанию — прекрасный способ избавиться от инфомусора.

​⏺ Три ошибки менеджера

Вы поставили человеку задачу и видите, что она не сделана. Значит, вы совершили одну из трех ошибок:

=> Неверно выбрали исполнителя.  
=> Плохо объяснили ему задачу.  
=> Не проконтролировали результат.  

Большинство менеджеров верят, что основная причина несделанной задачи —  не те люди. Или считают, что недостаточно контролировали исполнителя.

Но никто и никогда не готов признать, что причина провала в плохой постановке задачи.

Вы уверены, что хорошо ставите задачи?

🪳 Тренажер для менеджеров и не только 955-828

Вы — владелец компании, которая успешна на рынке и переросла рамки стартапа. Основной ее продукт — сервис поиска и покупки автомобилей в интернете.

В команде тридцать человек, большая часть которых с вами не первый год. Вы все еще руководите компанией, но подумываете нанять нового гендиректора, а себя посвятить стратегии и работе с инвесторами.  

Сейчас вечер пятницы. Вы решили посмотреть, как там поживает продукт. Тем более, позавчера был большой релиз. Берете пивка и открываете ноутбук.

Через некоторое время вы понимаете, что при некоторых условиях сервис работает не совсем корректно: пользователю наравне с обычными машинами предлагаются игрушечные. В алгоритме явно где-то ошибка. Вас она раздражает.