спасибо за ответ. да все это имеется, никто не застрахован он успеха :)
и как указано в первом видео к курсу, по статистике 80% продукта проваливаются (может и больше, если продукты умирают на более ранней стадии). почему? совокупность факторов. и время и рынок и циклы в экономике, и технологическая недостаточность.
какие конкретно вещи надо улучшать в конкретному продукте — это уже менторство, акселераторы, эдвайзинг и консультирование. а так же метод проб и ошибок :)
Константин, спасибо большое за такой хороший вопрос. Действительно это тот аспект, который многие обучающие курсы пропускают и не акцентируются на нем. В некоторой степени так и в моем курсе было, конспекты которого можно прочитать тут на Хабре.
О чем я упомянул в некоторых частях этой саги так это о том, что не стоит сразу же воплощать идею которая пришла в голову в программный продукт (делать «коробку которая кричить»), но еще и провалидировать эту идею на какие-нибудь потенциальных клиентах и собрать обратную связь с рынка. И только если кто-то нашелся кто за это потенциально готов заплатить — только тогда заниматься разработкой.
То что я вижу вокруг себя, когда работаю со студентами или с будущими основателями стартапов — они часто ходят с «готовыми» идеями и им лишь интересно как это запаковать в продукт или как проверить свою идею на рынке. Практически никогда не встречаю людей, которые приходят и спрашивают у окружающих — что бы такое сделать? «желание и силы есть, а идей нет» — невероятно редкий кейс. Но что я действительно часто вижу — у будущего фаундера (или его команды) есть идея и они готовы ее воплощать в жизнь, но когда начинают по всем канонам продакт-менеджмента эту идею прорабатывать, валидировать и смотреть на реакцию рынка — тогда изначальная идея умират и трансформируется в что-то немного другое или совершенно другое. Получается, что действительно команда может создать что-то такое, о чем изначально даже не задумывалась. Но при этом если не было какой-то другой изначальной идеи — то до работающей идеи они не дошли бы :)
Мы пишем требования в Confluence от Atlassian. Это (если не пользовались) такая wiki-система для написания текстов с медиа вставками, плюс там есть тесная интеграция с Jira — нашей трекер-системой. По сути подходит любой текстовый редактор, желательно с возможностью вставки таблиц, диаграм, рисунков и ссылками на сопутствующие материалы.
Спасибо за очень хороший комментарий. Вы абсолютно правы, в данном фреймворке Product Vision и Product Strategy расположены за рамками фреймворка, подразумевая, что то что создается — соответствует виденью компании и дальше уже дело за деталями — определения рынка, пользовательской аудитории, соответствие рыночному запросу той технологический экспертизе которая есть в компании. Поэтому в идеально картине мире, можно миксовать разные фреймворки, чтобы заполнить все области. Либо же создать свой, скомбинировав самое важное.
В достаточно широко развитом B2B-продуктах, коммуникации с клиентами выстариваются достаточно свободно и самих потребителей не так много, как в B2C-продуктах. Тем более что можно в первую очередь общаться с теми, кто приносит большую часть прибыли (это отличие от B2C-продуктов, где как правило цена потребления продукта не отличается от клиента к клиенту).
Но даже в B2C-продуктах можно заниматься сбором статистики и аггрегации пользовательских паттернов, чтобы сформировать группы пользователей, которые отличаются своим поведением. Это помогает в разработке, но уже не помогает в маркетинге. Для маркетинга необходимо делать разные посадочные страницы под разных пользователей, которые в итоге приводят к одному продукту.
Определение профиля персоны очень важно в маркетинге, когда коммуникация выстаривается через определенный язык, формат, стилистику и с отсылкой к каким-то «фишкам» и понятиям которые понятны для этой аудитории. Так можно получить гораздо большую конверсию от лидов к закрытыми сделкам, потому что люди чувствуют что с ними разговривают на одном языке.
А с точки зрения разработки продукта — я вижу, что разработчики часто спрашивают продакт-менеджеров — расскажите для кого мы создаем продукт. Кто эти люди? Почему они им пользуются? Ответы на эти вопросы помогают создать эмоциональную связь между «творчеством» разработчиков и потребителями.
Ваш ответ «Вы серьезно?» выглядит так, как будто мой вопрос «Какие проблемы и сложности?» подразумевал, что таких проблем и сложностей нет. Конечно же это не так, но я хотел у вас выяснить что именно вас беспокоит и интересует, чтобы дать ответ по этому вопросу.
Что касается денег — про расчет финансовой модели создаваемого продукта будет отдельный пост — из модели можно понять сколько компания собирается потратить на разработку и с учетом предложенной цены, будет ли игра стоит свеч.
Если же вы про привлечение инвестиций, чтобы в принципе начать дело, то это тема для отдельного курса :)
Данный пост — первый из серии постов, которые будут делится с читателями Хабра той информации, которая озвучивалась на курсе. Далее пойдут детали про каждый из блоков фреймворка и я уверен, многие стартаперы могут подчерпнуть кучу полезного для себя.
Сразу замечу, что в курсе не затрагивались вопросы связанные с регистрацией компании в госорганах, открытия банковского счета, найма сотрудников, привлечения инвестиций, аренда офиса. Курс был про то как создавать продукты, которые будут востребованы и как сделать так, чтобы про ваш продукт узнали многие и вы смогли его продавать.
Можно вас спросить, какие проблемы, сложности и вопросы есть в «мире реального стартапа», чтобы я понял какая тема с вашей точки зрения должна быть детально раскрыта?
Спасибо за подробный комментарий, тем более с указанием конкретных проектов и их функционала.
В моем списке были представлены те продукты, с которыми мне довелось или поработать или плотно исследовать. Вполне вероятно, что список надо расширять и дополнять. Тем более, проекты развиваются очень быстро и все смотрят на конкурентов для того, чтобы не упустить реализацию какой-нибудь фичи.
Что касается обзора коммерческий решений, то их гораздо сложнее получить в использование для того, чтобы составить полноценный обзор. Можно конечно сделать вывод только сравнивая презентации и datasheet, но желательно конечно получить такой обзор от тех пользователей, на сетях которых уже присутствуют такие продукты.
Вам доводилось внедрять или эксплуатировать какие-нибудь из представленных решений?
Спасибо, что читаете и делитесь своими комментариями!
И уверен, что не сколько сетевикам, сколько людям от бизнеса интересней узнать о работающих проектах.
Ведь сетевик был бы рад поработать с любой инновацией, если в нее будут вложены деньги. И технарей как правило не нужно убеждать попробовать что-то новое. А вот тех, кто инвестирует свои средства в будущие проекты — они гораздо больше задумываются о том, где это уже взлетело и стоит ли туда вкладывать.
Но тут можно попасть в интересную петлю. Если операторы долго будут ждать, пока кто-то другой у себя внедрит какую-то технологию и докажет рынку, что это работоспособно, то эти операторы могут просто изчезнуть с рынка, так как не успеют подготовиться к изменениями.
Простой пример с виртуализацией вычислительных ресурсов показал очевидную эффективность в повышенной утилизации железа и создания слоя абстракции между оборудованием и операционной системой.
Думаю крупные операторы осознают необходимость изменений, но им требуется решение, которое работает. Один из выводов статьи как раз в том, чтобы уже сейчас начать применять бесплатные решения в пилотах, чтобы персонал был готов к внедрению и использованию того решения, которое им предложат технологические вендоры.
Заменить «железный» файрвол на программный — это может быть первый шаг. Заменить «железный» BNG\BRAS на программный может быть вторым шагом. И так далее.
Про коллег из ЦПИКС не просто слышал, но и лично знаком с многими. Очень правильный вектор держат и желаю им успехов!
На семинаре по Cisco ACI демонстрировали возможности контроллера APIC, в который можно загрузить Device Package — подготовленный образ ВМ от других вендоров для реализации конкретной сетевой функции, в которые по заданному API-интерфейсу передается конфигурация во время применения этого device package к сервисному графу для реализации network function.
Демонстрация показала как в автоматическом режиме можно сетевые функции применять к трафику. Настраивать в консоле каждую ВМ с сетевой функции не было необходимости.
Не уверен, что технологические вендоры-лидеры будут игнорировать стандарт ETSI MANO. Чтобы это понять достаточно посмотреть на список компаний, в которых работают авторы этого стандарта:
NEC, Tech Mahindra, Orange, Cisco, Amdocs, Wind River Systems, Alcatel-Lucent, HP, Oracle, Orange, Juniper, ZTE, Intel, Telecom Italia, Wipro, EnterpriseWeb, NSN, Huawei, ASSIA, Telefonica, China Unicom, AT&T, Verizon, Docomo, Deutsche Telekom, Sprint, Vodafone, 6Wind, BT, tech Mahindra, Sonus, Brocade, ETRI, Ooredoo, Fujitsu, Ericsson.
А долго это один год или пять лет? :)
Мне видится, что сейчас такое время, когда в ближайшее время могут выстрелить сразу несколько вендоров со своими решениями по «магазину VNF приложений». Cisco аналог показывала где-то год назад в рамках функционала APIC-контроллера. NEC со своим SDN space призывает производителей VNF к сотрудничеству. HP недавно анонсировал открытие SDN app store.
Возможно прорыва стоит ожидать не сколько от сетевых вендоров, сколько от производителей OSS\BSS систем, в которые сейчас активно интегрируют MANO-компоненты.
спасибо, поправил
Спасибо за обратную связь!
Пользуйтесь на здоровье. Если будут уточняющие вопросы, то прошу задавать :)
и как указано в первом видео к курсу, по статистике 80% продукта проваливаются (может и больше, если продукты умирают на более ранней стадии). почему? совокупность факторов. и время и рынок и циклы в экономике, и технологическая недостаточность.
какие конкретно вещи надо улучшать в конкретному продукте — это уже менторство, акселераторы, эдвайзинг и консультирование. а так же метод проб и ошибок :)
О чем я упомянул в некоторых частях этой саги так это о том, что не стоит сразу же воплощать идею которая пришла в голову в программный продукт (делать «коробку которая кричить»), но еще и провалидировать эту идею на какие-нибудь потенциальных клиентах и собрать обратную связь с рынка. И только если кто-то нашелся кто за это потенциально готов заплатить — только тогда заниматься разработкой.
То что я вижу вокруг себя, когда работаю со студентами или с будущими основателями стартапов — они часто ходят с «готовыми» идеями и им лишь интересно как это запаковать в продукт или как проверить свою идею на рынке. Практически никогда не встречаю людей, которые приходят и спрашивают у окружающих — что бы такое сделать? «желание и силы есть, а идей нет» — невероятно редкий кейс. Но что я действительно часто вижу — у будущего фаундера (или его команды) есть идея и они готовы ее воплощать в жизнь, но когда начинают по всем канонам продакт-менеджмента эту идею прорабатывать, валидировать и смотреть на реакцию рынка — тогда изначальная идея умират и трансформируется в что-то немного другое или совершенно другое. Получается, что действительно команда может создать что-то такое, о чем изначально даже не задумывалась. Но при этом если не было какой-то другой изначальной идеи — то до работающей идеи они не дошли бы :)
А какая у тебя есть идея для реализации?
Можете пояснить про какой фреймворк спрашиваете? Тот который представлен в начальном посте habr.com/ru/company/acronis/blog/513808?
Но даже в B2C-продуктах можно заниматься сбором статистики и аггрегации пользовательских паттернов, чтобы сформировать группы пользователей, которые отличаются своим поведением. Это помогает в разработке, но уже не помогает в маркетинге. Для маркетинга необходимо делать разные посадочные страницы под разных пользователей, которые в итоге приводят к одному продукту.
А с точки зрения разработки продукта — я вижу, что разработчики часто спрашивают продакт-менеджеров — расскажите для кого мы создаем продукт. Кто эти люди? Почему они им пользуются? Ответы на эти вопросы помогают создать эмоциональную связь между «творчеством» разработчиков и потребителями.
Что касается денег — про расчет финансовой модели создаваемого продукта будет отдельный пост — из модели можно понять сколько компания собирается потратить на разработку и с учетом предложенной цены, будет ли игра стоит свеч.
Если же вы про привлечение инвестиций, чтобы в принципе начать дело, то это тема для отдельного курса :)
Сразу замечу, что в курсе не затрагивались вопросы связанные с регистрацией компании в госорганах, открытия банковского счета, найма сотрудников, привлечения инвестиций, аренда офиса. Курс был про то как создавать продукты, которые будут востребованы и как сделать так, чтобы про ваш продукт узнали многие и вы смогли его продавать.
Можно вас спросить, какие проблемы, сложности и вопросы есть в «мире реального стартапа», чтобы я понял какая тема с вашей точки зрения должна быть детально раскрыта?
Прошу результаты расследования в студию!
Спасибо за подробный комментарий, тем более с указанием конкретных проектов и их функционала.
В моем списке были представлены те продукты, с которыми мне довелось или поработать или плотно исследовать. Вполне вероятно, что список надо расширять и дополнять. Тем более, проекты развиваются очень быстро и все смотрят на конкурентов для того, чтобы не упустить реализацию какой-нибудь фичи.
Что касается обзора коммерческий решений, то их гораздо сложнее получить в использование для того, чтобы составить полноценный обзор. Можно конечно сделать вывод только сравнивая презентации и datasheet, но желательно конечно получить такой обзор от тех пользователей, на сетях которых уже присутствуют такие продукты.
Вам доводилось внедрять или эксплуатировать какие-нибудь из представленных решений?
Спасибо, что читаете и делитесь своими комментариями!
И уверен, что не сколько сетевикам, сколько людям от бизнеса интересней узнать о работающих проектах.
Ведь сетевик был бы рад поработать с любой инновацией, если в нее будут вложены деньги. И технарей как правило не нужно убеждать попробовать что-то новое. А вот тех, кто инвестирует свои средства в будущие проекты — они гораздо больше задумываются о том, где это уже взлетело и стоит ли туда вкладывать.
Но тут можно попасть в интересную петлю. Если операторы долго будут ждать, пока кто-то другой у себя внедрит какую-то технологию и докажет рынку, что это работоспособно, то эти операторы могут просто изчезнуть с рынка, так как не успеют подготовиться к изменениями.
Простой пример с виртуализацией вычислительных ресурсов показал очевидную эффективность в повышенной утилизации железа и создания слоя абстракции между оборудованием и операционной системой.
Думаю крупные операторы осознают необходимость изменений, но им требуется решение, которое работает. Один из выводов статьи как раз в том, чтобы уже сейчас начать применять бесплатные решения в пилотах, чтобы персонал был готов к внедрению и использованию того решения, которое им предложат технологические вендоры.
Заменить «железный» файрвол на программный — это может быть первый шаг. Заменить «железный» BNG\BRAS на программный может быть вторым шагом. И так далее.
Про коллег из ЦПИКС не просто слышал, но и лично знаком с многими. Очень правильный вектор держат и желаю им успехов!
Демонстрация показала как в автоматическом режиме можно сетевые функции применять к трафику. Настраивать в консоле каждую ВМ с сетевой функции не было необходимости.
NEC, Tech Mahindra, Orange, Cisco, Amdocs, Wind River Systems, Alcatel-Lucent, HP, Oracle, Orange, Juniper, ZTE, Intel, Telecom Italia, Wipro, EnterpriseWeb, NSN, Huawei, ASSIA, Telefonica, China Unicom, AT&T, Verizon, Docomo, Deutsche Telekom, Sprint, Vodafone, 6Wind, BT, tech Mahindra, Sonus, Brocade, ETRI, Ooredoo, Fujitsu, Ericsson.
Мне видится, что сейчас такое время, когда в ближайшее время могут выстрелить сразу несколько вендоров со своими решениями по «магазину VNF приложений». Cisco аналог показывала где-то год назад в рамках функционала APIC-контроллера. NEC со своим SDN space призывает производителей VNF к сотрудничеству. HP недавно анонсировал открытие SDN app store.
Возможно прорыва стоит ожидать не сколько от сетевых вендоров, сколько от производителей OSS\BSS систем, в которые сейчас активно интегрируют MANO-компоненты.