Всем привет. Меня зовут Валерьян Брунин. Я – CEO компании продуктовой разработки и в этом блоге я пишу про опыт компании и рассказываю о крутых кейсах. 

Моя прошлая статья на 14 страниц Экосистема на 1 000 000$ собрала 1300 показов и даже 26 закладок. 

В этом кейсе я все-таки решил придержать свои мысли и упаковать их в четкий формат, чтобы донести суть и максимум ценности. 

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

SaaS (Software as a Service) – пер. программное обеспечение как услуга – одна из форм облачных вычислений, модель обслуживания, при которой подписчикам предоставляется готовое прикладное программное обеспечение, полностью обслуживаемое провайдером. Если говорить простыми словами – это модель, по которой вы пользуетесь продуктом онлайн по бесплатному и платному тарифам. Например Figma, Canva, Jivosite и так далее.

О проекте

Upsales – инструмент повышения конверсии сайта. Основная мысль, которая легла в фундамент создания такого продукта – это область маркетинга под названием Growth Hacking. 

Growth hacking – пер. взлом роста – это область маркетинга, ориентированная на быстрый рост компании. Это называется как процессом, так и набором междисциплинарных навыков. Если говорить простыми словами – это набор практик, которые помогают резко и кратно увеличить какой-либо показатель воронки, желательно конечно факт продажи (для SaaS более характерна подписка). Если вообще просто, то это область, которая ищет волшебную таблетку, которая поможет без затрат или с минимальными затратами увеличить кратно показатель. 

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

В итоге в 2019 году мы запустили проект для нужд собственного отдела маркетинга. 

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

Сейчас я бы еще сказал, что перед тем, как начать делать свой продукт, вам надо провести UX исследование. Но тогда мы еще о таком не знали, поэтому пропустили данный этап. Но сейчас, когда к нам обращаются за разработкой или консультацией по разработке продуктов, мы всегда начинаем с исследования. Задача исследования понять: 

• для кого мы делаем продукт; 

• какая у них проблема;

• как они ее сейчас решают; 

• как мы будем решать эту проблему; 

• что хорошего мы возьмем у текущих решений;

• что плохое мы не должны скопировать у текущих решений.  

Основная проблема, которую мы решали собственным продуктом

• При работе с сайтами, маркетологу необходимо тестировать гипотезы, повышать конверсию, собирать контакты, делать A/B тесты. По сути мы искали быстрые и бесплатные способы тестировать гипотезы на сайтах в огромном количестве, но не хотели зависеть от разработчиков. 

К примеру: лендинг налогового адвоката практически не генерировал лидов. Денег на доработку сайта у клиента не было, а маркетинг (контекст) работал. Через upsales.pro мы поставили exit pop-up с текстом: Я понимаю, что вы зашли на мой сайт со сложным и важным вопросом, но, раз вы его покидаете, вы не нашли ответы на свои вопросы. Через сайт и текст сложно передать весь мой опыт и экспертизу. Но вы можете позвонить мне или написать в telegram и я бесплатно разберу ваш вопрос за 10 минут и вы поймете, что мне можно доверить вашу задачу.  В итоге конверсия в такой лид-магнит была около 60%. Клиент заработал денег, а сервис стоил для него 10$ в месяц. 

• Как правило, у клиента возникают проблемы с такими доработками или внесений изменений в сайт для A/B тестов. Причины две:
  

  • нет разработчиков, кто этот сайт делал; 

  • высокая стоимость часа разработчиков, что не окупает внесение изменений. 

• Если использовать сторонние сервисы, то возникает проблема: 
  

  • кто оплачивает сервис? если клиент, то надо проконтролировать, что он зарегистрировался, привязал карту, передал доступы. Если маркетолог или компания, то надо самостоятельно купить сервис, выставить счет, проконтролировать оплату, а при прекращении сотрудничества надо все передать клиенту и сохранить статистику. 

  • Иногда необходимо несколько сервисов и тогда проблема масштабируется. 

После того, как вы определили проблемы и боль аудитории, надо понять, как наш продукт решит эти проблемы. 

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

Как мы решили проблему: 

