Работа над продуктом/ продуктами
Критерии успеха продукта
1 – Наличие растущего рынка (самое главное).
2 – Команда. Команда должна быть крутой, сработанной и с взаимодополняющими компетенциями.
3 – Качество продукта и сам продукт.
Создание нового продукта
Шаг 0. Создаем команду из специалистов способных запустить продукт.
Знания и навыки необходимые для вывода нового продукта на рынок
- Design Thinking
- Маркетинг и методы анализа рынка
- Подходы к анализу конкурентов
- Проектное управление (гибкие методологии Scrum, Kanban)
- Аналитика, продуктовые KPI
- Сильные организационные навыки
- Уверенные навыки фасилитации рабочих встреч
- Начальные навыки активных продаж если есть в команде сильный продажник, если нет, то нужны сильнные навыки.
- Use Cases
- User Stories, JTBD
- CJM
- Желание поработать круглосуточно ближайшие пол года
Шаг 1. Анализ предметной области. Рынок, видение, стратегия, концепт.
Предварительный этап проработки идеи
Этап принятия решения ввязываемся или нет в активную проработку идеи (1 – 2 недели по паре часов в день; 2% работы над проектом)
- Анализ, сбор информации о “мире”, предметной области. Откуда брать идеи о том, что делать? (2 – 3 дня с перерывами на протяжении недели, чтобы было время отвлечься и уложить информацию)
- Обзор прессы, отчетов венчурных фондов, новостных заметок.
- Обзор и анализ нормативно правовых документов в предметной области.
- Обзор мнения “экспертов”, “лидеров мнений”, просто громких чуваков в области или предметной области. Обзор и поиск трендов и моды в предметной области. Обзор тренд сеттеров. Подписка и мониторинг тематических групп в фейсбуке и телеграмм в предметной области.
- Обзор открытых маркетинговых исследований в области.
- Динамика развития области за последние 5-10 лет. Финансовые показатели области в целом.
- Определение основных “проблем” и “узких мест” для пользователей в предметной области.
- Анализ какие альтернативы решения есть сейчас. Как сейчас решают свои проблемы пользователи, включая офлайн решения и самые не очевидные и никак не связанные с IT.
- Анализ стартапов/ продуктов предметной области за рубежом и у нас. Даже далеких от первоначальной идеи просто в предметной области. Анализ объема инвестиций в стартапы, динамика развития, отчеты инвесторам, проверка динамики развития по систем сравнительного анализа конкурентов.
- Анализ трендов и посещаемости разделов и продуктов на наших ресурсах.
- Анализ трендов поисковых запросов
- Поиск знакомых из предметной области и сбор общего видения ситуации. Вопросы “на кухне” к учредителям или людям с опытом в предметной области, сфере бизнеса, о том, что они думают об идее.
- Опрос пользователей (пока можно просто окружения) как они решают свои проблемы в предметной области.
- Анализ конкурентной среды, свободности и занятости рынка Владивостока, Дальнего востока, Новосибирска, России. Продумываем теоретические варианты масштабирования, чтобы сразу понимать есть ли шанс масштабироваться. Если зайдем в область с кем будем конкурировать.
- Прикидываем объем рынка в людях, которые сталкиваются с обозначенными проблемами в предметной области. Пока достаточно поверхностно на основе выбранного рынка и ЦА регионов.
- Ищем развалившиеся/ закрывшиеся/ умирающие продукты в предметной области. Читаем, ищем инфу, почему не взлетели. Находим основателей и читаем их твиттер, фб, колонки, персональные сайты, интервью прессе и т.д. Можно просто списаться и узнать почему не взлетело и спросить советов и видения развития области.
- Если вдруг рынок свободен, “очевидная” идея не реализована и нет конкурентов, то скорее всего (99.9%) идея – говно. Найди почему!
- Анализ готовности процессов в команде, проверка достаточности компетенций команды к работе над созданием нового продукта
- Общее понимание процесса работы каждой профессии в предметной области. Кто чем должен заниматься.
- Понимание и аналитика групповых динамик в существующей команде. Потянут ли они вообще большие проекты/ задачи. Или у них никогда не было опыта групповой работы над задачами.
- Анализ наличия нужных людей в команде, прикинуть сможешь ли ты сам закрыть недостающие компетенции, на что можно будет забить и что можно попробовать отдать на аутсорс договорившись с другими отделами, командами.
- Формирование первоначального видения для продукта. (1 день)
- Описываем основные проблемы, болевые точки, чаяния пользователей, которые будем закрывать продуктом.
- Обозначаем основной рынок и перспективы масштабирования (есть, нет.). Объем рынка в людях.
- Обозначаем объем рынка в деньгах.
- Описываем политическую и юридическую ситуацию в регионе/ области. Насколько сильно гос. регулирование, “московское лобби”, связи и т.д.
- Определение с первоначальной идеей. Общее видение бизнес модели будущего продукта: B2B2C, C2B2C, B2C, (B2B – почти всегда не ввязываемся, так как это низко маржинальная история)
- Пинч идеи. Попробуйте рассказать идею “на кухне” и продать ее коллегам, менеджерам других отделов или просто знакомым друзьям. Слушайте критику и сомнения. Корректируйте доводы, собирайте еще информацию, проводи анализ, чтобы получилось переубедить.
- Обязательно попробуй “продать” видение и идею команде. Слушайте критику и сомнения. Корректируйте доводы, собирайте еще информацию, проводи анализ, чтобы получилось переубедить. Следи за эффектом “конформности” и “желания понравится” в команде. Скажет ли тебе команда прямо критику или просто забьет и подтвердит, что не скажешь лишь бы отстала/отстал.
- Принятие решения о начала работ.
- “Загорелась” ли команда и так же верит в успех как и ты или все считают, что эта идея “говно” и “галлюцинации менеджера”.
- Анализируем все описанное выше и принимаем решение: “Прыжок веры” Тут только интуиция, после собранной инфы все еще хочется этим заниматься и осталась ли решимость и вера в успех. На этом этапе можем забить и выкинуть все наработки. Или повторить все несколько раз в произвольном порядке.
Основной этап проработки продукта
Принятие решения будем ли упарываться в разработку или забьем. ( 2 недели, 1-2 месяца активной работы, если делать большие MVP (нужно время, чтобы накопить данные); 10% работы над проектом)
- Проведение продуктовых исследований. Создание MVP без разработки
- Переформулируем проблемы, которые лежат в основе видения в гипотезы
- Прорабатываем качественные и количественные эксперименты по подтверждению/ опровержению гипотез
- Customer Development. The Mom Test.
- Опросы пользователей на наших ресурсах (главная ВЛ/Хаб, Дром, новости, офф)
- Создание тем на форумах с ЦА, общение с пользователями в группах соц. сетей
- Аналитика и сбор данных по поведению пользователей на наших ресурсах (схожие направления)
- Создание MVP без разработки: фейковые кнопки, лендинги с предзаказом, ручная обработка заказов/услуг. Когда и какие гипотезы стоит проверять через MVP, а для чего это просто трата времени?
- Предпродажа и начальные договоренности с партнерами.
- Генерим и проверяем гипотезы по УТП
- Корректировка видения продукта.
- Уточняем проблемы, которые есть у пользователей и будет решать продукт
- Фиксируем проверенные гипотезы с которыми будет строить бизнес модели
- Определяемся с ЦА, рынком
- Корректируем видение продукта
- Конкурентный анализ
- Набросок стратегии развития продукта, согласование с целями компании (как ты представляешь себе цели)
- SWOT анализ
- Стратегия голубого океана
- Operational Excellence, Customer Intimacy, Performance Superiority Strategies
- Product centred – Customer centred strategy (Long tail strategy)
- Определение бизнес модели
- Подбор бизнес модели (Lean Bussiness Model Canvas, Ostervald Model Canvas)
- По выбранной бизнес модели просчитать юнит экономику, получить начальные метрики
- Просчитать или найти инфу по стоимости лида, сделки.
- Каналы продвижения. Решаем откуда и за сколько будем брать трафик. Прогнозы сколько трафика откуда планируем привлечь.
- Условно бесплатные каналы для нас. Наши ресурсы.
- SEO
- Контекст и cpc, таргет
- Ну и остальные каналы
- Фин анализ для бизнес модели
- Анализ рисков
- Организационные – это риски, связанные с ошибками менеджмента компании, ее сотрудников; проблемами системы внутреннего контроля, плохо разработанными правилами работ, то есть риски, связанные с внутренней организацией работы компании или команды.
- Рыночные – это риски, связанные с нестабильностью экономической конъюнктуры: риск финансовых потерь из-за изменения цены, риск снижения спроса, неверно просчитанная бизнес модель.
- Юридические – это риски потерь, связанных с тем, что законодательство или не было учтено вообще, или изменилось пока делали проект; риск некорректно составленной документации, договоров, оферт и пр.
- Корректировка стратегии, бизнес модели
- Готовим документ в wiki:
- Background and strategic fit для компании, как соотносится с целями компании
- Видение продукта
- Исследования ЦА и их проблем. Customer Development, количественная аналитика.
- Анализ текущего состояния рынка
- Конкурентный анализ
- Сегментация аудиторий. Каналы продвижения. Откуда будем брать трафик на проект?
- Фин. анализ
- Основные продуктовые KPI и количественные прогнозы на основе данных. Прогнозируемые KPI для сравнения потом с фактическими.
- Презентация видения и стратегии команде, обоснование для учредителей. Корректировка видения и стратегии продукта на основе фидбэка.
- Принимаем решение будем ли упарываться в разработку. На этом этапе можем забить и выкинуть все наработки. Или повторить все несколько раз в произвольном порядке.
Шаг 2. Вывод продукта на рынок
Планирование работ по созданию первой версии
Требования, прототипирование, оценка затрат по созданию. ( 1 неделя активной работы; 10% работы над проектом)
- Сбор, анализ, постановка, описание требований для задач с командной разработки
- Выделение ролей системы
- Описание use cases для каждой роли
- Наброски эпиков, user stories(JTBD)
- Выделения критериев успеха: Макро и микро конверсии по историям.
- Создание интерактивного прототипа, wireframe
- Уточнение, нормальное проработка user stories
- Добавляем в план работы по:
- Настройке аналитики и учету метрик
- Деплою кода в прод, настройку инфраструктуры
- Задачи необходимые для начального привлечения трафика.
- SEO
- Лендинги на которые будем гнать трафик
- Рекламные виджеты на проектах
- Предпланирование и начальные эстимейты в SP с тех. лидом
- Составление графа зависимости историй
- Переписать/ доработать требования по фидбэку тех. лида
- Выделение MVP продукта
- Проводим с командой MustDo, ShouldDo, CouldDo c пользовательскими историями. Выкидываем на ShouldDo, CouldDo большинство задач. С MustDo – это то, с чем будем запускаться. Это и есть наше MVP, которое мы выкатим на прод и будем показывать миру.
- Все что можно делать вручную – делаем вручную. Выдрачиваем только основной сценарий пользователя!
- Привлечение партнеров, продажи. Составление договоров.
- Анализ договоров и оферт конкурентов. Представиться желающим подключиться и посмотреть как проходит процесс подключения у партнеров.
- По use cases составить набросок договора, оферты
- Активные продажи, переговоры, выезды к партнерам, обсуждение условий, нюансов, переделка договора
- Согласование договора, оферты с юристами компании
- Заключение первых договоров
- Подготовка плана запуска продукта, офлайн часть
- План сбора фидбэка от пользователей (КЦ, телефоны, системы сбора фидбэка, почты, т.д.)
- Наброски инструкций, скриптов работ для внедрения
- План рекламной компании
- Доп. договоренности что будет покупать, отдавать на аутсорс на первом этапе.
- Планирование этапов работ с командой
- Фиксируем, вспоминаем с командой Definition of Done. Для новых продуктов – это только прод в закрытом режиме!
- На iteration planning бьем эпики на задачи
- Задачи на кодирование
- Задачи под деплой и настройку окружения
- Задачи под тестирование
- Задачи под сбор аналитики и метрик
- Задачи по оптимизации скорости работы системы
- Эстимейтим задачи с командой (planning poker)
- Составляем карту зависимостей задач
- Разбиваем на спринты, определяем параллельность работ и количество человек, которые могут одновременно работать над созданием продукта
- Получаем примерное время работы и время релиза. Умножаем на исторический фокус – фактор. Добавляем спринт на реал тайм тестирование и фиксы.
- По SP считаем бюджет фичи.
- Принятие решения о начале работ. Старт разработки. Старт итерации.
- Смотрим на время разработки, бюджет разработки в деньгах – решаем будем делать или нет! Не дорого ли получается работа? На этом этапе можем забить и выкинуть все наработки. Или повторить все несколько раз в произвольном порядке. Или еще уменьшить функционал.
Работы по созданию продукта
- Мониторинг и контроль за разработкой. Как переложить его на процесс и тратить минимум времени?
- Спринты
- Epic Burndown Chart
- Переэстимейты перед каждым спринтом
- Самые рискованные, сложные, неизвестные вещи – вперед
- Дейли
- Ретро по корректировке процесса раз в 2 спринта.
- Подготовка промо материалов, рисовка баннеров, виджетов
- Настройка счетчиков аналитики
- Составление, согласование, подписание документов:
- Договора
- Оферты

