Выстраивание грамотной стратегии развития интернет-продукта с помощью метрик и OKR

Использование информации, собранной с помощью метрик — правильное решение для онлайн-бизнеса. На практике работа с аналитическими данными может выглядеть примерно так:

1. Определите точный объем затрат. Рассчитайте, сколько средств вам понадобится для организации бизнес-процессов.

2. Изучите статистические данные, произведите расчеты основных показателей и составьте прогноз спроса на определенные товары в интернет-магазине. Параллельно рассчитайте объем прибыли.

3. Учитывая прогноз, определите, сколько средств предстоит вложить в закупку товара. Понимая разницу между доходом и совокупным объемом затрат, можно будет подсчитать сумму, которую предстоит потратить на развитие онлайн-магазина и привлечение покупателей.

4. Обязательно рассмотрите метрики поведения пользователей на сайте интернет-магазина. Выявите проблемные части веб-ресурса, оперативно устраните недочеты. Если все хорошо, клиенты успешно взаимодействуют с онлайн-магазином, целесообразно выделить средства на внедрение новых эффективных решений.

5. Внимательно изучите целевую аудиторию. Разработайте идею рекламной кампании, определитесь с платформой для размещения и рассчитайте, сколько денег для этого потребуется. Запускайте рекламу только на тех площадках, которые приводят вам потенциальных клиентов.

6. Собирайте информацию по метрикам систематически. При необходимости сразу же реагируйте на ситуацию, вносите изменения и составляйте объективные прогнозы. Насколько часто целесообразно проводить анализ данных по метрикам, каждому предстоит определить опытным путем. Но на стартовом этапе работы делать это нужно как можно чаще. Старайтесь не реже одного раза в неделю изучать соотношение прибыли и расходов, каждый день следить за эффективностью рекламных кампаний. Мониторинг данных по метрикам можно проводить реже, когда бизнес-проект устойчиво «встанет на ноги».

Лайфхаки, которые необходимы для перехода в продакт-менеджеры или аналитики

В последнее время приходит очень много обращений и запросов на консультации по вопросам, как переходить в новую профессию. Открыт к этим запросам, а потому и собрал несколько лайфхаков:

⁃ Если есть возможность, лучше не подсаживаться на «денежную иглу» неплохой работы, а сразу потратить время, подготовиться и устроиться на лучшую. Считаю, что так можно расти сильно быстрее. Если нет такой возможности, то нужно учиться работать по 60-80 часов в неделю

⁃ Проходить собеседования — отдельный самостоятельный навык, который отличается от навыка работать по специальности. Я при поиске первой работы продактом прошел более 150 отборов. Между ними много общего, но прокачивать их надо по-разному.

⁃ Чтобы не перегореть за время активной подготовки к новой работе, лучше идти в комфортном темпе. По этой причине можно готовиться самостоятельно, а, например, не идти на курсы.

⁃ Обратите внимание на самое важное. Это может прозвучать банально, но аналитическое мышление и problem-solving — возможно, самые важные вещи в работе аналитиком и продактом

⁃ Не будьте токсиками, будьте людьми, с которыми приятно работать, которым не страшно задать любой, даже самый глупый, вопрос, с которыми комфортно решать проблемы. Помогайте заинтересованным людям в тематических сообществах, и, возможно, кто-то из них станет вашим коллегой в будущем, и вы вместе будете делать клёвый продукт.

⁃ Основная проблема - это необходимость практики. Даже начинающему специалисту недостаточно читать книги и смотреть обучающие видео, чтобы улучшать свои навыки. В стартапе, если вы готовы с головой погрузиться в работу и брать большое количество задач. На стажировке, это отличная возможность войти в профессию: к вам приставят более опытного продакта, который делегирует вам часть своих обязанностей. В пет-проекте (мой выбор, кстати),что позволяет пройти все стадии развития продукта: от создания идеи и MVP, до поиска точек роста и новых возможностей. И курсы, где все необходимые знания собраны в единую программу, рассчитанную на поэтапное освоение профессии. Большинство курсов построены с упором на практику, а поддержка ментора позволит разобраться с непонятными вопросами.

Интересен также опыт как перешёл в IT в 30 лет продуктовый аналитик Avito Алексей Авраменко — читайте по ссылке.

Подборка книг для роста в сфере анализа требований

1. «Разработка требований к программному обеспечению» Карл Вигерс и Джой Битти
Классика среди всех книг по разработке требований. В книге подробно даются процессы сбора, выявления, обработки требований и работы с ними. По каждому процессу показан пример работы.
Благодаря книге можно получить определенные методы, которые помогут сократить сроки разработки и уменьшить количество ошибок. Книга довольно трудна для первого прочтения, поэтому начинать лучше с книг под пунктами два и три.

2. «Психбольница в руках пациентов, или почему высокие технологии сводят нас с ума» Алан Купер
Алан Купер первым заговорил о том, что проектирование продуктов должно осуществляться до непосредственной разработки и является этапом первостепенной важности. Большинство продуктов функционирует и взаимодействует с пользователями только на основе задумки создателей, игнорируя реальные потребности использования.
Из книги следует мысль, что для продукта повышение качества взаимодействия важнее, чем снижение издержек. Для конечных пользователя удобный продукт всегда предпочтителен, чем неудобный многофункциональный.

