Предыдущая публикация
Как создать IT продукт. Руководство для продукт менеджера (курс product manager)
Это небольшое руководство для руководителей проектов, продукт менеджеров, в котором мы раскрываем основные вопросы становления своего программного проекта.
В первую очередь для людей, планирующих создавать свой продукт и для тех, кто уже столкнулся с подводными камнями реализации на практике. Изучив курс продукт менеджера, вы сможете более четко сформулировать, как и куда двигать свой продукт.
Также курс будет полезен менеджерам веб-проектов, которые вынуждены работать со слабым продукт-менеджером со стороны заказчика. В этом случае, ваши дополнительные скиллы помогут нивелировать слабости заказчика и сделать вас более ценным подрядчиком для него.
Зачем нам нужен курс product manager?
Моя задача - создать подготовленного заказчика, который понимает, что он хочет и имеет четкое видение по своему продукту.
Проекты в подавляющем большинстве проваливаются не из-за плохой реализации. Зачастую они изначально обречены на неудачу в силу того, что нет четкого понимания по становлению продукта.
Что будем рассматривать?
В первую очередь, это маркетинг. Для кого мы создаем продукт, зачем он им нужен? Какую роль закрывает и т.д.
Дальше - это детализация своей идеи в виде структуры продукта.
Курс был опубликован на сайте https://vc.ru в декабре 2019.
Материалы к курсу Product Owner по ссылке https://falconspace.ru/product-owner-docs
Вы можете скачать себе и работать в Excel с данными шаблонами, либо создать копию и использовать Google Spreadsheet (Файл / Создать копию...).
Шаблон включает в себя следующие элементы:
Простота
Чем больше людей, тем хуже будет продукт.
Введение к курсу
Для кого предназначен курс product owner product manager?В первую очередь для людей, планирующих создавать свой продукт и для тех, кто уже столкнулся с подводными камнями реализации на практике. Изучив курс продукт менеджера, вы сможете более четко сформулировать, как и куда двигать свой продукт.
Также курс будет полезен менеджерам веб-проектов, которые вынуждены работать со слабым продукт-менеджером со стороны заказчика. В этом случае, ваши дополнительные скиллы помогут нивелировать слабости заказчика и сделать вас более ценным подрядчиком для него.
Зачем нам нужен курс product manager?
Моя задача - создать подготовленного заказчика, который понимает, что он хочет и имеет четкое видение по своему продукту.
Проекты в подавляющем большинстве проваливаются не из-за плохой реализации. Зачастую они изначально обречены на неудачу в силу того, что нет четкого понимания по становлению продукта.
Что будем рассматривать?
В первую очередь, это маркетинг. Для кого мы создаем продукт, зачем он им нужен? Какую роль закрывает и т.д.
Дальше - это детализация своей идеи в виде структуры продукта.
Курс был опубликован на сайте https://vc.ru в декабре 2019.
Материалы к курсу Product Owner по ссылке https://falconspace.ru/product-owner-docs
Вы можете скачать себе и работать в Excel с данными шаблонами, либо создать копию и использовать Google Spreadsheet (Файл / Создать копию...).
Шаблон включает в себя следующие элементы:
- Шаблон создания концепции
- Шаблон формы работы с партнерами
- Сториборд потребителя
- Шаблон структуры проекта
- Карта рисков
- Управление требованиями через беклог
- Придумайте идею своего продукта в общих чертах. Если сейчас ничего не приходит на ум, берите идею создания CRM аренды недвижимости. В примерах мы будем рассматривать именно этот проект. Опишите вкратце свою идею в 3-5 предложениях своими словами.
- Если вы никогда не использование сервисы облачного хранения, то пора бы начать. Зарегистрируйтесь в Google Drive, Яндекс Диск или Dropbox. Почитайте статьи об их эффективном использовании. Если кратко - проще будет обмениваться файлами, документами и иметь доступ со всех своих устройств.
- Почитайте про следующие моменты: Модель Остервальдера, Lean startup, Customer Development.
Ключевые принципы и идеи для менеджера продукта
Принципы можно нарушать. Просто помните про риски, которые вы берете на себя в этом случае.
Цикл “Идея - Ручная проверка - Прототип — Сбор обратной связи — Выводы — Развитие или разворот”- У вас есть идея.
- Сделайте простейший прототип (в идеале за один день и бесплатно)
- Проверьте на кошках (на первых лояльных пользователях)
- Сделайте выводы: мы занимаемся никому ненужной ерундой или это реально кому-то очень нужно.
- Развивайте идею либо измените ее так, чтобы она стала ценной для потребителя.
Простота
- Чем проще решение — тем оно дешевле, быстрее работает, его быстрее собрать, его легче поддерживать.
- Стремитесь всегда к простоте и легкости.
- Система по мере развития будет усложняться. Если сразу делать ее сложной, то скорее всего в дальнейшем она станет неподдерживаемым монстром.
- Сложное решение может давать неожиданные побочные эффекты (динамические баги, стать причиной ошибки людей и т.д.)
- Отталкивайтесь от своего разума и фактов, а не сомнительных советов из статей (хорошая зацепка для комментария).
- Не подменяйте факты экспертным мнением.
- Критически воспринимайте обратную связь по своему продукту (не все что говорит пользователь ему реально нужно. Человек может говорить одно, а действовать по другому).
- Выберите некое видение продукта и придерживайтесь его во всех принимаемых решениях.
- Нельзя сразу нарисовать Мона Лизу. К этому нужно прийти.
- Создайте что-то малое, но работающее и полезное кому-то.
- Создайте ручеек и расширяйте его постепенно.
- Определяйте контрольные точки, фиксируйте достижения продукта в них и планируйте следующую контрольную точку.
- Детальное краткосрочное планирование и размытые дальние перспективы. Нет смысла детально определять то, что будет через N лет, т.к. через пару месяцев все может сильно измениться. Вы должны видеть только общие контуры и двигать продукт к ним.
Чем больше людей, тем хуже будет продукт.
- Во-первых, сложно заинтересовать других людей своим продуктом.
- Во-вторых, люди будут склонны размывать фокус продукта.
- В-третьих, информация будет быстрее передаваться и меньше требуется обсуждений.
- В-четвертых, меньше размыта ответственность.
- Если есть готовое решение и оно подходит — надо пробовать его (именно поэтому Excel — зачастую идеальное начальное средство для учета чего-либо).
- По мере увеличения потребностей подбираем более подходящее решение.
- Не нужно стрелять из пушки по воробьям, особенно если пушку делать год, стоит она 2 млн, а воробьев не более 100 шт.
- Эти принципы — не панацея. И, вероятно, с некоторыми вы будете категорически не согласны. Определите свой свод принципов построения продукта, ознакомьте команду с этими принципами, чтобы правильно сформировать ожидания по взаимодействию.
- Напишите какие из указанных принципов вы собираетесь намеренно игнорировать и почему (сделайте это нарушение принципов осознанным).
- Сформулируйте свою идею так, чтобы можно было в течение 20‑30 секунд рассказать о ней другому человеку. Соберите 3 отклика по своей идее и зафиксируйте в документе. Получилось ли у вас донести с первого раза свою идею донести до людей? (если вживую сложно это сделать, то на странице сайта это будет сделать вдвойне сложнее, т.к. у вас сильно ограниченная обратная связь от пользователя).
- Посмотрите инструменты макетирования и особое внимание обратите на Google Slides для простого и быстрого создания макетов.
- Научитесь делать скриншоты (например, в Яндекс Диск) и видеоскриншоты (screencast.com). Это упростит вам в будущем взаимодействие с исполнителями на проекте (программисты, продвиженцы, дизайнеры и т.д.).
Как создать продукт? Проработка и детализация идеи продукта
Что такое концепция проекта?
Концепция — это система взглядов на будущий продукт, описывающая видение руководителя проекта (либо группы заинтересованных лиц).
Помните, что все описанное в концепции является гипотезами, а не фактами. И эти гипотезы требуют подтверждения поведением реальных потребителей.
Зачем создавать концепцию проекта?
Концепция — это точка входа в проект
Концепция помогает структурировать начальное описание проекта. Концепция проекта описывает ключевые моменты вашего проекта и позволяет быстро вникнуть в суть проекта.
Как создавать концепцию?
Создавайте концепцию итеративно, т.е. опишите в начале поверхностно свою идею.
По мере поступления новой информации детализируйте концепцию. Задавайте новые вопросы и фиксируйте ответы в концепции проекта.
Кто создает концепцию?
Концепцию должен делать сам руководитель проекта (или product owner). Не нужно делегировать эту работу техническим специалистам и маркетологам. Концепция — это не бриф на разработку сайта и не план продвижения сайта. Концепция — это то, как видит product owner свой продукт.
Из чего состоит концепция проекта?
Кто есть целевая аудитория проекта и какие проблемы целевой аудитории мы решаем? Можно ли разбить целевую аудиторию на основные типовые сегменты
Как сейчас потребитель решает свою проблему? Как в идеале он мог бы решать эту проблему?
В чем наше решение?
Что для потребителя важно (какие характеристики наиболее критичны) в плане его проблемы?
В чем наше предложение потребителю? (оффер — цена, условия поставки, оказание услуг, дополнительные условия сделки)
Как мы планируем достучаться до потребителя? (реклама, каналы)
Основные характеристики нашего решения (возможности портала, структура)
Описание объектов и субъектов будущей системы (структура будущего продукта)
Кто наши партнеры? Кто есть наши стратегические партнеры (те, у кого такая же ЦА, что и у нас)? Кто есть наши партнеры-поставщики (кто будет помогать нам делать и поставлять продукт заказчику)?
В чем наши гипотезы монетизации? На чем планируем зарабатывать и когда это наступит от момента запуска в эксплуатацию?
Главные риски проекта. В чем видите основные риски провала проекта? Как их минимизировать (критичность, вероятность)?
Скачать шаблон концепции проекта https://docs.google.com/spreadsheets/d/1yY466nm_45SnKA70jWrvxEGZfoqGilODf-yj8tlq3rs/edit
Пишите кратко, без воды. Концепция — не про “продать продукт”. Это про то, чтобы как можно четче обозначить ключевые моменты проекта.
Все, что вы написали — это гипотезы и не более того. Они могут меняться по ходу выявления новой информации.
Советы
Концепция — это система взглядов на будущий продукт, описывающая видение руководителя проекта (либо группы заинтересованных лиц).
Помните, что все описанное в концепции является гипотезами, а не фактами. И эти гипотезы требуют подтверждения поведением реальных потребителей.
Зачем создавать концепцию проекта?
Концепция — это точка входа в проект
Концепция помогает структурировать начальное описание проекта. Концепция проекта описывает ключевые моменты вашего проекта и позволяет быстро вникнуть в суть проекта.
Как создавать концепцию?
Создавайте концепцию итеративно, т.е. опишите в начале поверхностно свою идею.
По мере поступления новой информации детализируйте концепцию. Задавайте новые вопросы и фиксируйте ответы в концепции проекта.
Кто создает концепцию?
Концепцию должен делать сам руководитель проекта (или product owner). Не нужно делегировать эту работу техническим специалистам и маркетологам. Концепция — это не бриф на разработку сайта и не план продвижения сайта. Концепция — это то, как видит product owner свой продукт.
Из чего состоит концепция проекта?
Кто есть целевая аудитория проекта и какие проблемы целевой аудитории мы решаем? Можно ли разбить целевую аудиторию на основные типовые сегменты
Как сейчас потребитель решает свою проблему? Как в идеале он мог бы решать эту проблему?
В чем наше решение?
Что для потребителя важно (какие характеристики наиболее критичны) в плане его проблемы?
В чем наше предложение потребителю? (оффер — цена, условия поставки, оказание услуг, дополнительные условия сделки)
Как мы планируем достучаться до потребителя? (реклама, каналы)
Основные характеристики нашего решения (возможности портала, структура)
Описание объектов и субъектов будущей системы (структура будущего продукта)
Кто наши партнеры? Кто есть наши стратегические партнеры (те, у кого такая же ЦА, что и у нас)? Кто есть наши партнеры-поставщики (кто будет помогать нам делать и поставлять продукт заказчику)?
В чем наши гипотезы монетизации? На чем планируем зарабатывать и когда это наступит от момента запуска в эксплуатацию?
Главные риски проекта. В чем видите основные риски провала проекта? Как их минимизировать (критичность, вероятность)?
Скачать шаблон концепции проекта https://docs.google.com/spreadsheets/d/1yY466nm_45SnKA70jWrvxEGZfoqGilODf-yj8tlq3rs/edit
Пишите кратко, без воды. Концепция — не про “продать продукт”. Это про то, чтобы как можно четче обозначить ключевые моменты проекта.
Все, что вы написали — это гипотезы и не более того. Они могут меняться по ходу выявления новой информации.
Советы
- Смотрите серию видео на нашем канале Youtube про #провалпроекта
- Прочитайте книгу С.Хёрф “Как создать продукт, который полюбят. Опыт успешных менеджеров и дизайнеров”.
- Создайте файл концепции своего продукта
- Покажите свою концепцию хотя бы одному представителю целевой аудитории. Соберите его комментарии по документу.
Проверка идеи продукта
Рассмотрим вопрос начальной верификации идеи вашего продукта.
Ваш продукт никому не нужен
Итак, вы, руководитель продукта, проработали концепцию своего продукта и определили его ключевые особенности. Не нужно сразу начинать искать исполнителя на проект и запускать проект в разработку для создания реального образца продукта. Почему? Очень вероятно, что ваш продукт никому кроме вас не нужен. Либо он кому-то нужен, но не настолько, чтобы за него платить. Возможно они и готовы платить, но не в том объеме, который нужен вам. Может этих людей не так много, как вам кажется. В априори считайте, что ваш продукт никому не нужен, и вам требуется доказать себе, что в нем есть реальная ценность для целевой аудитории.Будьте немного пессимистом в начале проекта и оптимистом на более поздних стадиях проекта (а он там точно пригодится).
Сейчас нужно проверить идею на реальных потребителях/заказчиках.
Рекомендуем посмотреть нашу статью Главная проблема стартапа - делать проект вслепую.
Что показывать целевой аудитории?
Создайте презентацию для заказчиков в Google Slides на 3 листах:
Найдите 2‑3 представителей целевой аудитории и покажите им свою презентацию. Где искать:
Проведите встречу с ними, либо скайп-колл. Упор надо сделать на общение, а не на презентацию. Презентация — это скорее дополнение к разговору, а не наоборот.
Что нужно выявить:
В идеале у вас перед началом проекта уже должен быть пул из 10 лояльных заказчиков, которые спят и видят, когда уже наконец появится ваш продукт.
Задание
Из чего состоит сториборд
Блоки, соединенные линиями. Каждый блок — это пользовательская история по некой активности пользователя в системе.
Например, для CRM аренды недвижимости это может быть так:
Можно ничего не придумывать, а просто спросить пользователей как они работают, а еще лучше — понаблюдать (хотя это и сложнее, но зато это даст более точную картину).
Не пытайтесь эти работы повесить на программистов, команду разработки или дизайнеров. Это не их задача. Это задача продукт-менеджера (ну или продуктового дизайнера). В итоге надо сразу расставить зоны ответственности и действовать по установленным договоренностям.
Если система делается для внешнего потребителя, можно начать с самых дальних касаний (например, потребитель увидел ваше рекламное объявление где-то в Сети).
Где заканчивать описание ключевого процесса?
Описывать следует до того момента, как пользователь получил ощутимую пользу от использования сервиса: разместил объявление на площадке, получил некую информацию, настроил свой профиль в социальной сети (например, >90% заполненности профиля).
Создание структуры проекта
Если говорить о некой многопользовательской системе, то проект можно разделить на области:
Сначала опишите состав меню каждого кабинета, а затем список внутренних страниц. Пример - Страница заказа. Ее не будет в меню. В меню будет страница Заказы, а уже с нее идет ссылка на Страницу заказа.
Создание макетов
Ключевое по макетам — создаем их быстро, а не технологично. Затем получаем обратную связь, дорабатываем макеты и так делаем, пока не будет простой и понятный функционал для пользователя.
Как создавать макеты:
Не нужно сидеть долго над каждым макетом. На 1 версию макета 1 страницы - не более 10 мин.
Лучше быстро сделать, показать, понять, что это совсем не то, переделать заново, нежели потратить 2 недели на макеты, а затем за них держаться, т.к. мы в них вложили столько сил и души. Человеку свойственно защищать то, во что он сильно вложился, даже если это полная ерунда. Поэтому не нужно слишком “прикипать” к своим макетам. Макеты — это просто способ общения с потребителями и разработчиками, не более того.
Примечание:
Стремитесь к тому, чтобы функционал первой версии был минимальный. Чем меньше объем, тем быстрее, проще и дешевле ее будет внедрить: меньше рисовать, меньше писать ТЗ, меньше кодировать, меньше в итоге переделывать.
У вас есть лояльные заказчики/пользователи. Используйте это для верификации ваших макетов. В правильном ли мы направлении движемся? Понимают ли они эти макеты без пояснений? Есть ли у них интерес к системе (в ходе взаимодействия это будет видно)?
Сразу настройтесь на то, что вы сделаете структуру и макеты за 1 день. В этом нет ничего сложного, можно подсматривать удачные решения из чужих систем (но не надо слепо копировать). Самые ужасные корявые макеты (но по смыслу правильные) лучше тех, которые сделают “в ближайшее время”.
Сбор обратной связи по прототипам
Созданные макеты следует показать пользователям и доработать их по их обратной связи.
Зачем это нужно:
Что необходимо сделать:
Кратко напомните суть сервиса и поблагодарите за помощь в создании сервиса
Покажите свои макеты, можно просто фото ваших набросков, и кратко опишите их
Задавайте различные вопросы формата “А как сделать то-то”. Это даст возможность выявить, насколько человеку понятен интерфейс программы
Дайте почувствовать пользователю себя экспертом и поощряйте его высказывать критическое мнение о системе и интерфейсе.
Задайте вопрос - решает ли система начальную поставленную задачу?
Спросите, какой макет он считает самым важным? Почему? Какие страницы ему кажется несущественными и ненужными? Чего не хватает? Как в идеале надо упростить процесс работы над системой?
Поблагодарите человека за помощь и скажите, что сообщите, когда появится пробный образец программы.
Занесите результаты и инсайты в документ Excel. Этот документ вы потом сможете использовать для поиска идей по улучшению вашего продукта.
Ваша задача - не продать решение, а получить максимум информации от данного пользователя. Если вы будете пытаться продать, то пользователь закроется.
Шаблон сториборда в табличном виде, структуры проекта и сбор обратной связи вы сможете найти среди материалов на нашем сайте
Советы
Что такое риск?
Риск — это негативное событие, которое может наступить с некоей вероятностью и имеет некую критичность для вас.
Ваша задача: выявить риски, распределить по типам и проранжировать их на основании критичности и вероятности.
Что делать с риском
Для каждого риска проставьте критичность K и вероятность P (от 1 до 3. 3- мегакритично, 1 — малокритично).
Получите интегральный показатель по всем рискам (например, по формуле P+ 2* K). Отсортируйте список в порядке убывания и у вас будет план по обработке рисков (начиная с самых критично-вероятных).
Возьмем риск, который несет на себе каждый из нас — автомобильная авария.
Вероятность — средняя, ближе к высокая (особенно для тех, кто постоянно катается за рулем на дальние расстояния).
Критичность — очень высокая.
Как можем снизить вероятность — меньше кататься на авто, найти работу поближе и ходить пешком, либо работать из дома. Не ездить с лихачами. Взять за правило никогда не гнать под желтый.
Как можем снизить критичность — купить машину побольше, всегда пристегиваться, машина с подушкой безопасности.
Полностью риска избежать не получится, и нужно смириться с тем, что это может произойти с каждым (но при этом надо предпринять как минимум те меры, которые мы описали).
Примеры рисков при разработке продукта
Выделим несколько рисков, с которыми вы можете столкнуться:
Усложнение функционала и ненужные функции. Стремление все усложнить и накрутить — очень частая история. Старайтесь сознательно с этим бороться.
Костыли. Программисты могут без вашего ведома использовать некие костыльные решение за неимением более подходящего решения. Проблема костылей в том, что они усложняют сопровождение и увеличивают риски возникновения ошибок в продукте
Смена product owner. При этом скорее всего изменится видение продукта, его стратегическое развитие. Если придет неподходящий человек, то это может погубить даже стабильный устойчивый успешный продукт.
Слишком сильное желание угодить потребителю - в погоне за мимолетными желаниями пользователей вы быстро потеряете фокус продукта и сделаете решение “все для всех”. Обычно такие решения очень сложны в использовании, неповоротливые и имеют очень сложный витиеватый интерфейс.
Также читайте нашу статью про риски веб-проекта
Описывать продукт необходимо итеративно. Для начала определитесь с 1 версией продукта - минимальный функционал, который будет введен в эксплуатацию.
Как описывать требования
Описывать его можно в виде пользовательских историй. Каждая история - это детализация возможности некоторой роли в системе. Можно это делать в формате “Я как роль такая-то могу сделать то-то с такой-то целью”.
Ключевые моменты пользовательской истории:
Организация хранения требований
Где хранить пользовательские истории? В беклоге. В самом простом случае это таблица Excel со следующими полями:
Как работать с беклогом
Если в ходе этап возникла идея - просто заносим в беклог и описываем ее в разрезе всех столбцов беклога. Очень часто возникает ситуация, что требование быстро становится неактуальным, либо трансформируется или уточняется. Поэтому нет необходимости транзитом через беклог сразу “гнать” требования в сторону разработчиков.
Двигаясь по этапам вы периодически обновляете беклог:
Пример карты рисков и шаблон беклога есть среди материалов к данному курсу
Советы
Хороший дизайн в нашем понимании — это:
Если у вас нет особого понимания по дизайну, то исходите из трех простых концептов:
Вам необходимо более подробно раскрыть вопросы из концепции:
По следующей структуре:
Альтернативный способ — собрать всю семантику (Wordstat, KeyCollector), структурировать ее и писать статьи под каждый семантический кластер. Этот вариант даст больше покрытие по ключевым словам, но материал будет не так хорошо структурирован как в 1 варианте.
В любом случае у вас в итоге должна появиться карта контента, которую вы будете использовать как план создания полезных материалов для вашего потребителя.
Как привлечь трафик. Основные каналы:
Обработка потенциального клиента
Руководитель продукта должен точно знать, что делать с потенциальным клиентом. По какой дорожке он должен пройти — от момента 1 касания до полного закрытия всех отношений с ним.
Что включает в себя эта дорожка:
В случае сервиса этот процесс будет немного отличаться:
Посмотрите нашу статью, сравнивающую облачные сервисы, разработку на заказ и готовые продукты.
Если решения нет, то пробуем делать на какой-либо готовой платформе.
Если нам нужно что-то сильно специализированное с широкими возможностями изменения, то делают с нуля по полному стеку разработки.
Мы занимаемся именно полуфабрикатами. У нас есть платформа, на которой мы создаем готовые решения, которые в будущем можно адаптировать и развивать под себя.
Варианты работы с подрядчиком разработки
Что важно учесть при поиске исполнителя
Ваш продукт никому не нужен
Итак, вы, руководитель продукта, проработали концепцию своего продукта и определили его ключевые особенности. Не нужно сразу начинать искать исполнителя на проект и запускать проект в разработку для создания реального образца продукта. Почему? Очень вероятно, что ваш продукт никому кроме вас не нужен. Либо он кому-то нужен, но не настолько, чтобы за него платить. Возможно они и готовы платить, но не в том объеме, который нужен вам. Может этих людей не так много, как вам кажется. В априори считайте, что ваш продукт никому не нужен, и вам требуется доказать себе, что в нем есть реальная ценность для целевой аудитории.Будьте немного пессимистом в начале проекта и оптимистом на более поздних стадиях проекта (а он там точно пригодится).
Сейчас нужно проверить идею на реальных потребителях/заказчиках.
- Заказчик — тот, кто покупает решение.
- Потребитель — тот, кто использует ваше решение.
Рекомендуем посмотреть нашу статью Главная проблема стартапа - делать проект вслепую.
Что показывать целевой аудитории?
Создайте презентацию для заказчиков в Google Slides на 3 листах:
- Для кого делается решение и в чем его боль?
- В чем суть решения?
- Какие условия использования, поставки?
- Кратко, без воды и общих фраз.
- Не нужно никого пытаться уговаривать (никаких продающих фраз). Вы не должны сейчас продавать решение, вы должны понять нужно оно кому-то или нет.
- Главная задача — донести правильно смысл
- Стилистика не важна. Фирменный стиль не нужен. Просто возьмите хороший аккуратный шаблон с минималистичным дизайном.
Найдите 2‑3 представителей целевой аудитории и покажите им свою презентацию. Где искать:
- ваши текущие клиенты
- друзья друзей в социальных сетях (под предлогом спросить профессиональное мнение по их области).
- поиск компаний заказчика и начало общения под видом заказчика с последующим переходом к идее сервиса.
Проведите встречу с ними, либо скайп-колл. Упор надо сделать на общение, а не на презентацию. Презентация — это скорее дополнение к разговору, а не наоборот.
Что нужно выявить:
- критична ли для них эта проблема? и насколько критична.
- как они сейчас решают проблему?
- как они в идеале хотели бы решать проблему?
- на каких условиях они готовы покупать идеальное решение?
- готовы ли они оставить свои критичные данные? (каталог-прайс, юридические данные, контакты внутренних заинтересованных лиц в их компании). Именно это служит позитивным сигналом, что идея им действительно интересна.
В идеале у вас перед началом проекта уже должен быть пул из 10 лояльных заказчиков, которые спят и видят, когда уже наконец появится ваш продукт.
Задание
- Создайте краткую презентацию
- Проведите минимум 3 опроса
- Создайте Excel файл Партнеры и занесите результаты опроса.
- Прочитайте книгу «Как создать продукт, который купят» Lean Customer Development https://cdn.dasreda.ru/storage-data/c51f50a1-729d-4301-868b-74a724b5574f/kak-sozdat-produkt-kotoryy-kupyat-metod-lean-customer-development-53872.pdf
- Ищите представителей ЦА с запасом. Кто-то обязательно отвалится, не сможет, поэтому лучше эти моменты делать с неким запасом.
Ключевой процесс продукта. Создание начальных макетов продукта
В каждом продукте можно выделить некий основной процесс, по которому работает 90% пользователей системы. Вам необходимо его найти, выделить и детально описать.
Сториборд — это визуальное (а в нашем случае табличное — для простоты и скорости составления) отображение ключевого процесса проекта.Из чего состоит сториборд
Блоки, соединенные линиями. Каждый блок — это пользовательская история по некой активности пользователя в системе.
Например, для CRM аренды недвижимости это может быть так:
- Вход менеджера CRM в систему
- Проверка наличия и бронь недвижимости по звонку от клиента
- Мониторинг панели основных показателей системы
- Завершение работы
Можно ничего не придумывать, а просто спросить пользователей как они работают, а еще лучше — понаблюдать (хотя это и сложнее, но зато это даст более точную картину).
Не пытайтесь эти работы повесить на программистов, команду разработки или дизайнеров. Это не их задача. Это задача продукт-менеджера (ну или продуктового дизайнера). В итоге надо сразу расставить зоны ответственности и действовать по установленным договоренностям.
Если система делается для внешнего потребителя, можно начать с самых дальних касаний (например, потребитель увидел ваше рекламное объявление где-то в Сети).
Где заканчивать описание ключевого процесса?
Описывать следует до того момента, как пользователь получил ощутимую пользу от использования сервиса: разместил объявление на площадке, получил некую информацию, настроил свой профиль в социальной сети (например, >90% заполненности профиля).
Создание структуры проекта
Если говорить о некой многопользовательской системе, то проект можно разделить на области:
- Неавторизованная область (пользователь не зарегистрирован в системе). Здесь будут общие текстовые страницы, каталог товаров/услуг, формы входа, регистрации.
- Кабинеты по типам пользователей. В системе могут работать Поставщики, Партнеры, Покупатели и другие типы внешних пользователей. На каждого из них будет свой вид кабинета со своим интерфейсом.
- Кабинеты для служебных ролей. Модераторы, операторы, администраторы, контент-менеджеры.
Сначала опишите состав меню каждого кабинета, а затем список внутренних страниц. Пример - Страница заказа. Ее не будет в меню. В меню будет страница Заказы, а уже с нее идет ссылка на Страницу заказа.
Создание макетов
Ключевое по макетам — создаем их быстро, а не технологично. Затем получаем обратную связь, дорабатываем макеты и так делаем, пока не будет простой и понятный функционал для пользователя.
Как создавать макеты:
- сначала вручную на бумаге (на А4 можно сделать 4 макета).
- визуализируем только ключевые детали (не нужно пока тратить внимание на мелкие несущественные детали)
- если есть время/деньги/желание, то даем задание перенести это в системы создания прототипов (Axure или др) с полной динамикой прохода по страницам
- описывайте только страницы ключевого процесса. Меньше страниц — меньше согласований, быстрее вносить правки, более точный фокус на основном.
- описывайте только страницы ключевого процесса. Меньше страниц — меньше согласований, быстрее вносить правки, более точный фокус на основном.
Не нужно сидеть долго над каждым макетом. На 1 версию макета 1 страницы - не более 10 мин.
Лучше быстро сделать, показать, понять, что это совсем не то, переделать заново, нежели потратить 2 недели на макеты, а затем за них держаться, т.к. мы в них вложили столько сил и души. Человеку свойственно защищать то, во что он сильно вложился, даже если это полная ерунда. Поэтому не нужно слишком “прикипать” к своим макетам. Макеты — это просто способ общения с потребителями и разработчиками, не более того.
Примечание:
Стремитесь к тому, чтобы функционал первой версии был минимальный. Чем меньше объем, тем быстрее, проще и дешевле ее будет внедрить: меньше рисовать, меньше писать ТЗ, меньше кодировать, меньше в итоге переделывать.
У вас есть лояльные заказчики/пользователи. Используйте это для верификации ваших макетов. В правильном ли мы направлении движемся? Понимают ли они эти макеты без пояснений? Есть ли у них интерес к системе (в ходе взаимодействия это будет видно)?
Сразу настройтесь на то, что вы сделаете структуру и макеты за 1 день. В этом нет ничего сложного, можно подсматривать удачные решения из чужих систем (но не надо слепо копировать). Самые ужасные корявые макеты (но по смыслу правильные) лучше тех, которые сделают “в ближайшее время”.
Сбор обратной связи по прототипам
Созданные макеты следует показать пользователям и доработать их по их обратной связи.
Зачем это нужно:
- интерфейс может быть непонятен им.
- возможно вы упустили важные для них особенности процессов
- возможно ваш интерфейс не решает важных задач пользователя
Что необходимо сделать:
- Выберите из вашего пула лояльных пользователей 2‑3, которые согласны на колл (звонок по скайпу) на 20 минут по вашей системе.
- Заранее запланируйте колл по скайпу с ними (важно чтобы пользователь был с ПК, а не с мобильного).
Кратко напомните суть сервиса и поблагодарите за помощь в создании сервиса
Покажите свои макеты, можно просто фото ваших набросков, и кратко опишите их
Задавайте различные вопросы формата “А как сделать то-то”. Это даст возможность выявить, насколько человеку понятен интерфейс программы
Дайте почувствовать пользователю себя экспертом и поощряйте его высказывать критическое мнение о системе и интерфейсе.
Задайте вопрос - решает ли система начальную поставленную задачу?
Спросите, какой макет он считает самым важным? Почему? Какие страницы ему кажется несущественными и ненужными? Чего не хватает? Как в идеале надо упростить процесс работы над системой?
Поблагодарите человека за помощь и скажите, что сообщите, когда появится пробный образец программы.
Занесите результаты и инсайты в документ Excel. Этот документ вы потом сможете использовать для поиска идей по улучшению вашего продукта.
Ваша задача - не продать решение, а получить максимум информации от данного пользователя. Если вы будете пытаться продать, то пользователь закроется.
Шаблон сториборда в табличном виде, структуры проекта и сбор обратной связи вы сможете найти среди материалов на нашем сайте
Советы
- Прочитайте книгу Д. Кнапп Спринт «Как создать и проверить продукт за 5 дней»
- Посмотрите книгу Р. Фитцпатрик Спроси маму. Как общаться с клиентами и подтвердить правоту своей бизнес-идеи, если все кругом врут?
- Вы можете довольно быстро научиться делать макеты в Axure (их проще развивать, изменять + можно делать динамический интерактивный интерфейс).
- Для создания структур проектов вы можете попробовать использовать FreeMind или программы аналоги. Они позволяют строить древовидные карты.
- Создайте свой сториборд ключевого процесса
- Получите комментарии пользователей к вашему сториборду и улучшите его.
- Создайте структуру своего проекта (кабинеты и страницы для них)
- Создайте макеты страниц от руки на бумаге.
Риск-менеджмент вашего продукта. Что должен делать руководитель продукта?
Закон Мёрфи — Всё, что может пойти не так, пойдет не так
Необходимо заранее охватить всевозможные риски и хотя бы принять их. Важно, чтобы свершившийся риск не был для вас полной неожиданностью.Что такое риск?
Риск — это негативное событие, которое может наступить с некоей вероятностью и имеет некую критичность для вас.
Ваша задача: выявить риски, распределить по типам и проранжировать их на основании критичности и вероятности.
Что делать с риском
Для каждого риска проставьте критичность K и вероятность P (от 1 до 3. 3- мегакритично, 1 — малокритично).
Получите интегральный показатель по всем рискам (например, по формуле P+ 2* K). Отсортируйте список в порядке убывания и у вас будет план по обработке рисков (начиная с самых критично-вероятных).
- Вырабатываем меры по уменьшению критичности
- Вырабатываем меры по уменьшению вероятности
- Если ничего сделать с ним не можем, то надо смириться с этим и знать что это может случиться.
Возьмем риск, который несет на себе каждый из нас — автомобильная авария.
Вероятность — средняя, ближе к высокая (особенно для тех, кто постоянно катается за рулем на дальние расстояния).
Критичность — очень высокая.
Как можем снизить вероятность — меньше кататься на авто, найти работу поближе и ходить пешком, либо работать из дома. Не ездить с лихачами. Взять за правило никогда не гнать под желтый.
Как можем снизить критичность — купить машину побольше, всегда пристегиваться, машина с подушкой безопасности.
Полностью риска избежать не получится, и нужно смириться с тем, что это может произойти с каждым (но при этом надо предпринять как минимум те меры, которые мы описали).
Примеры рисков при разработке продукта
Выделим несколько рисков, с которыми вы можете столкнуться:
Усложнение функционала и ненужные функции. Стремление все усложнить и накрутить — очень частая история. Старайтесь сознательно с этим бороться.
Костыли. Программисты могут без вашего ведома использовать некие костыльные решение за неимением более подходящего решения. Проблема костылей в том, что они усложняют сопровождение и увеличивают риски возникновения ошибок в продукте
Смена product owner. При этом скорее всего изменится видение продукта, его стратегическое развитие. Если придет неподходящий человек, то это может погубить даже стабильный устойчивый успешный продукт.
Слишком сильное желание угодить потребителю - в погоне за мимолетными желаниями пользователей вы быстро потеряете фокус продукта и сделаете решение “все для всех”. Обычно такие решения очень сложны в использовании, неповоротливые и имеют очень сложный витиеватый интерфейс.
Также читайте нашу статью про риски веб-проекта
Управление требованиями по продукту
Что реализовать продукт, его необходимо конкретно и однозначно описать. Чем точнее описание, тем меньше будет разница между ожиданиями и результатом.Описывать продукт необходимо итеративно. Для начала определитесь с 1 версией продукта - минимальный функционал, который будет введен в эксплуатацию.
Как описывать требования
Описывать его можно в виде пользовательских историй. Каждая история - это детализация возможности некоторой роли в системе. Можно это делать в формате “Я как роль такая-то могу сделать то-то с такой-то целью”.
Ключевые моменты пользовательской истории:
- роль
- что может сделать
- для чего он это делает.
- какие поля будут у формы,
- какие ответы должна обрабатывать форма
- реакция системы в специфичных ситуациях (например, на мобильном экране)
- специфические ограничения доступа.
Организация хранения требований
Где хранить пользовательские истории? В беклоге. В самом простом случае это таблица Excel со следующими полями:
- Пользовательская история
- Статус (Не начата, В работе, Отложено, Внедрено)
- Приоритет
- Сложность реализации
- Детальные требования
- Значение для продукта
Как работать с беклогом
Беклог - это постоянно обновляемый документ.
В него попадают все новые хотелки, возникающие по ходу проекта. Ни в коем случае не внедряйте сразу все, что приходит в голову.Если в ходе этап возникла идея - просто заносим в беклог и описываем ее в разрезе всех столбцов беклога. Очень часто возникает ситуация, что требование быстро становится неактуальным, либо трансформируется или уточняется. Поэтому нет необходимости транзитом через беклог сразу “гнать” требования в сторону разработчиков.
Двигаясь по этапам вы периодически обновляете беклог:
- обновляете статусы реализованных возможностей
- добавляете новые идеи
- детализируете самые приоритетные истории
Пример карты рисков и шаблон беклога есть среди материалов к данному курсу
Советы
- Посмотрите серию видео про бизнес-риски на нашем канале Youtube #bizproblem
- Составьте свою карту рисков и проранжируйте их по вероятности и степени критичности (по интегральному показателю).
- Составьте план мероприятий по обработке рисков.
- Сформируйте начальный беклог для своего проекта (не менее 5 возможностей) с заполнением всех полей.
Дизайн продукта
Дизайн продукта важен. Дизайн должен служить целям потребителя продукта, а не быть просто красивым.Хороший дизайн в нашем понимании — это:
- удобный ввод и вывод информации
- понятный с первого взгляда внешний вид
- отсутствие “удивляющих элементов”
- приятные удобства (горячие клавиши, множественное добавление, быстрый поиск, минимум простоя пользователя)
- хорошая адаптация под мобильные
- быстрая реакция интерфейса (а не как в Битрикс24 при открытии окна комментария — задержка на 1,5 секунды).
- сделаем очень красивую зеленую (нет, лучше красную) кнопку — это крайне важно для продаж
- нам нужно что-то свое, уникальное, чтобы отличаться внешним видом от других.
- как-то все простенько и примитивно, давайте сделаем что-то покруче.
- а давайте поиграем со шрифтами?
- нам нужны на каждой странице очень качественные фотки по 2Мб
Если у вас нет особого понимания по дизайну, то исходите из трех простых концептов:
- простота и понятность — все должно быть просто и понятно без лишних слов
- минимализм — чем меньше элементов, тем меньше будет проблем и неточностей на выходе. Дизайн будет более чистым.
- скорость — все должно быстро работать, ключевые функции должны быть легко доступны.
Продвижение и реклама
О продвижении надо задуматься до начала создания продукта.Вам необходимо более подробно раскрыть вопросы из концепции:
- как вы планируете привлекать целевую аудиторию к продукту
- какие каналы вы готовы задействовать для привлечения
- как вы будете проводить измерения эффективности своего продвижения
- какой контент нужен вам для продвижения
- как вы будете в деталях обрабатывать вашего потенциального клиента.
- вы создаете ядро — это может быть сервис или услуга, или очень ценная информация.
- вы создаете артефакты (контент), который ведет к этому ядру. Контент может быть на вашей площадке или размещен где-то вовне.
- вы настраиваете трафик не рекламируя ядро, а на вспомогательный контент (по сути это не реклама, а ценный контент для потребителя).
- привлекайте повторно тех, кто заинтересовался вашим контентом.
- Контент надо делать хорошим (никакого рерайтинга и продающих копирайтеров). Ваши материалы должны по сути быть хорошими, без воды. В сети и так куча мусора без вас.
- Не нужно предлагать не разогретому лиду свое конечное предложение — он все равно не готов его воспринимать сразу.
По следующей структуре:
- материалы о проблеме, которую вы решаете
- материалы по возможным решениям проблемы
- материалы по вашему решению проблемы (а также о проблемах, возникающих при использовании альтернативных решений)
- материалы по использованию вашего решения
- материалы про максимизацию выгоды от использования вашего продукта.
Альтернативный способ — собрать всю семантику (Wordstat, KeyCollector), структурировать ее и писать статьи под каждый семантический кластер. Этот вариант даст больше покрытие по ключевым словам, но материал будет не так хорошо структурирован как в 1 варианте.
В любом случае у вас в итоге должна появиться карта контента, которую вы будете использовать как план создания полезных материалов для вашего потребителя.
Как привлечь трафик. Основные каналы:
- SEO сайта. Обязательно необходимо все настроить базово на сайте (внутренняя поисковая оптимизация).
- Видео в youtube. Если возможности позволяют, то это хороший способ конкуренции в ТОП 10 Гугла и Яндекса по ключевым запросам
- Контекстная реклама Директ и Adwords - используйте только точечные настройки. Идти широким фронтом в этих системах будет крайне дорого. Используйте их в первую очередь для ретаргетинга.
- Внутренняя реферальная система. Если у вас действительно ценный сервис, то пользователей будет относительно несложно привлечь к тому, чтобы они делились информацией о сервисе с другими. Особенно если вы их простимулируете выгодными предложениями и скидками на ваш продукт.
- Социальные сети. Все зависит от вашей целевой аудитории. Пробуйте охватить узким таргетингом. Если он показывает низкий результат, то скорее всего расширение таргетинга только ухудшит показатели.
- Оффлайн реклама и работа с партнерами. Не стоит забывать и про эти способы. Вы можете привлечь партнеров через оффлайн.
- Внешние площадки с вашим контентом. Вы можете распространять свой контент на известных площадках и светиться на различных мероприятиях, где бывает ваша целевая аудитория.
Обработка потенциального клиента
Руководитель продукта должен точно знать, что делать с потенциальным клиентом. По какой дорожке он должен пройти — от момента 1 касания до полного закрытия всех отношений с ним.
Что включает в себя эта дорожка:
- первичный сбор информации и передача информации лиду
- коммерческое предложение
- сделка
- выполнение обязательств
- выявление и обработка дополнительных потребностей
- отзывы, рекомендации
В случае сервиса этот процесс будет немного отличаться:
- первичный визит сервиса
- изучение сервиса
- начало работы с сервисом
- получение фиксированного результата или ценности от сервиса
- возврат на сервис
- привыкание к сервису
Создание программных продуктов. Реализация продукта
Первое решение: Выбрать способ создания продукта — Разработка vs Готовый продукт vs Полуфабрикат.Посмотрите нашу статью, сравнивающую облачные сервисы, разработку на заказ и готовые продукты.
- Разработка — это долго, дорого, множество ошибок, но зато вы можете развивать продукт в точности под свои потребности и обходить ограничения готовых продуктов.
- Готовый продукт - быстро, относительно дешево, мало ошибок. Сложно менять и кастомизировать, в будущем могут возникнуть проблемы с производительностью и невозможностью дальнейшего развития (например, появился у вас новый филиал, а в программе не заложен такой функционал).
- Полуфабрикаты. Это платформы, которые позволяют быстро делать некие решения под свои требования. Имеют свои ограничения, но их можно обходить и развивать продукт под себя.
Если решения нет, то пробуем делать на какой-либо готовой платформе.
Если нам нужно что-то сильно специализированное с широкими возможностями изменения, то делают с нуля по полному стеку разработки.
Мы занимаемся именно полуфабрикатами. У нас есть платформа, на которой мы создаем готовые решения, которые в будущем можно адаптировать и развивать под себя.
Варианты работы с подрядчиком разработки
- инхаус (найм в компанию) - самый дорогой вариант, надо постоянно платить и чем-то занимать людей по 8 часов в день, сложно проверить квалификацию (если внутри нет технического специалиста), лучше всего контроль сроков.
- компания-подрядчик. Для серьезного долгосрочного варианта считаю что это оптимальным вариантом. Юридические обязательства по договору. Если возникает простой на проекте - то можно заморозить отношения и работы на проекте (что невозможно с работником). Скорее всего никуда не пропадут, как это может сделать физическое лицо. Есть свой менеджер проекта, который помогает координировать проект.
- фрилансер-подрядчик. Дешевле всего. Придется выполнять роль менеджера для фрилансера. Может внезапно пропасть. Если побочная загрузка и это скажется на сроках вашего проекта. Скорее всего все делаем сам, от чего может страдать качество (но если он может это все делать хорошо, то будет все быстро двигаться).
- Определяем первую версию для внедрения (список пользовательских историй в беклоге)
- Получаем общую начальную оценку по проекту от исполнителя по срокам и бюджету
- Согласовываем и подписываем договор об оказании услуг
- Определяем задание на первый этап (ТЗ в деталях) + определяем точную смету этапа и календарный план проверок по этапу.
- Проводим проверку в контрольных точках + обновляем беклог проекта (новые идеи, изменение статусов, детализация будущих задач).
- Проводим приемку этапа и переходим к следующему этапу.
Поиск и выбор подрядчиков на различные работы
Ключевые моменты по поиску исполнителей- Чтобы найти хорошего исполнителя, нужно иметь хороший выбор кандидатов (не думайте что из одного кандидата вы сможете найти одного хорошего исполнителя).
- в идеале лучше обойтись без подрядчика, если это возможно (поиск исполнителя - это головная боль и траты. Убрать исполнителя из проекта - еще более сильная головная боль).
- Нельзя заткнуть дыру в проекте еще большим количеством людей. Чем больше людей, тем сложнее всем этим управлять и тем больше энтропии.
- Если вы ищете одиночных исполнителей, то создавайте проект на fl.ru либо подавайте вакансию на hh.ru.
- Если вам нужна компания, то ищите в поисковиках по узким тематическим запросам (т.е. в точности что вам нужно, а не “создание сайта недорого”).
Что важно учесть при поиске исполнителя
- пишите все максимально конкретно и и точно. Так вы сможете сразу отсеять неподходящих. Не “требуется программист”, а “Требуется программист ABCD 4.5 с поддержкой баз данных QWE 5+”.
- в заявке в явной форме напишите кто вам точно не подойдет
- в заявке напишите, что должен указать кандидат в ответном письме (фильтруем неадекватных людей, которые не читают вашу заявку).
- Не приукрашивайте условия (только если к вам никто не идет можно сделать условия более привлекательными).
- Предлагайте небольшое тестовое задание (или выставление коммерческого предложения по вашему заданию) и проверяйте в первую очередь исполнительность (если исполнительность сильно страдает в начале, то с чего бы ей улучшиться потом?).
- С помощью другого исполнителя, которому вы доверяете
- Поспрашивать по деталям проектов, которые он делал (вы сможете понять участвовал ли он в них или нет).
- Спросить в деталях как он будет решать вашу задачу и какие идеи у него есть на этот счет. Детальный прозрачный план-смета - основа хорошего этапа.
- Давать задания на проверку человеческих качеств - порядочность и честность, исполнительность, аккуратность и т.д.
- Почитайте статьи про онбординг
- Изучите хорошо возможности площадок fl.ru и hh.ru с точки зрения работодателя.
- Почитайте пару статей на тему Основные правила дизайна, юзабилити
- Продвижение. Напишите начальную структуру своей карты контента
- Продажи. Напишите свой процесс обработки потенциального клиента.
- Напишите свое объявление на поиск программиста под ваш проект
- Напишите свое объявление и тестовое задание на поиск продвижения под ваш проект
- Определите ключевые подходящие качества людей в вашей команде и как вы планируете их проверить.
- Реализация продукта. Найдите подходящие готовые решения для создания своего продукта.
- Реализация продукта. Определите в деталях состав первой версии продукта (т.е. что должно быть внедрено в эксплуатацию в первичном виде)
- Дизайн. Определите точнее свой концепт дизайна, основываясь на описании целевой аудитории своего продукта.
- Дизайн. Критически просмотрите свои макеты, насколько они соответствуют правилам хорошего дизайна? Что можно улучшить?
Ввод в эксплуатацию
Ввод в эксплуатацию — это не просто “Поехали!"
Что необходимо сделать на этапе ввода в эксплуатацию:- Сменить все пароли, проверить еще раз кто к чему имеет доступ
- Проверить, что все переведено в боевой режим (а не тестовый)
- Убрать все тестовые данные
- Определить регламент по профилактике основных объектов (сервер и т.д.)
- Настроить резервное копирование
- Занести в Google Calendar ключевые даты по продлению домена, оплаты хостинга, продление ssl сертификата и т.д.
- Настроить систему мониторинга падений сайта (Uptimerobot.com — бесплатный сервис)
- Настройка счетчиков веб-аналитики
- Проверка скорости работы в Google Pagespeed
- Проведение аудитов SEO (можно использовать инструменты типа Seolik)
- Зарегистрировать сайт в Google и Яндекс Webmaster
- Пополнить все необходимые балансы (СМС и прочее)
- Подготовить документацию для пользователей
- Проверить готовность всех страниц с текстовым контентом: лендинги, правила пользования, политика конфиденциальности, о компании и т.д.
- Хорошо бы провести нагрузочный тест с реальным объемом данных в базе данных.
- Проверьте работоспособность ключевых форм на сайте и желательно создать регламент периодической проверки их работоспособности (1 раз в неделю).
Допустим, вы все сделали, можно запускать проект. Теперь вам необходимо проработать следующие вопросы:
- Проводить периодический анализ данных по веб-аналитике. Первое время вы можете смотреть каждое посещение в вебвизоре. Это даст вам много пищи для размышлений насчет того, что можно улучшить в вашем продукте.
- Осуществлять мониторинг проблем: могут быть ошибки в коде, почта может не работать, сервер может падать, могут быть критичные ошибки SEO. В начале эксплуатации продукта лучше быть чуть больше параноиком. Вы можете просто не знать, что у вас проблемы и думать, что клиент не идет просто потому, что продукт ему не интересен. А на самом деле у вас просто мобильная версия очень кривая и ничего не работает.
- Плотный контакт с потребителем. Ваша задача — как можно раньше получить обратную связь по вашему продукту от потребителя. Используйте свою базу лояльных заказчиков для данной активности. Также обеспечьте оперативное реагирование на чат техподдержки сайта. В нашем случае мы используем телеграм чаты: кто-то написал на сайте — это попадает в чат-телеграм и есть возможность оперативно ответить.
- Работа с трафиком — закупка рекламы, организация ретаргетинга, мероприятия по seo.
Адаптация пользователя
Мало привлечь пользователя — его надо еще адаптировать и привязать к сервису. В идеале он должен просыпаться и тянуться за телефоном, чтобы посмотреть что в вашем сервисе творится (ну в общем как обстоит с социальными сетями и мессенджерами).
Необходимо вернуться к сториборду первого контакта пользователя и сравнить план (сториборд) и реальность (вебвизор). Надо понять, почему возникают отличия и подкорректировать свой сториборд, либо внести изменения на сайте, чтобы реальный процесс был приближен к сториборду.
Важно, чтобы пользователь в кратчайшие сроки получил ценность от использования вашего сервиса. Если этого не произойдет, например, он просто не нашел подходящей ссылки, то очень вероятно, что вы потеряли его навсегда. Уберите все лишнее, ничто не должно мешать пользователю как можно быстрее получить свой профит.
Особый интерес вызывает возврат посетителя. Пользователь пришел на сайт, что-то посмотрел и ушел. Как его вернуть?
- Отправка полезной информации на почту. Это не должен быть СПАМ. Это может быть либо выгодное предложение, либо уведомление о важном для пользователя событии на сайте (новое сообщение), либо интересная аналитика по сервису.
- Ретаргетинг. Вы можете догнать пользователя через ретаргетинг. Именно так делают к примеру банки. Зайдите на сайт любого банка и вы скоро заметите, что реклама банка вас будет преследовать везде.
- Звонок по качеству обслуживания. Вы можете напомнить о себе через заботу о качестве и между делом предложить следующий шаг для более глубокого знакомства с вашим продуктом.
Привлекать пользователя гораздо дороже, чем его удержать. Если бы социальные сети не удерживали пользователей, а постоянно привлекали, то они давно бы разорились. Вы видели где-то в сети рекламу ВКонтакте? Удержание должно стать одной из главных ваших ключевых идей.
Как стимулировать пользователя более активно взаимодействовать с сервисом? Игрофикация. Создавайте специальные счетчики, рейтинги, бейджи, шкалы наполненности профиля, анимированных персонажей.
Пользователь не должен заскучать, у него должна быть четкая и простая мотивация совершить следующее действие. Люди не любят незавершенные действия. Напоминайте им специальными показателями прогресса, что они не до конца заполнили профиль или не до конца описали проект на аукционе.
В более сложном варианте можно создавать квесты для пользователя, но это потребует серьезной проработки игры и глубокого понимания мотивации и особенностей вашей целевой аудитории.
Еще лучше если вы сможете вовлечь пользователя во взаимодействие с другими пользователями на фоне игрофикации. Посмотрите мобильное приложение для караоке Starmaker — вы сразу окунаетесь в водоворот событий и взаимодействия с другими пользователями. Это сделано на высшем уровне. И потом обратите внимание на то, как они вас пытаются вернуть в приложение.
Важно выработать привычку пользоваться вашим продуктом. Это достигается за счет регулярности и простоты использования. На эту тему есть прекрасная книга Н. Эяль «На крючке».
Развитие продукта
Неразвивающийся продукт скорее всего быстро зачахнет и закроется.У вас должен быть подробный краткосрочный план по внедрениям новых возможностей в продукт, а также вы должны иметь общее видение (или долгосрочный план) того как будет развиваться продукт в целом, без проработки отдельных мелких деталей.
Не стремитесь объять необъятное. Двигайтесь итеративно. Внедряйте только то, что действительно имеет смысл для потребителя и добавляет ценности вашему продукту.
Соотнесите с видением продукта каждую новую возможность. Откажитесь от “классных“ идей, которые идут вразрез с концепцией продукта.
Каждая возможность продукта — это ответ на боль потребителя продукта. Если возможность особо ничего не облегчает потребителю, может она не нужна? Хотя бы просто отложите ее до будущего рассмотрения (возможно это станет со временем болью).
Беклог — это центральный документ развития вашего продукта. Фиксируйте все возможности продукта в нем. Ставьте приоритеты и планируйте изменения.
По поводу идеализма и стремления к совершенству при создании продукта — тут двоякий момент. Все знают пример Стива Джобса, который был ультра идеалистом (по крайней мере, так видится из книг). Где-то он был прав, где-то перегибал и довольно сильно.
Мое мнение: в ключевой идее вашего продукта вы должны постараться добиться максимальных результатов (конечно, учитывая те ресурсы, которые вам доступны).
Если вы терроризируете свою команду пытаясь усовершенствовать несущественные моменты для потребителя, то скорее всего вы просто сжигаете попусту время и другие ресурсы.
Избегайте вкусовщины. Отталкивайтесь от данных и обратной связи потребителя (с критической фильтрацией). Вы — не великий дизайнер, у вас нет какого-то уникального чувства вкуса. Идите от потребителя и постарайтесь реализовать то, что ему нужно, а не удовлетворяйте свой творческий голод в виде вкусовщины по дизайну продукта.
Ну и последнее — культ прототипных решений. Не пытайтесь делать крупные возможности сразу. Сначала сделайте прототип или даже макет. Покажите потребителям, соберите обратную связь. Может так получиться, что вы сделаете большой функционал в системе, а он никому не будет нужен и более того, усложнит жизнь пользователя (например, система будет работать медленнее чем раньше, или станет менее стабильной).
Рекомендуем посмотреть наши статьи о том сколько стоит содержать сайт и как развивать сайт.
Советы
- Прочитайте У. Айзексона «Стив Джобс» и «Инноваторы». В первой книге очень хорошо изложен концептуальный подход закрытой системы и как он был реализован в Apple. Вторая книга рассказывает об истории технологических свершений в области вычислительных машин.
- Прочитайте Н. Эяль «На крючке». Вы будете хорошо понимать,как формируется привычка использовать тот или иной продукт.
- Посмотрите сервис UptimeRobot
- Изучите по статьям и видео как использовать Вебвизор
- Используйте мобильное приложение starmaker. Отследите, как они адаптируют вас в социальной караоке-сети, и как они вас возвращают в приложение.
- Попробуйте измерить скорость сайтов (своих или любых других) с помощью Google PageSpeed
- Добавьте в чек-лист ввода в эксплуатацию пункты, специфичные для вашей ситуации.
- Проработайте анкету вопросов лояльным потребителям. Что вы хотите у них выявить? Как вы будете использовать эту информацию?
Следующая публикация
Нет комментариев