Как Notion создает продукт

Всем привет!

Автор статьи поделится интервью с Майклом Манопатом, Chief Product and Technology Officer компании Notion, о развивающихся внутренних процессах Notion, обзорах продуктов, каденциях планирования и растущем переходе к живой коммуникации.

Автор статьи – Lenny Rachitsky

На прошлой неделе я работал в своем домашнем офисе и услышал, как моя жена в другой комнате кричит: «Я люблю Notion!». И я знал, что она имела в виду: более 20 миллионов человек и сотен тысяч команд используют Notion по всему миру для организации своей работы и выполнения задач. В настоящее время Notion занимает четвертое место среди самых быстрорастущих приложений в мире (в прошлом году оно занимало 1-е место) и, что неудивительно, он является одной из наиболее востребованных команд. По этой причине в данной статье я бы хотел подробнее рассказать о команде Notion и о том, как лучшие продуктовые команды создают продукт.

Я с нетерпением жду того, чтобы рассказать вам об этом, и оно того стоит. Огромное спасибо Майклу Манапату, CPTO (Chief Product and Technology Officer) Notion, и всей команде Notion за ответы на мои многочисленные вопросы. Как обычно, вы найдете множество действенных уроков и фреймворков, и больше, чем в любом другом издании, готовых руководств и примеров.

Содержание:

1. Вот что больше всего, на мой взгляд, выделяется в подходе Notion к продукту
2. Как Notion создает продукт
3. В какой временной перспективе вы используете детализированное планирование, и как это менялось со временем
4. Сколько у вас продакт-менеджеров?
5. Используете ли вы OKR (Objectives and Key Results/Цели и Ключевые результаты) в той или иной форме?
6. Как проходят встречи по обзору нового продукта/дизайна?
7. Являются ли продукт и дизайн частью одной структуры? Кому в конечном итоге отчитываются продакт-менеджеры? Как это менялось с течением времени?
8. Какая структура у ваших продуктовых команд?
9. Какие инструменты используют ваши продуктовые команды?
10. Онлайн-курс “Продакт-менеджмент” для тех, кто тоже хочет научиться создавать продукты

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

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

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

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

До 15. Из 550 человек. Наша команда по управлению продуктами крошечная. Возможно, вы знаете, что мы долгое время не нанимали продакт-менеджеров. У нас впервые появился продакт-менеджер около двух лет назад, когда у нас было около 50-60 программистов. И я не уверен, что это было правильно. Notion и мой бывший работодатель Stripe - оба очень инновационно ориентированы на старте, и обе компании имеют ориентированных на продукт программистов, что, на мой взгляд, здорово. Тем не менее, существует разница между программистами, которые думают о продукте, и продакт-менеджерами, которые постоянно общаются с пользователями и работают с их отзывами, координируя свои действия с командами, занимающимися выходом на рынок, и хорошо разбираются в стратегии продукта. Думаю, что этого не хватало в Notion на раннем этапе. Поэтому я рад, что у нас теперь есть продакт-менеджеры и что мы развиваем команду управления продуктами.

Что интересно в Notion - что ни одна часть продукта не может быть изолирована. В Stripe существовал ряд полностью независимых продуктовых линеек. В группе, которой я руководил, продукты были связаны только компетенциями, необходимыми для их создания (помимо общей работы над продуктом, требовалось машинное обучение и глубина искусственного интеллекта). Например, был Radar, фрод-продукт. И был Капитал, кредитный продукт. Из общего у них было то, что они были созданы на базе машинного обучения и ИИ (искусственного интеллекта), но в остальном они были независимы - очень малое из того, что делал Радар, могло бы повлиять на Капитал, и наоборот. Но Notion нельзя разложить на отдельные продукты. Поэтому, если вы работаете над предложением по управлению проектами в Notion и изменяете работу баз данных или изменяете работу страниц, это влияет на использование Notion в качестве инструмента для работы с документами или Wiki. Таким образом, это больше, чем задача централизованного планирования и координации продукта - здесь важно убедиться, что продукты рассматриваются целостно и что люди не решают задачи таким образом, что делают продукт хуже в целом.

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

На уровне ниже общекорпоративного OKR вариаций больше. У некоторых команд или направлений также есть OKR; например, у команд, работающих над ростом за счет продукта. В других сферах этот процесс только зарождается, и, честно говоря, для нас это непростая задача выяснить, когда многое из того, что мы пытаемся сделать, - это действительно прорыв, и как мы на самом деле измеряем успех. Как бы это могло выглядеть? Какова правильная структура для этого? Я бы сказал, что мы очень далеки от Google, где у них есть OKR на уровне компании, направлений, команд и даже на индивидуальном уровне.