3. «UX-дизайн. Практическое руководство по проектированию опыта взаимодействия» Расс Унгер и Кэролайн Чендлер. Отличная книга для совсем начинающих специалистов. В книге даются основы основ проработки бизнес-идеи, определения требований, проведению интервью, подготовке документации и формированию взаимодействия пользователей и продукта.
Книга помогает понять, с чего следует начать в первую очередь, как одни этапы разработки продукта взаимодействуют с другими. Очень много примеров и шаблонов. Практически сразу же после прочтения книги можно приступить к работе.

4. «Современные методы описания функциональных требований к системам» Алистер Коберн
В оригинале книга называется "Writing Effective Use Cases", что наиболее полно отражает ее суть. В книге описаны методы и примеры создания юз кейсов на основе практического опыта автора. Книга помогает понять, как использовать юз кейсы при описании сложных многофункциональных систем и вариантов взаимодействия с ними.

5. «Пользовательские истории. Искусство гибкой разработки ПО» Джефф Паттон
Книга рассказывает про пользовательские истории (юзер стори) как о методе описания требований к проектируемому продукту.
Пользовательские истории довольно просто и доходчиво дают понимание заказчику, команде, пользователям о задачах и функциях разрабатываемой системы. Пользовательские истории находятся на более высоком уровне абстракции. На их основе удобно описывать сценарии взаимодействия (юз кейсы).

Как управлять удаленной командой в текущих реалиях

Принцип 1. К каждому сотруднику — свой подход. Оцените зрелость вашей удаленной команды. В ней одновременно могут быть и опытные специалисты с высокой самомотивацией, которые понимают цели и задачи бизнеса, и рядовые сотрудники, с которыми важно работать внимательнее. Проранжируйте членов команды с точки зрения их опыта, уровня мотивации и ответственности, чтобы найти баланс дисциплины и самоконтроля, необходимый каждому из них.

Принцип 2. Уважайте культурные особенности региона
В каждой компании есть корпоративная культура, которая задает определенные рамки коммуникации и подходы к работе. Однако помимо этого существует так называемый национальный культурный код, который не меняется десятилетиями, если вообще меняется. И самый умный выход — повернуть национальное многообразие удаленной команды в пользу бизнеса. Направляйте нужных людей для решения нужных задач и комбинируйте противоположные точки зрения.

Принцип 3. Поддерживайте коммуникацию с удаленными командами убедительнее, чем со стандартными
Многочисленные исследования подтверждают, что наши слова и голос отвечают только за половину передачи сообщения. Другая половина — невербальные сигналы: поза, положение относительно собеседника, выражение лица, взгляд. Очевидно, что в этом плане дистанционная коммуникация неполноценна, и чтобы сделать ее эффективной, нужно больше усилий. 

Принцип 4. Выстраивайте горизонтальные связи
Удаленная команда тем эффективнее, чем крепче горизонтальные связи внутри нее. Здесь нет отличия от стандартных команд, но с одним исключением: с удаленной командой ситуация обстоит сложнее, ведь сотрудник офиса в Волгограде вряд ли выпьет утренний кофе с коллегой с Урала. Чтобы нивелировать это, вовлекайте разных членов своей команды в кросс-функциональные проекты — если необходимо, выдумывайте их. Такие проекты не только позволят сотрудникам лучше узнать бизнес, но и повысят мотивацию.

Принцип 5. Даже если команда удаленная, организуйте личные встречи по крайней мере раз в год
Составьте рабочее расписание, в которое будет включена сессия знакомства. Кроме нее включите в повестку дня воркшопы или брейнсторминг, которые помогут членам команды сформулировать глобальные цели и обсудить проблемы. И, конечно, важен неформальный тимбилдинг: совместные развлечения сплачивают команду. 

Совершенно новый вызов - релокации, встал перед руководителями IT-команд в прошлом году. Когда команда релоцируется, то неизбежно меняются подходы к управлению.

Как ускорять А/В-тестирование

В своих выступлениях я часто говорю, что А/В-тест - достаточно долгий инструмент для проверки гипотез. Но есть лайфхаки, как его можно ускорить:

1. Определите ключевые метрики: перед началом тестирования определите, какие метрики будут являться ключевыми для оценки результатов. Это поможет сократить объем тестирования и сфокусироваться на наиболее значимых метриках. Определите наиболее важные изменения: сфокусируйтесь на наиболее значимых изменениях, которые могут повлиять на ключевые метрики. Это поможет сократить время на разработку и тестирование.

2. Уменьшите размер выборки: уменьшение размера выборки поможет ускорить А/B-тестирование, но необходимо убедиться, что результаты остаются статистически значимыми.

