MINISOL
Это стартап, там много рисков))
Но если ваша гипотеза подтвердится и мы сможем убить коррумпированный рынок, то точно взлетит!
Тем не менее с моей точки зрения это приложение не про взлет, рынок маленький для того, чтобы сделать единорога. Тем не менее это может быть хороший стабильный небольшой saas с дивидендной моделью.
Артём, да, сервисы такие есть, мы их смотрели и изучали конечно же.
В чем плюс таких сервисов? в закрытии множества вопросов одним приложением.
В чем минус?... в этом же) чем больше вопросов решает сервис в консервативной оффлайновой структуре, тем сложнее его внедрить. И это самая сложная задача. По крайней мере наше исследование показало, что очень многим не нужен функционал вокруг, а достаточно лишь специализированного сервиса для закрытия одной потребности. Меньше стоимость, меньше сложностей внедрения -> быстрее принятие решения и выше конверсия.
Данил, классная мысль, спасибо!
Общая задача учета отлично вписывается в концепцию сервиса. Подумаем в эту сторону тоже ;)
Василий, пока не считали, но думаю ~1 млн и пару месяцев для запуска первой версии. Но сложность этого проекта не в разработке...
Мы придумали гипотезу более дешевого и быстрого варианта выхода на рынок и хотим её протестировать. Подробности, увы, рассказать пока не могу. Но в будущих статьях точно напишем, сработает или нет.
Помимо просто удобства это ещё и скорость, пропускная способность. В каких-то случаях это означает возможность содержать только 1 охранника, а не 2-х, либо упразднить бюро пропусков. Я понимаю, что это все не очень дорого, сервис все равно дешевле.
У сервиса есть множество дополнительных преимуществ:
- отчеты и статистика
- история в удобном виде с поиском
- возможность хранить фото каждого посетителя/машины (то, с чем не справится журнал бумажный)
- ускоренная процедура при повторном посещении
- взимание платы (бывает платный въезд машин, например)
Вообще задачи по пропускному режиму действительно разнообразны, мы когда начали погружаться в тему, открыли для себя много нового)
Готовы, мы это проверили.
1. Охранник из ЧОПа стоит не 20К в месяц, а если речь идет о коменданте за 20к, то да, это скорее всего не наш клиент пока (возможно сможем придумать как автоматизировать именно чтобы заменить вообще таких комендантов и платить не 20К им, а например 5-10К за сервис)
2. Дед-охранник с СБ? нет, это фантазии. Там, где есть СБ, там нет деда и есть 5-10к на сервис пропусков.
Николай, и да, и нет.
1. Скорее всего вы говорите про Москву. Да, тут много чего автоматизировано, хоть и не всегда удобно
НО
2. Есть ещё регионы
3. Есть ещё коттеджные поселки
4. И даже в Москве есть старые заводы, НИИ и т.п., где, в отличии от БЦ, не так все классно
Верно, риск и силы. Это то, что должно быть у стартаперов. Мы же помогаем экспертизой, опытом и насмотренностью не совершить неправильные шаги и не потратить лишние деньги. Либо ускориться, если уже выбрана потенциально верная тактика.
И да, мы не стрижем по 500к, а честно их зарабатываем ;) и именно поэтому можем показывать цифры в кейсе, что делают очень редко. И по стоимости своих услуг, и по результатам.
Александр, спасибо)
Для запуска бизнеса нужно инвестировать в команду, разработку, рекламу. Также необходимо, чтобы кто-то лидировал процесс, сильный фаундер.
То факт, что там ниша на 250 млн не говорит о том, что это легко и просто. Да, мы знаем, как это делать. И у нас есть проекты, где мы становимся ко-фаундерами, и это действительно один из таких примеров. Тем не менее выделять команду целиком под проект, инвестировать деньги в разработку и рекламу, ставить своего фаундера у нас нет возможности, это разрушит текущий бизнес.
Сергей, классная мысль, мы тоже пришли к похожей ;) Заполняет форму и получает QR-код, который показывает на охране. Охрана с помощью мобильного считывает код и пропускает посетителя.
Есть ещё и альтернативные механики, когда анкету заполняет сам собственник, а посетитель получает код из 4х цифр — это вариант для владельцев кнопочных телефонов, которым доступны только смс.
Спасибо за классные вопросы, тут есть о чем поговорить!
Ответьте мне на такой вопрос по примеру вашей кофейни. Если продакт должен уметь делать прототипы для проверки своих гепотиз, то что из себя будет представлять прототип для кофеин с пандусами?
Я бы проверил гипотезу следующим способом:
Повесил листик А4 рядом с входом в кофейню на уровне глаз человека в коляске с текстом: для заказа кофе позвоните бариста по номеру +7-999-999-99-99 и он вынесет вам кофе и терминал для оплаты картой.
Что я получу в итоге эксперимента? Количество заказов, которое я не получил бы без этого листика и это та доп.выручка для кофейни, которая будет УТП сервиса и основой монетизации.
Кстати можно даже попробовать померять средний чек, частоту покупок и LTV, если вести базу звонков и вести лог: номер телефона / дата / сумма чека.
Что я не получу в итоге эксперимента? Данных о стоимости привлечения пользователей в сервис. Увы, потому что я буду использовать для эксперимента только естественный трафик.
Цена проверки гипотезы — листик бумаги и договоренность с кофейней. Второе, конечно, непростая задача, но кажется это тоже вполне проверка гипотезы сервиса, ведь без таких договоренностей сервис не запустить.
Верю, что есть и другие способы, я описал то, как это делал бы лично я.
Если менеджер не программист, то какое он ТЗ составит?
ТЗ всегда составляет исполнитель. То есть программист в данном случае. Продакт (я так понимаю в вопросе о нем) пишет список хотелок. После обсуждения с разработчиками он становится списком требований, и уже на основе этого пишется ТЗ.
Продакт говорит ЧТО ему нужно от программного продукта, он понимает конечный результат, который хочет получить, но не знает КАК его достичь. Разработчики же наоборот, понимают КАК, но не знают ЧТО. ТЗ кстати формализует ЧТО и описывает КАК.
П.с. Есть менеджер из вопроса был проджектом, то он должен координировать работу по выполнению и точно не должен писать ТЗ
Почему прожект анализирует потребности, и каким образом при отсутствии представления о потребностях продакт выводит гипотезы?
Ответ на вопрос Почему содержится во второй части вопроса — чтобы иметь представление о потребностях для формирования гипотез. При отсутствии данных о потребностях гипотезы будут из воздуха и смысла не имеют.
Часто бывает такое, что продакт может формировать гипотезы исходя из своих потребностей или представления о них. Это называется субъективное мнение и в этом случае продакт может угадать или не угадать. Супер-чуйка и удача, конечно, бывают, но исследования и цифры снижают риски принятия решений на основе мнения одного человека. Поэтому лучше все-таки изучать потребности сначала, иначе стартап или компания будет избавлять от боли, которой нет. Это, кстати, одна из основных причин краха стартапов.
Что такое - большая команда?Для меня этот параметр зависит от размера компании. Для компании из 3-х человек команда из 2-х уже большая. А для корпорации с 5000 человек команда 30 человек будет маленькой.
Назовите крупные компании делающие собственные продукты у которых так, как вы описали.
Я не понимаю, к чему именно относится вопрос( В статье больше про трансформацию опыта сотрудника, чем про разработку продуктов компаниями. В крупных компаниях много согласователей, бюрократии и регламентов, поэтому они и создают акселераторы внутри себя или покупают стартапы и растят внутри — Сбер, Яндекс, Mail, МТС, Газпром, РЖД.
Возможно я отвечу более конкретно, если вы уточните вопрос
Николай, сделали такую подборку:) https://vc.ru/hr/248319-bolshaya-podborka-dlya-menedzhera-digital-proektov-100-poleznyh-materialov-dlya-obucheniya-i-rosta
Согласен с комментариями выше, все справедливо — поменял.
Зависимость для нас прямая, но конечно LTV в деньгах, а в годах срок жизни
п.с. меряем мы LTV, но в паблике я решился показать только срок, а не деньги, поэтому все и смешалось
Николай, у наших друзей из IT-Agency есть план обучения менеджера, дает отличный практический результат: https://www.it-agency.ru/academy/manager-plan/
И спасибо за идею, сделаем подобную текущей подборку для менеджера проекта)
Если что-то могло пойти не так, то так и будет) вам достался счастливый билет понаблюдать за выкаткой чего-то нового на сайт.
Спасибо! поправили, теперь все так как должно быть
Руслан, спасибо за обратную связь)
Мы так и старались объединить максимум пользы в одном месте) Рады, что материал полезен.
Для БЦ, НИИ, завода не нужен функционал лицевых счетов, передачи показаний и вот это все. В данном случае речь не про цену, а про задачи и про удобство. Как выше подсказали хорошую идею, для университета тоже
Для домов и поселков доп функционал нужен, но не всегда. Есть масса и домов и поселков, в которых ничего нет.
Мы нашли своих клиентов, которые сказали "да") нет иллюзий, что данный сервис на 100% подойдет всем, конечно нет. Но ниша есть, а значит можно работать.
А то, что всегда найдется отговорка почему нет, почему это не нужно и т.п. — так это точно, Биллу Гейтсу тоже говорили, зачем человеку дома нужен компьютер)