У многих есть такой друг-продакт, который придумал, как сделать звездолёт, когда пользователь хотел получить звонок курьера перед доставкой.

Привет! Я Анатолий Кульбацкий — директор по продукту (CPO) ГК «Везёт». Занимаюсь продуктовой разработкой 10 лет. Начинал в небольшом мобильном операторе «Интертелеком», где развивал дополнительные сервисы для абонентов (VAS), затем 5 лет работал в разных продуктовых ролях в «Яндекс.Поиске» и «Транспорте», а сейчас в агрегаторе такси.

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

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

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

Определимся с термином MVP.

MVP (minimum viable product или минимально жизнеспособный продукт) — это одна из первых версий продукта или функциональности, после запуска которой понятно, стоит ли дальше развивать продукт или нет. MVP подтверждает или опровергает гипотезу о необходимости продукта.

Шаг 0. «У меня есть идея»

Часто фича появляется в готовом виде от руководителя, от конкурентов, а иногда из «ясного» видения продакт-менеджера или другого сотрудника. Это не очень хорошо, но так устроена продуктовая жизнь. Успех MVP сильно зависит от «домашней работы», которую вы проделаете до запуска: изучения пользователя (customer development), проверки количественным исследованием и ранжирование в бэклоге. Часто эти этапы пропускаются, MVP выпускают с плохим результатом, и, получается, что компания «инвестировала в опыт».

Я рекомендую такой подход: метрика –> идея –> изучение пользователей –> количественное исследование –> и только потом начало работы над решением. Таким образом продакт снижает риски неудачного запуска и экономит деньги и ресурсы компании. Команде стоит брать в разработку функциональность и писать код после завершения продуктовой проработки. Идея ничего не стоит, важна её реализация.

Подробный материал о том, как устроен продуктовый процесс в «Везёт», недавно публиковал Александр Токмаков.

Итак, шаг 0 завершен. Ниже иллюстрация с более правильной последовательностью. Если начали с идеи, то ничего страшного, можно двигаться дальше.

Пункт 1. Метрика успеха

На сколько должна вырасти ключевая метрика продукта.

Метрика продукта — конверсия в покупку, retention, снижение затрат на одну итерацию покупки или услуги пользователю, снижение времени заказа, средний чек и т.д. в экспериментальной выборке или когорте. Метрика считается на пользователя. Очень подробно про продуктовые метрики стоит посмотреть в видео Ильи Красинского и почитать у Олега Якубенкова.

Какой рост ожидать? Если вы смелый продакт, то ставьте двузначное число процентных пунктов, если осторожный — однозначное. Но лучший вариант — научиться в ROI.

ROI — return on investment или окупаемость инвестиций. Вы вложили в фичу N руб. (ресурсы разработки, сторонние решения и тд) и получаете рост затрат на одного пользователя (Average Cost — AC) — вернули через рост продуктовой метрики и увеличили средний доход с — ARPU. Такой подход убирает много вопросов про продактов, которые «двигают кнопки».

Похожим, но менее точным является метод RICE — ранжирование фичей через аудиторию (reach), влияние на ключевую метрику (impact), уверенность в решении (confidence) и затратами для реализации (effort). RICE подходит для быстрой оценки новой идеи к бэклогу, но сложнее приводить к деньгами. Подробнее про RICE можно почитать в блоге Intercom и в блоге Itamar Gilad

Если метрика не вырастет или упадет, то MVP провалился, и затраты необходимо будет «списать», а фичу удалить из продукта. Не оставлять, не искать способ все исправить, а переходить к следующей гипотезе. Если вы оставляете части продукта без явного смысла для него, то в будущем необходимо будет поддерживать данную функциональность: тратить время на регрессии и обеспечивать ей определенный уровень надежности. Это будущие затраты, которые никогда не окупятся.

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

Проблемы с MVP без метрик начинаются после запуска. Поиск того, что выросло или как это измерить, приведет к «аналитическому параличу» — невозможности рассчитать и обосновать развитие фичи. Или ещё хуже, к «прыжку веры»: «Мы посчитать не можем, но верим, что через год это выстрелит»(с).

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

Пункт 2. Самая сильная гипотеза и самая сильная боль

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

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

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

Я рекомендую для «набора базовых сервисов» использовать модель Кано. Модель позволяет разложить фичи по следующим категориям: обязательные, привлекательные, удовлетворительные и неважные. Проводится исследование с помощью анкетирования.