3. Используйте CUPED - это метод, который позволяет уменьшить влияние искажений на результаты исследования, связанных с различными факторами, которые могут повлиять на конечный результат. Он основан на использовании контрольной группы, которая исключена из эксперимента, но используется для сравнения с тестовой группой и оценки эффекта воздействия на тестовой группе. Кроме того, метод CUPED использует методы разности в различных периодах времени для более точной оценки эффекта воздействия.

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

5. Отсеките выбросы. Выброс - это экстремальные значение в данных, которые находятся далеко за пределами других наблюдений. Например, в приложении пользователи тратят в среднем от 8 до 12 долларов, и внезапно появляется пользователь, который заплатил 100 долларов. Выбросы в данных А/Б-тестов увеличивают дисперсию метрики и длительность теста, а также смещают оценку среднего. Это может привести, в итоге, к неверному решению о принятии проверяемой гипотезы

6. Используйте многоразовые шаблоны: создание многоразовых шаблонов для элементов дизайна и контента сайта или приложения может значительно сократить время на разработку и внедрение изменений.

7. Используйте предварительное тестирование: проведите предварительное тестирование, чтобы проверить, какие изменения наиболее эффективны, прежде чем начать полноценное A/B-тестирование

Ликбез про Graceful degradation

- Graceful degradation - это подход к разработке веб-приложений, который предполагает, что если какая-то часть функциональности приложения не работает или не поддерживается в браузере пользователя, то приложение должно продолжать работать и отображаться, но с упрощенной или частичной функциональностью.

- В контексте веба graceful degradation — это способность сайта адаптироваться под браузер, который несовместим с различным функционалом, использованным на сайте. Помимо наиболее распространенных случаев, таких как отключенный JavaScript или отключенные изображения, это может быть, например, не поддерживаемое CSS-свойство. В результате сайт упрощается, но остается доступным.

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

- Чтобы реализовать этот подход, необходимо провести анализ возможностей браузеров, которые используют пользователи, и определить, какие функции могут быть не поддержаны.
При этом, важно не забывать о том, что любая функция, которая не работает в полной мере, должна быть явно указана пользователю, чтобы он не пытался использовать недоступную функциональность и не был разочарован в работе приложения.

- Нужно хорошо знать и изучать алгоритмы graceful degradation логики, которые используются в фичах. Тут в Авито рассказали историю: после релиза новой фичи на платформе заметили аномалию — жители маленького дагестанского села за неделю внезапно создали 45 тысяч новых резюме. Чтобы выяснить, что пошло не так, пришлось устраивать целое расследование.

QA-инженер компании Алёна Луцик рассказал на vc.ru про этот опыт. Разбирать ошибки всегда полезно, в автотестах важно завязываться не только на факт создания данных, но и на их корректность, а graceful degradation логика также решает.

Все подробности — по ссылке.

Механики масштабирования Agile и Scrum

1. Создание нескольких команд: если объем работы слишком большой для одной команды, можно создать несколько небольших команд, каждая из которых будет отвечать за свою часть проекта. Каждая команда будет работать по методологии Scrum, а вся работа будет координироваться и согласовываться между командами.Каждая команда работает по методологии Scrum, а команды взаимодействуют друг с другом на регулярных встречах, называемых Scrum of Scrums. На этих встречах команды обсуждают свой прогресс, координируют работу и идентифицируют возможные проблемы.

2. Скрамбан: Scrum и Kanban можно объединить в одном методологическом подходе, который называется скрамбан. Этот подход позволяет справляться с более сложными проектами, где требуется гибридный подход. Scramban позволяет гибко управлять рабочим процессом, учитывая особенности каждой части проекта.

3. SAFe (Scaled Agile Framework): Это методологический подход, который разработан для масштабирования Agile на большие проекты. В рамках SAFe проект делится на несколько подпроектов, каждый из которых реализуется своей командой. Все команды работают в рамках общей стратегии и выстраивают связи друг с другом.

4. LeSS (Large-Scale Scrum): Этот подход разработан для масштабирования Scrum на большие проекты. В LeSS команда делится на несколько небольших, каждая из которых работает по методологии Scrum. Однако, в отличие от SAFe, в LeSS каждая команда является полноценной Scrum-командой, которая выполняет все этапы Scrum.

5. Еще одним подходом к масштабированию Agile и Scrum является использование методологии Nexus. Nexus представляет собой каркас, разработанный на основе Scrum, который позволяет объединить несколько Scrum-команд для работы над одним большим проектом. Nexus определяет роли, артефакты, правила и практики, которые позволяют командам работать вместе на более крупных и сложных проектах.

Как ChatGPT развивает продактов

1. Больше и быстрее читать
Сделать саммари любой статьи, вышедшей до 2022 года. Например, можно освоить всего Пола Грэма за вечер. Особенно полезно для проходных текстов, где смысла на абзац, а воды на 16 страниц.

2. Выбирать и сравнивать курсы
“Найди три лучших курса по пользовательскому поведению и сравни их, выведи достоинства и недостатки в таблице”. Дает толковые варианты.

