Процесс создания каких либо продуктов или услуг

Процесс создания каких либо продуктов или услуг thumbnail

Как в фильме Начало (Inсeption), реальность в продуктовой разработке имеет определенную вложенность слоев. В зависимости от того, какая роль вам выпала, ваше “начало” в проекте может произойти раньше или позже, но всегда приятнее быть в числе создателей новой реальности, не так ли?

Эта статья — вступительная часть к трилогии о том, что собой представляет в гибкой продуктовой разработке:

  • Готовность Начать
  • Готовность Завершить
  • Готовность Выпустить

Первая часть будет посвящена процессу открытия продукта (Product Discovery), вторая — процессу разработки продукта (Agile Delivery), третья — формированию цикла этих двух процессов, с обратной связью от рынка (Business Development). Здесь же, в начале, я задам общие рамки ролей и процессов, в которые буду углубляться в следующих частях.

Пишу эту статью для нынешних или начинающих Владельцев Продуктов — «ловцов снов» и «продавцов воздуха». Людей, идеи которых способны изменить реальность, а могут сами оказаться иллюзией.

Если ваша роль в продуктовой разработке не самая центральная, надеюсь, вы все еще найдете способ получить пользу из 3-5 экранов, в которые я постараюсь уложиться. Если благодаря этой статье вы сможете приблизиться к оси, по которой вращается вселенная вашего проекта, я буду рада, поскольку верю в то, что создание достойных покорения мира вещей возможно только путем командного взаимодействия. Поэтому, первое о чем я буду говорить в начале — о команде.

КОМАНДА ОТКРЫТИЯ ПРОДУКТА
Product Discovery Team

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

  • ценности продукта для бизнеса
  • удобства продукта для пользователей
  • реализуемости продукта в рамках времени и технологий

Именно эти три параметра: ценность, удобство и реализуемость, команда открытия должна держать в постоянном фокусе. Первые примеры таких команд мне приходилось видеть на конкурсах вроде DOU Mixer и Garage48.

Минимальный “комплект” это хакер (технологии), хастлер (маркетинг) и дизайнер (юзабилити). Когда я говорила “никогда не экономьте на команде”, я имела в виду вот что: эти три роли — это “гены” вашего продукта. Вы никогда не знаете вначале, какой продукт вы “вырастите”, но профессионализм команды открытия, важен практически так же, как здоровые гены в физическом теле.

КОМАНДА ОТКРЫТИЯ: UX Дизайнеры
Из этих трех составляющих команды открытия, сложнее всего найти хорошего “дизайнера”. Дизайном эта функция называется условно — слишком большой метаморфозе подверглась профессия дизайнера за последние 10 лет. Здесь имеется в виду роль проектировщика архитектуры взаимодействия пользователя с продуктом. Так что хакеры в своем понимании дизайна как архитектуры, ближе к истине, чем люди бизнеса, которые представляют симпатичные картинки. Дизайн — это UX (архитектура взаимодействия), которая впоследствии дополняется Usability (удобством) и UI (красотой).

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

КОМАНДА ОТКРЫТИЯ: Хакеры
Короткое отступление для читателей из мира аутсорсинга. Я противник разработки командой по готовой спецификации. “Требования” означает “Заткнись” (цитирую Алистера Коуберна). Если команда пишет продукт по «спущенным» требованиям, значит вы не используете ее исследовательский потенциал, это — ложная экономия.

Если хотите сэкономить на разработке — найдите людей, которые достаточно сыты самореализацией в корпоративном мире, гордостью за свои рейты на oDesk’е и экономическим благополучием. Несколько моих знакомых, ярких хакеров существенно опустились в гонорарах, потому что наступил период поверить в чей-то продукт и начать считать его своим. Это особенное чувство, вы знаете. Вам нужны такие люди, которые готовы пойти ва-банк, веря как в вашу идею так и в свое генетическое превосходство.

Если вы уже имеете дело с аутсорсингом, постарайтесь максимально включить команду в процесс открытия продукта. Под командой я имею в виду небольшие полнофункциональные составы “грабителей банков” (цитирую Максима Ткачука), в которых каждый хорош в своей специализации, при этом понимая суть и доверяя исполнению других ролей в своей “банде”.

