Джейсон Коэн, CTO стартапа WP Engine, в своем блоге рассуждает о customer development и ценности общения с клиентами. Он считает, что пора пересматривать подходы в работе с клиентами, призывает отказаться от MVP. Альтернативой предлагает SLC – продукт, который не требует постоянной доработки. Чем SLC лучше MVP читайте в нашем переводе. 


pic mvp 1.jpg

Уже лет десять разработчики поют старую песню про MVP (Minimum Viable Product, минимально жизнеспособный продукт), не пересматривая свой взгляд на правильность того или иного способа накопить больше знаний о потребностях пользователей и при этом угодить им.

Это не лучший метод. Он довольно эгоистичен и оскорбителен для пользователей. Мы не будем выпускать MVP для WP Engine.

Причины появления концепции MVP до сих пор актуальны:

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

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

3.         Если проект себя не проявил, его можно закрыть, а если в нём просматривается потенциал – проинвестировать.

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

Проблема в том, что пользователи ненавидят MVP. Великий Рид Хоффман (Reid Hoffman) призывает запускать стартапы на рынок «достаточно рано, чтобы вам было неловко за первый релиз продукта». Однако никто не захочет пользоваться продуктом, в котором не уверены сами его создатели. Пользователям нужны отличные продукты, готовые к применению прямо сейчас.

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

К счастью, существует лучший способ создать и опробовать новые продукты. Чтобы это понять, следует отдать должное вышеперечисленным полезным атрибутам MVP, при этом уделяя как можно больше внимания клиентскому опыту.

Чтобы продукт был небольшим и быстро попал к пользователям, он должен быть простым. Пользователи каждый день соглашаются использовать те или иные простые продукты. Они простят отсутствие у продукта всех необходимых функций, если продукт не был заявлен как нечто большее. Например, все спокойно отнеслись к тому, что ранние версии Google Docs могли выполнять лишь 3% функций Microsoft Word, поскольку Google Docs блестяще обеспечивал то, для чего изначально был предназначен – простоту в использовании и совместную работу в режиме реального времени.

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

В том, что продукт может быть одновременно простым и полноценным, нет никакого противоречия. В качестве примеров можно привести ранние версии WhatsApp, Snapchat, Stripe, Twilio, Twitter и Slack. Некоторые из них затем были расширены и усложнились (Snapchat, Stripe, Slack), в то время как другие остались верными принципу быть проще (Twitter, WhatsApp). Авиакомпания Virgin Air начиналась всего с одного маршрута – короткого, но полноценного.

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

Существует множество способов, чтобы сделать продукт привлекательным. «Минимальность» и «жизнеспособность» явно не входят в их список. Популярный в настоящее время подход к созданию привлекательного продукта кроется в его дизайне: необходимо сочетать удачный опыт взаимодействия (UX) с удобным пользовательским интерфейсом (UI). Но есть и другие способы. Культура компании-разработчика и ее отношение к пользователям может сделать продукт привлекательным. Например, блоги компании Buffer с её поразительной прозрачностью, MeetEdgar, действительно помогающая предпринимателям, а также HubSpot, чей блог с самого начала был, как минимум, так же полезен клиентам, как и сама платформа HubSpot. Другой способ заключается в глубоком понимании образа мышления и стиля работы клиентов. В качестве примера можно привести Heroku, которая порвала с традиционной маркетинговой моделью и вместо описания выгод использования разместила на своей домашней странице образцы параметров командной строки, таким образом наладив прямую связь со своей продвинутой целевой аудиторией:

pic mvp 2.jpg

Для MVP есть правильная альтернатива – SLC, вот составляющие: Simple, Lovable и Complete – Простота, Привлекательность и Полноценность. Мы в WP Engine произносим это как «слик» (англ. slick, созвучно аббревиатуре SLC – прим. перев.). Например: «Какова «сликовая» версия вашей идеи?»

Помимо всего вышесказанного, у принципа SLC есть ещё одно преимущество, которое вы ощущаете в ходе разработки следующей версии своего продукта.

SLC-продукт не требует постоянной доработки для увеличения ценности. Возможно, версия v1 с годами эволюционирует до версии v4, однако у вас есть выбор отказаться от дальнейших вложений в разработку продукта, хоть это по-прежнему увеличивает его ценность. Без дополнительных вложений в разработку MVP его качество будет низким. Продукт, разработанный по принципу SLC без дополнительных вложений, будет хорош при условии, что он будет малым.

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

    pic mvp 3.jpg

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

Подробнее рассмотрев один из примеров, о которых мы упоминали, Snapchat, можно увидеть, что его разработчики действовали по принципу SLC подобно метафоре с видами транспорта. В первой версии продукта был создан экран, прикасаясь к которому в любой точке, можно было сделать фото и отправить его кому-либо, указав, через сколько секунд после получения изображение исчезнет с устройства получателя. Никаких видео, фильтров, социальных сетей, комментариев и никакого пространства для хранения данных – всё просто. Однако продукт привлекательный и полноценный, судя по тому, как он массово распространялся среди пользователей. Решающей в плане привлекательности была идея не хранить фотографии, однако многие предполагали, что простота интерфейса сыграла не меньшую роль. Успеху способствовал сам факт того, что продукт был простым до невозможности (при этом разработчики не жертвовали его полнотой и привлекательностью).

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

Применяя данный принцип, вы получаете лучшие результаты и более благоприятные условия для дальнейших шагов. Если не получилось – ничего страшного. Значит, эксперимент не удался. Ни MVP, ни SLC не застрахованы от провала, ибо всё это эксперимент. Однако если эксперимент с SLC удался, то ваш продукт уже имеет экономическую ценность, и у вас есть множество доступных вариантов его развития, ни один из которых не является срочным. Работайте над версией v2.0, и, поскольку ваш продукт уже имеет ценность, у вас будет больше времени подумать над тем, как должна выглядеть следующая версия. Можно даже провести опрос среди имеющихся пользователей на тему того, что точно следует включить в версию v2.0, вместо того, чтобы нанимать армию альфа-тестеров, интересующихся лишь тем, когда вы «пофиксите баги».

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

Спросите своих клиентов. Они согласятся.

Подпишитесь на рассылку полезных статей и анонсов мероприятий