В самом широком смысле продуктовый подход — это метод решения сверхзадачи, которая требует найти продукт, проверить его полезность для клиента, правильно упаковать и помочь бизнесу на этом заработать. В сущности на руках у менеджеров фиксированный набор алгоритмов решения этих задач, но на деле это «кулинария по рецепту» — люди выкладывают на тарелку одинаковые ингредиенты и получают различные блюда.
О том, почему так происходит и как персоны и процессы внутри компаний влияют на итоговый результат Sostav рассказал ex-руководитель команды дизайнеров нефинансовых сервисов «Тинькофф», ex-продуктовый дизайнер «Яндекс Лавки» и старший продуктовый дизайнер Juro Алан Каджаев.
Базовые знания одни на всех
Сегодня большинство компаний используют одни и те же подходы к созданию продуктов — книг по этому вопросу написано достаточно, но по сути своей они не отличаются. В итоге на руках у основателей стартапов, руководителей, продуктовых менеджеров и дизайнеров схожий набор вариантов, который с поправкой на действительность воплощается в создаваемых продуктах.
Под продуктовым подходом понимаются процессы и инструменты, которые помогают избегать ошибок на промежуточных этапах создания продукта, сервиса или бизнеса — это своеобразная шпаргалка для предпринимателя, которая поможет вовремя понять, когда что-то идёт не так.
Главная мысль заключается в том, что в центре идеи стоят люди. Открытым остается вопрос, кто эти люди и что они хотят? Ответить на него можно несколькими способами. Если не углубляться в технические детали, то все варианты уязвимых в одних и тех же местах и «прорываются» под влиянием человеческого фактора:
- Над продуктом работает много людей с неоднородным бэкграундом и опытом;
- Людям свойственно заблуждаться и делать необоснованные выводы.
Как минимизировать возможный негативный эффект? Взять за основу один из готовых методов с модным названием. Самый популярный, с которым мне довелось работать — это дизайн-мышление. Этот подход помогает за несколько шагов определить проблему, с которой сталкиваются пользователи, и найти её решение.
Если решение по каким-то причинам не подходит, цикл повторяется. Команда возвращается к определению потребности, чтобы ещё лучше её понять и обновить решение. Завершающим этапом цикла, после определения проблемы и формирования решения станет разработка прототипа. В дальнейшем этот прототип проверяется на реальных пользователях. Вот основа процесса.
На каждом отдельном этапе можно обращаться и к другим специфическим подходам. Например, для подробного анализа проблемы, существует фреймворк Job Story или Job to be done (JTBD), который буквально помогает понять потребность и мотивацию пользователя.
Чтобы проверить результат на выходе, допустимо сочетать текущие процессы с методом RITE, который наиболее продуктивно работает с готовыми решениями. Его суть в том, что после каждого тестирования следует обновлять и улучшать решение, а не ждать пока закончится весь цикл. Таким образом за один круг тестирования из 7−9 пользователей, можно прийти к полноценному результату за 2−3 дня.
Следование алгоритму не гарантирует результат
И российские, и зарубежные компании, в которых я работал в роли продуктового дизайнера, использовали схожие процессы на основе подходов, описанных выше. Говорит ли это о том, что на выходе получается одинаково хороший продукт? Конечно нет. Помимо процесса и подходов, на результат влияет то, как в компании аккумулируют информацию.
Здесь работает два шаблона. В отечественных и зарубежных компаниях они разительно отличаются. В России знания «спускаются» сверху вниз. Топ-менеджмент или основатель накапливает знания и спускает их на уровень команд в формате: «Вот, что я знаю, давайте с этим что-то сделаем».
В этом случае все описанные выше подходы перестают работать. На первое место выходит знание, а на деле — всего лишь ощущение одного или нескольких человек. Иногда это выстреливает, особенно, если этот человек чувствует рынок или компания выпускает что-то новое. Однако развивать существующий продукт в таком ключе сложно. Работа становится постоянным выяснением, чьё мнение сильнее.
За рубежом принят противоположный шаблон. Все знания о пользователях в виде обратной связи хранятся в открытом доступе для любого сотрудника. Команда работает не только с мнением основателя, но и с обратной связью от пользователя. Персонал в таком процессе играет ключевую роль: самостоятельно определяет, что будет лучше для бизнеса, определяет OKR и развивает продукт. Точка зрения основателей стоит не дороже позиции любого другого участника команды. Дальше в работу включается опыт и талант сотрудников.
Может показаться, что один из этих подходов однозначно лучше. На самом же деле и тот, и другой может приносить результат или работать плохо.
Опережение потребностей
Приведу пример из практики. Когда я пришел в «Тинькофф» в роли ведущего продуктового дизайнера, мы работали над продуктом, которому не было аналогов на рынке. На тот момент в мобильном банке уже была нефинансовая часть сервиса (покупка билетов в кино, заправка автомобиля или запись на стрижку). Нам стало очевидно, что предложений нефинансовых сервисов настолько много, что потребителю становится трудно в них ориентироваться.
Мы придумали решение, которое невозможно было бы вынести из исследования позиции потенциального потребителя да и в целом из традиционного продуктового подхода. Мы разработали персональную ленту, которая на основе больших данных помогает видеть предложения от всех сервисов сразу в одном месте.
Это совсем иной вариант разработки продукта — не от потребности, а на её опережение. В традиционном продуктовом подходе сложно найти подтверждение разумности этого предложения, поэтому работать над реализацией идеи рискованно и необоснованно. В таких случаях принято вспоминать цитату Генри Форда «Если бы я спросил людей, чего они хотят, они бы попросили более быструю лошадь».
Есть в моей практике и пример успешной работы над продуктом по традиционному пути. Когда в компании Циан готовился к запуску новый функционал выбора квартир, мы выстраивали канонический процесс в рамках Design Sprint — формировали и проверяли гипотезы, интегрировали и валидировали решения.
В итоге получилась ментальная модель пользователя — оказалось, что выбирать квартиру в новостройке удобнее не по табличке, как предлагали наши конкуренты, а прямо на карте. Эта концепция и легла в финальный интерфейс.
Выбор в основе
Таким образом, итоговый результат сильно зависит от суммы факторов. Весьма важно и правильно подобрать подход и метод организации процесса, оставаться гибким в принятии решений до самого конца.