В зависимости, от рынка и технологий, состав и число “приближенных” может колебаться. Процесс открытия продукта может потребовать более глубокого вовлечения специалиста по базам данных (высоконагруженное приложение), математика (поисковый механизм), специалиста по искусственному интеллекту и т.п.

Оптимальный состав такой “боевой команды” — 3-5 человек. Вовлечение большего числа участников влечет за собой накладные расходы на общение. Но вы можете овладеть искусством фасилитации и научиться работать в малых группах над параллельными задачами, затем объединяя их результаты.

КОМАНДА ОТКРЫТИЯ: Хастлеры
Эта роль (hustler) умышлено оставлена без перевода. На самом деле, самые приличные варианты перевода это “энергичный человек” и “пробивной делец”, но все из них явно указывают на качества, которыми должен обладать ее носитель. Что бывает, если в команде есть просто “человек с идеей”, без пробивных бизнес-качеств? Получается бизнес трусогномов .

В чем профит? Именно этот вопрос — основная забота хастлера. В коммерческой разработке продукт всегда должен либо зарабатывать деньги, либо их экономить. В среде технологических

золотоискателей

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

Итак, предположим, вы собрали команду открытия продукта. Что дальше?

Я опишу один из вариантов “дорожной карты”. Карта — это не местность. Как случалось с Колумбом и другими искателями приключений, привести она вас может совсем не туда, куда предполагалось. Но иметь карту крайне важно, если вы хотите не топтаться на месте и использовать обнаруженные искажения в своем начальном представлении о пути и цели.

ШАГ 1. Определяем цели и принципы создания продукта.

Это могут быть:

  • Личные цели основателей
  • Цели бизнеса или организации
  • Принципы функционирования продукта

Этот шаг очень важен для дальнейшей работы. Процесс открытия продукта весьма увлекателен и может унести вас в неожиданном направлении довольно быстро. Такие базовые договоренности помогают верифицировать текущее состояние с исходными целями и, в случае отклонения, откорректировать курс.

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

ШАГ 2. Оцениваем возможности продукта

Это можно сделать используя такие инструменты, как Business Model Cancas или Lean Canvas. Или же ответив на вопросы оценки возможностей продукта по Кагану:

  1. Какую конкретно проблему решает продукт? (предложение ценности)
  2. Для кого мы решаем эту проблему? (целевой рынок)
  3. Как мы будем измерять успех? (метрики бизнеса)
  4. Насколько велики возможности? (объем рынка)
  5. Какие есть альтернативы? (текущие конкуренты)
  6. Почему наш продукт лучше подходит для решения проблемы? (наши отличия)
  7. Почему сейчас подходящее время? (окно рынка)
  8. Как мы будем запускать продукт? (стратегия выхода)
  9. Какие факторы критичны для успеха? (требования и риски)
  10. Беремся / не беремся?

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

ШАГ 3. Идентифицируем ключевых клиентов и пользователей

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

Будте внимательны к тому, являются ли ваши будущие пользователи вашими “избирателями”? Будут ли они использовать ваш продукт по собственной воле или в его внедрении будет заинтересованы над-структуры? Например, если вы разрабатываете банковский сервис, то удобство пользователя будет не самым главным критерием выбора и всегда будет уступать место надежности и безопасности решения.

Если покупать ваш продукт будут не те же люди, которые будут его использовать, полезно описать профайлы «покупателей», что бы учесть их интересы и приоритеты.

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

ШАГ 4. Проводим исследования пользователей

Это этап предварительного интервью с целевой аудиторией продукта. Цели этой активности:

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

Как готовиться интервью, выбирать аудиторию, задавать вопросы и анализировать ответы — я опишу в следующей части. Шаги с 4-го по 6-й могут быть выполнены несколько раз в цикле, еще до написания первой строчки кода.

ШАГ 5. Строим карту опыта пользователя “как есть”

Для этого подойдет любой инструмент, вроде составления линии времени или карта историй пользователя, описанной в следующем шаге. Цель этой активности — получить системное представление о ситуации “настоящего” для того, что бы разработать лучшее предложение “будушего”.