3. Решать кейсы и повышать насмотренность
“Я готовлюсь к интервью на позицию продакта. Дай мне кейс, я решу, а ты проверишь”. Возможность, прокачиваться в разных областях и отраслях.

4. Обстукивать идеи
“Я хочу проверить гипотезу Х способом Y c целью Z. Скажи, какие слабые места ты видишь”. Очень неглупый собеседник с дельными вопросами.

5. Тестировать себя и находить зоны развития
“Я продакт-менеджер и развиваю продукт Х в отрасли Y. Протестируй меня, чтобы проверить мои знания и выяснить, где подтянуть их”. Взгляд со стороны на свои точки роста.

А еще с помощью ИИ можно создавать крутые тексты, яркие офферы, презентации, КП. Собирать лендинги и сайты без специальных навыков, готовить питчдеки, считать объем рынка и юнит-экономику; автоматизировать рутинные задачи. Вопрос лишь в том, как обучить ИИ под себя и быстро получать качественные ответы, а не воду.

Важные примеры SQL-запросов для пользовательской аналитики

1. Запрос на выборку данных о пользователях - запрос на выборку данных о пользователях может помочь в понимании характеристик аудитории, таких как пол, возраст, местоположение и т.д.

SELECT COUNT(DISTINCT user_id) as unique_users, gender, age, geo_location FROM user_profiles GROUP BY gender, age, geo_location;

2. Запрос на выборку данных о поведении пользователей - запрос на выборку данных о поведении пользователей может помочь в понимании, как пользователи взаимодействуют с продуктом.

SELECT behavior_type, COUNT(*) as total_events FROM user_behavior GROUP BY behavior_type;

3. Запрос на выборку данных о трафике - запрос на выборку данных о трафике может помочь в понимании, как пользователи приходят на сайт, какие каналы трафика наиболее эффективны и т.д.

SELECT channel, COUNT(DISTINCT user_id) as unique_users FROM user_traffic GROUP BY channel;

4. Запрос на выборку данных о конверсии - запрос на выборку данных о конверсии может помочь в оценке эффективности продукта и выявлении проблемных зон.

SELECT step_name, COUNT(*) as total_visits, SUM(CASE WHEN next_step_name IS NOT NULL THEN 1 ELSE 0 END) as total_conversions FROM user_funnel GROUP BY step_name;

Хотите научиться писать такие запросы за 1,5 месяца? Приходите на курс Яндекс Практикума. Там сможете перейти от неподъёмных отчётов в Excel к автоматизированной работе с метриками и исследованиями. Вместо сложных фильтров и долгих поисков — запрос, который выгрузит, обработает и проанализирует данные сам.

Доступ к материалам бессрочный — вы всегда сможете найти шаблон решения для сложной рабочей задачи.

Записывайтесь на занятия, чтобы тратить меньше времени на рутину - Записаться

Как DevOps может помочь продакт-менеджеру

- Более быстрое и безопасное внедрение изменений. DevOps позволяет автоматизировать процессы разработки, тестирования и выкатки продукта, что ускоряет его запуск и снижает риск возможных проблем.
- Мониторинг и анализ производительности продукта. DevOps позволяет в режиме реального времени отслеживать работу продукта и собирать аналитику о его использовании, что помогает продакт менеджеру принимать решения по улучшению продукта.
- Оптимизация процессов разработки. DevOps может помочь выявить узкие места в процессах разработки и эксплуатации продукта, что помогает оптимизировать их и снизить затраты на разработку.
- Улучшение коммуникации между командами. DevOps улучшает коммуникацию и сотрудничество между различными командами в рамках процесса разработки и эксплуатации продукта, что помогает повысить качество и скорость разработки.

Об этом можно также узнать в книгах и ресурсах:

1. В статье Применение DevOps-аутсорса на разных этапах жизненного цикла продукта от Станислава Тибекина, CVO компании Nixys.

Особенно рекомендую начать погружение с этой практической статьи, она будет полезна не только в плане привлечения аутсорсинга. Когда появляется потребность в DevOps-команде, перед бизнесом всегда встают конкретные вопросы: “А всё-таки, как решить мою проблему — нанять DevOps-специалиста в штат, использовать аутстафф или отдать проект на аутсорс? Есть ли четкие критерии для выбора? Что будет эффективнее?”

2. "The Phoenix Project" автора Г. Кима, К. Бехра и др.

Данная книга описывает историю компании, которая сталкивается с техническими проблемами, и как внедрение DevOps позволило ей изменить свой подход к управлению IT и достичь успеха.

3. "Continuous Delivery: Reliable Software Releases through Build, Test, and Deployment Automation" автора Д. Фарли и Д. Хамбле

Данная книга объясняет, как внедрение DevOps-практик и автоматизации процессов позволяет создавать и доставлять программное обеспечение непрерывно, быстро и надежно.

4. "Accelerate: The Science of Lean Software and DevOps: Building and Scaling High Performing Technology Organizations" авторов Н. Форсгрен, J. Humble и G. Kim

В этой книге авторы рассматривают научный подход к изучению DevOps и объясняют, как организации могут создать высокопроизводительные команды и процессы с помощью DevOps-практик.

