Всем привет) мы разрабатываем курс по Customer Devepolment на чат-боте (наш аналогичный курс https://fh.school/course/storytelling)

будем рады дать доступ взамен за каздев)
Хотим узнать подробно что продакту нужно (в исследовании потребителя) и с какими задачами вы сталкивайтесь каждый день)

Взамен так же готовы дать доступ к любому из курсов школы

пишите в личку)

очень интересный чат

А где же чуть более сложные модели?  B2B2C или подобное?

Расскажи это как?

As an example of a B2B2C model, Business A pays Business B for users, leads or sales generated by Business B's business or website. Business A then uses Business B's channels to locate prospective customers. Business B provides its customers with new and relevant services, facilitating an increased customer base and earned revenue for sold products and services.

вот так например

Сорри, телеграм еще не научился редактировать опросы.

А есть кстати примеры всем известных компаний с такой моделью? А-то вангую что львиная часть из 554 мемберов ничего не поняли, как и я.

ну грубо  говоря например вы продаете свои товары через дилеров конечным покупателям — это по сути и есть b2b2c

один из вариантов

продажи через амазон тоже подходит

Тысячи их, это все что продается b2b но для клиентов этого b

Intercom, freshdesk, всякие hr системы типа workday, пэймент гейтвеи типа stripe

Если в тему чата, то, например, сюрвей манки или typeform

ок-ок

приношу извинения ребятам из страйпа, интеркома и тп, вы поучаствовать в опросе не сможете

Коллеги, привет, работаю в in-house, соответственно занимаемся автоматизацией в рамках крупного холдинга. IT очень на хорошем уровне, полностью своя команда разработки, выделены в отдельную компанию даже.

Разработка, как вы понимаете почти схожа с работой интегратора, т.е. заказная по сути своей, заказчики руководители из бизнеса, которые конечно часто даже не пользуются системами, которые заказывают.

Мы хотим перейти на продуктовую разработку, начать ориентироваться на конечных пользователей и их боли. Сейчас я начинаю готовить презентацию для проектного офиса, чтобы как-то начать подвижки в эту сторону.

В связи с этим интересует:
1) Есть ли подобный опыт у кого-то здесь
2) Может быть есть какие-то материалы/ презентации
3) В целом о чем можно релевантном рассказать, сейчас я остановился на том, чтобы рассказать про Cusdev, User Story/ Job Story, продуктовые метрики, способы получения информации от конечных пользователей.

Буду благодарен за помощь.

У меня есть такой опыт, сейчас расскажу тут, вдруг кому-то еще будет полезно

👍

В чем между нами разница? В том, что у меня была техническая команда, которая изначально была продуктовой. Но тот продукт умер и развалился, бизнес сказал, что больше не может платить зарплаты и мы после переговоров между моей командой и бизнесом пришли к тому, что выделились в отдельную компанию, забрали себе ресурсы(серверы, аккаунты в сервисах и т.п) и наработки(куча микросервисов, внутренних продуктов, побочных проектов). То есть исходная позиция, как по мне схожа, но все же отличается, это надо учесть.

Мы пробовали несколько направлений:
а) консалтинг
б) аутсорс
в) аутстафф
г) разработка своих продуктов


Теперь непосредственно к вопросу.... Если у вас непосредственно разработка и есть бизнес, который плохо понимает разработчиков, а разработчики плохо понимают бизнес, я бы начал банально с наведения моста между ними. Как ни странно, для этого есть в разработке практики, например Domain Driven Design. Здесь главные требования к руководителю: приглашать на кофе своих боссов, составлять общий словарь, говорить с ними об их бизнесе на их языке

Cust dev, продуктовые метрики и прочие радости это все-таки ведь про бизнес, а не разработку. Вы хотите на внешний рынок свои продукты пускать, или что? Какая конечная цель-то у вас?

В моей практике CusDev применялся как раз таки для автоматизации внутри большой компании. Потому что разработка с целью автоматизации того или иного уже существующего решения внутри компании в моем случае потребовали такой же проработки по CusDev, как и со всеми моими внешними проектами.
– Прищли идеи по автоматизации
– Создали гипотезы
– Начинали исследования. Сначала интервью с теми кто применяет существующее решение и темм, кто хочет его автоматизировать, протом провели наблюдения за использованием существующего решения.
– Потом мы смотрели на то, что есть вообще вокруг. Может кто-то уже что-то придумал и нам не нужно изобретать велосипед. Это касается и внешних решений и внутренних (мало ли)
– Дальше думали, считали, оценивали ресурсы и когда нам «окнули», мы сделали MVP по автоматизации части существующего решения
– Получили обратную связь
– Вышли на разработку полноценного решения по автоматизации
– Начали использование нашего решения
– Сняли обратную
– Начали совершенствовать (но уже без меня)