{"id":13505,"url":"\/distributions\/13505\/click?bit=1&hash=ca3734639136826288c9056e5c8fa03a05e87c4060ae84df200f2c90f5262470","title":"\u0412\u044b \u0440\u0430\u0437\u0440\u0430\u0431\u043e\u0442\u0447\u0438\u043a? \u0410 \u043f\u043e\u043d\u0438\u043c\u0430\u0435\u0442\u0435 \u0447\u0442\u043e-\u0442\u043e \u0432 \u0438\u0441\u043a\u0443\u0441\u0441\u0442\u0432\u0435 \u043a\u043e\u0434\u0430?","buttonText":"\u041f\u0440\u043e\u0432\u0435\u0440\u0438\u0442\u044c","imageUuid":"f5f0e11f-fefd-52f5-8712-82164a59b7ce","isPaidAndBannersEnabled":false}

Продакт-менеджмент глазами дилетанта

Предисловие:
Однажды на мероприятии для IT и технологических команд у меня произошёл диалог, который я не особо мог ни поддерживать, ни оппонировать, с одним довольно известным в этих кругах человеком. Речь шла о ролях Проджекта и Продакта, и почему мне, например, больше интересно первое, чем второе. Как выяснилось гораздо позже (к написанию статьи), говорили мы об одном и том же, но, не владея на тот момент терминологией, я не мог вразумительно объяснить свою позицию, и когда говорил, что мне интересен Проджект-менеджмент, подразумевал, в том числе, решение комплекса задач, входящих в зону ответственности Продакта, т.е. их-то мне решать очень интересно.

Вступление:
Не так давно произошла ситуация, сподвигнувшая меня вдумчиво и тщательно проанализировать процесс создания и ведения какого-нибудь IT продукта.
В качестве предмета для размышлений выбрал один из наиболее очевидных референтов - известную соцсеть, выросшую на наших глазах.
Я склонен к редукционизму, и решил разобраться, из каких нужд и потребностей возникла должность Продакт-менеджера, ведь в самом начале, когда, например, соцсеть создавалась в съёмной квартире, таких понятий ещё не было … но потребность уже должна была начать возникать, и её как-то должны были удовлетворять, а, значит, Продакт-менеджмент - это логический ответ и результат естественного решения очевидно проявившихся проблем.

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

Но сначала мой главный вывод о необходимых для Продакта скиллах, к которому я в процессе размышлений пришёл на данный момент:

Продакт-менеджмент требует всего одной физически сложной способности – это удержание в голове и максимально быстрая обработка большого объёма данных.
А ещё:
- Немного здравого смысла в виде Логики + (каузальная и предиктивная аналитики + (наблюдательность));
- Элементарных знаний из экономики и арифметики на уровне доходы/расходы, сложить/вычесть/поделить + Понимания основ рыночных отношений + Социальных навыков + Воображения;
- Excel и прочие подобные инструменты, без которых сегодня почти никто из дома с утра не выходит + Таск-менеджеры + В идеале ещё хоть на каком-то уровне разбираться в программировании (ну хоть чуть-чуть).

Необходимые для ПМ навыки и скилы, как я себе это представляю. Я художник, я так вижу.

Редукционизм:

Итак, что мы имеем:

Социальная сеть – огромный проект, с большим набором разнообразных функций и инструментов. Но как же это всё вести, контролировать и просчитывать одному человеку?
Очевидно, что никак.
За столом собирается группа лиц, и принимается решение о внедрении той или иной функции/сервиса, далее будем называть это – продукт.
[на каком основании они в данном разговоре обсуждают те или иные функции/сервисы – предмет их отдельной подготовительной работы, но сейчас пропустим. И после дальнейшего разбора, поднявшись снизу вверх по всей цепочке, это будет несложно понять]
Разработкой продукта должен кто-то руководить/отвечать за неё.
Очевидно же? Здравый смысл подсказывает, что очевиднее просто не бывает. Так обычно все процессы и организовываются.
Вот должность руководителя этого самого продукта и именуется Продакт-менеджер.

