Притчи продуктолога

2021-04-15 12:12:23 130. Горизонтальный рост для продакта

Менеджер продукта может расти вертикально: отвечать за группу продуктовых команд или стать директором по продукту, CPO или даже CEO. А может расти горизонтально – открывать новое, не меняя должность.

Хороший способ расти горизонтально – сменить продукт. У меня два раза получилось сделать это, не покидая компанию.

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

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

В обоих случаях и я и команда получили возможность заниматься новыми интересными вещами. При этом «старые» продукты никак не пострадали и не замедлили своего развития. К сожалению, я встречал и плохие примеры перехода, когда команда доводила свой продукт до такого печального состояния, что сама не была готова им заниматься и просто бросала его. В таких случаях «новой» команде приходилось в одиночку бороться за живучесть корабля.

Ранее я писал про майндсет и чеклист при передаче продукта. Открыть/Комментировать

2021-04-13 12:12:18 129. Уйти ответственно

Когда-то давно я работал дизайнером в московско-швейцарской компании. Делал весь дизайн – айдентику, графический дизайн, сайты. Общался с типографиями и разработчиками. За два года в моих руках сосредоточилось огромное количество материалов, исходников, контактов.

Когда я решил уйти из компании, я аккуратно разложил все по папочкам и написал подробную инструкцию, где что найти. Мне сказали: «Ой, спасибо, ты такой ответственный».

Через полгода позвонили:

– Привет, не подскажешь, где исходник взять?
– В такой-то папке.
– А где она?
– Я же вам отдал! По такому-то адресу в корпоративной сети.
– Ой, да… Хорошо, что есть такое.

После этого еще пару раз звонили, и этот разговор повторялся.

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

В течение года пару раз звонили:

– Ой, а помнишь мы вот это делали, где материалы?
– В такой-то папке.
– А где она?
– Я же вам отдал! По такому-то адресу в Гугл документах.
– Ой, да… Хорошо, что есть такое. Открыть/Комментировать

2021-04-12 12:12:07 Просить прощения авансом

На работе я запускаю сложные проекты, потому приходится общаться со многими людьми. С кем-то легко работать, с кем-то сложно. Бывают недопонимания, случаются конфликты и даже ссоры.

Я не буду разбирать моральную составляющую конфликтов. Обращу внимание на экономическую часть. Все время, пока длится конфликт, работа стоит или делается медленнее, чем могла бы. Неразрешенный конфликт – это убыток.

Если проблему невозможно решить в тот же день, я стараюсь извиниться авансом. Например, принес дизайнер макет в последний день срока и оказалось, что сделал не то, что нужно. Я не смог сдержать раздражения и наехал на него. Понимаю, что в ближайшие дни мы не сможем обсудить ситуацию, а макет нужно доделать. Тогда я говорю: «Прости, что говорил с тобой раздраженно! Я очень ценю то, что ты делаешь и благодарен за твою работу. У нас запланирована встреча через неделю, давай на ней разберем ситуацию и решим, как быть в будущем. А пока, если можешь, постарайся не сильно на меня обижаться. Мне жаль, что я тебя обидел».

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

————————————
Пост не номерной, потому что написан мною для другого канала. На своем канале я делаю перепечатку не раньше, чем через месяц после премьеры. #неуникальныйконтент Открыть/Комментировать

2021-04-08 12:12:14 128. Когда надо остановить или закрыть продукт

Когда мне было 13 лет, я смотрел боевик про крутого полицейского. Здоровый бородатый мужик спокойно раскидывал злодеев, включая модных тогда каратистов. По сюжету он – бывший гребец. Мой друг, с которым мы вместе смотрели фильм, сказал: «Понятно почему он такой здоровый, у нас на озере секция гребли, там все амбалы».

Я очень хотел быть большим и сильным, поэтому записался в секцию гребли. Я занимался 2 раза в день. Не отлынивал от заданий тренера. Тренировался самостоятельно. У меня начало неплохо получаться, и через несколько месяцев занятий меня взяли на соревнования в другой город. Я мечтал о спортивной карьере.

