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

Всем привет! Меня зовут Даниил, и вот уже 2 месяца мы с командой работаем над запуском нашего продукта — Chrony.

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

Перед Chrony мы около года занимались созданием системы приема платежей в криптовалюте. Мы верим в идеи WEB3, но нам очень не нравилось, как на тот момент выглядели и работали различные эквайринги. Всё было слишком болезненно, дорого и сложно. Выписав всё, что нам не нравилось, мы начали решать зафиксированные нами проблемы. Мы верили в то, что таких, как мы, много, и люди вокруг просто не знают, как можно делать по-другому: платить в крипте можно также удобно, как фиатом. Разработка длилась примерно полгода, за который несколько раз изменилось видение, но команда благополучно докатилась до первого запуска. Мы долго готовились к нему и старались сделать всё, чтобы о продукте узнало как можно больше людей. Были готовы сообщения для чатов, оформлен продукт на платформе Product Hunt, и в день запуска… Оказалось, что никому это не нужно, что проблема совсем не в том, что мы для себя определили.

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

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

Поиск новой идеи

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

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

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

Вся история создания первого iPhone довольно интересная, и часть от неё рассказывают в этом видео (рекомендация от меня) .

Команда, собравшаяся в стенах заброшенной лаборатории Apple, объединилась не вокруг идеи о создании нового смартфона. Все они собрались там вокруг общей боли (а если точнее работы, но про это чуть позже) — найти новые способы взаимодействия человека с вычислительным устройством. Речи про ёмкостный экран и управление несколькими пальцами, так ещё и в маленьком устройстве, вообще не шло.

Изучив эту историю чуть глубже, я понял, что мы очень сильно ошибаемся, когда сразу начинаем проектировать решение и общаться с пользователями про него. Да, на самом деле, и формулировка наших проблем уже содержит в себе какое-то решение. Мы сами додумываем за пользователя его проблему, а затем придумываем на это решение. И где тут понимание пользователя? Правильно, нигде. Мы думаем и говорим не о болях и проблемах, а о решениях.

В процессе ресерча мы с командой также наткнулись на методологию Jobs-to-be-done, которая в моей голове идеально легла на историю к подходу инженеров Apple.

Большинство компаний делят свою целевую аудиторию на сегменты по пользовательским или продуктовым характеристикам. Но у пользователя другой взгляд на рынок. У него просто есть задача, которую надо выполнить (job to be done) , и он ищет лучший продукт, который поможет ему в этом.

Клейтон Кристенсен, профессор Гарвардской школы бизнеса

Подробнее про jtbd можно почитать тут

Это был второй инсайт. Эта методология показала, как можно превратить новые мысли в действия и как это напрямую проверяется через общение с пользователями. Мы начали пересматривать наши гипотезы и искать в них те самые работы, которые нужно выполнить. Образовался пул таких работ, и мы были первыми, кто верифицировал эти гипотезы. Опрашивая друг друга как потенциальных пользователей, мы говорили просто про опыт друг друга в контексте определенных работ. Из этого разговора самым важным оказалось «Взаимодействие человека со своим расписанием». Это была крайне больная тема. Все мы студенты, и наше расписание постоянно меняется: пары переносятся, много дедлайнов, сдача работ. Также в процессе обучения мы работаем над командными проектами, и внутри есть свои задачи, встречи, дедлайны. Разобраться с этим всем было крайне тяжело. Некоторые просто терялись и плыли по течению, самые стойкие из последних сил пытались всё упорядочить в заметках и ежедневнике. В нашей ситуации быстро и эффективно взаимодействовать с расписанием было неудобно. Всех связывала экосистема Google, и календарь регулярно приносил нам боль. Застрелите человека, который придумал изменение времени при помощи круглых часов в мобильной версии Google календаря.

То, что мы общались о своих проблемах, мотивировало. Ещё больше мотивации придавал твит Пола Грэма о том, что можно делать продукты, которые в том числе нужны тебе самому.

How to make something people want?

Make something you want.

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

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

Общение с пользователями и формирование job stories

Выяснив наши общие проблемы, мы структурировали их в огромное количество job stories.

Формула Job Story:

Когда (описание ситуации) ,

Я хочу (мотивация) ,

Чтобы (результат) .

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

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

Мы сразу побежали общаться со студентами и преподавателями вокруг, узнавали об их опыте: как выполняют выписанные job stories. Пользователи сразу начали говорить о том, что их беспокоит. Буду честен, это были далеко не все, но оказалось, что такие истории совершенно не волнуют пользователей экосистемы Apple. В целом, это логично, так как мы исходили из общего непринятия Google Календаря.