Но продукт неправильно просто сделать - это же тут не развлечение, и у него есть вполне конкретные задачи – привлекать/удерживать пользователей.
А зачем? – Чтобы увеличить количество пользователей соцсети и время их пребывания на её страницах.
А зачем? – Чтобы соцсеть могла продавать рекламные объявления, оперируя величиной своего охвата. Поэтому продукт нужно [постараться] сделать правильно и подойти к этому процессу со всей ответственностью.
Но как развивать продукт, чтобы было «правильно»? – Отслеживать, выполняет ли он свою функцию и приносит ли он пользу и стараться делать так, чтобы да.
А как? – Для этого стоило бы придумать какой-нибудь количественный показатель, и он есть. Называется Метрика. Метрикой может называться любая важная единица, поддающаяся количественной оценке, например, у соцсети – это пользователи, у различных её сервисов-продуктов – количества просмотров, прослушиваний и т.д.
Отлично! И как мы можем повлиять на эту метрику? – Максимально удовлетворять пользователя.
Но как нам узнать, что его удовлетворит (почти равно вопросу «Чего он хочет»)? – Самый простой способ – это его спросить.

Существует целое направление под названием customer development, оно же custdev, оно же касдев. Суть которого сводится к «выуживанию» из пользователей интересующей вас информации, прибегая к различным уловкам и ухищрениям. Есть множество курсов и лекций на эту тему, но на самом деле достаточно иметь развитые социальные навыки и/или уметь пользоваться здравым смыслом (в виде тех самых каузальной и предиктивной аналитик) для оценки реакций людей и нюансов при их ведении диалога/ответов на поставленные вопросы.
Например,
- люди часто сами не знают, чего хотят;
- не могут объяснить, почему делают то-то и то-то и не делают то-то и то-то, и т.д.;
Поэтому - "Почему?". Один из самых главных вопросов!
"Почему?" "Почему?" "Почему?" - нужно постоянно спрашивать своего (будущего/существующего) пользователя "Почему?", чтобы пробудить у него желание и активировать механизм размышления и анализа и получить уже обдуманный ответ на этот вопрос.
Эти навыки можно развить в обычной жизни, не прибегая к узкой специализации ПМ.
Примечание: В исключительных случаях можно проскочить без подробных опросов аудитории, сделать продукт по своему усмотрению, и таким его продать. Но данная статья не об этом.

С касдевом разобрались, что дальше? – Дальше нам набросали много-много хотелок, и всем нужно именно то, что они указали, и вот прям сейчас.
Давайте всех удовлетворим? – Нет, всех удовлетворить мы не можем.
У нас ограниченные бюджет на разработку и трудовременные ресурсы, поэтому мы не имеем возможности сразу за всё хвататься.
Нам нужно как-то определить важность, а вместе с ней – дальнейшую очередность поступивших запросов для их ранжирования в бэклоге.
Как это можно сделать? – Немного фантазии и воображения, и решение найдётся!
Самый очевидный и простой вариант – это:
1. Составить таблицу-список заявок
2. Оценить потенциально принесённую каждым пользу (посчитанную, например, на основе данных по custdev)
и
3. Поделить её на затраты, которые потребует реализация того или иного пожелания (оплата программистов, маркетинг (о нём позже) и т.д.)
4. Получившийся стек проранжировать по степени убывания.
Есть давно разработанные методы: RICE, WSJF, GIFT и пр., и, в принципе, через некоторое время, буквально через несколько итераций, можно самостоятельно до них дойти. Но это потребует лишнего времени, и хорошо, что методы уже давно разработаны, их можно узнать и ими пользоваться (пока вы не придумали свои - творчество в подобных вопросах часто приветствуется и поощряется). Деятельность по определению очерёдности задач для выполнения называется Приоритизация, на начальном этапе можно нагуглить и использовать все ныне известные методы, в дальнейшем наверняка появятся свои уникальные или синтетические методы.
Тут есть производственный нюанс: Когда вы решили внедрить ту или иную функцию в существующий продукт – есть вероятность, что столкнётесь с большими трудностями, т.к. её нужно будет встроить в уже существующее решение. Вместо абстракций предлагаю рассмотреть очень хороший пример, который подробно и наглядно описали ребята из 2ГИС в своей недавно вышедшей статье.