ШАГ 6. Строим карту взаимодействия с продуктом

Отличный инструмент для этого — User Story Mapping от Джеффа Паттона. По сути, карта историй пользователя — это высокоуровневая, многомерная модель требований, описывающая сценарии использования продукта.

Этот инструмент хорош как для проведения мозгового штурма по проектированию функциональности, так и для выбора объема реализации в рамках релизов.

ШАГ 7. Выбираем минимальный ценный продукт (MVP)

На выходе предыдущего шага мы можем получить представление о минимальном наборе функциональности, которая будет ценной для поставки на рынок. Я выделила этот шаг в отдельную активность по трем причинам:

1. Уже на этом этапе вы можете проверить свою идею о ценности, попросив обратной связи на несуществующий продукт. Это занимает время.

Я понимаю, что тысяча коров не расскажут как приготовить хороший стейк, и что если бы Генри Форд спросил своих пользователей чего они хотят, то ему пришлось бы совершенствовать лошадь. Именно поэтому, интервью с пользователями и получение обратной связи лучше доверить профессиональному UX дизайнеру.

2. На этом этапе вам уже понадобятся наброски интерфейса пользователя. Их создание занимает время.
3. На этом этапе важно подумать о метриках успешности первой версии продукта и заложить функциональность, помогающую эти данные добыть.

Тема метрик крайне важна и заслуживает отдельной статьи. Предваряя разговор о разных системах и подходах в их создании (например, AARRR, или NSP), скажу довольно банальную вещь, которая лишь может натолкнуть на размышления.

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

Думаю, этого для Начала, этого достаточно. В следущей части постараюсь пройтись по важным деталям шагов 4-6 и обсудить Готовность начать разработку.

Источник

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

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

Работаем в разных отраслях: приборостроение, машиностроение, IT, продукты питания, услуги (сервисы), мебель, двери, интерьерные продукты, строительные материалы и конструкции…

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

из внутренних документов Humathèq

Спойлер: под каждый продукт мы формируем команду разработчиков, где обязательно присутствуют эксперты из отрасли, в которой мы выполняем соответствующий R&D-проект, причём разработчики могут быть из любой страны мира.

Кстати, из опыта: классные продукты получаются, когда работает максимально интернациональная команда.

Дмитрий Черноморец, директор по развитию Humathèq – New Product Development Company

Перейдем к обещанным в заголовке принципам, которые мы с коллегами сформулировали пару лет тому назад и исповедуем до сих пор:

Наша логика разработки новых продуктов. Картинка из внутренних документов Humathèq

Наши философские принципы:

1. Что такое сильный и слабый продукты:

СИЛЬНЫЙ продукт – это продукт, который продает себя сам и тем самым обогащает своего создателя и владельца.

СЛАБЫЙ продукт – это продукт, который не решает проблемы и боли клиентов и пользователей, а, следовательно, за него не готовы платить.

В результате слабый продукт – это продукт, который не продается и генерирует убытки.

2. Несмотря на то, что речь идет о B2B продуктах – они не создаются для компаний, корпораций, организаций и т.д. Они создаются для конкретных людей, которые в этих компаниях, корпорациях, организациях принимают решения и пользуются этими продуктами, решая свои профессиональные и личные проблемы.

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

4. Продукты создаются для решения проблем, а не для того, чтобы “поиграться в технологии” и реализовать свои знания и умения.

Если продукт не решает проблемы – он никому не нужен, и за него никто не будет платить деньги.

5. Люди на первое место ставят личные проблемы, далее следуют – профессиональные. При этом в целях политкорректности декларируют обратное.

6. Конечная цель создания продукта – прибыль, при этом на работу мы ходим, чтобы зарабатывать деньги.

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

7. Чаще всего создание универсального продукта (продукта для всех) заканчивается провалом. Напротив, чем точнее целишься в однородные группы клиентов/пользователей, тем вероятность успеха становится выше согласно геометрической прогрессии.

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

9. Продукты быстро устаревают, их копируют, поэтому продукты нужно постоянно развивать, подпитывая улучшающими инновациями, вовремя списывать и выводить новые, построенные на прорывных инновациях.

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

