Машинное обучение — это новый рубеж для исследования пользователей, ожидайте скоро увидеть его в своей дорожной карте! Но прежде чем паниковать, прочитайте мои 3 шага, чтобы гарантировать, что ваш продукт машинного обучения успешно выйдет на рынок.

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

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

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

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

1. Проводите поиск пользователей, а не продуктов

Одна из ключевых ошибок, которую допускают продуктовые команды, заключается в том, что они не проводят надлежащее исследование, и под «правильным» я имею в виду исследование, ориентированное на пользователя, — исследование и сопереживание нашему потенциальному рынку, знакомство с их задачами, потребностями, болевым синдромом и работой. -что-будет-сделано в мельчайших подробностях. Выполнение этого заранее и на глубине значительно снижает последующие риски, связанные с выводом на рынок любого нового продукта, не говоря уже о продуктах ML. Конечно, это довольно очевидный момент, но это не уменьшает важности его принятия. Чем больше вы знаете о своих клиентах и ​​их потребностях, тем лучше вы сможете их решить.

В Klydo мы сами допустили эту ошибку — во многом потому, что пространство, в котором мы находимся, и решения, которые мы выводим на рынок, настолько новы и оригинальны. Я помню, как в феврале 2021 года, когда мы были в середине наших семинаров по совместному творчеству, мы проделали неплохую работу по выявлению потенциальных вариантов использования и клиентов (хотя, оглядываясь назад, вероятно, недостаточно), и мы пригласили некоторых из них для серии семинаров. Мы надеялись выявить и понять их проблемы, а затем связать предлагаемое нами решение с потребностью, которая частично совпадала, путем совместного создания с ними потенциальных продуктовых маршрутов. Это хорошо помогло нам уточнить первоначальное видение и концепцию продукта, но не дало нам достаточно широты или смелости, чтобы выйти за рамки того, что мы надеялись найти. Если бы мы не были так сосредоточены на проверке варианта использования для извлечения сущностей или даже использования онлайн-данных в исследованиях, мы могли бы потратить больше времени в контексте их пути пользователя, чтобы действительно понять, нужны ли наши решения. Или мы могли бы начать с чистого листа и беспокоиться о реализации продукта, как только мы нашли желаемое решение.

Ключевое фундаментальное различие между пользователями и продуктами заключается в том, что вы не начинаете исследование с мыслью о решении, потому что, если вы это сделаете, вы почти всегда обнаружите необходимость соответствия. Но проблемы возникают, когда вы понимаете, что выявленная вами потребность может быть недостаточно распространенной или значимой, чтобы поддерживать бизнес-модель, и именно в этот момент вам приходится менять направление, пока вы не остановитесь на той, которая подходит. Это очень сложный процесс разработки продукта, который может быть невероятно расточительным. Тем не менее, понятно, что реальность разработки продукта ML означает, что часто вы не знаете ничего лучше, и, несмотря на ошибки, которые мы сделали в Klydo, мы все же получили невероятно важные знания об исследованиях пользователей, которым позавидовал бы даже Ласточкин хвост!

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

  1. Широкое понимание вашего предполагаемого рынка, кто является заинтересованными сторонами и как они связаны друг с другом? (Контекстные опросы, упражнения на погружение, 5 почему, картирование стейкхолдеров)
  2. Глубокое понимание пользовательского пути каждой заинтересованной стороны и, исходя из этого, их потребностей, болевых точек и задач, которые необходимо выполнить (для этого отлично подходят неархетипические Персоны и Приложения пользователя TheyDo).
  3. Необходимо согласование, какая потребность вызывает наибольшее разочарование? Какие заинтересованные стороны обычно проявляют эти потребности? (Концептуальное картирование, Матрица важности/сложности)
  4. Согласование продукта, есть ли решения на рынке (ML или другие)? Как вы могли бы отличить? Как и почему заинтересованные стороны используют эти решения? Взламывают ли они собственные решения? (Анализ конкурентов)
  5. Ключевые допущения, каковы возможности для решения и почему? Какие гало-инсайты вы обнаружили? (Матрица предположений для открытия)

2. Сосредоточьтесь на дополнении, а не на автоматизации

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

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

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

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

Неа. Такой тип мышления просто заставит вас запутаться в очень длинной и разочаровывающей ловушке осуществимости, поскольку вы потратите драгоценное время, пытаясь доставить слона на Луну, тогда как вы должны пытаться доставить его до Луны. Сначала Флорида. Зачем тратить свое время, пытаясь рискнуть и сделать все заранее, когда вы можете начать с малого и снизить риск путем итерации?

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

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

3. Забудьте о причудливых методах, будьте худыми и грязными

Один из вопросов, которые исследователи пользователей ЛЮБЯТ задавать другим исследователям пользователей, — это их любимые методы. Я сам виновен в том, что у меня есть несколько предпочтительных смешанных методов, которые до моего прихода в Клайдо я считал уверенными победителями в любой задаче. Оказывается, я был не прав!

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

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

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

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

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

Подведение итогов

  1. Сделайте правильное открытие, чтобы узнать и понять своего клиента, его путь пользователя, потребности, болевые точки и задачи, которые необходимо выполнить, используйте это, чтобы определить ключевые возможности для решения с вашим ML
  2. Расширяйте свои идеи, сосредоточившись в первую очередь на расширении задач и их реализации.
  3. Быстро разрабатывайте и экспериментируйте с прототипами без минимального кода, чтобы тестировать различные решения или аспекты различных решений изолированно в соответствии с вашими выявленными потребностями.