Comments 17
спасибо за статью! в контексте того, что происходит в нашем импортозамещении - актуально.
довольно длительное время (полтора года) работаю над крупным проектом, и на определенный момент встал перед выбором - выпустить MVP, обрезав функционал и положиться на использование сторонних библиотек, или упереться лбом и вести разработку до релиза в том виде, в котором изначально задумывался продукт.
покрутил-повертел MVP.. и продолжил писать - в этом виде система превращалась в ещё одну из десятков аналогичных, с разницей в виде монетизации и с перекрашенными кнопками, с напрочь убитой изначальной идеей. и эта самая изначальная идея просто-напросто не получила бы развития в дальнейшем - костыли/сторонние либы вросли-бы в код, и вместо внедрения ключевых фишек пришлось-бы сосредоточиться на обрастании (не всем нужным) функционалом.
что осознал (или подтвердил на личном примере), двигаясь по дорожке разработки без MVP:
вы не сможете оценить востребованность продукта на более-менее ранней стадии, что позволило бы более-менее безболезненно отказаться от концепции / сменить вектор разработки при её провале.
готовьтесь к тому, что бюджет закончится. совсем. время разработки увеличилось, притока денег нет.
проблемы найма - см. предыдущий пункт, плюс - на ранней стадии требуются действительно скилловые (читай - высокооплачиваемые) сотрудники. также возрастают затраты на контроль разработки, повышенные требования к ведению документации, большая нагрузка на позицию архитектора приложения. т.е. либо готовиться к соло-разработке, либо нужно иметь действительно внушительный бюджет.
старт будет труднее - если в случае с MVP ещё есть какой-то бюджет на рекламу - то тут придётся покрутиться.
надо быть морально готовым к провалу. я не к тому, что нацелен на него, конечно, но сколько раз видел коллег с горящими глазами - "моя убер-система нагнет рынок!" - и... околонулевые продажи, разочарование. в этом случае особенно тяжело воспринимается затраченное время. просто стоит расценивать как опыт, плюс наработки никуда не денутся.
если востребованность продукта на выбранном направлении высокая - конечно же, появятся решения конкурентов, которые пошли по пути MVP. и разработку начать могли позже, и нишу займут. ещё раз вспомнить ключевые фичи, ради чего всё начато и к чему стремишься придти.
блин, не комментарий получился, а крик души :)
Пожалуйста, рад, что понравилась:)
Какая дельта ценности для клиента между MVP и полностью готовым решением?
дельта ценности - незнакомый для меня термин
имеется ввиду оценка, насколько наличие функционала полной версии повлияет на принятие положительного решения о покупке? вопрос - как измерить, тут несколько факторов.
немного другой таргетинг, есть ключевые особенности, которые для одной группы могут быть важны, а для другой - малозначительны. как это измерить?
p.s. хотел проголосовать за комментарий, но промахнулся :( а исправить почему-то нельзя :( простите. (но плюсанул в карму - пожалуйста, пишите ещё, подписался)
Ничего страшного)
Я имел ввиду даже не столько о принятие положительного решения о покупки, сколько о том, насколько вырастит ценность полной версии для целевой аудитории.
Условно MVP = X ценность, а полная версия = 10X ценность. То есть, если полная версия может на порядок больше ценности доставить определенному сегменту и есть все основания предполагать, что это так, то усеченную версию делать смысла нет.
Единственное, пока писал вспомнил историю.
Ребята делали решение для андеррайтинга в банках и должны были написать программы для 20 разных кейсов. Проблема была в том, что у них денег на пару месяцев оставалось, но у них уже были коммиты в банках на внедрение.
Они пошли поговорили со всеми, выделили 3 основных кейса, запили их, получили деньги и пошли с остальными кейсами работать.
Возможно, ситуация похожая и можно как-то выделить ключевые классно работающие функции и продать, а потом продолжить.
Продолжая условность MVP = X ценности, а версия с тремя функциями = 4X ценности
а. тут так. я не представляю эту шкалу. т.е. они хоть и близкие по назначению - но очень разные, нельзя тут проводить оценку по количеству фишек. детали - то, что я делаю, можно принять за "что-то вроде атлассиан". и все замещают и замещают.
для меня же - вот я несколько лет назад был не согласен с этой подачей. ну не нравится мне - та же система документации - confluence - где-то избыточна, и неудобна. я работал на крупную компанию, и они сначала выбрали notion, а потом стали делать своё (не знаю, как сейчас у них). нельзя просто "я буду делать то-то и то-то, только круче". важно понять - что, зачем, почему.
моя концепция разработки - сделать удобно. я, кроме того, что программист с опытом в четверть века - специалист по ui/ux.
возвращаясь к вопросу - как оценить кейсы, когда о них никто не задумывался? или - я вот не хочу просто по историческим причинам, в ущерб своему доходу делать подписки. до 5 пользователей бесплатно, или лайфтайм лицензия на пользователя. это вот влияет?
вобщем, чем ближе я к релизу, тем страшнее ))
возвращаясь к вопросу - как оценить кейсы, когда о них никто не задумывался? или - я вот не хочу просто по историческим причинам, в ущерб своему доходу делать подписки. до 5 пользователей бесплатно, или лайфтайм лицензия на пользователя. это вот влияет?
Сложно без конкретики, но если никто не задумывался о том или ином кейсе, то это может по двум причинам происходить:
1) Существующее положение вещей всех устраивает и нужно понять почему. Таким образом можно будет сделать предположение, как с помощью моего решения изменится жизнь клиента и насколько для него это изменение может быть ценно?
2) Я глубоко погружен в процессы в той или иной области и уже просто вижу то, чего другие не видят. Вопрос такой же, как с помощью моего решения изменится жизнь клиента и насколько для него это изменение может быть ценно?
Понимаю, что это все на уровне предположений будет, но если обдумывать каждую отдельную ситуацию со всех сторон (аудитории, контексты, задачи и тд), то можно собрать достаточно полную картину и делать выводы
Возможно, есть еще какие-то причины, по которым никто не задумывался, мне только два сразу в голову пришло
не сможете оценить востребованность продукта на более-менее ранней стадии
Здесь учебник говорит, что надо сделать сайт, расписать на нем кто и как будет пользоваться продуктом и дать ссылку на скачивание в никуда. За полгода посмотреть статистику нажавших ссылку на скачивание. Вполне себе оценка продукта. Почему нет?
В последнее время всё чаще говорят об MLP - Lovable продукте. Тоже в некотором роде попытка вырваться из ловушки тыщ повторяющихся идей. Только тут рынок челленджится не за счёт новой категории, а за счёт новой эмоции. Типа "а что, так можно было?!"
о, хорошая концепция :)
Кажется, это про одно. Потому что, и новая категория и новая эмоция про создание новой схемы в голове потребителя. Вчера писал об этом подробнее в телеграме, если интересно сюда скопирую текст поста
С разных боков заход на ту же цель, да. Новая схема - это и есть "а так можно было?"
Выглядит как XY problem: где-то в душЕ все хотят некий Maximal Profitable Product, но делают что-то совсем другое. А потом ещё ноют, когда у них не получается.
Ага
Возможно, в статье есть некоторое смешивание (нестыковка) целей стартапов. Ведь от стартапа можно хотеть:
выпустить востребованный продукт;
заработать денег;
получить инвестиции.
Насколько понял из статьи, если цель стартапа это получить инвестиции, а инвесторы, в свою очередь, оценивают привлекательность на основе mvp - то именно туда и нужно вкладываться. Образно: банку для финансирования требуется бизнес-план - ок, создадим бизнес план; школьному учителю для отличной оценки требуется чтобы ученик знал параграф - ок, выучим параграф. Так знание параграфа ещё не означает знание предмета!! - Ну и что?!
Про "... Сейчас для решения любой задачи найдется с десяток предложений ..." - очень похоже на некоторую предвзятость. Например: 3D-принтеры для печати домов (насколько понимаю) всё ещё в начальной стадии; аккумуляторы электроэнергии (наподобие башни бетонных блоков, гидроаккумуляторы) - ну они как бы есть, но не разбежишься; дроны для исследования пещер - там тоже масса затыков; летающий автотранспорт (на одного-двух человек). И как-бы на исследования и апробации не сумасшедшие вложения требуются. Да, возможно не получится взять бетон, "... прикрутили ChatGPT ..." и он стал ровнее ложиться. Так это проблема не бетона, да?
Ведь от стартапа можно хотеть:
выпустить востребованный продукт;
заработать денег;
получить инвестиции.
Не совсем понял, почему это какие-то равнозначные цели. Для меня инвестиции и деньги — результат запуска востребованного продукта или веры в его востребованность после запуска. Можешь развернуть свою мысль?
Про "... Сейчас для решения любой задачи найдется с десяток предложений ..." - очень похоже на некоторую предвзятость. Например: 3D-принтеры для печати домов (насколько понимаю) всё ещё в начальной стадии; аккумуляторы электроэнергии (наподобие башни бетонных блоков, гидроаккумуляторы) - ну они как бы есть, но не разбежишься; дроны для исследования пещер - там тоже масса затыков; летающий автотранспорт (на одного-двух человек). И как-бы на исследования и апробации не сумасшедшие вложения требуются. Да, возможно не получится взять бетон, "... прикрутили ChatGPT ..." и он стал ровнее ложиться. Так это проблема не бетона, да?
Почему ты приводишь в пример хардверные штуки, где я писал про них? Ни на PH, ни в YC таких нет. Речь исключительно про цифровые продукты. Честно, мне казалось, что это считывается
Как минимально жизнеспособный продукт стал максимально переоцененной концепцией