из фотоархива Humathèq

Анализируя продукт, мы придерживаемся принципов:

11. Чтобы продукт хорошо продавался, он должен решать не только проблемы пользователя, но и клиента и дистрибьютора (если он есть в цепи поставок).

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

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

14. При анализе продукта сравнение нужно проводить не с конкурентами, а с ожиданиями клиентов, пользователей, дистрибьюторов.

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

из просторов интернета

16. Говоря об экономике продукта, необходимо анализировать его маржинальность, прибыль, которую генерирует продукт, а также рентабельность R&D.

Поэтому процесс R&D должен быть быстрым и дешевым и лучше всего осуществляться за деньги клиентов.

17. Стоимость продукта может быть всегда выше, если это повышение находится в нечувствительном для клиента диапазоне (закон эластичности спроса), или если растет ценность продукта.

18. Важно своевременно принимать решения об окончании продаж и производства продукта. Продукт должен завершать свою “карьеру” чемпионом.

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

Работа с подрядчиками и поставщиками технологий не терпит дилетантства.

20. Продукт всегда можно сделать лучше, вопрос в доступности технологий и экономической целесообразности улучшений.

из архива Humathèq

Принципы, которыми мы руководствуемся, создавая идеи и концепции новых продуктов:

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

При этом общение с клиентами, пользователями, дистрибьюторами – это не больно, это иногда и приятно (если правильно выстроить коммуникацию).

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

Проводя исследования, мы не собираем и так понятную информацию, а подтверждаем или опровергаем ранее сформированные гипотезы.

23. Шансы создания по-настоящему сильного продукта многократно увеличиваются, если к процессу разработки приглашаются клиенты, пользователи, дистрибьюторы, внешние эксперты, понимающие проблемы тех, для кого разрабатывается продукт, а также владеющие технологиями.

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

В нашем понимании проблема – это дискомфорт, который испытывает человек при недоступных способах от него избавиться.

Также важно принимать во внимание такое явление как боль.

Боль – это проблема высшей степени актуальности, где клиент готов заплатить любые деньги за ее решение.

Поэтому успешный продукт должен решать проблемы, а суперпродукт – избавлять от болей.

25. Дизайн продукта – это не только то, как выглядят его интерфейсы. Дизайн – это в первую очередь то, как продукт функционирует и как он взаимодействует с пользователем, клиентом, дистрибьютором.

Скетч мойки KitKraken из архива Humathèq

26. Продукт-менеджер и его команда не должны брезговать созданием прототипов, особенно если речь идет о прототипах нулевого уровня. На этом этапе дизайнеры-визуализаторы не нужны.

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

28. В ходе одной из итераций продуктовая команда может прийти к выводу, что продукт “не взлетит”. И здесь нужно набраться мужества, чтобы отказаться от продукта.

29. Прежде чем продукт станет продуктом, он требует тестирования, начиная со стадии прототипа нулевого уровня, завершая тестированием первого образца.

Тестирование происходит на всем протяжении жизненного цикла продукта, что необходимо для его постоянного совершенствования и поддержания актуальности.

30. Люди не любят и не читают инструкции, вернее читают, но тогда, когда уже что-то пошло ни так, т.е. тогда, когда они испытали отрицательные эмоции от пользования продуктом.

Если во время тестирования пользователь не может самостоятельно разобраться с продуктом, продукт нуждается в доработке.

творческий процесс

Когда мы занимаемся инжинирингом продукта, важно:

31. Продукт-менеджер должен очень хорошо понимать специфику R&D-процессов, в обратном случае он не может эффективно управлять как своей командой разработчиков, так и аутсорсинговой.

32. Стоимость разработки определяется некомпетентностью заказчика, поэтому нежелание погружаться работу подрядчика стоит очень дорого.

33. Отсутствие компетенций в компании не является ограничением для создания продукта. Сегодня компетенции можно очень быстро наращивать через процессы обучения и рынок труда.

34. Agile делает разработку быстрее и эффективнее. Главное не заигрываться и не превращать здравый смысл, заложенный в agile, в религию.

