1339 подписчиков
Как мы сэкономили на разработке MVP
Привет, на связи автор канала РОСЛОВЕЦ и в этом посте я расскажу, как нам удалось потратить сумму на разработку минимального продукта в 5 раз меньшую, чем оценивает рынок.
Ситуация: у нас б2б продукт, калькулятор расчета изделий из камня.
👻Наш продукт упрощает жизнь бизнесу и помогает просчитывать онлайн столешницы и другие изделия, выставлять клиенту коммерческие предложения и анализировать бизнес-данные, которые мы предоставляем.
Ниже рассказываю, как мне, как продакту удалось сэкономить на разработке и возможно мой опыт вам поможет.
😁 Быть противнейшим человеком на свете. Резать все хотелки к чертям! Оставлять только то, что относится к важнейшим ценностям для потенциального покупателя и за что они готовы платить. Фокусироваться только на том функционале и тех фичах, что относятся к монетизации.
Когда разрабатываешь продукт и ты эксперт в своей области, видение начинает уходить далеко вперед, ты стараешься засунуть туда то, что как тебе кажется обязательно нужно и никак иначе. В 30 процентах случаев эксперт прав, в остальном-его профессиональная деформация.
💃 Нанять сильного архитектора. Одного. Самого самого. И не жадничать. Он будет валидировать всю разработку, он максимально постарается выстроить все на готовых блоках и максимально универсален. Во времена экономии денег, когда один человек на всех ролях и нет времени и ресурсов искать под каждую задачу исполнителя, это будет золотой человек и единственный из команды, которые не будет спать ночами!
😘 Готовые блоки и сервисы. Нужен лендинг - берем тильду, нужен сложный код - сначала ищем готовые библиотеки. Нужно развернуть сервис- берем облако + облачные сервисы. Не надо писать с нуля "свое" на будущее. Частенько фаундеры относятся к своему продукту, как к погремушке. У меня, кстати, есть пост про фокусировке на технологии, в котором я рассказываю свой кейс, как технология нас "убила".
😎 Искать исполнителей, которые не про "напишите мне сначала подробное тз", а которые сами задают вопрос и погружаются. Да, многие скажут, что это вообще риск для исполнителя и такой подход применим только к адекватным заказчикам. Иначе можно нарваться на бесконечные переделки и на то, что часов в ходе выяснения на работу будет затрачено больше. Но бизнесу на этапе MVP очень тяжело писать подробные ТЗ и следовать ему от корки до корки. Теряется гибкость.
Я Фаря, автор канала о разработке и запуске продуктов @xuyanet. Не смотри на название, оно было шуткой)
Вот тебе еще мои статьи, которые тебе могут быть полезны:
Подписывайся @xuyanet
#интеграция
2 минуты
2 ноября 2023