А потом наступил 1991 год, рухнул Советский Союз, а вместе с ним система детско-юношеских спортивных школ. Тренировки прекратились. Другой секции в моем городе не было.

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

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

А прекрасная продуктовая команда пусть начнет заниматься новым продуктом. Открыть/Комментировать

2021-04-07 11:02:22 Я иногда приглашаю других авторов к себе на канал, чтобы они писали о том, в чем я не очень разбираюсь. Хочу представить вам консультанта по стратегии Алексея Подклетнова. На своем канале Disruptors он разбирает стратегии роста и рассуждает о трендах в различных индустриях.
————————————

Где в нишевых товарах собака зарыта

Лет 20-30 назад стратегические умы сформировали концепцию длинного хвоста. Суть такая: представьте весь спрос в виде какого-нибудь животного, например собаки. Массовые относительно недифференцированные товары пользуются высокой популярностью, но число их позиций ограничено, поэтому совокупный спрос на них похож на квадрат, или «тело» собаки. Нишевые высокодифференцированные товары пользуются меньшим спросом, но их ассортимент несметен и многолик, поэтому спрос на них растягивается в «длинный хвост».

Товары хвоста могут пользоваться стабильным спросом, но емкость их рынка ограничена, а потребители разрознены. Тем не менее, инновации (например, 3d-печать) повышают доступность производства мелкосерийных изделий, а маркетплейсы и новые решения в логистике (например, развитие доставки последней мили) упрощают процесс попадания таких товаров к потребителям. В итоге «хвост» утолщается и становится конкурентоспособной альтернативой «телу». Потенциально внутри хвоста сидят и нишевые товары массового спроса, пока не способные конкурировать с крупными брендами. Многие станут покупать зубную пасту и туалетную бумагу от нишевых производителей? Сейчас – вряд ли. Ведь помимо решаемых уже сейчас вопросов производства и доставки, есть более сложная проблема доверия.

Но и в этом направлении тоже есть подвижки. Появляются бизнес-модели для агрегации товаров нишевых производителей, упрощающие не только дистрибуцию и маркетинг, но и помогающие малым брендам репутационно. Яркий пример – Вкуссвилл. Небольшие хозяйства не только находят сбыт, но и, попадая в ассортимент крупной сети, показывают потребителю, что они не пассажиры, а достойные доверия поставщики. Другой пример – формирующийся маркетплейс фермерской сельхозки Свое.Фермерство от РСХБ (подробно разбирал здесь).

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

На своем канале @disruptors_only я рассказываю про инновационные практики, меняющие бизнес и нашу жизнь в целом.

#партнерскийпост Открыть/Комментировать

2021-04-06 12:12:13 127. Когда нужно разделить команду

С точки зрения пользователя у компании может быть один продукт, например, агрегатор объявлений об аренде квартир. Но внутри – это много разных продуктов: сборщик объявлений с разных площадок, система для модераторов, приложение под iOS, приложение под Android, веб-портал, биллинг, система для работы с корпоративными клиентами. У каждого такого «внутреннего» продукта может быть своя команда разработки, свой менеджер продукта и собственные бизнес-метрики.

Обычно компании растут постепенно и начинаются с одной команды и одного продукта. Постепенно происходит рост, но количество продуктов растет быстрее, чем количество команд. В какой-то момент одна команда отвечает за 8 разных продуктов. Приходится делить команду на две. А потом еще на две.

Делить команду нужно, когда этого попросит один из трех участников:

Команда. Разработчикам может быть морально тяжело отвечать за множество различных систем и постоянно переключаться. Или команда разрослась до 15 человек, и работать по Скраму стало затруднительно.

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

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

Технически команду делить не сложно. Скорее всего она уже давно внутри себя разделила зоны ответственности. Осталось оформить это официально и нанять недостающих людей в обе части. Открыть/Комментировать

