🗯79. Особенности проверки гипотез для маркетплейсов Давайте сегодня рассмотрим отличия в тестировании гипотез для двухсторонних и трехсторонних продуктов. 1️⃣ Двухсторонние продукты Самые распространенный вид продуктов. Сразу напомню, что есть утилитарные и функциональные двусторонние продукты, но это разделение мы сейчас не будем использовать. 🟠Роли: для наших целей важно, что есть собственнник продукта (владелец) и клиенты продукта. И взаимоотношения выстраиваются линейно, собственник vs клиенты. 🟠Проверка гипотез: для проверки мы должны найти клиентов, привлечь их и т.д. Собрав пул клиентов мы транслируем определенный месседж и по реакции клиентов на него интерпретируем их восприятие продукта. на самом деле мы добиваемся исполнения клиентами ключевого действия относительно продукта, которое заложено в нашу стратегию продаж. 🟠Ресурсы: у нас должны быть ресурсы для проверки гипотез - в общем случае время и средства на привлечение клиентов. 2️⃣ Трехсторонние продукты Здесь уже все существенно сложнее. Большее количество ролей, требуется в 2-3 раза больше ресурсов для проверки гипотез. 🟠Роли: есть исходная роль собственника продукта (владельца) и есть роли клиентов и исполнителей (поставщиков). 🟠Проверка гипотез: осуществляется гораздо сложнее. Мы должны проверить гипотезы между клиентом и решением (1), между исполнителем и решением (2) и взаимодействие между клиентами и исполнителями (3). Проблема осложняется тем, что если (1) и (2) мы еще можем проверить независимо друг от друга, то (3) мы сможем проверить только вместе: когда у нас уже на платформе есть пул или клиентов или исполнителей (поставщиков). То есть для этой проверки до привлечения другой стороны (условно, клиентов) мы должны уже обеспечить присутствие первой стороны (условно, поставщиков) в продукте. ⚫️Собираем клиентов, потом привлекаем поставщиков. Или собираем поставщиков, потом привлекаем клиентов. 🟠Ресурсы: трата ресурсов существенно возрастает. Нужно заложить двойной бюджет на проверку гипотез и бюджет на первоначальный сбор какой-либо из сторон. Есть возможности сделать это относительно небольшим бюджетом, но не нужно рассчитывать, что это осуществляется вообще без ресурсов. То есть бюджет (и действия) на сбор одной стороны и бюджет на привлечение второй стороны. 💯 Если рассматривать варианты проверки (1) или (2), то с точки зрения трудозатрат они чаще всего не эквиваленты. Скорее всего проблема одной стороны плюс-минус очевидна (прозрачна) и не требует серьезных проверок (не нужно подтверждать саму проблему только отдельные детали ее существования), а вот проблематика второй стороны не так уж очевидна и требует проверки по полной программе. ‼️ Более сложный случай - ключевая проверка (3). Как уже упоминалось, нам нужно сначала "физически" собрать одну сторону в продукте и, только потом, через затраты на рекламу привлечь в продукт вторую сторону для проверки их взаимодействия друг с другом через продукт. Трехсторонние продукты - парный танец, мы можем привлечь деньгами кого-то (одну сторону) на платформу, но без присутствия второй стороны в продукте, первая сторона - уйдет с нее. Обратите внимание, что времени на такой сбор - крайне мало, никто не будет ждать по пол-года в ожидании каких-либо действий в продукте. ⚠️ Пример: мы можем привлечь клиентов в маркеплейс через рекламу, но если там не будет поставщиков, которые закрывают запросы по поставкам, то клиенты оттуда уйдут и больше не вернутся - они получили негативный опыты (UX). Очень важно держать в голове опыт клиента в продукте, зачем возвращаться туда, где ничего не было? ⚠️ Пример: дейтинговая платформа. Мы можем привлечь на платформу юношей или девушек, но если там не будет партнеров противоположного пола, то клиенты будут уходить из продукта и мы зря потратим деньги на привлечение клиентов. ‼️Вывод: в трехсторонних продуктах не возможно реализовать или проверить ценность без вовлечения двух сторон одновременно. Резерв ресурсов на первоначальный сбор участников продукта - обязателен.