Еще одна подборка ресурсов для улучшения английского языка

• Курсы от команды Across English - где учат делать ежедневную работу продакта на английском языке
• Muzli Inspiration by Invision – еженедельный дайджест с подборкой вдохновляющего дизайн-контента.
• The Hustle – письма по утрам с новостями бизнеса и технологий, которые могут пригодиться тебе именно сегодня.
•Nir and Far – рассылка о психологии потребительского поведения от автора книги «На крючке» Нира Эяля
• Канал Стэнфордской высшей школы бизнеса
• Канал Y Combinator
• Второй канал Y Combinator: The Vault с нестандартным контентом  о жизни стартапов, интервью с основателями, прямыми трансляциями и т.п.
• Канал Уэса Буша, автора книги «Product-Led Growth»
•This is Product Management - подкаст, в котором продакт-менеджеры из разных компаний делятся своим опытом и знаниями о продакт-менеджменте. В подкасте затрагиваются такие темы, как разработка продукта, управление командой, маркетинг и продажи.
•The Product Experience - подкаст от двух продакт-менеджеров, в котором они обсуждают темы, связанные с продакт-менеджментом, и делятся своими личными историями и опытом. В подкасте затрагиваются такие темы, как дизайн продукта, управление командой, маркетинг и многое другое.
•The All Turtles Podcast - подкаст от стартап-студии All Turtles, в котором обсуждаются технологии, дизайн продукта и инновации. В подкасте также говорят о том, как разрабатывать продукты, которые решают реальные проблемы людей.
•Build - подкаст от интернет-магазина Webflow, в котором говорится о том, как создавать продукты и бизнесы. В подкасте также обсуждаются технологии, дизайн, маркетинг и другие темы, связанные с продуктами.
•Product to Product - подкаст от компании Roadmunk, в котором продакт-менеджеры и другие эксперты делятся своим опытом

Основные методики для быстрого роста компании и трекинга

- HADI-циклы — методика проверки гипотез, которая состоит из 4 этапов: постановка гипотезы, действия по ее реализации, сбор данных о результатах работы гипотезы, выводы на их основе. Наглядно показывает, как действия команды влияют на результат — это позволяет быстро тестировать идеи и отказываться от нерабочих.
- Приоритизация гипотез — ранжирование гипотез по потенциалу увеличения прибыли и скорости проверки. Помогает определить, какие из них стоит проверять в первую очередь, и выстроить последовательность шагов для системного достижения цели .
- Daily meetings — ежедневные планерки команды, цель которых — понять, что сделал каждый сотрудник за прошлый рабочий день, какие сложности у него возникли, что он собирается сделать за текущий день. Помогает скорректировать ежедневную работу членов команды, узнать о проблемах, которые возникают в процессе, предложить варианты решения.
- Customer Development — методология изучения потребностей потенциальных клиентов с помощью глубинных интервью. Помогает выявить инсайты, благодаря использованию которых можно увеличить ценность продукта для клиентов, средний чек, а в результате и пожизненную ценность клиента (Lifetime Value — прим.)
- ABCDX-сегментация — инструмент максимизации прибыли, помогает выделить самый маржинальный клиентский сегмент.
- Работа с «пайплайном» — инструмент диагностики продаж: помогает выстроить процесс продаж, увидеть, что его тормозит, и сократить цикл сделки.
- Design Thinking - методика, которая использует процесс мышления дизайнера для создания инновационных решений. Она помогает сосредоточиться на пользователях и их потребностях, а также на поиске новых возможностей для улучшения продукта.
- Lean Startup - методика, разработанная Эриком Рисом, которая позволяет минимизировать риски и издержки при запуске стартапа. Основная идея заключается в том, чтобы быстро создавать и тестировать минимальные жизнеспособные продукты (MVP), а затем собирать обратную связь от пользователей и основываясь на ней улучшать продукт.

Про венчурную аналитику

Метрики, которые точно надо раскрыть в рамках фин-модели или текущего трекшна продукта:
1. Monthly Recurring Revenue (MRR) - это метрика, которая показывает ежемесячный доход продукта от подписок или других повторяющихся платежей.
2. Customer Acquisition Cost (CAC) - это метрика, которая показывает, сколько денег тратится на привлечение одного нового клиента.
3. Customer Lifetime Value (LTV) - это метрика, которая показывает, сколько денег один клиент приносит продукту за весь период его использования.
4. Churn rate - это метрика, которая показывает, как быстро пользователи покидают продукт.
5. Gross Margins - это метрика, которая показывает разницу между доходами и затратами на производство продукта.
6. Net Promoter Score (NPS) - это метрика, которая показывает, насколько вероятно, что пользователи будут рекомендовать продукт своим друзьям и коллегам.
7. Conversion rate - это метрика, которая показывает, сколько пользователей, зашедших на сайт продукта, совершили желаемое действие, например, сделали покупку.
8. Run rate - это метрика, которая показывает, сколько продукт зарабатывает в месяц или в год на текущий момент, и как быстро он растет.
9. Burn rate - это метрика, которая показывает, сколько денег продукт тратит каждый месяц или год, и сколько времени у него остается до исчерпания финансовых ресурсов.
10. Market size - это метрика, которая показывает, какой рынок адресует продукт, сколько там потенциальных пользователей, и каков его потенциал для роста

