«Пользователю не нужно прямо сейчас все, что задумано»: на чем сосредоточиться на старте разработки SaaS-продукта?

Первая итерация: пользователю не нужно прямо сейчас все то, что задумал основатель 

У нашего партнера, голландского предпринимателя Менно Олсторна, было четкое видение, какой стартап он хочет запустить: пользователь оплачивает подписку, получает доступ к десятку шаблонов резюме, а команда может в любой момент локализовать сервис под новую страну через административную панель. Более того, Менно даже сам нарисовал примерные интерфейсы с помощью Balsamiq, чтобы показать нам все от и до. 

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

Самая первая версия редактора, 2016 год

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

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

А вот подписку, несмотря на упрощенную реализацию редактора резюме, мы запустили сразу. Делали это через Stripe — у них удобный SDK (software development kit, набор библиотек для реализации стандартных сценариев), и виджет оплаты на сайт подключается за 10 минут. Они сами занимаются валидацией формата карт, 3-D Secure — нам надо было только вставить код на сайт. 

Текущая версия редактора

Мы с Тихоном не анализировали аналоги и не полагались на прототипы Менно. Если бы пошли таким путем, то без конца бы застревали на разном функционале: «Почему они реализовали его именно так?». Мы же на каждом шаге спрашивали себя: «А каким конструктором резюме стали бы пользоваться сами?». 

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

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

Вместе с этим отложили на следующие итерацию все контентные составляющие: email-рассылку и блог. Человек приходит в сервис, чтобы решить свою проблему. А узнать планы по обновлению продукта или получить инструкцию, как им пользоваться, при желании можно все тем же способом — написав сообщение в поддержку. Конечно, такое решение разумно только при небольшом количестве клиентов — иначе вам придется брать отдельного человека, чтобы разбирать почту.  

Дальнейшее развитие: как настроить процессы и какие функции продукта взять в приоритет 

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

Далее мы стали анализировать запросы в поддержку: какие повторяются чаще всего? Их и стали автоматизировать. Например, сделали так, чтобы пользователь мог сам оформить возврат. За все пять лет, что мы работаем, только сейчас нам понадобились дополнительные люди в команду support — до этого со всеми запросами справлялся один человек.

Для того, чтобы у нас получился продукт, который похож на первоначальные ожидания Менно, потребовалось около двух лет. Сначала у нас было совсем базовое приложение, которое полностью работало на Ruby on Rails и на jQuery, а потом мы начали переезжать на React. Тогда у нас появился фирменный стиль в дизайне, мы пересобрали редактор резюме — и это, кстати, то, на что ушло существенное количество времени. Мы рассчитывали на три месяца, а получилось в два раза больше. 

Сам процесс работы мы настроили так, чтобы сторонний человек мог легко влиться и разобраться в продукте. Это важно и для онбординга новых сотрудников, и для последующей продажи компании. Мы использовали трекер задач, проводили code review, внимательно писали readme-файл и выводили принципы для дизайн-системы, еще когда продуктовая команда состояла только из нас двоих. 

Пример того, как мы организуем базу знаний

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

Гораздо позже мы начали вкладываться в диверсификацию трафика. Изначально привлекали пользователей в основном с помощью Google Adwords. В конце 2018 года завели блог и партнерскую систему. В это же время стали расширять продуктовую линейку: добавили конструктор сопроводительных писем, инструмент для поиска работы и трекер откликов работодателей — нашим приоритетом стал рост LTV. 

Пара статей из блога

Сложности: с какими стоп-факторами мы столкнулись на масштабе

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

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

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

Они сложнее в конфигурации, нужно заниматься поддержкой, но на нагрузках можно сэкономить. На следующем уровне: строишь свой дата-центр — так делают компании, у которых 1000+ сотрудников. Далеко не всегда это решение оправдано.

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

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

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

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

Как выстроить процесс: быстро делаем MVP и находим первых пользователей, а потом — замедляемся

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

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

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

Фото на обложке: dotshock/shutterstock.com