Итак, у вас есть отличная идея и вы хотите создать продукт SaaS (программное обеспечение как услуга) на основе подписки. Хорошо, а что дальше? С чего начать? Что нужно учитывать, чтобы воплотить идею в реальность и масштаб? Что вам нужно покрыть, чтобы дать себе больше шансов на успех? Вот несколько идей, [в произвольном порядке], которые следует учитывать на вашем пути, чтобы указать вам правильное направление:

Всегда начинайте с анализа требований

Это важный шаг, поэтому давайте определим, какими должны быть требования:

Требования - это то, для чего предназначен программный продукт или то, что вы собираетесь создать.

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

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

Вы всегда должны записывать свои требования. Без исключений.

Тем не менее, вот несколько советов, когда дело доходит до анализа требований:

  • Определите ключевые заинтересованные стороны и вовлеките их при определении ваших требований.
  • Проведите этот этап, анализируя и разбираясь в бизнес-процессе. Старайтесь не смотреть на требования через призму заранее определенного решения; просто документируйте бизнес-процессы и последовательность действий.
  • Как только вы поймете бизнес-процесс, попробуйте его улучшить / улучшить. Вопрос, почему в настоящее время все делается именно так. Получите обратную связь от ключевых заинтересованных сторон (они могут стать вашими будущими клиентами!).
  • Выберите централизованное место для документирования и управления вашими требованиями (например, Github или Jira). Это касается и гибких проектов!
  • Если вы отдаете разработку своего приложения на аутсорсинг, то обязательно иметь полный документ с требованиями. Многие ошибки продукта происходят из-за недопонимания между ключевыми заинтересованными сторонами и разработчиками.
  • Не предполагайте, получите обратную связь по ходу дела.

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

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

Подтвердите свою идею… на рынке!

Начнем с фундаментальной предпосылки / идеи:

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

Ваша цель - продемонстрировать, как ваш продукт может помочь предполагаемым пользователям / организации достичь любой / всех этих целей. Если вы можете продемонстрировать это в виде точных цифр (например,% увеличения объема продаж,% экономии часов / затрат), то вы на пути к победителю!

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

Это поднимает еще один ключевой момент. Вам необходимо найти общий адресный рынок (TAM) для вашего продукта. Отсюда следует, что чем больше TAM, тем больше у вас возможностей зарабатывать деньги, поскольку есть больший набор потенциальных клиентов, которых нужно обслуживать. . Вам следует сосредоточиться на небольшом рынке только в том случае, если вы создаете нишевый продукт или ваш доход больше на аккаунт / клиента, чтобы сделать это стоящим начинанием.