Правда жизни: Если тебе не стыдно за то, что ты выкатил пользователям – ты запустился слишком поздно!!! Говно и палки на этом этапе наше все
Запуск проекта, фаза слабоумие и отвага
Важно! При запуске проекта весть фидбэк пользователя только на менеджеров. Никаких прослоек в виде КЦ или клиент менеджеров. Все косяки пользователей и партнеров вручную должен решать запустивший проект менеджер.
- Планерка по запуску
- Распределение ролей, кто за что отвечает
- Брейнсторм, что может пойти не так. Работа с рисками, risk management plan. Кто и как разруливает реализовавшиеся риски.
- Мониторинг аналитики и показателей.
- Разбор фидбэка пользователей. Решение проблем пользователей. Составление реестра предложений и фидбэка, откуда потом будем черпать идеи, что может быть не так.
- Разбор фидбэка партнеров. Решение проблем партнеров. Составление реестра предложений и фидбэка, откуда потом будем черпать идеи, что может быть не так.
- Перевод команды из работы по спринтам в режим херачим все что видим (назовем этот режим – Канбан)
- Привлекаем всех кого можем на правку багов. Летит критичный фидбэк – кто не правит другую кричную багу, тот и правит этот фидбэк. Быстро, можно говнокодом. Оперативно разруливаем косяки, которые забыли и не учли при запуске в функционале, договорах, взаимодействии с пользователями/ партнерами.
Первые результаты после запуска проекта
- Сравнение фактических KPI продукта с прогнозируемыми. Пытаемся понять почему мы не дотягиваем. Очень редко, что стреляет сразу Мы точно сперва не дотягиваем.
- Составление реестра гипотез (HADI), почему не дотягиваем до KPI. Идеи берем из:
- Качественных источников: Фидбэки пользователей и партнеров, прямое общение с пользователями, NPS, вебвизор или наблюдение за тем как пользователи пользуются продуктом.
- Количественных данных по воронке продаж, аналитике, сравнение реальных KPI с прогнозируемыми.
- Запускаем серии экспериментов по проверке гипотез. Фейковые кнопки, ручные фиксы, имитации с минимумом разработки. Как находим подтверждение в данных – уже пилим стабильную фичу. Смотри часть “Работа над фичей”
Шаг 3. Вывод продукта на стадию роста
Работа над конверсией основных сценариев/ воронок
- CJM
- Метрики воронок
- АБ эксперименты
Успокаиваемся, когда начинаем видеть рост DAU, WAU. Убеждаемся, что все норм с удержание (retention) пользователей и они не “утекают”.
Привлечение пользователей
Аналитика каналов привлечения пользователей, стоимость привлечения пользователей, конверсии, Retentions, Assisted Conversions и роль канала в них…
Канал продвижения | Стоимость | Эффективность с точи зрения прямого привлечения трафика (1-5) | Для чего подходит лучше?Понятно, что в начале все каналы дают новых пользователей. | Как подготовить? | Метрики |
---|---|---|---|---|---|
Ссылка в левом меню на VL | Бесплатно | 3 | Довозвраты существующих, легкий способ найти полюбившийся продукт на ВЛ или ДВХабНовых пользователей можно получить чуть чуть в начале, если выделить ссылку | Согласовать с Егором установку ссылки и написать на SUPVL, чтобы ребята поставили. | |
Виджет на главной VL | Условно бесплатно. Тратим ресурсы компании на создание виджета. | 3 | Довозвраты существующих, легкий способ найти полюбившийся продукт на ВЛ или ДВХаб | ||
Виджеты на ресурсах | Условно бесплатно. Тратим ресурсы компании на создание виджета. Ресурсы разработки, но небольшие | 2 | Узнаваемость и привлечение новых пользователей.Для довозвратов долго держать не получится, нужно приучать пользователей искать напрямую продукт.Для рекламы наших продуктов во Владивостоке и Хабаровске. При выходе на Россию можно заюзать Дром и Фарпост в других городах. | Согласовать вид виджета с Титус и рекламным отделом, чтобы не перебивать платную баннерную рекламу.Согласовать установку с владельцем продукта, разработать виджет, замерить CTR, utm метки | CTR виджетаМикро и макроконверсии с канала |
Баннера | Условно бесплатно. Тратим ресурсы компании, что в целом дороже, чем просто деньги тратить. Ресурсы дизайна, но небольшие | 1 | Узнаваемость и привлечение новых пользователей.Для довозвратов нужно будет постоянно обновлять баннера и посылы.Для рекламы наших продуктов во Владивостоке и Хабаровске. При выходе на Россию можно заюзать Дром и Фарпост в других городах. | CTR баннераМикро и макроконверсии с канала | |
SEO | Условно бесплатно. Тратим ресурсы компании, что в целом дороже, чем просто деньги тратить | 4. Долго, так как придется на протяжении полугода настраивать и следить за эффектом. | Довозвраты пользователей по брендовым запросам продукта.Привлечение новых, если ключевики не выкупаются агрессивно конкурентами | ||
Google Adwords и Яндекс Директ | Платно, дорого. Но зато быстро получаем целевой трафик | 5 | Для привлечения новых платящих клиентов, когда точно определена макроконверсия на продукте. Покупка, подписка, просмотр телефона и т.д.Есть смысл подключать канал при хорошей (direct) конверсии и удержании. Когда продукт начал работать. | Согласовать бюджеты с Егором. Договориться с отделом интернет-маркетинга о запуске компании.Настроить аналитику по ключевым словам в Гугле и Яндексе: макро и микро конверсии, чтобы можно было корректировать кампании.Подключить Директ и AdWords к настроенным счетчикам | CTRПозиции словСтоимостиМикро и макроконверсии по ключевым словам и группам |
MyTarget | Платно, дорого. Но зато быстро получаем целевой трафик | 5 | Согласовать бюджеты с Егором. Договориться с отделом интернет-маркетинга о запуске компании. | ||
Наши группы в cоц. сетях | Бесплатно | 2 | Новые пользователи и больше для того, чтобы в общем узнали о продукте | Договориться с владельцами группы | |
Чужие группы в соц. сетях | Платно за деньги | 3, если подобрать правильную тематическую группу | Новые пользователи и больше для того, чтобы в общем узнали о продукте | ||
Новости | 4 | Новые пользователи и больше для того, чтобы в общем узнали о продуктеРазовое привлечение, либо нужно новости публиковать на постоянку, но нужны инфоповоды. | |||
Посты на форумах | 2 | Новые пользователи и больше для того, чтобы в общем узнали о продукте | |||
Youtube | ? | Новые пользователи и больше для того, чтобы в общем узнали о продукте | |||
Кросс-пиар с партнерами. Ролики в кинотеатрах, брендирование стадионов. | 1 | Чисто узнаваемость бренда, так как прямых переходов получишь не много.Постоянное фоновое напоминание о продукте | |||
Growth Hacking техники | Много ресурсов и денег компании на разработку и эксперименты. | 5 | |||
Участие в тематических встречах/ выставках/ конференциях… | Платно | 1 – для пользователей4 – для партнеров | |||
Почтовые рассылки | Условно бесплатно | 3 | |||
BTL (Раздача листовок) | Платно | 1 | |||
Баннерная офлайн реклама на щитах по городу | Платно, дорого | 2 | |||
Реклама в лифтах (жилых домов, офисов) | Платно | 3 | |||
Объявления на фарпосте в тематических разделах | Бесплатно. Виртуальный счет ушедший в минус на барахолке за деньги не считаем Но при фин. учете можем | 2 |
Работа над фичей
- Определение стадии ЖЦ продукта
- Продуктовый анализ и исследования. Обоснование начала работ.
- Сбор и анализ требований
- Планирование этапов работ с командой
- Принятие решения о начале работ. Старт разработки
- Мониторинг и контроль. Как переложить его на процесс и тратить минимум времени?
- Внедрение и запуск фичи
- Мониторинг аналитики и показателей
- Доработка? Как понять, что мы все сделали?
Pivot? Как понять, что мы все сделали и можно переводить на поддержку из активной разработки?
- Выводы. Итоги. Ретроспектива по итерации
Перевод продукта/фичи на поддержку из активной разработки. Поддержка продуктов на стадии рост-зрелость.
- Автоматизация бизнес – процессов, снижение затрат на поддержку.
- Организация мониторинга основных KPI продукта, дашборды.
- Передача операционных задач в отдел поддержки. Проверка документации и инструкций. Доработка инструментов поддержки по надобности. Все зависит от задач: активное привлечение и продажи можно передать в рекламу, поддержку оперативную пользователей и партнеров в КЦ, работу с партнерами клиент менеджерам. По загрузке отделов и возможности взять на себя доп. работы нужно договариваться с каждым из руководителей отделов отдельно. Обязательно организовать общую группу с коллегами для поддержки и ответов на оперативные вопросы. Если ты передаешь дела в другой отдел – еще пол года минимум вы будете отлаживать процессы и нужно активно помогать коллегам разобраться с новой работой.
- Организация сбора фидбэка от внутренних заказчиков/ отдела поддержки.
- Тушение пожаров.
Тушение пожаров
- Идентификация источника проблемы
- Действия по минимизации дискомфорта для пользователей и партнеров
- Координация работ по фиксу проблемы
- PostMortem анализ. Брейнсторм, что сделать чтобы не допустить повторения
- Принимаем действия по недопущению повторения
