Hello, SaaS | Создание нового продукта и почему не работает MVP

  • Tutorial
Я начинал писать свой блог с поста о создании SaaS продуктов. Пост получился довольно поверхностным, даже не поверхностным, а это была первая итерация в очень крупную клетку. Сегодняшний пост будет исключительно практическим и и посвященным New product development (NPD) в компании Dental Cloud.





Напомню, что мы делаем сервис автоматизации стоматологии, который а) классически b2b б) в него заложены все архитектурные требования NITS к SaaS — мультитенантность, кроссплатформенность в) и мы реализовываем требования на MS Azure. Важно, что я не говорю cейчас про многие SaaS-ы, которые взяли исключительно SaaS, как бизнес-модель например, к такой категории я бы отнес witget.com. или www.jivosite.ru

С точки зрения бизнеса мы играем в «багровом океане» — только в России порядка 30 игроков в сегменте 10 000 потенциальных клиентов и нам на уровне продукта надо быть априори лучше. Мое личное мнение, что в нашей истории не сработает MVP. Объясню почему — мы не продадим MVP и он ни кому не будет нужен. Мы не продадим из-за того, что MVP всегда будет проигрывать и вера в Lean Startup может сыграть с нами злую шутку. В сегменте автоматизации стоматологии уже масса коомодизи решений, успешных кейсов, практик и мы будем всегда в конце шорт-листа в очереди к потенциальному клиенту. Т.е. мы понимали, что никогда не продадим сервис в стандартных направлениях автоматизации — у нас это CRM-BPM (EHR — Electronic Health Records)
Что мы продадим, а не раздадим, как freemium:
  • будущие ожидания — каким продукт будет через время N
  • Clouds vista

Выход есть

В ситуации догоняющего перед командой встала задача (что делать, Карл?) каким должен стать продукт для того, чтобы он стал не MVP, а
  • конкурентным на момент запуска
  • оставался простым и понятным пользователю

Задача была решена примерно через 2 месяца обсуждений и команда пришла к выводу о том, что Dental Cloud должен лежать на стыке классических парадигм автоматизации CRM-BPM c добавлением Community составляющей в виде отдельных интегрированных сервисов или позиционирование его, как платформа. При этом мы не отошли от парадигм создания SaaS, а добавили к относительно простому функционалу автоматизации коммуникационную составляющую. Так в платформе сохранена доля автоматизации внутренних процессов клиники — 30%. Все модули не перегружены лишним, а самодостаточны для небольших стоматологических клиник.
Пока мы не до конца понимаем — станет ли Dental Cloud платформой или мы будем продавать наборы сервисов — это вопрос будущего и экспериментов, но уже сейчас понятно, что мы, по крайней мере, не конкурируем с большинством существующих в сегменте решений.



Новый подход

Какие тезисы к разработке SaaS я добавил из практики Dental Cloud и они, скорей, обязательные условия для запуска успешного продукта.
  • создание в frontend продуктах commynity составляющей через интеграцию или собственных сервисов-надстроек
  • интеграции с другими сервисами — например, voximplant.com
  • мульти — коммуникационная составляющая на уровне «пользователь приложения — клиент пользователя» поможет вам выиграть
  • наличие Rest API и коннекторы с облачными платформами, например, формат APS apsstandard.org

Ранее я делал акцент на том, что SaaS:
  • Это функционал, решающий одну проблему клиента
  • Соответствие NITS
  • Отсутствие лишнего — прав администратора, например


Из ярких последних примеров реализации всех моих тезисов о NPD — это Slack — ребята просто взяли все и перевернули с ног на голову — собрали вокруг коммуникаций все бизнес-приложения и в итоге побеждают.

* мои предыдущие материалы из серии «Hello, SaaS» можно прочитать по ссылке
Dental Cloud Inc 42,89
Компания
Поделиться публикацией
Ой, у вас баннер убежал!