Ошибка в этом месте может стоить дорого — отсутствие привычных фичей разозлит пользователя, и он не заметит ваше улучшение, а лишние фичи удорожают разработку. Определите рыночный «базовый набор» по составу MVP. Далее формируйте опросник и получайте веса для фичей. Если никогда не сталкивались с данной моделью, то рекомендую начать с этой статьи и дальше адаптировать ее для своего продукта. Данный шаг позволит не перенасытить MVP ненужными фичами и не делать звездолёт.

Пример. В Транспорте мы решали задачу передвижения пользователей из точки А в точку Б без своего автомобиля. В бэклоге были разные идеи про общественный транспорт, такси и велосипеды. При проработке задачи из исследования мы узнали, что у более 50% пользователей есть автомобильные права, и что они активно начинают использовать каршеринг в Москве. Так, в списке задач появился список функциональностей про каршеринг: машины на карте вокруг пользователя, время в пути, маршруты, бронирование внутри приложения и так далее. И самая большая боль у пользователей — свободная машина у нескольких каршеринговых компаний. Так, задача сузилась до отображения доступных авто на карте, выиграла у других задач и была реализована летом 2017 года.

Пункт 3. Конкурентное окружение

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

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

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

Пункт 4. Базовое качество

— Это что за ерунда у вас в проде болтается?

— Это MVP, не успели все доделать и решили так запускаться.

Я нередко встречаю ситуацию, когда про базовое качество не думали, а итоговый продукт низкого качества называют MVP. Как отличить очень плохой продукт от MVP?

Базовое качество MVP — это вероятность того, что пользователь сможет решить свою задачу с помощью MVP. Например: вероятность, что пользователь найдет в приложении свой автобус; увидит ближайшую каршеринговую машину и сможет ее забронировать; что авто или автобус приедут в то время, что вы показывали в приложении. Если для замера качества не хватает данных, то в первом запуске соберите эти данные, а потом последовательно переходите к замеру продуктовых метрик.

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

По моему опыту, в большинстве случаев достаточно выдержать около 80% метрики качества — при частоте использования раз в неделю и реже; 90% и выше — при более частотных кейсах. Совсем высоко и близко к 99% — если кейс ежедневный и многочасовой: приложение для водителей или приложение для работы операторов в колл-центре, где длительность смены 8 часов и его используют больше 20 дней в месяц. При значении метрики качества в 60% и ниже можно запускать, если у вас прорыв, вау-реакция при тесте прототипа, рынок без единого конкурента или все на рынке с низким качеством.

Если от вашего сервиса зависит здоровье и жизнь человека, на рынке есть регулирование — то базовое качество должно быть иным. Я бы не ожидал хороших пользовательских метрик в авиакомпании с 80% успехом перелета.

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

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

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

Пример: в приложении такси мы запускали предсказание времени подачи машины (на карте, до совершения заказа). Для проверки гипотезы мы использовали модель с 80% точностью, для предсказания +/-2 минуты. Мы сэкономили время на разработке более точной модели и запустили проверку гипотезы за две недели — увидели прирост конверсии в заказ MVP и запланировали улучшение точности.

Пункт 5. Проектирование интерфейса и прототип

Продакт смотрит в аналитике, как пользователи не могут найти функциональность и не понимают ее, и восклицает: «Какие же пользователи неразумные, неужели они не могут догадаться пойти в настройки, провалиться на 6 уровней, где явно стоит тумблер “Показывать слой”».

Поэтому проверяйте первые прототипы на пользователях: если есть UX-lab, то сходите туда с прототипами в Invision или Principle, если нет, то коридор, улица, курилка (курение вредит вашему здоровью), кафе с обедами и тд, это может быть любое место, где есть пользователи продукта. Если можете быстро сделать фейковые или заготовленные данные, делайте, но важно — быстро.

Сейчас, в период пандемии, тестируйте прототипы с помощью Skype или Zoom, в них есть функция поделиться экраном. Этот метод также подойдет для удаленных от своего рынка продактов и дистанционной работы. Искать респондентов можно в Facebook или на сайтах фрилансеров. За небольшую плату вы найдете людей, которые потратят час своего времени и расскажут вам, что и как устроено. Выборка может перекоситься и быть нерепрезентативной, но даже такой тест лучше, чем его отсутствие.

Что нужно для хорошего интервью:

• Используйте один и тот же скрипт для всех интервью.
• Не продавайте и не навязывайте свое решение.
• Меняйте прототип, если 3-4 раза подряд пользователи «спотыкаются» на вашем решении.
• Завершайте тестирование и изменение прототипа, когда будет минимально понятный уровень UI для решения задачи.