• Создали продукт с 4-мя основными формами, которые необходимы в 90% случае и которыми можно тестировать гипотезы, выводить быстро информацию на сайт и не зависеть от разработчиков. 

• При этом маркетолог может создать инструмент для клиента и передать ему доступ к управлению, либо клиент может создать инструмент и раздать доступ маркетологу. 

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

• Все инструменты можно использовать на одном проекте одновременно, или можно тестировать, какой инструмент лучше.

• Можно создавать тесты внутри самого инструмента, а не только между самими инструментами. 

• Вся статистика собирается в одном месте. 

• Маркетолог может генерировать отчеты для клиента в презентации. 

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

И этот момент максимально важен для каждого продукта. Поверьте, в компании мы делали 30+ продуктов на заказ и сколько их погибло из-за этой ошибки – вам не рассказать. Как правило в этот момент владельцы такого продукта смотрят на него и думают: ну он сырой для трафика, пользователей и вообще, не достоин рынка, давайте еще добавим фич, допилим продукт. Все, на этом моменте можно хоронить продукт. Как только мы начнем пытаться сделать идеальное решение со всеми возможными продуктовыми кейсами, мы не сможем остановиться, затраты на разработку, сервера и так далее сожрут все ресурсы, а продукт станет огромным и новые пользователи не захотят в нем разбираться. 

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

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

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

Чего добились в итоге после первого запуска и года работы:

• При запуске продукта все наши клиенты, кто был на маркетинге, подключили себе сервис. За первый месяц мы подключили около 30 проектов. 

• Когда контроль оплаты от мелких проектов стал занимать много времени, мы просто предложили за 100$ купить годовую подписку. В итоге 30-40 проектов купили годовую подписку или хотя бы сразу на пару месяцев.  

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

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

• На платформе настроено хорошее SEO. Последние год-два мы не писали материалы и статьи, но трафик все равно рос. При должной системности кейсов и контента, трафик увеличится кратно. 

Вторым шагом мы пошли в социальные сети и сообщества, где нас знали, но мы не так сильно могли контролировать процесс. Но у нас уже было социальное доказательство в виде 30-40 компаний и несколько крутых кейсов. Так мы добавили еще пользователей на платформу. 

Дальше необходимо действовать максимально понятно и по методичке. Используйте Lean-подход к развитию продукта. В разработке используйте Scrum и двигайтесь спринтами. Тестируйте гипотезы, вносите изменения в продукт, контролируйте юнит-экономику. 

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

• Agile / Scrum / Lean – методики управления проектами и продуктами 

• Unit-экономика – финансовая модель 

• Lean Canvas – понимание продукта, фичи

• P4P и все остальные ответвления модели 

• Продуктовое исследование 

Это самый базовый минимум. 

Давайте еще раз тезисно пройдемся по тому, как надо разрабатывать свой продукт:

• Узнали о боли или осознали ее у себя 

• Провели исследование и сделали выводы 

• Определили MVP и реализовали его для подтверждения гипотезы 

• Запустили первых пользователей по принципу высоковязких фруктов 

• Улучшили продукт на основе первого опыта использования вашего продукта

• Если гипотеза подтвердилась еще раз, переходим на Lean-модель развития продукта

• Считаем юнит-экономику

• Масштабируемся

• Зарабатываем много денег – едем на Бали)  Это уже опционально. 

Еще очень важный момент. Есть одна тонкая грань, которую надо попытаться объяснить и не уйти в дебри. Когда вы создаете MVP, вам надо нащупать баланс между тем, чтобы реально сделать минимальный жизнеспособный продукт, который решает базовую боль и делает это так круто, что можно не обращать внимание на косяки в продукте, интерфейсе и онбординге. Но я не согласен с большинством экспертов по стартапам, кто говорит, что MVP должен быть на коленках написан.  Сейчас не бум стартапов, чтобы пользователи сломя голову неслись на новый проект, как лет так 8-10 назад (золотые времена были). Даже если ваш продукт реально крутой, но прям сырой, кривой, косой, скорее всего пользователь останется там, где удобнее, хоть и дороже, или так, кто тоже не огонь, но он хотя бы привык и не будет тратить свою энергию на переход. Но так же вам не стоит переходить на сторону сильного MVP, которое содержит много кейсов и решений, но 90% из них не нужны пользователю, мешают понять суть продукта и увидеть самую суть и простоту решения своей боли. 

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

