Grow hacking в b2b довольно специфическая вещь. В основном по причине того, что в этом сегменте пользователи и покупатели это разные группы. Также нет никакого обмена информацией, то есть вирусность не сработает.
Очень хорошо показывают себя такие инструменты как интеграция и партнерство (это самый важный). На втором месте демонстрация отраслевой компетенции.
На мой взгляд нужно добавить в самом начале примечание как именно нужно сегментировать рынок. Мы не должны просто разбивать рынок на сегменты, а отталкиваться от product vision и product strategy.
Для примера с такси product vision (отвечает на вопрос «зачем», идея) может быть таким: мы хотим сделать грузовые такси-перевозки доступными. Поэтому сегментация должна учитывать
— сколько людей перевозят вещи (между квартирами, домами и дачами)
— междугородние перевозки
— сколько платят за услуги.
Если брать по схеме: TAM, SAM, TM, SOM, то мы учтем все такси, включая бизнес и прочее.
По этой причине мне кажется фреймворк от Pragmatic Institute, не смотря на его очень хорошую структуру, не подходит для объяснения как создавать продукты. Скорее как их реализовывать. Сам я использую схему для этапа планирования:
— product vision
— product strategy
— market research
— industry analysis
— risk management
Людей, которые пользуются именно такими подписками не встречал. Была только оплата через SMS, но в этом случае надо подтвердить оплату ответным сообщением.
Что интересно, в случае с Мегафоном, подписок не бывает (по крайней мере у меня их не было) в следующих случаях.
— Когда тариф корпоративный. Тут понятно, им проблемы с большим клиентом не нужны.
— Когда используешь vpn. С этим интересно, вроде как они утверждают, что не передают идентификатор абонента. Как оказывается, vpn защищает скрывая данные.
— Когда в салоне связи говоришь, что симкой будет пользоваться ребенок. Они тогда что-то делают на своей стороне и подписки не появляются. При этом ребенок может легко подписаться на «официальные» рассылки через сим меню.
Движок может распознавать произвольный рукописный текст на страничке, или натренирован только на российские паспорта? Используете ли базу имен для валидации результата?
Текущая ситуация оказалась тестированием, по результатам которого оказалось, что работать удаленно и распределенно не так страшно. У нас тоже после карантина не будут открыты половина офисов https://www.zdnet.com/article/opentext-wont-reopen-half-of-its-physical-offices-post-covid-19-pandemic/
Думаю, что для ИТ сферы это наоборот даст новый толчок. Теперь компании еще более охотно будут набирать сотрудников по всему миру.
Код это биты и байты. Для клиента надо, чтобы продукт решал проблему. Как это сделано внутри для него неважно. Это имеет значение только с точки зрения экономики производства.
Вы уделили этому внимание, потому, что знаете «внутренность» процесса разработки. В качестве управжнения возьмите другую область. Например, железо.
Пример: мышки с usb приемником. Возражение на выбранную технологию: «Это плохое решение, приемники будут теряться. Надо использовать Bluetooth. Давайте переходить на Bluetooth».
Техническое решение: переход на Bluetooth.
Административное решение 1: продажа универсальных приемников
Административное решени 2: бесплатная отправка клиентам утерянных приемников.
Все мы знаем, что обе модели существуют сейчас и успешны.
Да, с ним можно жить. Но я не считаю обновление технологии в деньгах. Это трудно предсказуемо. Я пробовал это делать, как мне кажется, в более простом случае: влиянии наличия одного продукта в портфеле на продажи другого. В итоге отказался считать такой «наведенный» доход. Только прямые цифры.
Переход на новую технологию может наоборот принести убытки. Пример из головы, выбор Windows Workflow Foundation. В момент презентации технология казалась перспективной.
Переход на новые технологии, процент ошибок, сопровождение продукта, на мой взляд, это больше про риск-менеджмент, а не следование методологиям.
Как потребитель, какой продукт, или товар вы бы купили, если используемая в нем технология была другой?
Я все же попытаюсь переубедить. На мой взгляд отсутствие внутренней коммуникации воспринимается как «всем наплевать». Например, отказ продукт менеджера менять устаревшую технологию на новую без объяснения считается «накоплением технического долга». А на самом деле замена технологии сейчас стоит условно 1000 копеек, приносит 0 копеек (технологии никогда не продаются). При этом на 1000 копеек мы можем сделать фичу, которая принесет 5000, а убытки от старой технологии будут 2000. Мы в плюсе, заняли нишу, и есть еще средства на переписывание.
Какой продукт Вы сами считаете сделанным идеально или близким к идеалу?
Похоже на выводы по одному опыту. Продукты сделаны настолько качественно, насколько это требуется. Есть ведь разница между требованиями к Notepad и RTS системам самолета или ПО для медицинских систем. Так же есть стоимость исправления ошибки. Стоимость тестирования.
И компании есть разные. В некторых есть менеджеры которые отвечают за свою часть работы: за разработку и качество кода, за его безопасность, за тестирование, за поддержку, и за прибыль в конце-концов. И каждому точно не наплевать за его часть работы.
Думаю, что есть и психологический момент. Чаще условно красивый продукт воспринимается надёжнее.
На фото кнопки рядом, они "гуляют", и кажется, что скоро выпадут. На новом дизайне, я уверен, кнопки так же подвижны, но это менее заметно на фоне соседних.
model произносится «модл» [mɔdl]
а вот module — «моджул» ['mɔdju:l]. Иногда это слово произносят как «модул» и это воспринимается носителями как «model»
Zendesk имеет русскоязычный интерфейс. И закрывает все ваши задачи. Я внедрял этот хелпдеск.
Хорошая система api, можно стартануть с покрытием 80%, а остальные 20 уже в процессе доделать. Например, интеграции с внутренними crm.
Замените Jira на любую абстрактную систему. Суть RPA в экономии времени. Существующих сотрудников не увольняют, но и новых не будут набирать.
Ещё пример — Automator в macOS. Написав интеграционный сценарий можно связывать действия.
И верно, чаще всего это не тиражное решение.
В моей области — capturing — это реализуется в сценариях работы с документами. Оператор открывает картинку из вложения в почте, или из SAP и сразу может извлечь данные в поля.
В общем это такие расширенные автоматизированные бизнес-процессы, которые не просто работают в какой-то системе, но и немного выходят за ее рамки в том числе интерфейс.
Пример, у вас есть система документооборота, в которой вы создаете задания, например, на согласование документа. При «классической» автоматизации надо открыть интерфейс системы, создать задание, назначить его и отправить. При RPA подходе, вы например, работаете с почтой. К вам падает письмо с текстом от сотрудника «Готова финальная версия договора». При этом у вас на письме появляеться подсказка «Похоже, что надо отправить документ на согласование Иванову, Петрову. Сделать?». Вы жмете на кнопку и все запускается.
Другой пример. Вы ведете задачи в Jira. К вам часто приходят сообщения от коллег «Посмотри багу BUG-123451» просто текстом. Вам нужно открыть Jira и найти баг. Это надоедает.
Вы берете Autohotkey. Пишете скрипт, который будет в активном окне искать текст типа BUG- и автоматом его открывать в Jira. Вуаля, у вас теперь есть собственный RPA
Предложение по структуре было «формирование проблемы — решение». Если в указанных примерах так строить доклад, то проблема будет притянута за уши. Она играет тут втростепенную роль.
Условно «Рынок планшетов испытывает падение в перспективе 5 лет». Это для производителей планшетов проблема. А для нас информация не выпускать софт на эту платформу.
Или доклад для владельцев бизнеса. «Выпуск новой версии может увеличить выручку на N%, потому, что у нас есть перспективные заказчики на нее.» А если не выпустим это проблема, так?
Я просто привел примеры, что тем где структура «проблема — решение» не нужна.
Подпишусь. Не будучи занудой, я за правильный подход в дайджесте управления продуктами. Хайповость приводит к стартапам по типу «еще один мессенджер, но с ...» или еще один кошелек
Вызов в том, чтобы не превратить обзор в нудятину.
Вроде бы да. Но кофейни говорят — мы фотографируем для определенных целей. А это уже "является основным объектом использования".
Хорошо бы юрист прокомментировал.
Про продукты, хотелось бы точки зрения продукт-менеджера.
Почему Kabuto? Мне кажется, что не станет бизнесом (как и любой проект чемоданов с Kickstarter). Первых инноваторов и пользователей они получат, за счет «вау эффекта». Потом нужно будет переходить к массовому рынку (тот самый Crossing the Chasm). А для таких продуктов это только создание сервиса. Ремонт колес, креплений колес, фиксаторов ручек, молний, батареи. Все что может повредить авиакомпания. Навряд-ли они смогут это организовать. Я не помню ни одного примера багажа с kickstarter, которые бы перешли к устойчивому бизнесу. Но мне интересно узнать пример, если есть.
Очень хорошо показывают себя такие инструменты как интеграция и партнерство (это самый важный). На втором месте демонстрация отраслевой компетенции.
Есть ли курсе разбор этой темы?
Для примера с такси product vision (отвечает на вопрос «зачем», идея) может быть таким: мы хотим сделать грузовые такси-перевозки доступными. Поэтому сегментация должна учитывать
— сколько людей перевозят вещи (между квартирами, домами и дачами)
— междугородние перевозки
— сколько платят за услуги.
Если брать по схеме: TAM, SAM, TM, SOM, то мы учтем все такси, включая бизнес и прочее.
По этой причине мне кажется фреймворк от Pragmatic Institute, не смотря на его очень хорошую структуру, не подходит для объяснения как создавать продукты. Скорее как их реализовывать. Сам я использую схему для этапа планирования:
— product vision
— product strategy
— market research
— industry analysis
— risk management
Что интересно, в случае с Мегафоном, подписок не бывает (по крайней мере у меня их не было) в следующих случаях.
— Когда тариф корпоративный. Тут понятно, им проблемы с большим клиентом не нужны.
— Когда используешь vpn. С этим интересно, вроде как они утверждают, что не передают идентификатор абонента. Как оказывается, vpn защищает скрывая данные.
— Когда в салоне связи говоришь, что симкой будет пользоваться ребенок. Они тогда что-то делают на своей стороне и подписки не появляются. При этом ребенок может легко подписаться на «официальные» рассылки через сим меню.
Думаю, что для ИТ сферы это наоборот даст новый толчок. Теперь компании еще более охотно будут набирать сотрудников по всему миру.
Вы уделили этому внимание, потому, что знаете «внутренность» процесса разработки. В качестве управжнения возьмите другую область. Например, железо.
Пример: мышки с usb приемником. Возражение на выбранную технологию: «Это плохое решение, приемники будут теряться. Надо использовать Bluetooth. Давайте переходить на Bluetooth».
Техническое решение: переход на Bluetooth.
Административное решение 1: продажа универсальных приемников
Административное решени 2: бесплатная отправка клиентам утерянных приемников.
Все мы знаем, что обе модели существуют сейчас и успешны.
Переход на новую технологию может наоборот принести убытки. Пример из головы, выбор Windows Workflow Foundation. В момент презентации технология казалась перспективной.
Переход на новые технологии, процент ошибок, сопровождение продукта, на мой взляд, это больше про риск-менеджмент, а не следование методологиям.
Как потребитель, какой продукт, или товар вы бы купили, если используемая в нем технология была другой?
Какой продукт Вы сами считаете сделанным идеально или близким к идеалу?
И компании есть разные. В некторых есть менеджеры которые отвечают за свою часть работы: за разработку и качество кода, за его безопасность, за тестирование, за поддержку, и за прибыль в конце-концов. И каждому точно не наплевать за его часть работы.
Думаю, что есть и психологический момент. Чаще условно красивый продукт воспринимается надёжнее.
На фото кнопки рядом, они "гуляют", и кажется, что скоро выпадут. На новом дизайне, я уверен, кнопки так же подвижны, но это менее заметно на фоне соседних.
model произносится «модл» [mɔdl]
а вот module — «моджул» ['mɔdju:l]. Иногда это слово произносят как «модул» и это воспринимается носителями как «model»
Zendesk имеет русскоязычный интерфейс. И закрывает все ваши задачи. Я внедрял этот хелпдеск.
Хорошая система api, можно стартануть с покрытием 80%, а остальные 20 уже в процессе доделать. Например, интеграции с внутренними crm.
Его как раз разрабатывали для облачной печати. И он, в том числе, рекомендуется к использованию в TWAIN Direct для autodiscovery.
Замените Jira на любую абстрактную систему. Суть RPA в экономии времени. Существующих сотрудников не увольняют, но и новых не будут набирать.
Ещё пример — Automator в macOS. Написав интеграционный сценарий можно связывать действия.
И верно, чаще всего это не тиражное решение.
В моей области — capturing — это реализуется в сценариях работы с документами. Оператор открывает картинку из вложения в почте, или из SAP и сразу может извлечь данные в поля.
Пример, у вас есть система документооборота, в которой вы создаете задания, например, на согласование документа. При «классической» автоматизации надо открыть интерфейс системы, создать задание, назначить его и отправить. При RPA подходе, вы например, работаете с почтой. К вам падает письмо с текстом от сотрудника «Готова финальная версия договора». При этом у вас на письме появляеться подсказка «Похоже, что надо отправить документ на согласование Иванову, Петрову. Сделать?». Вы жмете на кнопку и все запускается.
Другой пример. Вы ведете задачи в Jira. К вам часто приходят сообщения от коллег «Посмотри багу BUG-123451» просто текстом. Вам нужно открыть Jira и найти баг. Это надоедает.
Вы берете Autohotkey. Пишете скрипт, который будет в активном окне искать текст типа BUG- и автоматом его открывать в Jira. Вуаля, у вас теперь есть собственный RPA
Условно «Рынок планшетов испытывает падение в перспективе 5 лет». Это для производителей планшетов проблема. А для нас информация не выпускать софт на эту платформу.
Или доклад для владельцев бизнеса. «Выпуск новой версии может увеличить выручку на N%, потому, что у нас есть перспективные заказчики на нее.» А если не выпустим это проблема, так?
Я просто привел примеры, что тем где структура «проблема — решение» не нужна.
2. Обзор рынка или технологии.
3. Прогноз по выручке / прибыли.
Вызов в том, чтобы не превратить обзор в нудятину.
Вроде бы да. Но кофейни говорят — мы фотографируем для определенных целей. А это уже "является основным объектом использования".
Хорошо бы юрист прокомментировал.
Почему Kabuto? Мне кажется, что не станет бизнесом (как и любой проект чемоданов с Kickstarter). Первых инноваторов и пользователей они получат, за счет «вау эффекта». Потом нужно будет переходить к массовому рынку (тот самый Crossing the Chasm). А для таких продуктов это только создание сервиса. Ремонт колес, креплений колес, фиксаторов ручек, молний, батареи. Все что может повредить авиакомпания. Навряд-ли они смогут это организовать. Я не помню ни одного примера багажа с kickstarter, которые бы перешли к устойчивому бизнесу. Но мне интересно узнать пример, если есть.