Как перестать блуждать ёжиком в тумане и улучшать продукт разумно

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

Предисловие. Как мы допустили ошибку

Если вы хотите управлять проектами, одного приложения недостаточно. Именно поэтому work-management платформы Wrike, Asana, Jira охотно интегрируются с приложениями вроде Zoom, Outlook или Slack — они хотят сделать работу клиентов более связной и комплексной.

Нередко платформы интегрируются с другими продуктами наобум — добавляют свои самые популярные функции в чужую экосистему и напрасно ждут успеха. Компания Wrike допустила ту же ошибку. Наше приложение для MS Teams было лишь бледной копией основной версии. Пользователи MS Teams устанавливали интеграцию Wrike из внутреннего маркетплейса, но почти не использовали её в ежедневной работе. Аудитория интеграции росла медленно, компании не докупали расширенные планы.

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

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

И первым делом мы решили лучше изучить наших клиентов.

Этап 1. Общаемся с клиентами

Мы отобрали около двадцати пользователей, которые уже пробовали пользоваться Wrike-интеграцией в MS Teams. Они занимали разные должности в своих компаниях и, как оказалось, пытались решить с помощью нашей интеграции разные проблемы.

После интервью мы разделили всех пользователей на четыре роли и отметили, какие именно проблемы были для них важными, а какие — второстепенными:

Этап 2. Формируем стратегию

Опираясь на результаты исследований, мы составили 5D-конструктор, который вмещал в себя все возможные комбинации пользователей:

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

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

Напоследок мы определили продуктовую метрику, на которую хотели повлиять:

Этап 3. Подбираем конкретные задачи

Во время интервью Работники чаще всего просили:

• Присылать в чаты уведомления об изменениях в проекте: смену статусов и ответственных, упоминания в комментариях
• Заменить плоский список задач на Проводник для того, чтобы видеть структуру проектов
• Добавить возможность создавать задачи прямо в MS Teams

Мы наложили запросы пользователей на наш 5D-конструктор и посмотрели, какие именно просьбы совпадают с выбранным нами направлением:

Задача "Нотификации в чаты" совпала с нашей новой стратегией на 100%

А вот «Создание задачи прямо из MS Teams» немного разошлась с нашими целями (уровень 4)

Читайте подробнее: Как мы проектировали нотификации для MS Teams

Был ли данный эксперимент полезен?

Безусловно, да.

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

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

Бизнес-департамент убедился, что мы не бродим вслепую, а планомерно изучаем сегмент за сегментом, ища точки роста для бизнеса.

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

На каждый шаг у нас имелся аргумент — и это сэкономило миллионы нервов всем участникам проекта.