Ну. И что?
Реклама
Комментарии 17
  • +1
    В e-commerce есть похожая боль с MVP…
    • +1
      MVP работает уж в очень сильных новациях, а так, голову пудрят народу очередной логичной теорией.
    • +4
      Вы это… Читать то что пишете не пробовали?))
      Вот реально, это просто неуважение к читателю. А так, конечно есть интересные мысли. Но выковырять их из потока сознания, который вы по ошибке называете циклом статей (на хабре я тоже вас читаю), это целое искусство.
      • 0
        Я ссылку скину на английскую версию — там редакторы обязательно поправят.
        • +2
          Чё?
          Какая версия, какие редакторы?.. Я не вижу тега перевод, вижу тег «учебник».
          Ладно, проехали.
      • 0
        «Учебник» — мое, да, как и вся серия. А что именно не понятно? Я очень старался )
        • +1
          > Мое личное мнение, что в нашей истории не сработает MVP
          > Объясню почему — мы не продадим MVP и он ни кому не будет нужен
          > вера в Lean Startup

          Т.е. вы отказались от основной концепции Lean Startup — проводить эксперименты и получать фактические данные, на которые следует опираться. И заменили это на субъективное личное мнение, объяснения и веру. И после этого критикуете Lean Startup и говорите, что там что-то не работает? Оооокккк… Но может быть все-так не лыжи не едут?)
          • 0
            MVP используется для тестирования спроса. Т.е. вы хотите сказать, что тестирование спроса не работает? Мощное однако заявление)
            • 0
              Ну смотрите, я написал про конкретные сегменты автоматизации — BPM и CRM — тут ясен спрос, есть рынок и игроки. Т.е. он даже не нужен (не работает). Но если бы мы делали попытки выходить в эти сегменты, то очевидно, что проиграли. По-этому появился SaaS продукт, который изображен на схеме. Как-то так. Если вы делаете новацию, то, да, LS может пригодиться. Но новаций нам моей памяти случилось очень мало за последнее время.
              • 0
                Дьявол в деталях в случае с CRM уж точно.
                Никакой одной гипермысли там не будет и показывать прототип без всех деталей — никакого смысла нет.
                • 0
                  Именно по-этому я и написал и предупредил разработчиков облаков не пользоваться методом. Но может быть я ошибаюсь и высказал снова же свое мнение )
                  • 0
                    > показывать прототип без всех деталей — никакого смысла нет.

                    Позвольте аргументированно возразить. Вот был у меня например тестовый проект с идеей одной CRM. С одной стороны можно было сделать продукт целиком и показывать его. С другой стороны можно было составить MVP и тестировать его. MVP это же не значит, что нельзя показать детали. Можно сделать демку, можно интерактивный макет, можно слайды, можно сделать много чего с нужным уровнем детализации. Главное — понять, интересно ли такое предложение, готовы ли за него платить. Так вот я сделал что-то типа MVP и даже больше. Кстати, это было ошибкой — потерял на этом лишнее время и деньги, можно было реально обойтись MVP без работающего продукта. И в итоге выяснил, что мои предположения о спросе на предложение были неверны по ряду параметров. Так что делать полноценный продукт даже смысла нет — одни убытки будут, он нежизнеспособный получался. Хотя в теории все красиво, всем все нужно и нравится — но только не продается по ряду причин. В итоге я сэкономил много ресурсов. Насколько я понял Lean Startup, MVP именно про это.
                  • 0
                    Так все-таки «не нужен» или «не работает»? Это сильно разные понятия все-таки. Ну ок — вы решили например не терять время на создание MVP так как он вам не нужен. Но зачем утверждать, что он «не работает»? Это все равно что сказать: «я не буду оформлять страховку на автомобиль, страхование в моем случае не работает».
                    • 0
                      В моем кейсе не работает и я об этом рассказал. По-поводу вашего не понимаю и надо смотреть.
                      • 0
                        А почему у вас «не работает» то что даже не пробовали сделать? Из текста статьи так и не понял. Как MVP может «не работать»?
                        • 0
                          У нас был выбор делать MVP в CRM — BPM или бандле сегментов автоматизации. В этих сегментах не надо ни чего доказывать и мы пошли дальше (сделали слайд). На выходе новые требования к SaaS, которые я перечислил в конце поста. Т.е. пост не совсем про MVP, а про новую парадигму для SaaS/ Вот.
                          • 0
                            > В этих сегментах не надо ни чего доказывать

                            Так и MVP не для «доказывания», а для тестирования оффера (предложения) и спроса на него + проверки гипотез.

                            > Т.е. пост не совсем про MVP

                            Ну так если пост совсем не про MVP, зачем его упоминать в заголовке, писать о нем в статье и еще говорить, что MVP «не работает»? Написали бы просто пост о своем опыте. А так получается, что пост не про MVP, но при этом с глобальным утверждением о том, что он почему-то якобы не работает. И в комментах обсуждаем MVP. Сразу вспоминается, уж простите, анекдот про трусы и крестик :)

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

              Самое читаемое