Почему Granola «заходит» и что мы забываем в JTBD

На AI-Олимпе появился сервис Granola. Казалось бы, ещё один про заметки. Но его полюбили фаундеры и VCs. Почему?

Смысл там такой: ты сам пишешь заметки, Granola просто исправляет ошибки, добавляет пропущенное по смыслу, делает красиво.

Все конкуренты (Otter, tl;dv и др.) делают акцент на автосаммари через «просто добавь бота в Zoom». Часто это поверхностное саммари без особой структуры.

Я, например, таких случаях что делаю? Я беру сырой транскрипт и начинаю с ним работать вChatGPT, задавая вопросы и прося цитаты.

И это интересно, потому что фаундеры заметили такие паттерны: люди всё равно писали свои заметки, даже с ботом.

И тогда родилась гипотеза: «а что если сделать сервис, где человек пишет заметки сам, а AI просто помогает?»

То есть вы можете писать заметки во время звонка, как обычно. Granola потом: дополняет их, правит ошибки, сокращает, убирает мусор, показывает, где AI добавил, а где сами написали.

Давайте разберем эту штуку через методологию.

Большинство конкурентов видят явный JTBD: «Когда я на встрече, я хочу записать всё, чтобы потом не забыть и не делать заметки вручную.» Это ведёт к ботам в Zoom, саммари на 3 параграфа, короче фокусу на «запись», «автоматизацию» и на «сэкономить время».

Но это — commodity. Все делают это.

У granola появился инсайт: Мне нужно, чтобы мои заметки были лучше, чем я способен сделать сам. Но без давления, что «AI всё сам сделает». Это снижает тревожность: контроль остаётся у человека.

Сервис явно показывает: что написал ты, а что добавил AI (цветом, форматированием).

Granola не сделала просто фичу «AI summary», она сделала сценарий, устраняющий тревогу при важных встречах.

Чем-то мне это напоминает сервис Loom - если копнуть глубже, оба построены на эмоционально-заряженных, скрытых сценариях. Когда рынок думал: «Видео — это про запись туториалов и асинхронные встречи»

Loom понял: «Я хочу быстро объяснить что-то 1 человеку, без Zoom и без бесконечных писем.»

Оба продукта вытащили скрытый JTBD и превратили его в продукт с «вау» через поведенческий инсайт.

Какая сейчас проблема у многих команд. Исследование сделали, фичу и интерфейс придумали, сценарий — нет. То есть JTBD превратился в шаблон, а не в инструмент понимания. Команды заполняют формулу: “Когда я делаю X, я хочу Y, чтобы Z.”

Пример: «Когда я работаю с клиентами, я хочу записывать важное, чтобы не забыть.»

Это может значить всё, что угодно: от диктофона до Miro.

Тут мы переходим к формулировке функциональной работы через практическое поведение.

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

Без него всё превращается в красивую, но бесполезную обобщёнку.

Сравните: «Когда я только что закончил звонок с клиентом и не уверен, что запомнил, что пообещал, я хочу, чтобы заметка уже была готова и выглядела чётко, чтобы я мог сразу отправить её в Slack и выглядеть собранным.»

«Я хочу просмотреть и отправить готовую заметку в Slack» - теперь это про UX, про сценарий, про флоу. Поведение превращает мотивацию в дизайнерскую задачу.

Такие микроджобы можно сразу трансформировать в дизайн-брив: «После клиентского Zoom-звонка (контекст) ощущает тревогу, что мог забыть обещание (эмоция) копирует заметку в почту самому себе (обход)

->>>>нужен 1-клик-шаринг готовой заметки в Slack + метка «обещание» (решение).»

Так дизайнеру/разработчику передаётся не абстракция «сделай кнопку», а живая сцена.