35. Сильная команда разработчиков (включая руководителя) и возможность быстрых замен, если что-то пошло не так – важное условие успешного завершения R&D-проекта в срок.

Скриншот из архива Humathèq

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

Кроме денег разработчику важен внутренний рейтинг и референс-лист, который в будущем будет определять, в каких проектах он будет задействован. При этом самым важным мотиватором разработчиков является увлечённость проектом.

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

37. Планирование и контроль – это наше все!

38. Самый лучший тестировщик – это пользователь.

39. Любые разработки необходимо бюджетировать, также необходимо контролировать следование бюджетным ограничениям, в обратном случае может получиться так, что R&D-инвестиции отбить не получится, не говоря уже о “заработать”.

40. С MVP (Minimum Viable Product, минимально жизнеспособный продукт) нужно быть аккуратным.

Часто “играя” в MVP, компании выбрасывают на рынок настолько сырые продукты, что они даже не способны “оторваться от земли”.

Принципы маркетинга новых продуктов:

41. Маркетинг нового продукта очень отличается от поддерживающего маркетинга. В первом случае нам необходимо вывести продукт “на орбиту”, т.е. обеспечить продукту “вертикальный взлет”, во втором – корректировать “движение продукта по орбите”, перемещать “на орбиты большего радиуса”.

42. Думая о монетизации продукта, важно не останавливаться на одном способе монетизации.

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

43. Сильный продукт-менеджер должен быть сильным маркетологом.

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

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

Поэтому запараллеливая продвижение и продажи с R&D-процессами мы, с одной стороны, быстрее начинаем продажи, с другой – в активной фазе коммуникаций с клиентами получаем обратную связь, которую сможем использовать в R&D.

фото из архива

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

фото из архива

46. Бренд – это инструмент, который решает две задачи: помогает склонять клиента и пользователя к выбору вашего продукта и помогает продавать дороже.

Бренд по-настоящему состоялся, когда он превратился в имя нарицательное и его пишут с маленькой буквы.

47. В маркетинге нового продукта отлично работает правило Паретто.

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

48. В 21 веке у большинства компаний существует соблазн сосредоточиться исключительно на онлайн инструментах, игнорируя офлайн, что в свою очередь делает олдскульные каналы менее конкурентными и достаточно эффективными.

Одним словом, нужно совмещать online и offline активность, не игнорируя что-то одно, а балансируя между реальным и виртуальным.

49. Маркетинговая активность – это дорогое удовольствие, а неэффективная маркетинговая активность – это расточительно, а, следовательно, короткий путь к банкротству.

Поэтому, принимая решение о том, стоит ли реализовать ту либо иную активность – задайте себе вопрос: как это поможет нам больше зарабатывать. Если никак, то не тратим ресурсы.

50. Самый большой маркетинговый грех – это когда продукт-команда судит о клиентах, пользователях и дистрибьюторах по себе.

…и немного о бизнес-модели продукта и стратегии продуктового бизнеса

51. Планируя развитие бизнеса, продуктового направления, компания должна отталкиваться от желаемых будущих результатов (стратегических целей), а не от текущего состояния бизнеса.

52. Компания должна стремиться к изменению ситуации на рынке (революционный подход) вместо приспособления к сложившейся рыночной ситуации (защитный подход).

53. Бизнес должен стремиться к созданию новых пространств для конкуренции (новых сегментов, новых продуктов, новых бизнес-моделей ) вместо поиска своего места и своих продуктов в существующей структуре рынка.

54. Компания должна стремиться к прорывным инновациям, а не делать ставку на постоянные улучшающие изменения существующих продуктов, хотя второе тоже необходимо.

из архива Humathèq

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

56. Компания должна стремиться к смелому соединению новых ресурсов и использованию нетрадиционных источников знаний.

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

58. Бизнес-модели рождаются в ходе экспериментального и предпринимательского подхода, а не книжных теорий.

59. Берите в продуктовые команды дивергентов, место конвергентов – за станком (пока ещё всё окончательно не роботизировали).

А ТЕПЕРЬ ЖИВИТЕ С ЭТИМ 🙂

#продукт-менеджмент #менеджмент продукта #менеджмент #разработка продукта #product management

Источник