Это еще одна область, где мы проходим много итераций. Раньше у нас было то, что мы называли «рабочими сессиями». Они длились от 30 до 45 минут и были относительно неструктурированными. Когда команда хотела обсудить что-то с руководителем продукта или у нас было что-то, что мы хотели обсудить с командой, мы просто организовывали встречу. И это были в основном мозговые штурмы или обсуждение идей.

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

В итоге мы пришли к процессу с четырьмя контрольными точками. Вот эти четыре этапа:
1. Обозначение проблемы пользователя
2. Обсуждение возможных направлений - каковы три или около того возможных подхода для решения проблемы пользователя и что рекомендует команда?
3. Полноценное решение, с точным дизайном и решенной проблемой
4. Финальный вариант, готовый к итоговой проверке качества

Все эти пункты в основном “асинхронны”. На каждом из этих шагов инженер, дизайнер, продакт-менеджер или программист пишут электронное письмо с тем, к чему они пришли, а затем мы рассматриваем и даем обратную связь. Мы обсуждаем все, начиная с «Что именно является проблемой пользователя?» и заканчивая «Как это решение взаимодействует с другими существующими решениями?», иногда придираясь к самым мелким деталям продукта.
Однако мы обнаружили, что такие несинхронизированные статусы не работают для некоторых типов задач. Какие варианты вы рассмотрели, и что вы думаете о каждом из них? Почему вы выбрали именно их? Объяснение этого в письменной форме занимает много времени. Люди тратили слишком много времени на документирование своих ответов, плюс обмен письмами - в общем процесс затягивался надолго.

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

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

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

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

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

Сейчас есть, по сути, четыре слоя команд. Первый слой - команды, работающие над пользовательскими сценариями использования, рабочими процессами (например, команда управления проектами), команда по работе с документами и Wiki. Они должны убедиться, что Notion решает проблемы пользователей путем сочетания существующих базовых решений, их расширения по мере необходимости и разработки пользовательского функционала. А ниже, образно говоря, есть команды, которые отвечают за базовые решения, такие как база данных в Notion. Базы данных нужны как команде Wiki, так и управления проектами, поэтому обе этих команды по сути являются «клиентами» команды баз данных (которую внутри мы называем «Коллекции»).

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

Иногда задачи не совсем четко соотносятся с какой-либо из этих отдельных команд. У нас есть команда по продуктам, которая занимается корпоративным сегментом в целом, хотя их повседневная работа, как правило, связана с тем, что нужно конкретному человеку (закупщику компании или администратору). Но с учетом общей направленности сегмента они задумываются о таких вопросах, как - например, что нужно компаниям с 20 000 пользователей от wiki-продукта? Возможно, им нужно что-то вроде верификации страниц. И тогда они должны рекомендовать внести эти изменения, даже если это будет делать другая команда (что так и происходило). А также, что им нужно с точки зрения хранения данных, их локализации или безопасности? Руководитель продакт-менеджеров также общается с департаментом инфраструктуры. Крупным компаниям также нужен Notion для слаженной работы с другими инструментами, что требует работы над нашим API и интеграциями - частью "средних" слоев. Таким образом, Биркан, который руководит всеми продакт-менеджерами, на самом деле работает над всем Notion и не привязан четко к одной команде.

Мы используем Notion практически для всего - создания текстов, управления проектами, презентаций и т. д. И мы надеемся, что, по крайней мере, продуктовые команды, они могут использовать Notion (почти) для всего. «Почти» - потому что некоторые важные задачи, например, дизайн (здесь мы используем Figma), настройка и анализ экспериментов (мы используем Statsig) или анализ данных (мы используем Hex), вы не можете сделать в Notion, и это не те задачи, которые имело бы смысл добавлять в Notion - по крайней мере, в ближайшее время. Конечно, вы можете встроить свою работу из многих из этих инструментов в Notion, что поможет сохранить Notion в качестве «хаба» для всей вашей работы.

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

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

В результате курса вы:

• Создадите прототип продукта за 3 месяца или улучшите текущий продукт
• Научитесь проводить качественные исследования рынка
• Узнаете, как выводить продукты на зарубежный рынок
• Посчитаете экономику продукта и сможете принимать решения на ее основе

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

Чтобы начать чувствовать себя уверенно в профессии и найти востребованную работу — оставляйте заявку по ссылке.

Также вы можете оставить заявку на наш корпоративный тренинг по Product Management.