Структура проекта

Итак, когда мы разобрались, как запустить SaaS, давайте поговорим о структуре такого продукта. Данную структуру можно использовать в любом продукте. 

Глобально все состоит из таких частей как:

• Информационные страницы

• Личный кабинет пользователя 

• Панель администрирования 

• Серверная часть 

Информационные страницы

• Главная страница. Служит для распределения пользователя по платформе и конверсии в регистрацию. Главная страница должна рассказывать о продукте и максимально мотивировать на регистрацию. 
  

  • Используйте принципы сторителлинга и воронки продаж. 

  • Ваша цель – получить email, чтобы дальше дешево греть пользователи. 

  • Если email не получите, придется догонять ремаркетингом (ретаргетингом), а это дорого. 

• Страница всех инструментов. Если ваш продукт состоит из нескольких инструментов, возможностей. 
  

  • В основном создается на будущее и для SEO. 

• Страница отдельного инструмента. Если у вас несколько инструментов / решений. 
  

  • Каждая страница должна быть в виде лендинга, с теми же принципами сторителлинга и воронки продаж.

  • Необходимо для настройки трафика на страницу инструмента, чтобы запрос совпадал с посадочной страницей.

  • Также такие страницы необходимы для SEO. 

  • На страницу также желательно выводить кейсы по инструменту и статьи. Это повысит конверсию и хорошо для SEO. 

• Кейсы.
  

  • Для SEO трафика и маркетинговых активностей. 

• Статьи.
  

  • Для SEO трафика и обучения пользователей. 

• Глоссарий.
  

  • Для SEO трафика и обучения пользователей терминологии.  

• FAQ.
  

  • Для SEO трафика и обучения пользователей. 

• Стоимость.
  

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

• Договор публичной оферты. PDF.
  

  • Для платежной системы и соблюдения законодательства. 

• Техническая поддержка.

• Политика конфиденциальности. PDF.
  

  • Для платежной системы и соблюдения законодательства. 

• Вход. Регистрация. Восстановления пароля. Вход и регистрация через сервисы. 
  

  • Ваша задача, чтобы на каждой странице, блоке была возможность в один клик зарегистрироваться в системе. 

• Технические страницы: 
  

  • Спасибо страница. 

  • Страница 404. 

  • sitemap.xml 

  • robots.txt 

Личный кабинет пользователя

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

• Профиль: заполнение, отображение, редактирование. 

• Техническая поддержка в виде онлайн-чата в системе. 

• Тарифы: выбор, продление, изменение, отмена. 

• Оплата онлайн, оплата безналичным расчетом с выгрузкой актов. 

• Создание проекта. Проверка кода установки. 
  

  • Любой SaaS, который как-то взаимодействует с вашим сайтом, генерирует вам js код для установки. 

• Страница отдельного проекта. Со статистикой. 

• Проекты, доступные пользователю. Если есть делегирование прав доступа. 

• Инструменты. В каждом инструменте есть возможность создания, настройки, отображения, редактирования, тестирования и сбора статистики. 

• Статистика доступна в таблице, в графиках и в презентации-отчете. 

• Для инструмента exit форм и сбор контактов доступна база пользователей, которые оставили контакты. 

• База знаний. Для быстрого изучения материалов. 

Панель администрирования

В панели администрирования, владельцы платформы видят: 

• Продуктовую статистику в разрезе периода. 

• Всех пользователей, их тарифы и проекты. Запросы от пользователей. 

• Все проекты. 

• Все оплаты. 

• Создание контента для SEO: Блог, FAQ, Глоссарий, Кейсы. 

• Создание промокодов. 

• Логи. 

• Также администратор может по запросу пользователя переключиться в его личный кабинет и проверить настройки системы для помощи с проектом. 

Серверную часть не описываю. Это уже программирование по большей части. Не мой профиль. 

Как разработать такой продукт

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

