Менеджмент цифрового продукта. От идеи до идеала

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

Вариант 1. Гипертрофированный водопадный подход:

➠ Закупить партию велосипедов.

➠ Арендовать склад.

➠ Арендовать магазин.

➠ Заказать брендинг для компании.

➠ Заказать дизайн интерьера.

➠ Сделать ремонт в магазине.

➠ Пошить униформу.

➠ Нанять персонал.

➠ Сделать сайт с каталогом продукции.

➠ Заказать в рекламном агентстве кампанию.

Вариант 2. Гипертрофированный Lean startup подход:

➠ Дать бесплатное онлайн-объявление о том, что продается винтажный велосипед, используя фото из интернета.

➠ В случае, если кто-то откликнется, перепродать велосипед, доставив самостоятельно.

➠ Проанализировать, может ли бизнес быть прибыльным и как увеличить объем продаж:

➠ заказ напрямую у поставщика;

➠ закупка оптом;

➠ организация собственной службы доставки;

➠ др. вариант.

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

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

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

Подход бережливый стартап (второй вариант) позволяет без избыточных издержек протестировать гипотезу жизнеспособности продукта, фиксируя при этом риски на каждом этапе. Как только становится понятно, что модель не сходится[35], есть возможность моментально отказаться от продолжения эксперимента.

Важно, что после первого «проворота» lean-цикла становится понятно, к какому элементу цепочки ценности важно приложить усилия. Возможно, компании вообще окажется не нужен сайт или физический склад, а упор нужно сделать на оптовую закупку или собственное производство.

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

Есть несколько популярных способов добиться сокращения издержек на тестирование гипотезы жизнеспособности.

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

2. Ограничение качества реализации функциональности. Намеренное занижение качества пользовательского опыта для сокращения стоимости и сроков разработки. Например, использование готовых компонентов интерфейса может быть не оптимальным с точки зрения клиентского путешествия – потребуется большее количество действий для достижения результата, чем если бы компоненты разрабатывались непосредственно под данную задачу с учетом лучших практик. Другой вариант: использование чат-бота в мессенджере вместо классического приложения с экранными формами. Это позволяет очень быстро разработать функциональность с ограничениями в UX[36], свойственными диалоговым интерфейсам.

3. Ограничение стабильности. Продукт работает стабильно только для количества пользователей, достаточного для получения репрезентативных данных[37] [36]. Применяется дешевый или бесплатный стек технологий, домашняя или грантовая[38] облачная инфраструктура.

4. «Волшебник страны Оз»[39]. Человек имитирует действия системы, например изображая интеллектуального чат-бота.

5. «Педальный привод». Часть функциональности берет на себя человек, например сотрудник службы поддержки.

6. Ограничение аудитории. Сокращая пользовательский сегмент, можно сократить разработку. Например, сначала сделав разработку для пользователей с операционной системой Android, а потом переходить на iOS или web-версию. Также можно ограничить поддерживаемые версии операционных систем или браузеров, что значительно может уменьшить сроки эксперимента.