"Как разработать продукт (сайт, приложение)? Я ничего в этом не понимаю". *** Никак. Нельзя "ничего в этом не понимать" и создать успешный продукт. Инвестируй в то в чем понимаешь или понимай то во что инвестируешь.
Реальность такова, что таких стартаперов становится все больше, по личным ощущениям. Возможно, дело в том, что люди с деньгами из традиционных отраслей ищут, куда бы инвестировать на фоне стагнации в традиционной экономике - вот такое у меня лично объяснение.
Поэтому и писался материал, потому что вопросы жизненные.
> Чтобы бизнес был прибыльным, стоимость привлечения одного клиента (CPA — cost per acquisition) должна быть больше вашего общего заработка с этого же клиента за все время его жизни (LTV — lifetime value) — CPA < LTV.
Не надо давать таких вредных советов заказчикам. Если все потенциальные клиенты будут так делать, то большая проектов умрет на стадии "Убедитесь, что ваш продукт будет востребован" и большинство разрабов с голодухи перемрёт.
Но, может, в долгосрочной перспективе и лучше, что неуспешных проектов будет меньше?
На 100% проверить, что продукт будет востребован и будет генерировать прибыль, можно только построив продукт.
На одной конференции услышал интересную мысль "Время довольных клиентов прошло. Нужно, чтобы ваши клиенты были успешными". Как разработчик, представьте, что лучше (1) к вам приходит клиент, вы ему разрабатываете проект, который не взлетает, и потом клиент не возвращается (2) проект "взлетает", и клиент приходит к вам опять за доработками.
Чёт автор немного попутал. В этой схеме второй вариант тоже можно зачеркнуть, потому как он подходит только для запустившегося продукта, которых хоть что-то генерит.
При запуске продукта нужно понять его востребованность и состоятельность вживую, а не работать со сферическими метриками. Где пресейлы, кастдев, проверка на прототипах и т.д? Юнит экономика не спасет, если ты не понимаешь юнитов.
Я, возможно, не совсем правильно донес мысль. Все, про что Вы говорите ("пресейлы, кастдев, проверка на прототипах") включено во второй диаграмме в "Реализовали / доработали продукт" и "Сняли обратную связь". Просто не детализировано. Можно считать прототип первой версией продукта.
Диаграммой же пытался донести мысль о цикличности действий по разработке / запуску в такой "быстрой" отрасли, как ИТ (да и уже во многих других традиционных так же). Просто многие все еще мыслят категориями "сколько нужно денег, чтобы разработать продукт", не понимая постоянности этого процесса.
Сережа, не дурите людям голову. 300 часов на приложение, 800 на сайт) ибо вы этим формируете неоправданные ожидания у той группы людей, которые это все читает и верит в чудеса. Разброс от проекта к проекту будет настолько сильный, что предсказать это просто нельзя. И почему вы пишете о разработчике, а UX, а дизайн, а тестирование, а администрирование сервера, а менеджмент, я бы ваши оценки смело умножил на 3 и назвал бы это потолком для MVP, куда больше будет походить на правду
Вы абсолютно верно подметили, что разброс может быть гигантским, но в статье постарался явно упомянуть, что цифры примерные, для понимания порядка. То есть простое мобильное приложение - это не 30, но и не 3000 часов. За 300 часов вполне есть очень простые проекты, так же как и простые вебсайты за 800.
По поводу UX/UI/менеджмент/тестирования, это частично заложено в стоимости часа студии, если мы смотрим стоимость часа по различным вариантам подрядчиков (и не заложено, например, в просто программисте), хотя, возможно, нужно было описать это более явно. Не было идеи очень подробно расписать структуру затрат на MVP, это могло бы быть темой для следующей статьи :) чего точно не хотелось - так это дать чересчур оптимистичные цифры.
"Как разработать продукт (сайт, приложение)? Я ничего в этом не понимаю".
***
Никак. Нельзя "ничего в этом не понимать" и создать успешный продукт.
Инвестируй в то в чем понимаешь или понимай то во что инвестируешь.
Так умиляют все эти статьи для мамкиных стартаперов)
Реальность такова, что таких стартаперов становится все больше, по личным ощущениям. Возможно, дело в том, что люди с деньгами из традиционных отраслей ищут, куда бы инвестировать на фоне стагнации в традиционной экономике - вот такое у меня лично объяснение.
Поэтому и писался материал, потому что вопросы жизненные.
> Чтобы бизнес был прибыльным, стоимость привлечения одного клиента (CPA — cost per acquisition) должна быть больше вашего общего заработка с этого же клиента за все время его жизни (LTV — lifetime value) — CPA < LTV.
Все таки меньше, а не больше.
Сорри, опечатка, уже поправила редакция.
Не надо давать таких вредных советов заказчикам.
Если все потенциальные клиенты будут так делать, то большая проектов умрет на стадии "Убедитесь, что ваш продукт будет востребован" и большинство разрабов с голодухи перемрёт.
Но, может, в долгосрочной перспективе и лучше, что неуспешных проектов будет меньше?
На 100% проверить, что продукт будет востребован и будет генерировать прибыль, можно только построив продукт.
На одной конференции услышал интересную мысль "Время довольных клиентов прошло. Нужно, чтобы ваши клиенты были успешными". Как разработчик, представьте, что лучше (1) к вам приходит клиент, вы ему разрабатываете проект, который не взлетает, и потом клиент не возвращается (2) проект "взлетает", и клиент приходит к вам опять за доработками.
Чёт автор немного попутал. В этой схеме второй вариант тоже можно зачеркнуть, потому как он подходит только для запустившегося продукта, которых хоть что-то генерит.
При запуске продукта нужно понять его востребованность и состоятельность вживую, а не работать со сферическими метриками. Где пресейлы, кастдев, проверка на прототипах и т.д? Юнит экономика не спасет, если ты не понимаешь юнитов.
Я, возможно, не совсем правильно донес мысль. Все, про что Вы говорите ("пресейлы, кастдев, проверка на прототипах") включено во второй диаграмме в "Реализовали / доработали продукт" и "Сняли обратную связь". Просто не детализировано. Можно считать прототип первой версией продукта.
Диаграммой же пытался донести мысль о цикличности действий по разработке / запуску в такой "быстрой" отрасли, как ИТ (да и уже во многих других традиционных так же). Просто многие все еще мыслят категориями "сколько нужно денег, чтобы разработать продукт", не понимая постоянности этого процесса.
Сережа, не дурите людям голову. 300 часов на приложение, 800 на сайт) ибо вы этим формируете неоправданные ожидания у той группы людей, которые это все читает и верит в чудеса. Разброс от проекта к проекту будет настолько сильный, что предсказать это просто нельзя. И почему вы пишете о разработчике, а UX, а дизайн, а тестирование, а администрирование сервера, а менеджмент, я бы ваши оценки смело умножил на 3 и назвал бы это потолком для MVP, куда больше будет походить на правду
Вы абсолютно верно подметили, что разброс может быть гигантским, но в статье постарался явно упомянуть, что цифры примерные, для понимания порядка. То есть простое мобильное приложение - это не 30, но и не 3000 часов. За 300 часов вполне есть очень простые проекты, так же как и простые вебсайты за 800.
По поводу UX/UI/менеджмент/тестирования, это частично заложено в стоимости часа студии, если мы смотрим стоимость часа по различным вариантам подрядчиков (и не заложено, например, в просто программисте), хотя, возможно, нужно было описать это более явно. Не было идеи очень подробно расписать структуру затрат на MVP, это могло бы быть темой для следующей статьи :) чего точно не хотелось - так это дать чересчур оптимистичные цифры.