Итак. Предположим, мы определились с болью, а теперь вам надо перейти к реализации. Вам надо пройти этапы: 

• UX Исследование. На этом этапе вы проверяете свою идею и сравниваете ее с реальным миром. Если результаты исследования подтвердили вашу идею – переходим дальше. 

• Техническое задание. Данный документ служит для того, чтобы заложить фундамент документации проекта, а также определить границы MVP. Результатом данного этапа будет техническое задание на разработку MVP. 

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

• На основе UX дизайна (прототипов) создается UI дизайн. В современной разработке минимум рекомендуется делать через компоненты, UI библиотеку и только реально крутые ребята идут через дизайн-систему. Мы обычно делаем просто UI библиотеку. Дизайн рекомендуется делать для всей системы. Но можно пропустить панель администрирования, так как это ваша закрытая зона сайта и лучше не тратить бюджет туда. Как правило, мы рекомендуем в любом случае делать мобильную версию информационных страниц. Если позволяет бюджет, то мобилку личного кабинета также можно. Мобильную версию панели администрирования рекомендуем делать для богатых заказчиков) Адаптировать проект можно и без дизайна. 

• Программирование. Делится на front-end, back-end. Также есть серверная часть и мобильное приложение, чат-боты, браузерное расширение. Все это индивидуально. Здесь уже работа команды разработки. Для себя мы выбрали Laravel на back-end и vue.js + nuxt.js на front-end. При разработке мобильных приложений мы используем Flutter – кроссплатформенное решение для iOS и Android. 

• На этапе программирования лучше всего еще тестировать продукт своими силами или силами тестировщика. 

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

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

Теперь давайте посчитаем бюджет такого проекта не у фрилансеров, а у компании. Предположим, что мы считаем: 

• UX Исследование

• Техническое задание

• UX дизайн – низкоуровневые прототипы – без детализации: информационные страницы, личный кабинет и панель администрирования 

• UI дизайн: десктоп (информационные страницы, личный кабинет), мобильная версия (информационные страницы, личный кабинет)

• Программирование без приложения и так далее. Только веб версия 

• Тестирование

• Продакшн 

Итак, продук вышел в бюджет:

Детали расчетов – большая таблица, я вынес по ссылке - расчеты проекта в деталях 

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

А теперь давайте посчитаем, когда продукт станет окупаемым. 

Монетизация

Итак. Предположим, что наш проект за первые 6 месяцев потратил 60 000$ и каждый месяц будет тратить еще по 6 000$. Итого за первый год он потратит 96 000$.

За второй год мы будем добавлять еще и фишки, значит поддержка будет примерно 12000$ в месяц. Значит за второй год мы потратим 144 000$. Итого за 2 года – 240 000$.

Первые пользователи должны пойти с 7-го месяца. Значит у нас есть 18 месяцев на то, чтобы заработать больше, чем 240 000$ + маркетинговый бюджет. 

Для простоты расчетов возьмем 100$ в год с пользователя. За 18 месяцев мы запишем 150$ в пользователя.  

Если на маркетинг нам надо 10% от среднего чека, то это 15$ на пользователя. Значит 150$ отнимаем 15$ на его привлечение и нам остается 135

Значит чтобы заработать 244 000$ за два года, окупить разработку, маркетинг и стать прибыльными, нам надо 1777 платящих пользователей. Это по 98 в месяц. Звучит не очень правдиво. Но моя задача просто показать логику. Когда мы начали, мы привлекли 100 компаний просто бесплатно по чатам и так далее. Когда у вас есть экономика, воронка и показатели, вы можете с этим работать. 

Масштабирование. Экосистема

Ну и моя любимая тема – это экосистема. Не люблю делать просто так что-то. Я всегда смотрю глобально и мечтаю, что любой продукт станет экосистемой. 

В данном проекте в экосистему прийти можно через создание всех инструментов, которые нужны маркетологу. Но это всего лишь развитие продукта. Даже если мы добавим AI на создание текста, дизайна форм – это тоже все о развитии платформы. 

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

Надеюсь, вам было интересно и полезно. 

Всегда рад поделиться своим опытом.