Про венчурную аналитику рекомендую почитать:
-“Венчурный капитал. Как заработать на стартапах" - авторы Брэд Фельд, Джейсон Мендельсон
-“Стартап. Начните свой бизнес на собственные условия" - автор Эрик Рис
-“Венчурная инвестиция в России. Как создать и продать стартап" - авторы Дмитрий Куреев, Виктор Пономарев, Юлия Соловьева
-“Основы венчурного инвестирования" - авторы Пол Драпер, Пола Као, Рэнди Коул
-“Венчурный бизнес: от идеи до IPO" - автор Джейсон МакКензи
-“Путь венчурного инвестора" - автор Питер Тил
-“Венчурные инвестиции. Принципы и практика" - автор Реймонд Курцвейль
- "Как создать стартап, привлечь венчурный капитал и обогнать конкурентов" - автор Джеймс Скрамко
-“Венчурный капитал и риск" - автор Джозеф Гайнс
- "Сделки с венчурным капиталом. Как выйти на новый уровень развития" - авторы Александр Горохов, Алексей Попов, Алексей Черняк

Примеры MVP жизнеспособных продуктов

1. Uber. В изначальной версии приложение могло только соединять клиентов с водителями. Эта его простота и привлекла клиентов. А когда MVP продукта доказало свою состоятельность, появились все остальные функции, вплоть до семейного профиля, планирования поездок и возможности разделения тарифа. У многих стартапов возникают идеи, что чем больше возможностей — тем лучше. Но если бы у Uber всё это было с самого начала, клиенты не стали бы во всём разбираться. А так — компания получила множество данных для анализа, поняла, в каком направлении стоит развивать приложение, и сейчас превратилась в бизнес стоимостью $53 млрд.

2. Yahoo! Минимальным продуктом здесь была простая страничка со списком ссылок на популярные сайты. Это был вполне достаточный функционал, чтобы удовлетворить пользователей на ранних этапах интернета. А когда сайт приобрёл трафик и популярность, началась его адаптация и развитие. Сегодня это вторая по успешности поисковая система в мире с доходом $5+ млрд в год.

3. Snapchat. Сервис начинался максимально просто: быстрая маленькая утилита, позволяющая обмениваться сообщениями, которые удалялись бы через 10 секунд после прочтения. Когда в 2011 году на iOS была выпущена первая версия, из «продвинутых» функций в ней была разве что загрузка изображений. Сейчас у продукта 230 млн пользователей каждый день, а компанию оценивают в $35 млрд.

4. Instagram - первый MVP Instagram был небольшим приложением для iPhone, которое позволяло пользователям делиться фотографиями и применять к ним фильтры. Это приложение было создано за несколько недель и было доступно только на iOS. Благодаря большому спросу на приложение и положительным отзывам пользователей, Instagram быстро расширил свой функционал и стал доступен на других платформах.

5. WhatsApp. В 2009 году Ян Кум и Брайан Эктон решили создать мобильную телефонную книгу, которая бы показывала статус контакта: доступен, занят, на совещании и так далее. Контакты пользователей этой книги получали соответствующие всплывающие уведомления. Однако вскоре они стали использовать статусы для общения. Тогда создатели выпустили новую версию WhatsApp с функцией отправки сообщений.

6. Amazon — один из самых успешных примеров минимально жизнеспособного
продукта. Джефф Безос основал маркетплейс в начале 1990-х, и первоначально это был онлайн-магазин с книгами. Для решения он выбрал MVP одной функции: сначала Безос провел мозговой штурм и составил список товаров, которые можно было бы продавать в интернете. Из 20 различных вариантов в финал вышли 5 продуктов: видеокассеты, книги, программное обеспечение, компьютеры и компакт-диски.

Чек-лист, как спроектировать платформу для экосистемы

1. Определите цель и ценности экосистемы. Необходимо понимать, какие цели хотите достичь и какую ценность предлагаете вашим пользователям.
2. Изучите потребности пользователей и рынка. Исследуйте рынок, понимайте потребности пользователей и анализируйте данные, чтобы создать платформу, которая наиболее эффективно удовлетворит потребности пользователей.
3. Разработайте стратегию взаимодействия между участниками экосистемы. Определите, какие участники будут использовать вашу платформу и как они будут взаимодействовать между собой.
4. Сформулируйте план продукта и определите функциональные требования. На основе стратегии и целей платформы необходимо разработать план продукта и определить необходимые функциональные требования.
5. Выберите технологические решения и архитектуру. Рассмотрите различные технологии, которые помогут реализовать платформу, и определите необходимую архитектуру.
6. Разработайте MVP (минимальный жизнеспособный продукт). Создайте минимальный жизнеспособный продукт, чтобы протестировать гипотезы и получить обратную связь от пользователей.
7. Проведите тестирование и оптимизацию. Проведите тестирование MVP, соберите обратную связь от пользователей и оптимизируйте продукт.
8. Запустите продукт и продолжайте его улучшать. После запуска продукта необходимо продолжать его улучшать, чтобы удовлетворять потребности пользователей и достигать целей экосистемы.
9. Разработайте стратегию масштабирования. Определите, как будет происходить масштабирование платформы и как вы будете решать проблемы, связанные с ростом экосистемы.

