Автор: Lenny Rachitsky (Ленни Рачицкий) Май 2024 г. Повествование от третьего лица. Вольный перевод сделал Роман Петров.
Мы общаемся в Telegram канале - Канбан клуб - присоединяйся
Основанный меньше двух лет назад, Perplexity стал для Ленни Рачицкого повседневным инструментом — он открывает его по нескольку раз в день, заменив значительную часть его поисков в Google, — и он не один такой. Имея менее 50 сотрудников, компания выросла до десятков миллионов пользователей. Они уже генерируют более $20 млн годовой выручки по подпискам (ARR) и бросают вызов и Google, и OpenAI в битве за будущее поиска. Недавний раунд в $63 млн оценил компанию более чем в $1 млрд; среди инвесторов — Nvidia, Джефф Безос, Андрей Карпаты, Гарри Тан, Дилан Филд, Элад Гил, Нэт Фридман, Даниэль Гросс и Навал Равикант (самого автора среди них нет 😭). Генеральный директор Nvidia Дженсен Хуанг сказал, что пользуется продуктом «почти каждый день».
Ленни Рачицкий поговорил с Джонни Хо, сооснователем и руководителем продукта Perplexity, чтобы дать читателю взгляд изнутри на то, как Perplexity делает продукт — и, по его мнению, это похоже на будущее продуктовой разработки во многих компаниях:
- AI‑first. Они задают ИИ вопросы на каждом шаге построения компании, включая «Как запустить продукт?». Сотрудников поощряют сперва спросить у ИИ, прежде чем отвлекать коллег.
- Организация как «слизь» (slime mold). Они минимизируют издержки на координацию, максимально распараллеливая части каждого проекта.
- Малые команды. Типичная команда — 2–3 человека. Их сгенерированный ИИ (и высоко оценённый) подкаст делает и ведёт один человек.
- Мало менеджеров. Они нанимают самоорганизованных индивидуальных исполнителей (IC) и намеренно избегают тех, кто силён прежде всего в «руководстве чужой работой».
- Прогноз на будущее. Джонни говорит: «Если бы мне пришлось гадать, со временем наиболее ценными в компании станут технические PM или инженеры с хорошим продуктовым вкусом».
Как Perplexity строит продукт
1. Использование ИИ-инструментов внутри Perplexity
По словам Джонни Хо, в самом начале команда не знала многого — от продакт-менеджмента и проектного управления до финансов и HR. Имея ранний доступ к GPT-3, они начинали почти любую тему с вопросов ИИ: «Что такое X?» и «Как правильно делать X?». Например: «Как запустить продукт? Какие шаги входят в запуск?» Модель давала черновой поэтапный план — для стартапа этого хватало, а дальше шли естественные итерации.
Самостоятельные попытки разобраться занимали у команды дни, тогда как с ИИ и парой подсказок удавалось сдвинуться за пять минут. Этот подход сохраняется и сейчас: например, на этой неделе Джонни спрашивал у Perplexity, как написать приглашение в Perplexity Pro.
Команда пробовала применять ИИ и для разработки, но выяснила, что для устойчивой кодовой базы ИИ пока годится главным образом на уровне скриптов и шаблонов. Полноценные «долгоиграющие» абстракции он по-прежнему не проектирует.
2. Сколько продакт-менеджеров в компании
В организации из ~50 человек — всего два продакт-менеджера на полной ставке.
Типичный проект ведут один-два человека; самые сложные — три-четыре. Например, подкаст компании от и до делает один человек: по роли он бренд-дизайнер, но берёт на себя и аудиоинженерию, и ресёрч. Продакт-менеджер туда практически не вовлекался.
Продакт-менеджмент используют прежде всего там, где есть сложные развилки и более «тяжёлые» инициативы. Ключевая компетенция PM, по словам Джонни, — продуктовый вкус к use case’ам: в ИИ их слишком много, и нужно принимать качественные ветвящиеся решения на базе данных и пользовательских исследований. Ранним стратегическим выбором стала ориентация на «производительные» сценарии (vs. «разговорные»/развлекательные), но дискуссии продолжаются. В течение года планируют нанять ещё 1–2 PM — лишь при прохождении кандидатами крайне строгого отбора.
3. Подход к найму
Команда прежде всего ищет гибкость и инициативу — способность продуктивно строить в условиях ограниченных ресурсов и нескольких ролей на человека. По мнению Джонни, с приходом ИИ навыки «руления чужой работой» и процессами стали менее критичны: компания ценит сильных IC с явным внешним влиянием на пользователей, а не на внутренние процессы. Резюме с акцентом на «Agile expert»/«Scrum Master» обычно сигналят о низком совпадении с требованиями роли в Perplexity — компания ищет сильных IC с техническим бэкграундом и продуктовым вкусом, а не специалистов по процессам и координации людей.
ИИ позволяет PM делать больше индивидуально — от анализа данных до инсайтов по клиентам. Базовая математика/статистика и базовое программирование всё ещё нужны, но «быть техническим PM» стало проще. Культурный фит и лёгкость взаимодействия важны, но слоёв менеджмента, по мнению Джонни, в индустрии со временем станет меньше; наиболее ценными будут технические PM или инженеры с продуктовым вкусом.
4. Как структурированы команды
Цель Джонни — минимизировать «координационный встречный ветер» (по Алексу Комороске, метафора slime mold). По мере роста организации издержки координации растут, а добавление менеджеров не спасает: стимулы расходятся, информация искажается по управленческой вертикали.
Подход Perplexity — держать цели выровненными и максимально распараллеливать работу за счёт переиспользуемых гайдов/процессов. ИИ используют как «резиновую уточку» для прогонки идей и снижения координационных затрат. Во внутренних доках поддерживают актуальный «who’s who», и любой может напрямую обратиться к нужному коллеге — на доверии. Ещё важнее то, что благодаря ИИ к людям реже приходится обращаться вообще: часто достаточно минуты с ИИ, чтобы получить адекватную стартовую точку.
5. Горизонты и стабильность планов
Компания планирует поквартально; внутри кварталов держит стабильный продуктовый roadmap: несколько крупных проектов на всех и набор мелких задач, которые сдвигают по приоритетам. В ИИ изменения непредсказуемы, поэтому гибкость критична. Развитие open-source-моделей и контекстной длины напрямую влияет на продукт, карту и бизнес. Недавние примеры — Llama 3 от Meta и 8x22B от Mistral: команда ищет способы их интеграции.
Продуктовая карта идёт параллельно с технической/модельной; инженеры переключаются между поддержкой и разработкой новинок. Техкарта разрастается по мере ограничений систем и техдолга; приоритет — техдолг, который разблокирует продуктовые улучшения.
На недельном горизонте планы относительно стабильны. По понедельникам — короткий kickoff и культура «75%-целей»: каждый формулирует главный приоритет недели и целится в ~75% его выполнения. Это задаёт прозрачность приоритетов и снижает реактивность. Со временем улучшились и оценка размеров задач, и приоритизация по ROI.
6. OKR
В квартальном планировании — максимальная строгость и опора на данные. Все цели измеримы: количественными порогами или булевым «сделано/не сделано». Амбиции высокие: к концу квартала обычно закрывают около 70%; оставшиеся 30% подсвечивают пробелы в приоритизации и укомплектованности (например, недобор инфра-инженеров быстро проявляется в провале инфра-целей).
7. Как проходят продуктовые/дизайн-ревью
После постановки центральных целей и high-level-дизайнов решения принимают децентрализованно. У каждого проекта есть DRI, а исполнение максимально идёт параллельно. Первый шаг — декомпозировать работу на самодостаточные параллельные задачи (в Linear), чтобы не было блокеров; спорные решения допускаются — разруливаются позже.
Короткий kickoff на старте, далее — асинхронные итерации без жёстких процедур согласования. Когда кому-то нужна обратная связь, материалы уходят в Slack, команда даёт честный, конструктивный фидбек. Релиз не происходит, пока продукт не наберёт внутреннюю тягу (dogfooding).
Джонни поощряет параллельность: дизайн, фронтенд и бэкенд работают одновременно; теперь и бизнес-направление подключается параллельно, тогда как в классическом цикле ждали бы мокапы.
8. Подчинение и метрики
Команды организованы по функциям (продукт, R&D, дизайн, бизнес и т. д.), но весь фокус — на улучшении ядра продукта. На уровне целей — общие верхнеуровневые метрики и целостное улучшение UX; внутри своих слоёв команды A/B-тестируют. Чтобы избежать политики и «привязки идентичности» к компонентам, структура держится максимально плоской, приоритеты диктуются не линиями отчётности, а обязательствами по top-level-целям. Два full-time PM (веб и мобайл) репортят head of product; там, где PM нет, участники берут PM-функции на себя — режут скоуп, принимают пользовательские решения и опираются на собственный вкус.
9) Что централизовано в подходе к продукту
Команда целенаправленно собирает фидбек — внешний и внутренний — и перегоняет его в небольшое число интуитивных решений, подходящих многим клиентам. Видение остаётся широким, а локальные решения — за владельцами. Децентрализация передаёт ответственность «на край» и ускоряет итерации без этапных одобрений; локальные срочные решения принимаются быстро, а разнобой выравнивается постфактум.
10) Инструменты задач и багов
Основной таск-трекер — Linear. В ИИ-продуктах грань между задачами, багами и проектами размыта, но механики Linear (Leads, Triage, Sizing и др.) оказались очень полезны. Любимая фича — автоархивация: если задачу давно не упоминали, вероятно, она не важна.
«Источник истины» — Notion: в разработке — дизайн-доки и RFC, после релиза — документация, постмортемы, история. Фиксация хода мысли («класть мысли на бумагу») делает решения яснее и позволяет синхронизироваться асинхронно, без встреч.
Недавно добавили Unwrap.ai — чтобы консолидировать и количественно осмыслять качественный фидбек. В ИИ многие проблемы не детерминированы настолько, чтобы метить их как баги; Unwrap группирует разрозненные отзывы в темы и зоны улучшений.
11) Откуда появляются идеи roadmap
Top-down ставят высокоуровневые цели и направления, но много идей рождается bottom-up. Инженеры и дизайнеры владеют идеями и деталями — особенно важно в ИИ, где ограничения понятны только после прототипирования. Есть выделенный brainstorm-канал в Slack; доработки фиксируются в Linear; полировки часто сразу летят в код.
Сильные примеры bottom-up — Discovery, Collections и Sharing. Бренд-дизайнер Фи параллельно делает подкаст Discover Daily, принимает решения по скрипту, интеграции ElevenLabs, бренду и аудиоинженерии. Год назад никто бы не предсказал, что опыт Discover перетечёт в подкаст.
12) Что даётся сложнее всего
Главный вызов — переход к следующему масштабу: и найм, и исполнение/планирование. Важно не потерять идентичность плоской, коллаборативной среды. Даже бытовые решения — как масштабировать Slack и Linear, сохраняя прозрачность и не взрывая уведомления — требуют аккуратной настройки.
13) Ритуалы и традиции
Многие заметные фичи и продукты родились в рамках коротких хакатонов (неделя и меньше). Такие сфокусированные «рывки» — самые драйвовые и запоминающиеся. Первый прототип интерактивного поиска, Pro Search (ранее Copilot), собрали за несколько дней, а затем доводили множеством полировок.
Ленни благодарит Джонни, а также Фи Хоанга за помощь с визуалами.
Если хотите узнать больше — загляните в Perplexity. И да, они нанимают!
Хорошей и продуктивной недели 🙏
--------------
Мы общаемся в Telegram канале - Канбан клуб - присоединяйся