В итоге поняли, что у людей вокруг нас также есть эта боль, и они тоже видят, что UX Google Календаря сломан. Но была ещё одна ценная вещь: оказалось, что много событий, задач, встреч, созвонов приходят пользователям в мессенджеры, в частности в Telegram. Это придало больше понимания ситуации нашего пользователя, за которого мы уже взяли ответственность, и мы начали думать, как решить его проблему.

Первое решение и проверка ценности

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

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

Но как получить деньги от пользователей, при этом не тратя огромное количество времени на разработку первого MVP? Здесь мы вспоминаем про FaaS (founder-as-a-service) или более близкое понятие «Флинстоун MVP».

Вспомнив о пользовательском опыте с задачами и событиями в мессенджерах, мы быстро определили, что и как может делать наш воображаемый телеграм-бот. По сути, мы написали для себя инструкции и начали их выполнять. Со стороны это выглядело очень забавно. Мы подошли к тем пользователям, с которыми ранее общались, и сказали, что подумали о нашем прошлом разговоре и создали бота, который может добавлять события и задачи в Google Календарь, а также выполнять все озвученные работы. Наше предложение было следующим: вы пользуетесь ботом неделю и платите за использование 100 рублей, а в конце сможете продлить подписку на бота, заплатив нам ещё 100 рублей.

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

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

Для нас это выглядело как-то так:

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

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

Создание первой версии продукта и предпродажи

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

Для продукта мы выбрали формат Telegram-бота под именем Chrony (да, в процессе работы мы придумали ему такое название) , потому что видим, что наши друзья, преподаватели и однокурсники постоянно используют Telegram для организации встреч, событий и созвонов. Также мы поняли, что многие задачи и события приходится ставить «на ходу».

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

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

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

Chrony — это личный секретарь, который старается понять любой запрос пользователя. Почти все use cases из нашего общения с пользователями были продуманы и превращены в функционал бота. Вы можете просто подумать о том, что нужно сделать, и спросить об этом у Chrony. Бот либо выполнит задачу, либо объяснит, почему не может этого сделать.

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

Таким образом удалось получить 60 оплаченных месяцев подписок по предзаказу. Это придало нам мотивацию и подтвердило, что не только мы видим ценность разрабатываемого продукта. Через пару недель мы обрадовали этих пользователей, выпустив первую версию бота, которую предоставили им в пользование. Это был первый мягкий тест нашего решения. Мы постоянно анализировали, как пользователи используют Chrony: как они ставят события, какими функциями пользуются, какие ошибки возникают. Также была создана группа с самыми активными пользователями, которые помогали нам улучшать Chrony на каждом этапе.

Как сейчас выглядит Chrony

Chrony — это чат-бот для Google Календаря, который позволяет управлять событиями с помощью текста, голоса и изображений прямо в Telegram. С его помощью вы можете:

  • Создавать, редактировать и удалять события и задачи
  • Отправлять фотографии и скриншоты для добавления в календарь
  • Запрашивать план на день и быть в курсе своего расписания

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

Также мы долго думали над системой монетизации и поняли, что Chrony раскрывается через несколько использований, и пользователю нужно время, чтобы он стал частью его жизни. Мы также размышляли над конверсией и в итоге пришли к следующей модели: каждому пользователю предоставляется 2 недели полного доступа к Chrony. По истечении 2 недель у пользователя заканчивается пробная подписка, и ему предлагается продлить её либо остаться на бесплатной версии бота с ограниченными функциями. Таким образом мы можем удерживать пользователя и далее увеличивать количество подписок среди уже имеющихся пользователей. Больше про эту систему можно прочитать в этой статье.

Запуск на площадках

Сегодня мы выходим на Product Radar, и это еще один этап проверки жизнеспособности нашего видения и той проблемы, которую мы определили. Сколько людей столкнулось с той проблемой, которую мы увидели? Хотим проверить это и дать Chrony в руки как можно большему количеству людей.

Если вы почувствовали, что мы говорим о вас, то вы можете поддержать наш проект на площадке. Каждый голос и комментарий важен для нас и поможет сделать Chrony еще круче.

Надеюсь, наша история откликнется вам и, возможно, наш опыт поможет кому-то. Благодарю вас за прочтение. Всем пока!

1616
10 комментариев

Удачного запуска!

3
Ответить

Желаю успехов с запуском и развитием продукта!

2
Ответить

Спасибо!

2
Ответить

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

2
Ответить

не полетит

1
Ответить

Почему?

Ответить

Я что-то прочитав статью не очень понял ваше отличие от помощников гугл и сири ? Там же тоже можно просто голосом сказать и он поставит встречу.

1
Ответить