На какие метрики обратить внимание при внедрении игрофикации?

1. Коэффициент участия (Participation Rate) – показатель, отражающий, сколько пользователей активно участвуют в игровых элементах продукта или сервиса.
2. Коэффициент удержания (Retention Rate) – показатель, отражающий, сколько пользователей возвращаются в продукт или сервис после того, как они уже взаимодействовали с ним.
3. Коэффициент конверсии (Conversion Rate) – показатель, отражающий, сколько пользователей выполняют желаемые действия (например, покупают товар или регистрируются) благодаря игровым элементам.
4. Коэффициент задействования (Engagement Rate) – показатель, отражающий, насколько активно пользователи взаимодействуют с игровыми элементами продукта или сервиса.
5. Коэффициент реферралов (Referral Rate) – показатель, отражающий, сколько пользователей привлекли новых пользователей в продукт или сервис благодаря игровым элементам.
6. Время взаимодействия (Time Spent) – показатель, отражающий, сколько времени пользователи проводят взаимодействуя с игровыми элементами продукта или сервиса.
7. Количество достижений (Achievement Count) – показатель, отражающий, сколько достижений пользователи получили благодаря игровым элементам продукта или сервиса.

Как адаптировать продажника или бизнес-лидера к новому продукту?

Адаптация менеджера по продажам к работе с новым продуктом может быть вызовом, особенно если новый продукт значительно отличается от того, с чем менеджер работал раньше. Ниже приведены несколько советов, которые помогут вам адаптировать менеджера по продажам к работе с новым продуктом:

1. Обучение: обучите менеджера по продажам новому продукту. Проведите серию встреч и тренингов, чтобы познакомить его с особенностями продукта и помочь ему понять, как продукт отличается от тех, с которыми он раньше работал.

2. Обновление материалов продаж: обновите материалы продаж, чтобы они отражали новый продукт. Это могут быть брошюры, презентации, видео и т.д.

3. Создание сценариев продаж: создайте сценарии продаж, которые помогут менеджеру по продажам лучше понять, как продавать новый продукт. Сценарии продаж могут содержать информацию о том, как презентовать продукт, как рассказывать о его преимуществах и как отвечать на возражения клиентов.

4. Поддержка: обеспечьте менеджера по продажам поддержкой и ресурсами, необходимыми для продаж нового продукта. Это может включать в себя доступ к экспертам продукта, обучающим материалам и технической поддержке.

5. Поддержка существующей клиентской базы: если новый продукт предназначен для существующей клиентской базы, обеспечьте менеджера по продажам поддержкой и ресурсами, необходимыми для общения с этими клиентами. Это может включать в себя создание специальных кампаний, персонализированные предложения и т.д.

6. Отслеживание метрик: отслеживайте метрики продаж нового продукта и используйте их для улучшения процесса продаж. Это может включать в себя анализ того, как менеджер по продажам представляет продукт, какие сценарии продаж работают лучше всего и т.д.

Две альтернативы А/В-тестам

Квази-эксперимент
Мы подбираем псевдо контрольную группу, например другой регион, если мы какой то оффлайн ритейлер и проводим эксперимент на каком то магазине, мы можем подобрать магазин/магазины в других районах,  в качестве такой  псевдогруппы. Про то так это делать, можно поговорить отдельно, сейчас мы верхне-уровнево пройдемся, потом у нас будет подробное рассмотрение с кейсами. Примеры: это differences-in-differences, реализация этого подхода синтетический контроль, например causal impact придумали ребята из гугла.

Одним из примеров квази-эксперимента может быть сравнение результатов продаж в двух магазинах, один из которых был обновлен и получил новый дизайн, а другой оставлен без изменений. В этом случае, исследователь не контролирует все условия, такие как расположение магазинов, демографические данные покупателей и другие факторы, но старается минимизировать влияние этих факторов на результаты исследования.

Квази-эксперименты могут использоваться в тех случаях, когда невозможно провести полноценный эксперимент, например, из-за ограниченности бюджета или сложности контроля всех факторов. Однако, они могут быть менее точными и допускать большее количество ошибок по сравнению с полноценными экспериментами.

Искусственный контроль
Следующий подход, это когда у нас нет возможности подобрать псевдо контрольную группу в виде региона, либо другого магазина. Здесь мы по историческим данным обучаем модельку прогнозирования временных рядов и у нас получается, как бы, две вселенные: что было бы, если мы ничего не выкатывали? (то есть до момента воздействия обучаем модельку), что было по факту? И по сути разница между этими двумя вселенными это эффект.