2021-04-01 12:12:12 126. Советоваться нужно, но сложно

Мне всегда нравился этот отрывок из Притчей Соломона:

Предприятия получают твердость чрез совещание, и по совещании веди войну. (Притчи 20:18)

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

Прежде всего я довольно гордый и самоуверенный человек. Мне кажется, что я сам отлично знаю, как построить команду, как провести эксперимент, сделать продукт успешным. Так зачем советоваться? Жизнь не раз учила меня, что так поступать глупо, но я все равно наступаю на эти грабли.

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

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

В конце концов я сделал работу гораздо эффективнее и элегантнее, чем планировал изначально. Но далось мне это нелегко. Открыть/Комментировать

2021-03-30 12:12:13 125. Допустимая ржавчина

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

У моего коллеги была крутая тачка – девятка. Она была достаточно новая и совсем не ржавая. Я завидовал ему всеми оттенками зависти. Однажды я увидел, что на его прекрасно-нержавой машине дворники покрыты ржавчиной. Я очень удивился и спросил: «Почему ты не заменишь дворники, это же недорого?»

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

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

Коллеги ворчат, мол, зачем это все, формализм ведь, толку никакого. А я улыбаюсь и говорю: «Лучше пусть бюрократия будет здесь, чем в нашем продукте». Открыть/Комментировать

2021-03-25 12:12:25 124. Закон Мёрфи в разработке продуктов

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

Менеджер продукта пробует новую фичу, чтобы сделать красивые скриншоты и похвастаться достижениями. Случайно он обнаруживает критическую проблему. Инженер по качеству и программисты в шоке от того, что пропустили такой косяк. Каются. Все исправляют.

Новую фичу презентуют заинтересованным лицам. Во время демонстрации перед всем честным народом вылазит новая ошибка, еще более страшная, чем все предыдущие. Вся команда в шоке. Все каются. Исправляют.

Однажды фичу решает посмотреть САМЫЙ-БОЛЬШОЙ-НАЧАЛЬНИК, это может быть главный инвестор или какой-нибудь председатель совета директоров. Он не пользовался продуктом уже полгода, но тут решил зайти на пару минут. Именно в эти пару минут он находит самую ужасную ошибку из всех виденных ранее.

Мы столкнулись с частным случаем закона Мёрфи:
Чем выше начальник, тем критичнее проблема, которую он обнаружит. Открыть/Комментировать

2021-03-23 12:12:15 123. А/Б-эксперименты без стратегии – путь в никуда

Раньше я считал А/Б-эксперименты вредной ересью. Сначала дизайнер с любовью и вкусом создает продукт, например, сервис по бронированию отелей. Потом устраивают 200 тестов «какая кнопка принесет больше покупок, красная или синяя» и в результате получают неудобного и некрасивого монстра. Множество маленьких полезных улучшений не приводят к хорошему результату.

Поэтому я предпочитал развивать продукты, основываясь на юзабилити-исследованиях и собственном хорошем вкусе. Это приносило плоды. Но лишь до поры, пока я не стал заниматься сложными продуктами с большой аудиторией. В них количество факторов, влияющих на результат, оказалось таким большим, что создавать продукт на основании дизайнерской чуйки стало невозможно.

В результате я примерил два подхода:

1. Если не понятно, куда развивать продукт стратегически, мы генерируем из головы хоть какие-то идеи и на их основе проводим количественные А/Б-эксперименты и качественные UX-исследования. Цель – провалидировать идеи и понять «в какую сторону бежать».

2. Когда понятно, в какую сторону развивать продукт, надо писать стратегию и дальше двигаться под ее руководством. Анализировать все новшества качественно (UX-техники) и количественно (аналитика).

3. А/Б-эксперименты использовать для контроля, как способ проверить, что не делаешь хуже.

Если совсем коротко: А/Б-эксперименты без стратегии – вредны. Но они помогают с идеями на ранних этапах и помогают не заблудиться на поздних. Открыть/Комментировать