Знай свои числа!

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

  • Стоимость привлечения клиента (CAC)
    Это мера, позволяющая определить общую сумму, которую вы в настоящее время тратите на привлечение клиента для своей услуги. Например. Ваша компания потратила 1000 фунтов стерлингов в год, чтобы привлечь 100 пользователей, поэтому ваш CAC за год составляет:
    1000 фунтов стерлингов / 100 = 10 фунтов стерлингов.
  • Ежемесячный периодический доход (MRR)
    Периодический доход - это источник жизненной силы вашего SaaS-бизнеса, поэтому вам следует ежемесячно отслеживать текущую сумму общего регулярного дохода. Например. У вашей компании 200 пользователей в месяц, которые платят 10 фунтов стерлингов в месяц, поэтому ваш MRR составляет:
    10 фунтов стерлингов x 200 = 2000 фунтов стерлингов.
  • Годовая скорость выполнения (ARR)
    Умножьте MRR на 12, чтобы получить годовую частоту выполнения.
  • Средний доход на аккаунт (ARPA)
    Разделите MRR на общее количество клиентов вашей услуги. Рекомендуется измерять ARPA для новых и существующих учетных записей отдельно.
  • Показатель оттока клиентов: отток клиентов и отток доходов
    Регулярный доход - это только часть общей картины, вам также следует отслеживать уровень оттока, чтобы лучше понять состояние вашего бизнеса. Отток относится к количеству существующих пользователей / доходов, покидающих ваш сервис в определенный момент времени. Если многие люди покидают вашу службу, вам необходимо об этом знать. Есть два типа оттока:
  • Отток клиентов: например, Ежемесячный отток клиентов
    (Всего # клиентов в начале месяца - Всего # клиентов в конце месяца) / Всего # клиентов в начале месяца
  • Отток дохода: например, Ежемесячный отток доходов
    (MRR в начале месяца - MRR в конце месяца) - MRR от обновлений в месяце / MRR в начале месяца
  • Использование и взаимодействие
    Это немного сложнее сформулировать в формуле, поскольку она зависит от вашего продукта. Примером может служить количество входов в систему на одного пользователя за определенный период. Другим примером может быть количество новых задач, созданных / выполненных в вашем приложении для управления проектами. В качестве альтернативы вы можете создавать и отслеживать события в своем приложении, чтобы получать более подробную информацию об использовании.

Эти цифры предназначены для измерения общего использования, работоспособности и роста вашего сервиса SaaS. Этот список далеко не полный. Для более полного списка по этой теме я рекомендую прочитать Руководство по основным показателям SaaS - saasmetrics.co.

Следуйте методологии 12FA

Фантастическая методология создания приложений SaaS - это методология 12 Factor App:



Приложение« Двенадцать факторов
Методология создания современных, масштабируемых и обслуживаемых приложений типа программное обеспечение как услуга . 12factor.net»



Принимайте решения по масштабированию, надежности и мультитенантности

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

  1. Технический масштаб: это относится к архитектурным решениям, которые вы должны принять в отношении реального продукта, который вы создаете, и его базовой инфраструктуры (чтобы справиться с возросшей нагрузкой по мере того, как ваш продукт SaaS набирает обороты и становится популярным).
  2. Масштаб бизнеса: это относится к решениям в отношении финансовых и бизнес-процессов, которые вы должны принять (чтобы ваш бизнес мог быстро расти / маневрировать и повышать прибыльность).

Вот несколько решений, которые я принимаю заранее:

Решения по технической шкале

  1. Мультиарендность:

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

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

2. Бессерверные (например, PaaS, FaaS) или контейнеры (на IaaS)

Решите, хотите ли вы принять бессерверную парадигму, используя продукты (например, Firebase, MongoDB Stitch или Google Cloud Functions), или вам нужен больший контроль над инфраструктурой.

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

Я лично запускаю контейнеры с помощью Google Kubernetes Engine. Я лично рекомендую использовать как минимум инфраструктуру как услугу (IaaS), такую ​​как Google Cloud Platform, Azure или AWS.

3. Обработка изменений для арендаторов

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

Не запускайте в производственной среде несколько версий одного и того же программного обеспечения с разной кодовой базой - это верный путь к катастрофе. Сохраните одну кодовую базу и создайте архитектуру plug-in / config, позволяющую вносить эти изменения.

Если вы не последуете этому совету, вас ждет кошмар DevOps! Например. Каждый раз, когда вы выпускаете новую версию, вам придется объединять ее в отдельные кодовые базы, которыми вы управляете для каждого клиента.

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

4. Надежность

  • Аварийное восстановление. Составьте план по хранению резервных копий данных клиентов.
  • Высокая доступность. Контейнеры отлично подходят для поддержания вашей службы SaaS в сети. Я использую сервис Google Kubernetes Engine для управления доступностью своих серверов приложений и баз данных.

Масштаб бизнеса

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

  • Уточните свой бизнес-процесс, чтобы сделать процесс подключения менее привлекательным (например, они могут самостоятельно зарегистрироваться и платить онлайн, практически не взаимодействуя с вами). Если каждый раз, когда вы создаете новую учетную запись или сбрасываете пароль, требуется вмешательство человека, вы создаете узкое место, и у вас будут проблемы с ростом, если ваш бизнес станет больше.
  • Определите свою стратегию монетизации. Учитывайте стимулы для обеспечения денежного потока (например, 12 месяцев по цене 10, если вы обязуетесь платить ежегодно сегодня).
  • Создайте базу знаний об общих проблемах, чтобы клиенты могли сначала ответить на свои вопросы.

Составьте общий контрольный список продуктов SaaS

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

Вы должны стремиться создать повторно используемую библиотеку / базу кода, чтобы использовать ее в качестве основы для вашего приложения SaaS. Вот список, на который я ссылаюсь, чтобы убедиться, что продукт охватывает все основы, прежде чем я буду реализовывать какую-либо бизнес-логику (в контексте NodeJS, опять же, это всего лишь набросок, я расскажу более подробно в будущих статьях):

  • Инструменты для сборки и стартовый набор (например, create-react-app или razzle-js)
  • Контроль версий (например, github)
  • Аутентификация (паспорт.js)
  • Авторизация и управление доступом на основе ролей
  • API (внутренний и внешний) (например, express-js)
  • Маршрутизация приложений (например, реагирующий маршрутизатор)
  • Управление состоянием приложения (например, Redux, если я использую REST или Relay, если я использую graphQL)
  • Бэкэнд / база данных (например, DBaaS или MongoDB самостоятельно)
  • Библиотека пользовательского интерфейса (react js)
  • Поиск (например, ElasticSearch)
  • Журнал событий (например, Sentry)
  • Подписка и выставление счетов / платежи (например, Stripe)
  • Библиотеки тестирования для разработки через тестирование
  • Меры безопасности
  • Работайте с приложением по SSL
  • Общий веб-сервер и управление субдоменами в экспресс-режиме для мультитенантности.
  • Решите, является ли приложение только клиентским или оно должно быть отрисовано на сервере / универсальным.
  • Графические библиотеки и абстракции для построения бизнес-аналитических отчетов.
  • Автоматизация развертывания (например, Jenkins)

Маркетинг

Создание отличного продукта - это только половина дела; вам нужно сообщить людям, что он существует и может приносить пользу.

Важно различать продажи и маркетинг. Под продажами понимается создание пользователем / организацией новой учетной записи для вашего продукта / услуги. Под маркетингом понимается повышение видимости вашего продукта на целевом рынке, чтобы они знали, какую ценность он может принести (например, Adwords или Billboard Ads).

Вот несколько моментов, которые следует учитывать в отношении маркетинга (не исчерпывающий, поскольку он слишком велик, чтобы подробно описать его в этом посте)

  • Определите свой целевой рынок и создайте свой профиль / образ клиента.
  • Создайте воронку продаж и процесс для управления вашей воронкой продаж.
  • Предоставьте демонстрационные видеоролики о продукте, чтобы продемонстрировать его ценность.
  • Используйте подходящий канал интернет-маркетинга: Adwords, Facebook / Twitter / LinkedIn Ads и т. Д.
  • Вам также нужно заниматься офлайн-маркетингом, посещайте мероприятия в своей сфере!

Сосредоточьтесь на заботе о ваших существующих клиентах

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

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

Надеюсь, вы нашли это полезным! Пожалуйста, оставьте свои мысли / комментарии ниже :)