«Продакт-менеджер – это тот, кому больше всех надо» (народная мудрость)
Есть банальный, но действенный способ понять, приносит ли ваша работа какую-то пользу: попробуйте объяснить инвестору (или бабушке), чем вы занимаетесь, не используя явных заимствований. Что, менеджер? Не слышали. Евангелист? Спасибо, бабушка еще на этапе Башорга записала вас в секту. Инженер? Уже лучше, но как быть с гуманитариями?
После десяти лет работы проджект-менеджером я придумал, что для родителей я «организатор» (полшага от массовика-затейника). А потом сменил работу на еще менее понятную для старшего поколения и снова начал мучительный поиск формулировки. Конечно, спасает фраза, вынесенная в эпиграф, но сейчас у меня большие надежды на интенсив Product Degree. Это почти некоммерческий проект, в модном формате обмена опытом между первыми среди равных. Натурально — 12 лекций об управлении мобильными продуктами читают спикеры в диапазоне от визионера-ньюбиза до инвестора. Каждое занятие длится 3 часа, и еще не хватает. Product Degree ставит перед собой, извините за штамп, амбициозную цель — дать нам возможность попробовать себя в новой роли и задуматься о том, чтобы в ней остаться. В ближайших шести статьях я расскажу все, что узнаю о продакт-менеджерах, – такие знания должны быть доступными. Текста будет много, картинок мало.
Лекция первая. Зачем нужны продакт-менеджеры?
Лекцию вел Михаил Калашников, продакт-менеджер Sports.ru и создатель блога Mediaskunk. Если вам лень читать текст ниже и хочется разобраться во всем самостоятельно – вот презентация Михаила.
Запускать продукт нужно, пока за него еще немного стыдно
Итак, вернемся к сектантам, пытающимся на языке маркетингового булшита объяснить родным, что продакт-менеджер – это не управляющий ларька и не наркодилер. Я, со своим опытом проджект-менеджера, вынужден сказать: продактам еще труднее. Проект в силу своей природы рано или поздно закончится, а продукт будет жить “вечно”.
Важно понимать, что продукт как таковой содержит в себе предложение, притом публичное. То, чего нет, не продукт, а идея; то, что не несет ценности, не продукт, а эксперимент; то, что нельзя произвести не продукт, а концепт. Видите, мы еще и не начали толком, а уже куча придирок.
Есть классическая схема «четырех пэ»:
- Product,
- Price,
- Place,
- Promotion.
Продакт-менеджер отвечает за принятие решения по всем четырем пунктам, поддерживая правильный баланс между желанием бизнеса сэкономить и стремлением разработчика сделать всё и сразу. Можно сказать, продакт отвечает за этакий бизнес в миниатюре.
… и где они обитают?
Про Толстого (а иногда Достоевского) ходит байка, что на первой же странице рукописей, принесенных ему молодыми творцами он писал красным (!) карандашом (!!) единственное слово: «Зачем?».
Профессия продакт-менеджеров начала формироваться примерно после эпохи доткомов, когда в разных прогрессивных отраслях самые неугомонные специалисты осознали, что работа, которую они делают помимо своих основных обязанностей, сама по себе содержательна. Поэтому общение с практиками для начинающего продакта может оказаться гораздо полезнее отдельного академического курса. Зафиксируем: менеджеры продуктов приходят из разных областей, но в какой-то момент они перестают быть дизайнерами, разработчиками или маркетологами. В своем новом качестве они должны постоянно думать о балансе (но не компромиссе!).
За себя и за того парня
Если продакт идет на компромисс, это будет сделкой с дьяволом неполноценности: в итоге проиграют все. Практика показывает, что эффективнее всего смотреть на мир глазами потребителя: требовать от команды максимума за минимум бюджета. Да, многие вас за это возненавидят. И пользователи тоже. Увы.
Но зато перед вами открывается новый мир, и вы в нем хозяин. Только ваш продукт может эффективно решить выявленную проблему наилучшим образом и ко всеобщему счастью. А иначе зачем он вам (см.первый абзац)?
Подход «за себя и за того парня» работает и в обратную сторону: компания осознает потребность в продакт-менеджере, когда ощущает недостаток специальной экспертизы, открывает новый бизнес или просто активно растет. Если вы уже некоторое время размышляете, как объяснить руководству, почему вам должны платить больше, порефлексируйте над этим списком:
- вы хотите и умеете делать что-то в команде;
- вам интересно повлиять на разработку существующего продукта;
- вы планируете начать свой бизнес, но хотите размяться на чужих кошках.
Step by step (пока от монитора не ослеп ;)
Если вы уже были менеджером (то есть руководителем, а не просто жертвой косноязычности отдела кадров), вы, возможно, сталкивались с необходимостью правильной постановки задач. Это важно для продакт-менеджера – ему приходится все придумывать самому. Примерный путь работы с продуктом можно описать так:
- Гипотезы. Что будет, если сделать А и В? А если не сделать? Правильно сформулированная гипотеза задает верное направление всему процессу.
- Постановка задач. Мало самому понять, что нужно, необходимо еще смочь объяснить это команде, притом каждому на его языке и по нескольку раз. Вероятно, вы сто раз объясните, уже и сами поймете, а дизайнер (разраб, тестировщик, инвестор) опять нет.
- Выставление приоритетов. Это как в хорошей игре: нужно правильно выбирать, что прокачивать, — только без сохранений.
- Коммуникация. Я уже говорил про важность общения — и еще скажу.
- Исследование. Гипотеза должна строиться на накопленных данных. Запомните, вы не ваша целевая аудитория, какими бы обманчиво близкими вам ни казались ее параметры. Редкий продукт делается «для своих», да и своих мы знаем хуже, чем кажется.
- Тестирование и адаптация. Мало что бывает сделано так, как изначально задумано.
- Обратная связь. Помните, я обещал вернуться к теме общения?
Суммирую сказанное выше: продакт-менеджер – это мини-гендиректор, только с минимальным бюджетом, выделенным под конкретную цель. Оборотная сторона всех этих продуктовых проблем с самоопределением — возможность сделать что-то по-настоящему крутое и нужное.
Каждый продукт проходит в своем становлении следующие этапы: идеи > выбор (одна идея) > бизнес-план > прототип > тестирование > производство. Стартовая идея должна быть спектром идей. Не надо пытаться сразу переходить к финальному решению, задумайтесь о смысле, проблеме, которую продукт должен решать. Вот вам второй полезный список:
- для кого ваш продукт?
- какую боль он снимает? (вульгарный, но меткий американизм).
- когда им пользоваться?
- как люди узнают об этом продукте?
- чем он отличается от аналогов? Серьезно, не пропускайте этот пункт.
- кто платит?
Отвечая хотя бы мысленно на эти вопросы, вы можете двигаться по одному из двух путей:
— minimal viable product (минимальный возможный продукт),
— minimal desirable product (минимальный желаемый продукт).
Лекция вторая. Дизайн мобильных интерфейсов.
Лекцию читала Мария Михальчук, продакт-дизайнер в Kixx.
Сначала было слово
И пусть это слово будет кратким и ясным, и опишет базовые пользовательские сценарии так, чтобы все 12 колен (и Разрабманы, и Тестировичи) вас поняли однозначно. Это, конечно, неловкая шовинистская шутка, но серьезно — пользовательские истории «рулят». Придумайте конкретного пользователя Гошу, и пусть вся его жизнь сводится к взаимодействию с вашим продуктом.
Все остальное время Гоша страдает: интеллектуально, сенсорно, моторно и как угодно еще. Потребитель находит шаткий баланс в уровне дискомфорта, и ваш продукт не должен его нарушить. Кажется, всё в этой жизни против пользователя. Интеллектуальная нагрузка дома и на работе формирует слишком большое количество логических связей, и чем их меньше, тем проще жить. Повседневность постоянно давит на сенсоры: на слух, зрение, обоняние и прочие органы восприятия – давит точечно и комплексно, лезет в голову рекламой и забивает канал инстаграмами и прочими вейпами. И все это в метро, в толчее, среди детей и домашних животных, в компании нетрезвых друзей в клубе.
Футбол, политика и дизайн
Я уверен, есть по крайней мере три сферы, в которых вы отлично разбираетесь, поэтому в части дизайна остановлюсь на 2 ключевых требованиях:
- ясность
- простота взаимодействия.
Ясность предполагает продуманную структуру, минимум ввода с клавиатуры, точные тексты, вдумчивую навигацию и правильную контрастность, читаемые шрифты. Простота взаимодействия касается, в первую очередь, элементов ввода (они должны быть адекватны вводимым данным), кнопок и областей нажатия и отклика интерфейса. Вы думаете, что я говорю банальности? Сходите посмотреть на приложения из третьего десятка любого стора.
Еще один важный момент – существование пользовательских сценариев во времени. Задумайтесь, кто ваш примерный Гоша:
- спринтер (есть конкретная цель, мало времени – ему нужны монофункциональные приложения)
- стайер (есть абстрактная цель, а времени много – ему подойдут новости, соцмедиа и тому подобное).
Знание природы поведения пользователя поможет сформировать структуру элементов: определить, как сочетаются графическая доминанта и второстепенные информационные слои, как происходит взаимодействие фона и фигуры. Кроме того, в разработке структуры важно правило «один экран – одно действие». «Стайерам» стоит давать больше «неразведанного пространства», развернутый контент и несколько информационных слоев.
А судьи кто?
Имена их известны: App Store и Google Play. Дизайн-стандарты платформ не только создают множество проблем на всех этапах дизайна и разработки. Они еще и формируют привычки взаимодействия пользователей с интерфейсом, подготавливая их и снимая сенсорную нагрузку.
Android использует material design с небольшой глубиной пространства, простыми геометрическими формами и активным использованием floating action button. Вопреки распространенному мнению, приложения на нем не обязательно должны быть выполнены в кислотной палитре, можно сделать и в спокойной гамме. iOS много внимания уделяет глубине пространства, контенту, простоте, анимации. В последних версиях активно используют размытие. Снова даем бой стереотипам – не обязательно делать iOS-приложение в стиле светлого минимализма. Скрытый бонус – приложения, следующие платформенным стандартам дизайна, охотнее продвигаются самими сторами.
Re: Re: Re: Re: Re: The last & final design v121.3
Дизайнер – один из первых, на чьем языке продакт-менеджер должен заговорить. И заговорить надо быстро, так как необходимо донести дизайнеру идею еще на этапе ее формулировки, чтобы получить быстрые первые наброски. Дизайнер начнет со сложных нагруженных экранов и отрисовки основного пользовательского сценария. Этот процесс нельзя пускать на самотек, нужно постоянно пробовать, смотреть и дорабатывать.
На этом же этапе формируется идентичность бренда. Когда вы определились с основными экранами, можно фиксировать общий стиль и переходить ко вторичным и пустым экранам, лендингам и т.п. При этом важно постоянно помнить, что разработка дизайна идет в тандеме с порядком взаимодействия пользователя с приложением.
Подумайте, в частности, вот над чем:
- Сложные экраны и навигация,
- Основной пользовательский сценарий,
- Общий стиль,
- Второстепенные экраны,
- Пустые экраны (до введенного контента),
- Вводный экран для нового пользователя (т.н. onboarding),
- Посадочная страница (ака landing page),
- Оформление магазина.
Не говорите этого своим дизайнерам, но: примерно до этапа второстепенных экранов всё можно выкидывать и рисовать заново несколько раз, до того как вы придете к финальному общему стилю. И вот еще что: дизайнер занимается проектированием интерфейсов, иллюстратор занимается отрисовкой. И еще: первые черновики дизайна нужно пытаться получить как можно быстрее. Из первых макетов нужно делать первые прототипы, чтобы выловить ошибки в проектировании, но не стоит сильно их детализировать и вообще в это чрезмерно вкладываться.
Что еще важно учесть, или Третий полезный список
Постоянно помните про образцового Гошу. После проработки основных и второстепенных экранов можно заняться пустыми экранами, вводными экранами, эмоциональным вовлечением пользователя, реферами социальных медиа, call-to-action-элементами.
- Пустые экраны (Empty states). Экраны без данных тоже важны: они должны сообщить, что данных нет, дать возможность это исправить, предложить другие пути.
- Микровзаимодействие и отклики интерфейса. Отклик описывает взаимодействие пользователя с приложением: подумайте о кликах, подтверждениях нажатия, подтверждении инициации действия.
- Анимация должна быть ненавязчивой, скромной, стильной. Важно помнить про стилистику продукта и бренда.
- Обязательно нужно проработать экраны ошибок. Показывать их необходимо сразу, сообщение должно быть простым и рассказывать о следующих шагах. Важно, чтобы пользователь продолжал чувствовать себя комфортно.
- Упрощение взаимодействия. Используйте автозаполнение и подсказки. Раскладка должна соответствовать типам данным. Валидация должна происходить в реальном времени. Элементы управления не должны перекрывать содержимое приложения.
Заключение
Помните, продакт-менеджер представляет интересы пользователя. Ему необходимо держать в голове все сказанное выше, но при этом все равно готовиться к худшему. На этой радостной ноте, пожалуй, я возьму паузу и пообещаю вознаграждение: в следующий раз я попробую пересказать «длинное и бессвязное выступление менеджера по продажам компании Aviasales» (так оно и было нам анонсировано) – потому что «все, что угодно, можно упростить в два раза».
Спасибо образовательному проекту Product Degree и лично Марку Тену, а также добрякам из Appodeal, пустившим меня в свой блог. Еще увидимся.
Комментарии (21)
M-A-XG
26.11.2016 19:57+1Лекция первая. Зачем нужны продакт-менеджеры?
А хз зачем.
Нормального ТЗ не предоставляют, тем более актуализированного.
Проводить хоть какое-то тестирование продукта отказываются.
Бизнес-логики продукта не знают.
Организовать процесс не могут.
Зачем они? У меня есть предположение, что для того, чтобы получать зарплату.
Ну типа как:
— Зачем вам голова?
— Я ем в нее.
Хотя, может это мой печальный опыт и в аутсорсе на запад что-то иначе. :)
проджект-менеджера, продактам
Развелось же их баранов недорезанных.
требовать от команды максимума за минимум бюджета
Требовать максимум чего? :)
компания осознает потребность в продакт-менеджере, когда...
Вообще-то какой-то толковый менеджер должен быть. Но компании осознают потребность в них, когда много лишних денег. :)
Примерный путь работы с продуктом можно описать так
Если бы так делали, то это было бы просто замечательно! :) Такие управленцы, конечно же, нужны.industrial_designer
27.11.2016 11:23Много раз видел эту картинку и подобные ситуации на улице и думал: вот так всегда – куча менеджеров, а пашет один Вася. И только через время до меня дошло, что если в яме будет больше одного человека, то они начнут мешать друг другу и копать станет невозможно. Можно, конечно, яму сделать побольше, но зачем, если она нужна маленькая. Может быть Вася выкопает проход в коллектор, в который зайдет вся эта бригада, и каждый займется своим делом. Так и в ваших рассуждениях. Вы оцениваете пост с точки зрения, когда нужно решать небольшие быстрые задачи, а описанный подход применяется в больших проектах, для которых нужна большая команда, где каждый не может постоянно держать в голове всю стратегию развития продукта.
M-A-XG
27.11.2016 14:42Я оцениваю с точки зрения, когда у меня на работе куча дармоедов, которые нихрена не делают.
Я не против адекватных управленцев, читайте последнее предложение. :)
И относительно Васи. Над Васей можно поставить одного ответственного управленца, а не кучу ни за что не отвечающего мусора. Но как хотите.vjjvr
27.11.2016 20:26Госконтора? Мегакорпорация?
Крайне сомнительно чтобы в средних размерах фирме были такие толпы.
Это экономически не выгодно.M-A-XG
28.11.2016 10:13Мегакорпорация.
Ну вот кто-то начитался, что нужны менеджеры, ну и давай внедрять менеджеров.vjjvr
28.11.2016 10:35Для мегакорпорации — абсолютно нормально.
Я понимаю, что вам кажется, что они ничего не делают.
Но они хоть какие-то нервы в организме вашей конторы.
Без них и смысла в существовании вашей конторы и не было бы.
Ведь не все конечные исполнители работают в направлении, нужном мегакорпорации, а не только в направлении нужном лично исполнителям.M-A-XG
28.11.2016 14:45Но они хоть какие-то нервы в организме вашей конторы.
Я бы сказал, что они едят нервы другим…
Кто-то услышал диалог двух таких менеджеров:
— А ты сам понял, что написал в ТЗ?
— Нет. Но это ж моя работа.
Или Вы относитесь к управленцам? Тогда повторю: я обома руками за нормальных управленцев.
Последнее предложение не понял. :)vjjvr
28.11.2016 16:09Про последнее предложение — В мегакорпорации работники сами не работают.
Вернее они способны работать и сами — но в своих интересах.
Менеджмент направляет действия в нужно фирме русле.
KirillKobelev
28.11.2016 10:30Вижу, наболело :).
Согласен с тем, что эта картинка — про необходимость правильного соотношения специалистов и управленцев.
А что касается первого комментария в ветке, надеюсь, усилиями неравнодушных хороших продактов станет больше. Составные вашего печального опыта как раз хорошо описывают, зачем они (продакты) нужны. Выходит, это в большей степени вопрос качества, а не необходимости.
Lucidus
27.11.2016 11:23Тоже есть печальный опыт. Такие ребята предназначены для комфортного общения некомпетентного в вопросах проектов владельца компании (ВК) с группой разработчиков (ГР). В проекте слабо разбираются.
Концепт продукта продакт-манагером (ПМ)? Проработка, оценка и прочее? Пфф… Все делается силами ГР, оформляется в отчет. Отчет с торжеством и ликованием на лице ПМ-а преподносится ВК.
Если подытожить, то функции такого манагера: транслятор ВК->ГР и ГР->ВК, коллектор отчетности, пальцем погрозить от имени ВК. Может и ничего страшного. Главное, чтоб не включался режим «игра в разработчика» и «да я R2D2 прошивал, сосунки».KirillKobelev
28.11.2016 10:37Печаль, но я хорошо представляю ситуацию, которую вы описываете. Думаю, во многом это результат подхода из коммента выше: «Кто-то начитался… и ну внедрять».
Очень надеюсь, что продакты будут расти и займут свою правильную нишу, встав у руля продуктов, которыми они заведуют.Lucidus
28.11.2016 15:33Я в той компании уже давно не работаю. Но с экс-коллегами общаюсь, отличные ребята и много общего. Ситуация за годы не особо изменилась и даже, можно сказать, усугубилась (со слов очевидцев). Недавно группу уволили целым составом, а ПМ отделался испугом (штраф, вроде бы). Подробности мне не известны, вроде как группа выполняла все поставленные задачи из бэклога, все были довольны и тут такое. Что тут можно сказать? Выросли ПМы, даже заняли правильную… =)
NeverIn
В чем смысл запускать продукт за который стыдно? Тестировать на пользователях?
CrazyViper
Не совсем стыдно, а немного стыдно. Прочтите эту фразу как «не надо впадать в паралич перфекциониста».
А смысл в том, чтобы быстрее получить обратную связь и переделать, пока точка не возврата не пройдена.
NeverIn
Если недоделки небольшие и вы про них знаете(стыдно) лучше немного задержать выпуск продукта и устранить, чем потом заниматься этим же, но параллельно с поддержкой. Ну и на карму бренда это положительно не скажется. Зайдет пользователь — тут косяк, там косяк и больше не вернется.
vjjvr
Обратная проблема — когда пилят до бесконечности — тоже существует.
И она встречается частенько.
newross
Лучше выпустить и проверить, как этим будут пользовататься. Если не будут — выпилить, если будут — доработать.
Мелкие доработки зачастую занимают больше времени, чем основная разработка. А за это время можно успеть запустить продукт, продать его и собрать фидбэк.
Карма бренда, мнимые косяки — это все вторично. Если продакт попал в цель идеей продукта и решает проблемы пользователей, продукту все простят.
KirillKobelev
Это, конечно, вопрос баланса. Выпускать совсем сырой продукт значит собирать армию недовольных пользователей, отлаживать до полного блеска — терять драгоценное время.
Думаю, тут стоит отталкиваться от критического сценария, который должен работать как надо, и дальше допиливать, прислушиваясь к отзывам.
И потом: продукт ведь будет меняться постоянно, вряд ли вообще возможно получить «полностью готовый» продукт; и задача менеджера — выбрать оптимальное время для выхода.
irbis_al
Там написано немножко стыдно… и это меняет суть…
Ни один новый ресторан не открывается идеально, ни один новый магазин или отель...(я просто занимаюсь их автоматизацией… и видел изнутри неоднократно их старты и административные косяки, что приходилось решать)… так же как и новый программный продукт не идеален… проходит время и в любом старте происходит стабилизация.
KirillKobelev
Плюсодин; пожалуй, дополню свою мысль: продакт должен не только увидеть эту вилку между высоким качеством и потерей времени, но и суметь принять своевременное решение о релизе. И главная сложность этого решения в том, что не существует однозначной успешной инструкции по его принятию :(.
Вот Миша Калашников склоняется к «чуть раньше».