Моделирование: используется для создания моделей на основе данных для прогнозирования поведения пользователей или других параметров. Например, модель прогнозирования вероятности конверсии, основанная на исторических данных.

Анализ данных: анализ большого количества данных, собранных от пользователей, может помочь выявить паттерны и тренды в поведении пользователей и определить, какие изменения в продукте могут привести к улучшению метрик.

Пять ошибок при финансовом моделировании

⁃ Непонимание назначения финмодели. Если нужен финансовый план на следующий год, обязательно закладывайте возможность создания нескольких сценариев и функцию сопоставления реальных и планируемых данных. Если работаете над привлечением новых инвестиций, не забудьте четко описать все вводные параметры и логику сценариев – она для инвесторов интереснее текущих цифр. Если же важно понять, как функционирует бизнес с финансовой точки зрения, подумайте, как сейчас устроена компания, какие отделы уже есть, чтобы финмодель отражала реальность. Если подход к учету денежных потоков и построению модели расходятся, нужно либо принять ограниченные финансовые данные и попробовать изменить модель, либо изменить методику финансового учета. В стартапах это не так болезненно, как в крупных компаниях.

⁃ Неадекватные вводные параметры. Все финансовые модели строятся на базе различных вводных параметров, таких как объем рынка, себестоимость продукта, его цена и др. Количество параметров зависит от того, насколько подробная нужна финмодель. И здесь нет универсального варианта – в каждом случае важно найти баланс между сложностью, удобством и пользой. Слишком лаконичная модель не даст детального понимания происходящего в проекте, в то время как исчерпывающая модель с большим количеством вводных сможет хорошо описать бизнес, однако ее регулярное обновление будет занимать много времени. 

⁃ Говоря о вводных параметрах, нельзя забывать об их динамичности.
Я часто вижу, как в попытке быстро сделать расчеты фаундеры пишут формулы с реальными текущими значениями, а не с переменными, например выручка = 10$ (цена) х 1000 (количество пользователей). Но если завтра цена изменится, придется вручную все обновлять.

⁃ Неучтенный оборотный капитал. Дальше нужно выяснить, как новая модель влияет на состояние банковского счета. Этот момент часто упускается – команды сосредоточены на развитии продукта и общении с пользователями, и могут даже не догадываться, что денег у них осталось всего на пару месяцев. В первую очередь нужно сделать прогноз трат на следующие 1-2 года, сопоставить его с текущим счетом и вычислить период времени до момента, когда у стартапа закончатся деньги.

⁃ Отсутствие структуры. Все инвесторы хотят видеть детальный план, как будет расти клиентская база от месяца к месяцу, как будут меняться расходы и доходы. И если еженедельное планирование сильно обременяет, то ежегодная репрезентация скрывает важные детали. Месяц – оптимальный отрезок. Существует много шуток на тему community adjusted EBITDA – индикатора, разработанного WeWork для измерения чистой прибыли. Инвесторам важно видеть все издержки, прибыль, выручку, динамику роста клиентов и команды, чтобы поддерживать этот рост.

Фича за 30 минут. В GPT-чате

На разработку плана внедрения функции — например, регистрации на сайте — у продакта уходит 8-10 часов, если делать вручную. С gpt-чатом — 30 минут.

1. Пишем User Story
«Приведи пользовательские истории для регистрации на сайте»

2. Выставляем критерии успеха (User Acceptance Criteria)
«Напиши для каждой истории UAC»

3. Строим график разработки
«Для каждой истории дай последовательность реализации. Напиши, какие задачи можно выполнять параллельно»

4. Расставляем приоритеты
«Определи приоритеты на основе ценности для бизнеса и простоты»

5. Составляем план тестирования
«Создай план тестирования для пользовательских историй»

6. Задаем трекшн
«Какие ключевые метрики нужно отслеживать для функции регистрации»

Чек-лист нужна ли вам экосистема

Когда вы размышляете о наилучшей модели для управления бизнесом, вам следует рассмотреть возможность создания бизнес-экосистемы, если:

- Вы сталкиваетесь с непредсказуемой, но очень податливой бизнес-средой, которая требует от вас сотрудничества с другими игроками, чтобы сформировать или перестроить отрасль.

- Отдельные компоненты решения могут быть легко и гибко объединены, но необходим определенный уровень координации для поиска партнеров, определения их ролей и согласования их деятельности.

- Вы сможете извлечь выгоду из открытости, быстрого масштабирования, а также гибкости и устойчивости, которые предлагает экосистема.

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

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

- Экосистемы транзакций связывают независимых производителей товаров или услуг с клиентами через единую платформу. Например eBay соединяет независимых продавцов с покупателями. Uber позволяет пассажирам найти свободное такси. Upwork помогает компаниям искать внештатных сотрудников. Ценность такого типа экосистемы возрастает с количеством ее клиентов. Они даже могут стать производителями. Например, когда зрители на YouTube превращаются во влоггеров или арендаторы становятся арендодателями, выставляя свое жилье на Airbnb.