И мне тоже Google Reader в голову пришел, когда я вспоминал о примерах! Очень это показательный случай. Escrow чаще применяется в b2b.
Хороший пример Blender. Они пошли не по стандартному пути, конечно. Сначала закрытый продукт, а потом open source.
Подумал, что хорошо, что вы привели этот пример. Тут важно рассмотреть, кто именно платит за продукт. В случае с Google Reader выручка шла не от пользователей. Основная группа это рекламодатели. А также сам Google, который мог собирать статистику. Что-то пошло не так, и продукт, как источник прибыли не оправдал себя.
Таким образом иметь escrow или даже передавать что-то в открытый доступ пользователям бессмысленно. Они не являются целевой группой, как ни странно.
Вторая: понимание рынка и пользователей. Если работаешь на американском рынке, ты должен хорошо знать своего пользователя, разделять его боли. А если ты здесь ни разу не был и не жил, то не понимаешь, о чём страдают американские люди.
Про траты на визу и хороший рынок местных продакт-менеджеров все верно, но с пунктом про понимание рынка могу поспорить. Из моего опыта это свойственно только B2C продуктам. В B2B и особенно международной компании культурные особенности стоят на самом последнем месте. А на первом понимание как работает компания-клиент, и особенности работы регуляторов.
И добавлю позитива. Релоцироваться продакт менеджеру можно. Не обязательно это делать в США. Atlassian набирал активно в доковидные времена (Австралия). Zalando (Германия) нанимает сейчас достаточно pm с релокацией.
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 системам самолета или ПО для медицинских систем. Так же есть стоимость исправления ошибки. Стоимость тестирования.
И компании есть разные. В некторых есть менеджеры которые отвечают за свою часть работы: за разработку и качество кода, за его безопасность, за тестирование, за поддержку, и за прибыль в конце-концов. И каждому точно не наплевать за его часть работы.
В состав office365 входит Planner. Пока Microsoft не сильно его продвигает. Но для простого проектного управления вполне подходит. Нет диаграмм Ганта. Зато есть интеграция через Microsoft Flow и Power Apps
Это в физике появилось с момента перехода от философии. В любом уравнении можно выделить необычный кусок. Можно комплексную массу найти, и даже векторную. Объяснить физический смысл — вот это задача. Меня зацепила в статье начало с завязкой на гравитацию. Но бесконечный разгон, честно, выглядит слабо. Например, что будет с энергией такой системы и импульсом (который вроде как должен быть равен нулю)
Про отрицательную массу хочется больше деталей. С точки зрения математики — понятно, есть статья в википедии с уравнением Шредингера. Но с позиции физики? Например, как связано понятие отрицательной массы и поле Хиггса?
Думаю, что есть и психологический момент. Чаще условно красивый продукт воспринимается надёжнее.
На фото кнопки рядом, они "гуляют", и кажется, что скоро выпадут. На новом дизайне, я уверен, кнопки так же подвижны, но это менее заметно на фоне соседних.
model произносится «модл» [mɔdl]
а вот module — «моджул» ['mɔdju:l]. Иногда это слово произносят как «модул» и это воспринимается носителями как «model»
Zendesk имеет русскоязычный интерфейс. И закрывает все ваши задачи. Я внедрял этот хелпдеск.
Хорошая система api, можно стартануть с покрытием 80%, а остальные 20 уже в процессе доделать. Например, интеграции с внутренними crm.
Замените Jira на любую абстрактную систему. Суть RPA в экономии времени. Существующих сотрудников не увольняют, но и новых не будут набирать.
Ещё пример — Automator в macOS. Написав интеграционный сценарий можно связывать действия.
И верно, чаще всего это не тиражное решение.
В моей области — capturing — это реализуется в сценариях работы с документами. Оператор открывает картинку из вложения в почте, или из SAP и сразу может извлечь данные в поля.
Хороший пример Blender. Они пошли не по стандартному пути, конечно. Сначала закрытый продукт, а потом open source.
Подумал, что хорошо, что вы привели этот пример. Тут важно рассмотреть, кто именно платит за продукт. В случае с Google Reader выручка шла не от пользователей. Основная группа это рекламодатели. А также сам Google, который мог собирать статистику. Что-то пошло не так, и продукт, как источник прибыли не оправдал себя.
Таким образом иметь escrow или даже передавать что-то в открытый доступ пользователям бессмысленно. Они не являются целевой группой, как ни странно.
Про траты на визу и хороший рынок местных продакт-менеджеров все верно, но с пунктом про понимание рынка могу поспорить. Из моего опыта это свойственно только B2C продуктам. В B2B и особенно международной компании культурные особенности стоят на самом последнем месте. А на первом понимание как работает компания-клиент, и особенности работы регуляторов.
И добавлю позитива. Релоцироваться продакт менеджеру можно. Не обязательно это делать в США. Atlassian набирал активно в доковидные времена (Австралия). Zalando (Германия) нанимает сейчас достаточно pm с релокацией.
Очень хорошо показывают себя такие инструменты как интеграция и партнерство (это самый важный). На втором месте демонстрация отраслевой компетенции.
Есть ли курсе разбор этой темы?
Для примера с такси 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. В момент презентации технология казалась перспективной.
Переход на новые технологии, процент ошибок, сопровождение продукта, на мой взляд, это больше про риск-менеджмент, а не следование методологиям.
Как потребитель, какой продукт, или товар вы бы купили, если используемая в нем технология была другой?
Какой продукт Вы сами считаете сделанным идеально или близким к идеалу?
И компании есть разные. В некторых есть менеджеры которые отвечают за свою часть работы: за разработку и качество кода, за его безопасность, за тестирование, за поддержку, и за прибыль в конце-концов. И каждому точно не наплевать за его часть работы.
В состав office365 входит Planner. Пока Microsoft не сильно его продвигает. Но для простого проектного управления вполне подходит. Нет диаграмм Ганта. Зато есть интеграция через Microsoft Flow и Power Apps
Это в физике появилось с момента перехода от философии. В любом уравнении можно выделить необычный кусок. Можно комплексную массу найти, и даже векторную. Объяснить физический смысл — вот это задача. Меня зацепила в статье начало с завязкой на гравитацию. Но бесконечный разгон, честно, выглядит слабо. Например, что будет с энергией такой системы и импульсом (который вроде как должен быть равен нулю)
Думаю, что есть и психологический момент. Чаще условно красивый продукт воспринимается надёжнее.
На фото кнопки рядом, они "гуляют", и кажется, что скоро выпадут. На новом дизайне, я уверен, кнопки так же подвижны, но это менее заметно на фоне соседних.
model произносится «модл» [mɔdl]
а вот module — «моджул» ['mɔdju:l]. Иногда это слово произносят как «модул» и это воспринимается носителями как «model»
Zendesk имеет русскоязычный интерфейс. И закрывает все ваши задачи. Я внедрял этот хелпдеск.
Хорошая система api, можно стартануть с покрытием 80%, а остальные 20 уже в процессе доделать. Например, интеграции с внутренними crm.
Его как раз разрабатывали для облачной печати. И он, в том числе, рекомендуется к использованию в TWAIN Direct для autodiscovery.
Замените Jira на любую абстрактную систему. Суть RPA в экономии времени. Существующих сотрудников не увольняют, но и новых не будут набирать.
Ещё пример — Automator в macOS. Написав интеграционный сценарий можно связывать действия.
И верно, чаще всего это не тиражное решение.
В моей области — capturing — это реализуется в сценариях работы с документами. Оператор открывает картинку из вложения в почте, или из SAP и сразу может извлечь данные в поля.