Теперь у нас на вооружении: Метрики, Касдев, Приоритизация – можем ли мы взлетать? – Почти, но нет.
Для того чтобы повысить метрики, нужно:
- провести касдев
- разработать новые функции и
- сообщить о них пользователям.
С первыми двумя пунктами разобрались, что значит третий:
Мы можем сообщить пользователям о новых изменениях в рамках того или иного продукта внутри своей социальной сети, но при таком подходе эту информацию могут увидеть только самые активные из существующих пользователей (а нам вообще новые нужны), поэтому мы вынуждены транслировать такую информацию во вне, используя различные рекламные каналы, за которые нужно платить.
И возникает риск, что затраты, которые мы понесём на рекламные объявления, информирующие потенциальных пользователей, превысят ту пользу, которую мы ожидаем получить от их запланированного увеличения.
Что делать? – Тут как раз понадобятся знания из области экономики, арифметики и основ рыночных отношений:
- составляем формулу, учитывающую все возможные затраты, [которые понесём на разработку нужной функции и её продвижение до того момента, как она наберёт необходимое количество пользователей], и
- получившийся результат сопоставляем с той ожидаемой пользой, которую принесёт их [пользователей] количественный прирост.
Область, к которой относятся эти задачи, называется Юнит-экономика.
Опять же - логика, здравый смысл. Здесь - на основе экономики и математики.
И, исходя из вышесказанного, можно сделать вывод, что Приоритизация и Юнит-экономика должны идти бок о бок.
Примечание: Рано или поздно уровень задач выйдет далеко за возможности палочного счёта. Поэтому, нужно много практиковаться и специальную литературу всё-таки читать. А ещё нужно читать/смотреть материалы некоторых известных многим специалистов из этой области.

Летим? – Почти.
Ведь для более корректных расчётов в юнит-экономике нужно бы разобраться с нюансами, особенностями и принципами работы различных каналов продвижения (блогеры, таргетинг, контекст, seo) и инструментов их аналитики - в зависимости от выбранных инструментов итоговые показатели могут разниться (например, Google Analytics и Google Ads по-разному учитывают/(-ли) конверсии, есть нюансы). Для каких целей, какие каналы лучше работают, сколько стоят, сколько отдают (конверсия) и в каких инструментах (фб,инст, вк, ютуб и т.д.) какие существуют нюансы и особенности.
Разберёмся в процессе полёта? – На начальном уровне можно попробовать и так.

Летим? – Взлетаем.
Только всё вышеописанное нужно как-то фиксировать и с командой нужно как-то коммуницировать, иными словами – вести учёт и контроль (времени, задач и количества, качества, сроков и пр.)
Для этого существует множество приложений и различных сервисов, каждый из которых предназначен для решения комплекса этих задач и предоставляет различный функционал - Таск-менеджеры (или куда более нагруженные варианты).
Лично я люблю использовать либо кастомные решения, разработанные исходя из собственных предпочтений и потребностей на текущий момент, либо Блокнот+ручка и Excel.
Кто-то скажет, что с Экселем и блокнотом многопользовательский сервис на сотни тысяч подключений не запустишь, а разработка кастомизированного решения для этой потребности выльется в такие средства, что на сам проект не только не останется, но и кастом не доделается. Это тоже правда. (Но есть исключения).

Летим.
В процессе полёта помним, что мы летим не одни: кругом множество конкурентов, которые тоже без дела не сидят, проводят все те же исследования и улучшения, что и мы, и стараются первыми долететь до нового слоя, богатого на свободных пользователей. Так что работаем активнее и продуктивнее! И можно почитать книги по теории игр, для начала без научных выкладок, а описывающих эту дисциплину в общих чертах.

И тренды. Тренды тоже необходимо отслеживать. Иначе может оказаться, что относительно других мы уже сбились с маршрута и летим в совершенно пустом, никому не нужном пространстве. Помимо прочего тренды позволяют «распрямить» кривую жизненного цикла продукта и определить, в каком направлении его развивать дальше, чтобы эволюционное развитие в актуальном направлении предотвращало закономерный спад любого неразвивающегося продукта.
Лично я предпочитаю анализировать свою «большую» ленту (сборка из нескольких каналов связи с внешним миром) и читать различные научные и бизнес исследовательские отчёты о ведущихся разработках в области технологий.

Послесловие:

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

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

Если вам нужен помощник, и вы готовы сотрудничать – я открыт для диалогов.
Если можете порекомендовать кого-либо – буду благодарен за connect.
Связаться со мной можно здесь или в TG: @Chiginev

P.s.
Это - вторая версия одной и той же статьи. Первая была написана более фривольным и экзальтированным языком, однако при этом была и более сервильна. Но после публикации я решил, что на деловом портале стоит придерживаться более делового стиля повествования. Поэтому, если кому-то будет интересно - дополнительно повторно выложу первый вариант. Прям готовый кейс для А/В получился! Ниже небольшой фрагмент первой версии:

Я и IT в начале пути
0
Комментарии
Читать все 0 комментариев
null