Это небольшое руководство для руководителей проектов, продукт менеджеров, в котором мы раскрываем основные вопросы становления своего программного проекта.
В первую очередь для людей, планирующих создавать свой продукт и для тех, кто уже столкнулся с подводными камнями реализации на практике. Изучив курс продукт менеджера, вы сможете более четко сформулировать, как и куда двигать свой продукт.
Также курс будет полезен менеджерам веб-проектов, которые вынуждены работать со слабым продукт-менеджером со стороны заказчика. В этом случае, ваши дополнительные скиллы помогут нивелировать слабости заказчика и сделать вас более ценным подрядчиком для него.
Моя задача - создать подготовленного заказчика, который понимает, что он хочет и имеет четкое видение по своему продукту.
Проекты в подавляющем большинстве проваливаются не из-за плохой реализации. Зачастую они изначально обречены на неудачу в силу того, что нет четкого понимания по становлению продукта.
В первую очередь, это маркетинг. Для кого мы создаем продукт, зачем он им нужен? Какую роль закрывает и т.д.
Дальше - это детализация своей идеи в виде структуры продукта.
Курс был опубликован на сайте https://vc.ru/ в декабре 2019.
Материалы к курсу Product Owner по ссылке https://falconspace.ru/product-owner-docs
Вы можете скачать себе и работать в Excel с данными шаблонами, либо создать копию и использовать Google Spreadsheet (Файл / Создать копию...).
Шаблон включает в себя следующие элементы:
Задание
Советы
Принципы можно нарушать. Просто помните про риски, которые вы берете на себя в этом случае.
Основной смысл в том, чтобы делать этот цикл с каждым разом все быстрее и быстрее.
Простота
Чем больше людей, тем хуже будет продукт.
Задание
Советы
P.S. Работа с курсом предполагает условно 5% чтения, 10% поиска дополнительной информации и 85% адаптации тезисов под ваш проект. Если же прочитаете сразу весь материал, проигнорировав задания, — это просто будет очередная “проглоченная” длинная статья без действий.
Концепция — это система взглядов на будущий продукт, описывающая видение руководителя проекта (либо группы заинтересованных лиц).
Помните, что все описанное в концепции является гипотезами, а не фактами. И эти гипотезы требуют подтверждения поведением реальных потребителей.
Концепция — это точка входа в проект
Концепция помогает структурировать начальное описание проекта. Концепция проекта описывает ключевые моменты вашего проекта и позволяет быстро вникнуть в суть проекта.
Создавайте концепцию итеративно, т.е. опишите в начале поверхностно свою идею.
По мере поступления новой информации детализируйте концепцию. Задавайте новые вопросы и фиксируйте ответы в концепции проекта.
Концепцию должен делать сам руководитель проекта (или product owner). Не нужно делегировать эту работу техническим специалистам и маркетологам. Концепция — это не бриф на разработку сайта и не план продвижения сайта. Концепция — это то, как видит product owner свой продукт.
Кто есть целевая аудитория проекта и какие проблемы целевой аудитории мы решаем? Можно ли разбить целевую аудиторию на основные типовые сегменты
Как сейчас потребитель решает свою проблему? Как в идеале он мог бы решать эту проблему?
В чем наше решение?
Что для потребителя важно (какие характеристики наиболее критичны) в плане его проблемы?
В чем наше предложение потребителю? (оффер — цена, условия поставки, оказание услуг, дополнительные условия сделки)
Как мы планируем достучаться до потребителя? (реклама, каналы)
Основные характеристики нашего решения (возможности портала, структура)
Описание объектов и субъектов будущей системы (структура будущего продукта)
Кто наши партнеры? Кто есть наши стратегические партнеры (те, у кого такая же ЦА, что и у нас)? Кто есть наши партнеры-поставщики (кто будет помогать нам делать и поставлять продукт заказчику)?
В чем наши гипотезы монетизации? На чем планируем зарабатывать и когда это наступит от момента запуска в эксплуатацию?
Главные риски проекта. В чем видите основные риски провала проекта? Как их минимизировать (критичность, вероятность)?
Скачать шаблон концепции проекта
Пишите кратко, без воды. Концепция — не про “продать продукт”. Это про то, чтобы как можно четче обозначить ключевые моменты проекта.
Все, что вы написали — это гипотезы и не более того. Они могут меняться по ходу выявления новой информации.
Советы
Задание.
Рассмотрим вопрос начальной верификации идеи вашего продукта.
Итак, вы, руководитель продукта, проработали концепцию своего продукта и определили его ключевые особенности. Не нужно сразу начинать искать исполнителя на проект и запускать проект в разработку для создания реального образца продукта. Почему? Очень вероятно, что ваш продукт никому кроме вас не нужен. Либо он кому-то нужен, но не настолько, чтобы за него платить. Возможно они и готовы платить, но не в том объеме, который нужен вам. Может этих людей не так много, как вам кажется. В априори считайте, что ваш продукт никому не нужен, и вам требуется доказать себе, что в нем есть реальная ценность для целевой аудитории.Будьте немного пессимистом в начале проекта и оптимистом на более поздних стадиях проекта (а он там точно пригодится).
Сейчас нужно проверить идею на реальных потребителях/заказчиках.
Ваш продукт должен быть актуальным и для первых, и для вторых.
Рекомендуем посмотреть нашу статью Главная проблема стартапа - делать проект вслепую.
Создайте презентацию для заказчиков в Google Slides на 3 листах:
Важные моменты:
Найдите 2‑3 представителей целевой аудитории и покажите им свою презентацию. Где искать:
Проведите встречу с ними, либо скайп-колл. Упор надо сделать на общение, а не на презентацию. Презентация — это скорее дополнение к разговору, а не наоборот.
Что нужно выявить:
Заведите файл Excel с партнерами, которых вы опросили: ФИО, контакт, краткое резюме, степень лояльности проекту.
В идеале у вас перед началом проекта уже должен быть пул из 10 лояльных заказчиков, которые спят и видят, когда уже наконец появится ваш продукт.
Задание
Советы
В каждом продукте можно выделить некий основной процесс, по которому работает 90% пользователей системы. Вам необходимо его найти, выделить и детально описать.
Сториборд — это визуальное (а в нашем случае табличное — для простоты и скорости составления) отображение ключевого процесса проекта.
Блоки, соединенные линиями. Каждый блок — это пользовательская история по некой активности пользователя в системе.
Например, для CRM аренды недвижимости это может быть так:
Степень детализации не имеет значения. Важно воспроизвести точный привычный порядок действий пользователя и получить обратную связь от пользователей.
Можно ничего не придумывать, а просто спросить пользователей как они работают, а еще лучше — понаблюдать (хотя это и сложнее, но зато это даст более точную картину).
Не пытайтесь эти работы повесить на программистов, команду разработки или дизайнеров. Это не их задача. Это задача продукт-менеджера (ну или продуктового дизайнера). В итоге надо сразу расставить зоны ответственности и действовать по установленным договоренностям.
Если система делается для внешнего потребителя, можно начать с самых дальних касаний (например, потребитель увидел ваше рекламное объявление где-то в Сети).
Описывать следует до того момента, как пользователь получил ощутимую пользу от использования сервиса: разместил объявление на площадке, получил некую информацию, настроил свой профиль в социальной сети (например, >90% заполненности профиля).
Если говорить о некой многопользовательской системе, то проект можно разделить на области:
Определите список кабинетов в системе и для каждого кабинета опишите список доступных страниц.
Сначала опишите состав меню каждого кабинета, а затем список внутренних страниц. Пример - Страница заказа. Ее не будет в меню. В меню будет страница Заказы, а уже с нее идет ссылка на Страницу заказа.
Ключевое по макетам — создаем их быстро, а не технологично. Затем получаем обратную связь, дорабатываем макеты и так делаем, пока не будет простой и понятный функционал для пользователя.
Как создавать макеты:
Не нужно сидеть долго над каждым макетом. На 1 версию макета 1 страницы - не более 10 мин.
Лучше быстро сделать, показать, понять, что это совсем не то, переделать заново, нежели потратить 2 недели на макеты, а затем за них держаться, т.к. мы в них вложили столько сил и души. Человеку свойственно защищать то, во что он сильно вложился, даже если это полная ерунда. Поэтому не нужно слишком “прикипать” к своим макетам. Макеты — это просто способ общения с потребителями и разработчиками, не более того.
Примечание:
Стремитесь к тому, чтобы функционал первой версии был минимальный. Чем меньше объем, тем быстрее, проще и дешевле ее будет внедрить: меньше рисовать, меньше писать ТЗ, меньше кодировать, меньше в итоге переделывать.
У вас есть лояльные заказчики/пользователи. Используйте это для верификации ваших макетов. В правильном ли мы направлении движемся? Понимают ли они эти макеты без пояснений? Есть ли у них интерес к системе (в ходе взаимодействия это будет видно)?
Сразу настройтесь на то, что вы сделаете структуру и макеты за 1 день. В этом нет ничего сложного, можно подсматривать удачные решения из чужих систем (но не надо слепо копировать). Самые ужасные корявые макеты (но по смыслу правильные) лучше тех, которые сделают “в ближайшее время”.
Созданные макеты следует показать пользователям и доработать их по их обратной связи.
Зачем это нужно:
Все это вы сможете выявить в процессе беседы с представителями целевой аудитории.
Что необходимо сделать:
В самом колле:
Кратко напомните суть сервиса и поблагодарите за помощь в создании сервиса
Покажите свои макеты, можно просто фото ваших набросков, и кратко опишите их
Задавайте различные вопросы формата “А как сделать то-то”. Это даст возможность выявить, насколько человеку понятен интерфейс программы
Дайте почувствовать пользователю себя экспертом и поощряйте его высказывать критическое мнение о системе и интерфейсе.
Задайте вопрос - решает ли система начальную поставленную задачу?
Спросите, какой макет он считает самым важным? Почему? Какие страницы ему кажется несущественными и ненужными? Чего не хватает? Как в идеале надо упростить процесс работы над системой?
Поблагодарите человека за помощь и скажите, что сообщите, когда появится пробный образец программы.
Занесите результаты и инсайты в документ Excel. Этот документ вы потом сможете использовать для поиска идей по улучшению вашего продукта.
Ваша задача - не продать решение, а получить максимум информации от данного пользователя. Если вы будете пытаться продать, то пользователь закроется.
Шаблон сториборда в табличном виде, структуры проекта и сбор обратной связи вы сможете найти среди материалов на нашем сайте
Советы
Задание
Закон Мёрфи — Всё, что может пойти не так, пойдет не так
Необходимо заранее охватить всевозможные риски и хотя бы принять их. Важно, чтобы свершившийся риск не был для вас полной неожиданностью.
Риск — это негативное событие, которое может наступить с некоей вероятностью и имеет некую критичность для вас.
Ваша задача: выявить риски, распределить по типам и проранжировать их на основании критичности и вероятности.
Для каждого риска проставьте критичность K и вероятность P (от 1 до 3. 3- мегакритично, 1 — малокритично).
Получите интегральный показатель по всем рискам (например, по формуле P+ 2* K). Отсортируйте список в порядке убывания и у вас будет план по обработке рисков (начиная с самых критично-вероятных).
Возьмем риск, который несет на себе каждый из нас — автомобильная авария.
Вероятность — средняя, ближе к высокая (особенно для тех, кто постоянно катается за рулем на дальние расстояния).
Критичность — очень высокая.
Как можем снизить вероятность — меньше кататься на авто, найти работу поближе и ходить пешком, либо работать из дома. Не ездить с лихачами. Взять за правило никогда не гнать под желтый.
Как можем снизить критичность — купить машину побольше, всегда пристегиваться, машина с подушкой безопасности.
Полностью риска избежать не получится, и нужно смириться с тем, что это может произойти с каждым (но при этом надо предпринять как минимум те меры, которые мы описали).
Выделим несколько рисков, с которыми вы можете столкнуться:
Усложнение функционала и ненужные функции. Стремление все усложнить и накрутить — очень частая история. Старайтесь сознательно с этим бороться.
Костыли. Программисты могут без вашего ведома использовать некие костыльные решение за неимением более подходящего решения. Проблема костылей в том, что они усложняют сопровождение и увеличивают риски возникновения ошибок в продукте
Смена product owner. При этом скорее всего изменится видение продукта, его стратегическое развитие. Если придет неподходящий человек, то это может погубить даже стабильный устойчивый успешный продукт.
Слишком сильное желание угодить потребителю - в погоне за мимолетными желаниями пользователей вы быстро потеряете фокус продукта и сделаете решение “все для всех”. Обычно такие решения очень сложны в использовании, неповоротливые и имеют очень сложный витиеватый интерфейс.
Также читайте нашу статью про риски веб-проекта
Чтобы реализовать продукт, его необходимо конкретно и однозначно описать. Чем точнее описание, тем меньше будет разница между ожиданиями и результатом.
Описывать продукт необходимо итеративно. Для начала определитесь с 1 версией продукта - минимальный функционал, который будет введен в эксплуатацию.
Описывать его можно в виде пользовательских историй. Каждая история - это детализация возможности некоторой роли в системе. Можно это делать в формате “Я как роль такая-то могу сделать то-то с такой-то целью”.
Ключевые моменты пользовательской истории:
Совместно с разработчиком можно детализировать описание и добавить технические ограничения и детали:
К первой версии программы надо идти поэтапно. В крайнем случае это может быть 1 этап. ТЗ (техническое задание) на этапе - это по сути набор пользовательских историй. К пользовательским историям можно прикладывать макеты, которые были сформированы ранее.
Где хранить пользовательские истории? В беклоге. В самом простом случае это таблица Excel со следующими полями:
На основании приоритета, значения для продукта и сложности вы можете определить, что необходимо реализовать в первую очередь.
Беклог - это постоянно обновляемый документ.
В него попадают все новые хотелки, возникающие по ходу проекта. Ни в коем случае не внедряйте сразу все, что приходит в голову.
Если в ходе этапа возникла идея - просто заносим в беклог и описываем ее в разрезе всех столбцов беклога. Очень часто возникает ситуация, что требование быстро становится неактуальным, либо трансформируется или уточняется. Поэтому нет необходимости транзитом через беклог сразу “гнать” требования в сторону разработчиков.
Двигаясь по этапам вы периодически обновляете беклог:
Когда подходит время делать следующий этап, вам не нужно судорожно придумывать, что делать дальше. Вы берете из беклога самые приоритетные истории и из них делаете ТЗ.
Пример карты рисков и шаблон беклога есть среди материалов к данному курсу
Советы
Задание
Дизайн продукта важен. Дизайн должен служить целям потребителя продукта, а не быть просто красивым.
Хороший дизайн в нашем понимании — это:
Неверное понимание дизайна:
Как понять, какой дизайн мне нужен? Все просто — отталкиваемся от вашей целевой аудитории. Каждая аудитория ценит что-то свое. Основные принципы остаются теми же, просто добавляются некоторые штрихи и детали, которые делают ваш интерфейс “своим” для потребителя.
Если у вас нет особого понимания по дизайну, то исходите из трех простых концептов:
О продвижении надо задуматься до начала создания продукта.
Вам необходимо более подробно раскрыть вопросы из концепции:
Примечание:
По следующей структуре:
Каждая предыдущая ступень должна ссылаться на материалы следующей ступени. Таким образом потребитель подбирается к ядру — вашего основному предложению.
Альтернативный способ — собрать всю семантику (Wordstat, KeyCollector), структурировать ее и писать статьи под каждый семантический кластер. Этот вариант даст больше покрытие по ключевым словам, но материал будет не так хорошо структурирован как в 1 варианте.
В любом случае у вас в итоге должна появиться карта контента, которую вы будете использовать как план создания полезных материалов для вашего потребителя.
Как привлечь трафик. Основные каналы:
Посмотрите нашу статью про оптимизацию контента сайта.
Руководитель продукта должен точно знать, что делать с потенциальным клиентом. По какой дорожке он должен пройти — от момента 1 касания до полного закрытия всех отношений с ним.
Что включает в себя эта дорожка:
В каждом случае будет свой уникальный процесс. Вы должны максимально точно прописать как это будет происходить в вашем случае.
В случае сервиса этот процесс будет немного отличаться:
Процесс адаптации к сервису называется онбординг. Вы должны максимально мягко адаптировать пользователя к вашему сервису. Также вам понадобятся инструменты для возврата пользователя на сервис (ретаргетинг, push-уведомления, email с аналитикой и т.д.)
Первое решение: Выбрать способ создания продукта — Разработка vs Готовый продукт vs Полуфабрикат.
Посмотрите нашу статью, сравнивающую облачные сервисы, разработку на заказ и готовые продукты.
Если есть подходящее готовое решение и нет видимых ограничений и рисков его использования в обозримом будущем (1-2 года), то надо брать его.
Если решения нет, то пробуем делать на какой-либо готовой платформе.
Если нам нужно что-то сильно специализированное с широкими возможностями изменения, то делают с нуля по полному стеку разработки.
Мы занимаемся именно полуфабрикатами. У нас есть платформа, на которой мы создаем готовые решения, которые в будущем можно адаптировать и развивать под себя.
Также посмотрите статью Как выбрать программиста или подрядчика, не понимая деталей процесса разработки?
Хорошая тактика - найти продукт, который вам нравится и узнать кто его технически реализовал. При этом необязательно это должен быть аналог вашего продукта. Например, команда, реализовавшая хорошо некий интернет-сервис для банка, скорее всего хорошо сделает и аналогичный сервис для совершенно другой среды.
Советы
Задания
Ввод в эксплуатацию — это не просто “Поехали!"
Что необходимо сделать на этапе ввода в эксплуатацию:
Используйте этот чек-лист, когда будете запускать свой проект в эксплуатацию.
Допустим, вы все сделали, можно запускать проект. Теперь вам необходимо проработать следующие вопросы:
Про аналитику, продвижение продукта (площадки) смотрите блок статей Продвижение площадки.
Мало привлечь пользователя — его надо еще адаптировать и привязать к сервису. В идеале он должен просыпаться и тянуться за телефоном, чтобы посмотреть что в вашем сервисе творится (ну в общем как обстоит с социальными сетями и мессенджерами).
Необходимо вернуться к сториборду первого контакта пользователя и сравнить план (сториборд) и реальность (вебвизор). Надо понять, почему возникают отличия и подкорректировать свой сториборд, либо внести изменения на сайте, чтобы реальный процесс был приближен к сториборду.
Важно, чтобы пользователь в кратчайшие сроки получил ценность от использования вашего сервиса. Если этого не произойдет, например, он просто не нашел подходящей ссылки, то очень вероятно, что вы потеряли его навсегда. Уберите все лишнее, ничто не должно мешать пользователю как можно быстрее получить свой профит.
Особый интерес вызывает возврат посетителя. Пользователь пришел на сайт, что-то посмотрел и ушел. Как его вернуть?
В идеале хорошо бы проработать сториборд и для последующих повторных визитов. И так же сравнивать поведение пользователя с ним.
Привлекать пользователя гораздо дороже, чем его удержать. Если бы социальные сети не удерживали пользователей, а постоянно привлекали, то они давно бы разорились. Вы видели где-то в сети рекламу ВКонтакте? Удержание должно стать одной из главных ваших ключевых идей.
Как стимулировать пользователя более активно взаимодействовать с сервисом? Игрофикация. Создавайте специальные счетчики, рейтинги, бейджи, шкалы наполненности профиля, анимированных персонажей.
Пользователь не должен заскучать, у него должна быть четкая и простая мотивация совершить следующее действие. Люди не любят незавершенные действия. Напоминайте им специальными показателями прогресса, что они не до конца заполнили профиль или не до конца описали проект на аукционе.
В более сложном варианте можно создавать квесты для пользователя, но это потребует серьезной проработки игры и глубокого понимания мотивации и особенностей вашей целевой аудитории.
Еще лучше если вы сможете вовлечь пользователя во взаимодействие с другими пользователями на фоне игрофикации. Посмотрите мобильное приложение для караоке Starmaker — вы сразу окунаетесь в водоворот событий и взаимодействия с другими пользователями. Это сделано на высшем уровне. И потом обратите внимание на то, как они вас пытаются вернуть в приложение.
Важно выработать привычку пользоваться вашим продуктом. Это достигается за счет регулярности и простоты использования. На эту тему есть прекрасная книга Н. Эяль «На крючке».
Неразвивающийся продукт скорее всего быстро зачахнет и закроется.
У вас должен быть подробный краткосрочный план по внедрениям новых возможностей в продукт, а также вы должны иметь общее видение (или долгосрочный план) того как будет развиваться продукт в целом, без проработки отдельных мелких деталей.
Не стремитесь объять необъятное. Двигайтесь итеративно. Внедряйте только то, что действительно имеет смысл для потребителя и добавляет ценности вашему продукту.
Соотнесите с видением продукта каждую новую возможность. Откажитесь от “классных“ идей, которые идут вразрез с концепцией продукта.
Каждая возможность продукта — это ответ на боль потребителя продукта. Если возможность особо ничего не облегчает потребителю, может она не нужна? Хотя бы просто отложите ее до будущего рассмотрения (возможно это станет со временем болью).
Беклог — это центральный документ развития вашего продукта. Фиксируйте все возможности продукта в нем. Ставьте приоритеты и планируйте изменения.
По поводу идеализма и стремления к совершенству при создании продукта — тут двоякий момент. Все знают пример Стива Джобса, который был ультра идеалистом (по крайней мере, так видится из книг). Где-то он был прав, где-то перегибал и довольно сильно.
Мое мнение: в ключевой идее вашего продукта вы должны постараться добиться максимальных результатов (конечно, учитывая те ресурсы, которые вам доступны).
Если вы терроризируете свою команду пытаясь усовершенствовать несущественные моменты для потребителя, то скорее всего вы просто сжигаете попусту время и другие ресурсы.
Избегайте вкусовщины. Отталкивайтесь от данных и обратной связи потребителя (с критической фильтрацией). Вы — не великий дизайнер, у вас нет какого-то уникального чувства вкуса. Идите от потребителя и постарайтесь реализовать то, что ему нужно, а не удовлетворяйте свой творческий голод в виде вкусовщины по дизайну продукта.
Ну и последнее — культ прототипных решений. Не пытайтесь делать крупные возможности сразу. Сначала сделайте прототип или даже макет. Покажите потребителям, соберите обратную связь. Может так получиться, что вы сделаете большой функционал в системе, а он никому не будет нужен и более того, усложнит жизнь пользователя (например, система будет работать медленнее чем раньше, или станет менее стабильной).
Рекомендуем посмотреть наши статьи о том сколько стоит содержать сайт и как развивать сайт.
Советы
Задания
Источник: сборник наших статей на vc.ru - https://vc.ru/marketing/95255-product-owner-00-kurs-po-sozdaniyu-svoego-produkta-nachalo
