«Мне снится один и тот же страшный сон. Я влез в кредиты, чтобы создать приложение, а его скачала только мама. Разработчики уверяют, что теневой бан в App Store существует, а инвесторы внесли меня в черный список», — из вымышленного дневника стартапера. Как не оказаться в этом кошмаре, рассказываем в статье.
Привет, на связи Евгений, системный аналитик Purrweb — студии дизайна и разработки MVP для стартапов. В этой статье поговорим об ошибках, которые мешают стартапу покорить сердца юзеров и развиваться после релиза.
Ошибка 1. Не учитывать потребности целевой аудитории до запуска проекта
Иногда к нам в Purrweb приходят клиенты с идеями продуктов, которые мы называем «всё на черное». Владелец стартапа настолько уверен в своей гипотезе, что потребности и боли ЦА проверять не хочет. Такой проект может выстрелить, но чаще его сложно развивать и сделать коммерчески успешным. Он просто не нужен или не удобен пользователям.
Чтобы такого не случилось, рекомендую провести исследование аудитории до запуска проекта. Оно даст четкий срез потребностей будущих пользователей продукта, а иногда и неочевидные инсайты. Анализ бизнес-идеи и ЦА для стартапа стоит в агентствах около 300 000 ₽. При среднем чеке кастомной разработки в 7 млн ₽ посчитать потери в случае, если продукт не попадет в нужную аудиторию, несложно.
Вот какие исследования будет полезно провести любому стартапу:
1. Количественное исследование: опрос. Задача этапа — получить статистические данные. Например, нужно сделать сервис для аренды жилья. В опросе мы узнаем, сколько времени в среднем уходит у собственника, чтобы сдать квартиру. Или как долго арендатору приходится искать жилье. Стоит оставить и поля для открытого ответа. В них респондент сможет написать свои мысли, а вы получите полезные инсайты.
Количество респондентов для опроса я советую определять с помощью онлайн-калькулятора. Он учитывает сразу несколько показателей, которые важны для расчета конечной выборки:
— Коэффициент уверенности (КУ) отражает, насколько мы будем уверены в результатах исследования. Я рекомендую выбирать стандартный КУ 95%, чтобы снизить вероятность провальных результатов до минимума — 5%. Такое соотношение оптимально, когда нужен баланс между бюджетом, сроками исследований и их точностью.
Если брать КУ меньше, например 90%, мы пренебрегаем уверенностью в результатах, зато можем опросить меньше человек. Такой вариант подходит для продуктов с быстроразвивающимся рынком или для сегмента B2B, где сложно собрать много респондентов.
— Погрешность исследования отражает, насколько полученные результаты отклоняются от истины. Например, мы опросили 100 арендаторов, 20% из которых ищут жилье больше полугода. Если мы задали погрешность в 10%, то допускаем, что число таких арендаторов на реальном рынке может быть в диапазоне от 10 до 30%. Чем ниже показатель погрешности, тем более узким будет этот интервал и точнее результат.
— Общее число целевой аудитории отражает, сколько человек из нашей ЦА есть в России или другой стране. Здесь необязательно указывать точное количество. Например, мы опрашиваем тех же арендаторов. Понятно, что ЦА измеряется не десятками, не сотнями, а скорее миллионами человек, если речь идет о российском рынке. В этом случае можно задать 10 млн человек для расчета выборки. Если же вы делаете продукт для более узкой аудитории, ориентируйтесь на открытые статистические данные в Wordstat или Google Trends.
2. Качественное исследование: кастдевы. Это серия встреч с потенциальными пользователями. Так, в примере про сервис аренды жилья на кастдевах выясняют, какие проблемы есть у арендаторов и арендодателей, как выглядит график встреч с кандидатами, что бесит больше всего и удобно ли пользоваться продуктами, которые уже есть на рынке.
Мы опрашиваем около 20 человек, если сфера продукта понятна и хорошо изучена. Если же идея клиента лежит в менее очевидной плоскости — например, он хочет сделать приложение для сельскохозяйственных закупок, — выборку лучше увеличить до 40 респондентов.
О том, как провести кастдевы самому, рассказали в этой статье.
По результатам исследований вы сможете точнее определить ЦА и сделать продукт под ее потребности. Если этим пренебречь, продукт будет очень сложно развивать, ведь он получится для всех и ни для кого конкретно.
Кейс из практики. Недавно к нам обратился стартапер, который хотел сделать соцсеть для желающих похудеть. Мы провели исследования и выяснили, что ЦА неинтересно постить фото себя в зале и общаться с единомышленниками. Зато было много респондентов, которые перепробовали все способы сбросить вес, но так и не достигли цели.
Мы предложили вместо соцсети сделать приложение, где юзеры смогут получить профессиональную помощь. Найти тренера или специалиста по питанию, который подберут личную программу похудения. В результате человек сможет достичь результата без жестких ограничений и стресса. Получится действительно полезный продукт, а не просто приложение в вакууме.
Ошибка 2. Включать в MVP много функций сразу
Представьте: стартапер решил создать маркетплейс товаров для фотографов. Механика приложения сложная: несколько магазинов, рекомендации, отзывы, платежный модуль, статусы доставки и даже нейросети под капотом. А стартапер решает делать всё сразу, хотя это дорого и долго.
Два года и десять миллионов рублей спустя предприниматель наконец выкатывает приложение на рынок. И вдруг оказывается, что половина фич вообще не нужна юзерам, а UI уже устарел, и его надо изменить. Вместо того чтобы развивать продукт, приходится топтаться на месте и переделывать то, что есть.
Мораль: для MVP лучше ограничить число функций. Например, для маркетплейса стоит начать с каталога, оплаты и доставки, а систему умных рекомендаций оставить на потом.
Вспомните, как зародился Телеграм: на старте это был простой мессенджер. Теперь это сложный продукт с чат-ботами, сторис, видеозвонками и рекламной платформой. Сперва Дуров протестировал, хороша ли его идея, а уже после этого стал развивать продукт и добавлять фичи. Это пример грамотного развития.
Чтобы определить главные функции приложения, советую использовать правило «большого пальца». На этапе кастдевов ищите главную боль аудитории и спрашивайте, насколько та или иная ситуация волнует человека по десятибалльной шкале. Если больше половины респондентов ставят уверенную десятку, значит, проблема существует. Тогда приоритет мы отдаем той фиче, которая ее решит.
Кейс из практики. Мы в Purrweb разрабатывали сервис для удаленного ремонта квартир в Дубае. Клиент хотел сделать за три месяца мобильное приложение для пользователей, приложение для дизайнеров, админку для веба и лендинг, чтобы собирать заявки.
За такой срок реализовать всё перечисленное нереально. Поэтому мы предложили версионный подход: начать с MVP-версии приложения, для нее выбрать самые приоритетные фичи, а потом постепенно наращивать функции. Всего запланировали пять версий приложения, чтобы после каждого этапа обновлять его в сторах. Так можно было бы постепенно увеличивать число функций продукта, а клиент мог бы влиять на его развитие, выбирая наиболее приоритетные фичи.
Ошибка 3. Не учитывать в архитектуре, что продукт будет развиваться
Если мы заложили для приусадебного участка размер метр на метр, разбить там фруктовый сад технически невозможно. Так же и с ИТ-продуктом. На старте стоит предусмотреть в архитектуре резерв для его развития. Заложить условные 5–10 метров слева и справа от нашего метрового пятачка. Если этого не сделать, продукт не сможет расти и в скором времени перестанет закрывать потребности пользователей.
Например, стартапер планирует сделать соцсеть для меломанов. Идея выглядит так: музыкальный сервис и чат для общения. После релиза пользователи просят добавить систему рекомендаций и ленту новостей. Но продукт сделан на платформе no-code, поэтому добавить новые фичи сложно. Придется ограничиться чатом с проигрывателем или придумывать костыли.
В нашем примере стартаперу стоит применить первое правило масштабирования: спланировать наперед, как продукт будет развиваться, приоритизировать фичи и на старте обсудить это с подрядчиком. В этом случае всё можно предусмотреть заранее. И не придется переделывать всю функциональность приложения, чтобы добавить новую фичу.
Мы в Purrweb подходим к архитектуре комплексно, это помогает заложить резервы для будущего развития продукта 👇🏻
1. Выбираем способ построения архитектуры: монолит или микросервисы. Если у клиента нет много времени на разработку, но важна масштабируемость, мы рекомендуем делать монолит с модульной системой. Такую архитектуру можно в будущем разбить на микросервисы или добавить новые модули, а на старте разработчику не придется продумывать сложную архитектуру каждого микросервиса и систему взаимосвязей между ними.
2. Используем подход Domain-Driven-Design Эрика Эванса. Его еще называют предметно-ориентированным проектированием. DDD мы используем в случае монолитной архитектуры, так как с ним проще добавить в продукт новые фичи и, если нужно, поделить его на микросервисы.
Объясню, как это работает. В DDD-подходе существует понятие ограниченного контекста. Внутри одного такого контекста мы программируем решение задач по одной бизнес-цели. Допустим, в продукте уже есть два контекста: контекст планирования производства и контекст реализации плана на этом производстве. Если мы хотим добавить в продукт статус отгрузки товара, то внесем изменение в уже существующий контекст реализации. А если юзерам понадобится фича вне готовых контекстов, например управление филиалами производства, тогда лучше дополнить продукт новым контекстом.
Когда мы хотим добавить новую функциональность в продукт, отвечаем на вопрос: она относится к уже существующей бизнес-цели или к новой? Если цель новая, делаем новый контекст. Если она уже есть в системе, дополняем существующий. Такую систему несложно разделить на микросервисы, потому что все сущности уже расфасованы по контекстам, а коммуникация между ними понятна.
3. Выбираем подход к разработке: no-code или кастом. Первый вариант сразу накладывает ограничения на развитие: для приложения используют стандартизированное ПО. Time to market продукта будет намного короче, но потом его не получится масштабировать. С кастомной разработкой можно сделать приложение любой сложности и добавлять фичи до бесконечности.
Ошибка 4. Не узнавать, ведется ли документация
Бывает так: стартапер заказал MVP у подрядчика, а развивать продукт решил с помощью инхаус-команды. Но вдруг он узнает, что никакой документации по проекту не велось. А значит, команде придется потратить месяцы, чтобы разобраться в чужом коде и вникнуть в бизнес-логику. Это время стартап буксует, а его владелец тратит деньги на зарплаты команды, которая не вносит ничего нового в продукт.
Мы не считаем, что на этапе MVP стоит упарываться в документацию и фиксировать каждый шаг, но есть несложные правила, которые облегчат жизнь в будущем. Рекомендуем проверить, выполняет ли команда разработки эти действия.
Ведет документацию бизнес-логики. Мы в Purrweb используем систему BPMN-диаграмм, которая иллюстрирует все этапы работы продукта. Например, клиент заказал пять творожных сырков в сервисе по доставке продуктов. Из BPMN-документации можно узнать, как именно сырки попадут к нему домой, а еще что будет, если на складе сырков не хватает или они закончились.
Помимо BPMN-диаграмм, мы в Purrweb ведем и другие документы. Например, UML-диаграммы и критерии приемки продукта. Но клиенту разбираться в них вовсе не обязательно. Главное, что должно быть понятно из документации, — как приложение закрывает потребности целевой аудитории. Если из документации это не очевидно, стоит синхронизироваться с подрядчиком еще раз.
Что в итоге
Итак, чтобы не попасть в страшный сон стартапера, нужно:
- Выбрать конкретную целевую аудиторию и понять ее потребности и боли.
- Не делать из MVP сложный продукт с множеством функций.
- Убедиться, что команда разработки продумала архитектуру продукта так, чтобы его можно было развивать.
- Следить за документацией: она должна быть хотя бы в гигиеническом минимуме и содержать описание бизнес-логики продукта и критерии его приемки.
Готово, вы восхитительны! Шансы на успешный релиз и дальнейшее масштабирование повышаются. Если вам хочется больше узнать о секретах успеха развития ИТ-продуктов, приходите в наш телеграм-канал. Там мы много рассказываем о MVP и стартапах. До встречи в следующих статьях, stay tuned!
Как думаете, какие еще ошибки мешают приложению масштабироваться?
Почему no code сейчас так популярен, если в статьях на vc пишут, что с ним потом ниче не сделать? А для чего тогда подходит эта платформа?
Мне кажется, секрет популярности no code прост:
- онлайн-школам надо продавать свои курсы по зерокодингу
- большая часть стартаперов не думает, как развивать продукт после запуска mvp
На самом деле no-code привлекает низкой ценой и простотой в использовании. Как и любой инструмент, его можно использовать для решения определенных задач.
Например, если мы точно понимаем, что какую-то часть функций мы не будем менять, то можно использовать no-code. И наоборот, то, что точно будет меняться с течением времени, лучше делать кастомным.
А понять, что будет меняться, а что нет, можно через исследования своей аудитории и планирование бэклога функций 😉
ну вот на исследования часто забивают болт)
Думаете, в 2013 году Дуров знал, что в телеге будут сторис и платная подписка? 😄
Думаю в 2013 году Павел думал, что ТГ заменит смс и звонки.
а в каком году вообще появился ТГ ?
у него в голове? )
Хороший вопрос:) Лучше спросить у него 😂
К вам реально приходят люди с запросом выкатить приложение с миллионом фич за 3 месяца? 😆
Да, приходят. Не претендуем на истину в последней инстанции, но по нашим наблюдениям это идет от базовой неуверенности в собственной идее, которую стартапер компенсирует валом разных фичей и желанием все сделать быстро.
Мы как раз через исследования помогаем преодолеть эту неуверенность, чтобы стартапер точно понимал, что идея найдет отклик у аудитории.
Так там валенки, которые в айти не работали. Посмотрели фильм про стартаперов и розовые пони бегают в голове.
блин, ну если в стартаперы пойдут только айтишники, то скучновато будет, нет? без задоринки)) самые классные идеи рождаются, когда не знаешь, что что-то невозможно хахах
А кастдевы самому вообще реально провести? Если нет социологического бэкграунда 🤔
Конечно реально. Методология сама по себе несложная.
Но, чаще всего, фаундерам тяжело их проводить беспристрастно из-за привязки к идее. Они обычно задают вопросы не про предыдущий опыт, а про будущий, типа «а хотели бы вы пользоваться таким приложением?». Такой кастдев не поможет выявить потребность.
А 40 человек хватит, чтобы собрать какую-то статистику и найти данные для разработки? непонятно, где гарантия, что остальные 200 тысяч человек, для которых делается продукт, будут нуждаться в том же, что и эти 40
В случае с качественными исследованиями 40 человек хватит.
Дело в том, что качественные исследования нужны для знакомства с рынком, чтобы понимать, какие люди, какие у них потребности, что они делают, чтобы закрывать эти потребности, и какие есть проблемы с существующими решениями. А проверять эти инсайты нужно на количественных исследованиях. И для этого, разумеется, 40 человек не хватит.
стартаперы должны быть максимально вовлечены и внимательны , особенно в плане изучения ЦА ,дабы не было ошибок в создании продукта , плюс следует добавить еще активную работу над рекламой продукта и обязательно следить за документацией и разбираться в ней ,тут даже и объяснять не нужно что и зачем
Вот интересно получается: у стартапера есть своя идея, но на этапе исследований она может кардинально поменяться. А ему потом интересно будет делать вообще другой продукт? Хотел чел соцсеть сделать, а пришлось пилить обычную приложуху с тренерами, коих уже есть множество
Классный вопрос =)
Тут всё зависит от мотивации стартапера. Для кого-то важнее сугубо деньги. В таком случае смена вектора не повлияет на интерес. При условии что это в итоге принесет денег.
Если же на первом месте кайф от создания, а деньги на втором, тогда да, смена концепции может подкосить интерес.
Вообще тему с мотивацией лучше на старте поглубже раскапывать. Тут помогают такие вопросы: «А почему я захотел сделать именно это тех. решение? Какая глубинная причина?». Возможно, хочется делать соцсеть, потому что нет желания самому делать и модерировать контент.
Сейчас уровень сервиса интернет ресурсов такой, что проще определить уровень интереса аудитории с помощью клика по рекламе-завлекашке и фиксации на лендинге, нежели сделать недоделанный MVP, который задаст отрицательный пользовательский опыт как в примерах на скриншотах, где нельзя поменять телефон или пароль в уже зарегистрированном аккаунте. И пользователи потом на него не вернутся. Но за статью спасибо, интересен ваш опыт.
На самом деле в тесте продакт-маркет фита нужно разделять 2 гипотезы:
1. Интерес в общем. Это про то, есть ли на рынке люди с потребностью и интересом закрыть эту потребность вашим продуктом. И для теста интереса подойдет реклама-завлекашка, лендинг или другой дешевый тест. Мы как раз в Purrweb так и тестим интерес к продуктам. А после смотрим, стоит ли двигаться во вторую гипотезу и делать MVP.
2. Готовность пользоваться именно вашим продуктом. А вторая гипотеза именно про физическую готовность и желание пользоваться продуктом. То есть не на гипотетическом уровне, а именно на практическом. И вот эту гипотезу, к сожалению, без прототипа или MVP потестить навряд ли получится.
Так как понять на этапе разработки MVP, что именно эта фича нужна пользователям? Может мы ошибаемся и именно смена пароля аккаунта в итоге приведет к отказу от использования нашим недоделанным сервисом...
Чтобы понять, нужна ли какая-то фича или нет, нужно проводить интервью по тех. решениям. То есть брать каждую юзер стори и обсуждать с ЦА. Таким образом получать какой-то фидбек. Причем желательно делать это на прототипе.
В общем прототип это про примитивные продукты, те, которые уже состоялись и механика их понятна. Допустим всякие трекеры, crm и т.п. Можно скопировать в свой продукт часть функционала и тестировать. А если что-то реально новое, то пока не внедришь, не поймёшь полетит оно или нет.
Теперь мне нужна соцсеть для меломанов)) Такая где-то есть?)
Скоро должно выйти приложение Musircle. На лендинге говорят, что будет прям соцсеть для меломанов:)
Вы DDD прям в КАЖДОМ проекте используете? Не у всех же клиентов есть столько времени, чтобы погружаться в эти контексты
Не в каждом. Обычно используем его на больших проектах, которые надо сделать в короткие сроки. Причем мы заранее пониманием, что будет много функций и в будущем точно надо будет распиливать это все на микросервисы.
На самом деле нужно не так много времени для погружения в контекст. Как правило, системному аналитику совокупно 4-6 часов хватает. Дальше остаются точечные вопросы. В 99% случаев наши клиенты находят время для этого, так как хотят выпустить продукт =)
Котик потрясающий на обложке)
а прям всегда и всем надо делать сначала MVP? Вот например маркетплейс для фотографов. Можно ведь было потратить полгода и сделать цельный продукт, с магазинами там, с рекомендациями. В чем смысл маркетплейса без этих фич? За полгода ведь не поменялись бы потребности, и дизайн бы вряд ли устарел
Разумеется, нет. Если вы стартапер, то лучше выпустить MVP, чтобы проверить самые рискованные гипотезы и начать собирать пользователей. Это уже даст какой-то выхлоп, который можно будет реинвестировать в продукт.
Если же вы прям железно уверены в идее и нет проблем с финансированием, то можно попробовать сделать сразу полноценный продукт. Но в этом случае в разы больше рисков.
Ну как говорится на ошибках учаться, думаю что после прочтения вашей статьи можно для себя тоже самые распространённые ошибки выявить и в будущем их точно не допускать
А вы даете какую-то гарантию на продукты, разработанные вами, что данные от пользователя будут защищены? Или может какую-то оперативную поддержку в случае непредвиденной ситуации, по типу хакерской атаки и т.п.?
Мы подписываем SLA после релиза, где прописаны сценарии реагирования в случае атак, падения серверов и прочих непредвиденных ситуаций
А разве проекты «всё на черное» не проще потом продвигать? Вот соцсеть для худеющих например могут и мамы в декрете скачать, и худеющие. Может даже спортсмены на сушке. Больше охват и популярность в итоге. Как-то нелогично
По первому предложению кажется, что мы по-разному используем термин «всё на чёрное». В нашем понимании это когда стартапер вообще ничего не исследует и не считает заранее, а просто делает продукт и смотрит на отклик. В вашем — когда делаешь проект на максимально широкий сегмент.
Это была минутка духоты 😅 А теперь ответ на вопрос =)
Проекты на широкий сегмент наоборот тяжелее продвигать. В плане точности это будет как стрельба из пушки по воробьям. Может попадете, а может нет. Да и бюджеты нужно заливать солидные, чтобы получить широкие охваты.
И даже если получится найти деньги на охваты, после старта все равно придется общаться с аудиторией. И может выясниться, что продукт вообще не закрывает их потребности. Придется кардинально менять продукт, а это доп траты.
Разве нельзя потом no-code заменить на кастомное решение? То есть MVP работает на no-code. Мы посмотрели, что все хорошо и можно двигаться дальше. Запилили кастомное решение и подменили no-code этим решением во время обновления )
Да, так тоже можно делать. Важно только контролировать, чтобы опыт пользователей не ухудшился.
Я не очень понимаю, как может родиться идея чего-нибудь, без понимания причин её нужности. Напридумывать можно всякого, но пытаться это реализовать? Давайте сделаем соцсеть для..., это не идея вообще, а хотелка. Если говорить о концепции, то она реализуется комплексно, а не кусками в MVP.
Пользователи действительно идут от боли. Но, к сожалению, многие стартаперы за основу берут тех, решения, а не боли. И это грустно, да.
Но в случае с делайтерами типа соцсетей или игр ситуация сложнее. На старте эти идеи смотрятся как хотелки. Но их все равно придется тестить на прототипе или MVP, чтобы видеть эмоции пользователей. Это ключевое отличие от пейнкиллеров.
Про это кстати писали в другой статье неделю назад : https://vc.ru/services/1009334-kastdevy-yunitka-i-boli-ca-kak-za-4-ponyatnyh-shaga-uznat-vzletit-li-vashe-prilozhenie
Вы преувеличиваете значение кастдевов. Прежде всего, нужно сформулировать правильные вопросы, но это уже предполагает понимание проблемы, а вопросы уточняют. Вам честно ответят на вопрос, но всегда есть сопутствующие условия, при которых ответы актуальны, а это комплекс.
MVP призван решать главную проблему, если она есть. Я не знаю ни одной потребности, которая так или иначе не закрывалась бы, поэтому жизнеспособность MVP можно обеспечить только через комплекс решений, это и будет МVP по критерию жизнеспособности. Исключениями являются сугубо специальные сервисы для узкого круга. В таких я вообще смысла не вижу, это игра в песочнице.
В случае с соцсетями, нужен функционал, который качественно превосходит текущие возможности. У меломанов нет форумов и сообществ? Есть, так где идея?
Многих начинающих стартаперов отпугивает элементарное непонимание процесса: с чего начинать, как будет выглядеть результат и ид. Можно бесплатно смоделировать результат с помощью ИИ и получить вполне достоверный прототип исследования , а потом делать реальное . Я пишу в статье об этом https://vc.ru/1020507