Как создать стартап
Шрифт:
а) именно на его дату вдруг занято, а есть другая дата (в системе что-то напутали) и
б) предлагают провести оплату вне системы
В случае (а) клиент говорит что в сервисе работают мудаки и уходит. В случае (б) заработок сервиса равен нулю.
7) ЛкТуриста (№5) – Нет острой проблемы, узкая ниша, редкие транзакции клиента. Более менее ОК если сможешь сделать агрегатор скидок или решить проблемы в других сегментах в тревеле – командировочные сотрудники, бизнес-поездки, движуха вокруг эвентов.
Честно говоря, это был мой любимый проект из всех. Так тяжело его выкидывать! Я подумал, ну вот, я часто самостоятельно путешествую. Последняя поездка по Европе
Но увы, в реальности это не надо, гранаты не той системы. Финальный аккорд – наткнулся на отличную статью "Почему не стоит заниматься созданием сервисов для планирования путешествий" на вц.ру.
В 2х словах – экономика проекта не сходится. Лучший продукт не всегда означает хороший бизнес. Самостоятельно путешествуют 1%, узнают о вашем продукте 1% из них, воспользуются – 1% из вторых, а даже если воспользуются, то в следующий раз вернутся в приложение при следующем отпуске через 6-12 мес если вспомнят (CAC намного больше LTV, Retention в жопе, масштабируем убытки – ахиллесова пята B2C проектов). Основную прибыль зарабатывают первые в цепочке путешествия – отели и авиакомпании. Вторые в очереди агрегаторы и метапоисковики (букинг, скайсканер) откусывают от пирога немного. Приложение планировщик отпуска – третье в очереди и будет довольствоваться крохами от того, что не доели первая и вторая категории.
Какие проекты более-менее ОК по мнению биздева из YNDX:
1) ЗаявкаНаПокупку (№49) – Может сработать, особенно для трудно сравниваемых, но дорогих товаров "Хочу трешку в ЗАО за 16млн" или "Куплю подержанный джип не дороже 3х лямов". С точным определением товара хуже "Дайте самый дешевый iPhone XS Max 512GB Silver". Плюсы – большой чек. Проблемы тоже есть – у того же Циана или БН есть разделы на сайте "Оставьте заявку на покупку недвиги", но в полудохлом состоянии, видимо на все заявки спамят все АН без разбора. Короче, надо исследовать тему и особенно, клиентов, готовы ли они к такому сценарию "отложенной покупки".
2) УберКодревью (№71) – В целом ОК, но это B2B, длинный цикл сделки, сложно продать, есть проблемы с приватностью данных, если инхаус, наверно ок, надо поспрашивать тех же техлидов и руководство ИТ-компаний будет ли у них на это бюджет. Крутым компаниям проще пинать разрабов, ставить процесс кодревью или нанять доп архитекторов для ревью. А у мелких компаний и фриланса нет денег, т.к. они потому и мелкие и бедные что идут и ищут на подработке фрилансеров.
Это мой второй по любимости проект. Просто меня дико бесит, когда в команде кодят "на отвали", т.е. формально это компилится, работает, но ужасно написано, трудно поддерживается, с кучей ошибок и кода "и так сойдет" – магические константы, хардкод, копипаст, SELECT * там, где нужно тянуть мало данных с бэка на фронт и т.д. Самому ревьюить обычно нет времени, своих задач хватает. Т.е. я думал, что тема огонь. Особенно круто, если ПМ на стендапе будет видеть статус косяков, всплывших на ревью и в прямом эфире пропесочивать разрабов. Или внешний клиент, заказавший разработку индусам
В процессе исследования рынка по проблеме наткнулся на сайт pullrequestDotcom. Оказывается, "Убер для техлидов" (Codereview as a service) уже сделали. В мае 2017 проект был на продуктханте, они были в батче YC S17 и подняли 12.7M $ инвестиций. Ура! Я придумал проект, который прошел бы в YC! Но щас, похоже, сайт дохлый. Хотя CEO еще в феврале 2019 искал разрабов в команду. Не знаю, сдохли ли они или просто сайт тупит при доступе из РФ. Прайсинг у них, конечно, офигеть! 300$/мес за 1 дева и ревью 5тыс строк кода. А за команду из 5 разрабов 3500$ мес. Проще еще одного разраба нанять. Хотя, это цифры для США, там наверно это дешево.
Итого: выхожу к руководству курсов с предложением работать над ЗаявкаНаПокупку (№49) и возможно УберКодревью (№71) – копикэт проекты в целом тоже ОК для других юрисдикций и я точно его придумал сам:)
Дальше будет опрос про эти 2 проекта, какой ОК.
Занятие 2. Гипотезы
Определение гипотезы
Использование методологии SMART
Циклы HADI как способ ускорения развития продукта
Игра «HADI циклы»
Чему научитесь:
Корректно ставить цели. Тестировать гипотезы. Ускорять развитие продукта.
Посетил 2ое занятие курса по продукт менеджменту. Тема: Гипотезы, HADI-циклы, SMART.
Пусть простит меня лектор, но вау-эффекта не было. Далее идет скучный разбор занятия на десяток абзацев и не говорите, что я вас не предупреждал.
Тема, на самом деле, огонь. Гипотезы – это самая мякотка работы продакта, исследование реального мира. От занятия я ждал магии, неожиданных и неочевидных открытий и не побоюсь этого слова, гроусхакинга.
Что же было рассказано.
Теория: цели должны быть SMART, т.е. определенными, измеримыми, достижимыми, релевантными (это самое важное – иметь смысл, отвечать на вопросы "зачем я это делаю", "чтобы что") и ограниченными по времени.
Гипотезы надо выдвигать как можно чаще через HADI-цикл (гипотеза, действие, получение данных, инсайты).
Придумали гипотезу, поменяли бизнес-процесс (перекрасили кнопку на лендинге) поменялась конверсия, поняли ОК это или нет.
Классическое определение стартапа про временную организацию, организованную для поиска масштабируемой бизнес-модели.
Странный слайд про 4 вида организаций: простая, сложная, неопределенная и хаотическая. Тут я, каюсь, вспылил и спросил, что за хрень происходит и как слайд связан с темой занятия – гипотезами. Еще в презу добавить GTD и 7 навыков высокоэффективных людей и бинго! Отдаем Тони Роббинсу и он соберет с этой презой стадионы. Вырулили в итоге на то, что из 4х типов компаний HADI подходит только типу 3 "неопределенные" (с чего это вдруг?), а к ним относятся стартапы и значит HADI+startups=love