При этом на этапе тестирования важно отсечь «слабые» части сложной функциональности и приблизиться к уровню «палок и веревок», или минимальной функциональности. Это стоимость разработки, которая влияет на ваш ROI. Если на стадии тестирования прототипа у пользователей «с болью» нет заинтересованности или сложности с использованием, вероятность успеха снижается. Да, сложно собрать на тестировании прототипов репрезентативную выборку, но и быть «глухим» к сигналам не стоит.

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

Мне везло с продуктами — пользователей общественного транспорта и такси много, с поиском тоже все хорошо. Для каких-то минорных кейсов мы делали быстрый опрос в приложении и собирали группу в телеграмме/вотсаппе, созванивались и разговаривали.

Пункт 6. Замер

Очень большая ошибка не замерять метрики при запуске MVP или отложить замеры на поздние версии. Вы допускаете «прыжок веры» в продукте и прыгаете с мыслью, что сможете «хорошо приземлиться» через время. Без подтверждения данными — это очень опасная стратегия.

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

Самые точные результаты получают А/Б тестом. Но когда пользователей совсем мало и их долго собирать, можно смотреть по когортам в новом релизе, по сравнению с предыдущим. Против вас в этом случае может играть сезонность, влияние рынка, активность конкурентов. Данные эффекты лучше убираются А/Б тестом. В большинстве случаев, на уровне MVP должен быть виден эффект — вы должны получить статистически значимый результат улучшения.

Если слышите от команды или руководителей такие фразы как «не стало же хуже», «мы же не зря работали — ничего не испортили», «не, нам надо поднять качество, и тогда вжух, и как ракета полетит» –— остановитесь. Должно быть иначе: одна метрика выросла на столько, вторая — на столько — в итоге стало лучше.

Важный момент. Если метрика не выросла и не упала? Можно её оставить? В общем случае, нет. Одна из больших ошибок в моем опыте — «пинать дохлого осла, в надежде что побежит». Не побежит, если сразу видно, что изменений нет или ухудшение. Вы добавили функциональность в продукт, её надо поддерживать, а при переезде на новую технологию — переписывать (даже если сейчас оставить её условно бесплатно). То есть вы своим решением вкладываете деньги и ресурсы компании в фичу, которая не приносит пользы.

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

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

Для таких возражений: «не взлетело, выпиливаем», «ну если бы нормально шрифты/анимацию/на всю страну/на весь мир/точным предсказанием сделали — то взлетело бы», есть ответ: «сколько процентов принесут шрифты/другое изменение, если нам до успеха не хватило n%. Мы стоим перед выбором положить сейчас ресурсы и перепроверить с новыми шрифтами, или попробовать новую идею».

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

Пункт 7. Маркетинг

Мне нравится концепция с MVP и MMP (minimum marketable product). Разница — в уровне базового качества и аудитории, на которую работает привлечение. Если базовое качество ниже 80%, писать пресс-релизы и массово привлекать аудиторию не стоит. Сфокусируйтесь на необходимой и достаточной выборке для замера. Это важнее, потому что, скорее всего, вас ждет еще несколько итераций перед тем, как рассказать о своей «прорывной функциональности». Я считаю, что версия для массового привлечения — это вторая и более поздние версии продукта с поиском сходимости модели CAC

Как их отличить? «Если вы запускаете свою первую версию и вам не стыдно, то вы запускаете ее слишком поздно» — говорит нам Рид Хоффман. Поэтому если вам «стыдно», промоутировать стоит очень точечно (контекстная реклама, баннер на небольшую часть аудитории внутри продукта) для сбора статистически значимых данных о запуске.

Я работал с продуктами, у которых большая аудитория: мы формировали размер достаточной выборки и раскатывали функциональность на % от общей аудитории. Заранее готовили ответы на вопросы от пользователей для поддержки и, после положительного результата запуска MVP, рассказали и сделали функциональность доступной большой аудитории.

Пункт 8. Развитие

После того как MVP сработал — цикл обращается заново. Теперь улучшение идёт по пути минимально значимого улучшения. С замерами на каждом этапе.

Пункт 9. One more thing. Как продать MVP команде?

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

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

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

Команда покупает свадебный торт, а вы ведете их по пути капкейк –> пирог –> свадебный торт. И если капкейк не «вкусный», то надо делать другое блюдо, а не «невкусный» пирог.

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

Вывод

MVP — это минимально жизнеспособный продукт. Для минимальности продукта смотрите на одну самую важную проблему пользователя, конкурентов и ищите достаточность уже на стадии прототипа. Для уверенности в жизнеспособности продукта составьте метрики продукта и проверьте их. И не бойтесь простых итераций — в них сила. Улучшения должны стоять на «твердом» фундаменте, а «пустые» фичи или сервисы закрывают первыми.