Методичка · Библиотека ДИС
Основы продуктового мышления в AI и IT
Учит начинать с проблемы пользователя, проверять гипотезы через MVP и измерять результат продукта.
| МЕТОДИЧЕСКОЕ РУКОВОДСТВООсновы продуктового мышления для AI/IT-специалистаОт проблемы пользователя и ценности — к гипотезе, MVP, метрикам и масштабированиюСквозной пример: AutoSfera AI Редакция: 30 августа 2026 годаСТЕПАНОВ ДМИТРИЙ / МЕТОДИЧЕСКАЯ СЕРИЯ 2026 |
|---|
Назначение
Пособие предназначено для IT- и AI-специалиста, которому нужно перестать начинать проект с технологии и научиться начинать с результата пользователя и бизнеса. Главный вопрос продуктового мышления: не «что мы можем построить?», а «какую подтверждённую проблему мы решаем, для кого, каким минимальным способом и по каким данным поймём, что решение работает?»
После изучения вы сможете
отличать продуктовый outcome от технического output;
формулировать проблему, сегмент, JTBD и ценностное предложение;
строить проверяемые продуктовые гипотезы и выбирать MVP как эксперимент;
разделять discovery и delivery, не превращая discovery в разовую фазу;
назначать продуктовые, пользовательские, технические и guard-метрики;
принимать решения GO / ITERATE / PIVOT / STOP на основании фактов.
1. Продуктовое мышление: от функции к результату
Продуктовое мышление — это дисциплина принятия решений в условиях неопределённости. Команда не считает выпуск функции доказательством успеха. Функция — только ставка на то, что поведение пользователя или бизнес-результат изменятся.
| Проектное/feature-мышление | Продуктовое мышление |
|---|---|
| «Нужно сделать чат-бота» | «Какую проблему клиента должен уменьшить сервис?» |
| Успех = релиз | Успех = измеримый outcome |
| Roadmap функций | Гипотезы, возможности, эксперименты |
| Технология выбирается первой | Технология следует из задачи и ограничений |
| Обратная связь после релиза | Проверка предположений идёт постоянно |
AutoSfera AI: смена формулировки
Слабая постановка: «сделать мультиагентную AI-платформу для автосалона». Продуктовая постановка: «сократить время первого полезного ответа клиенту и увеличить долю обращений, которые переходят в квалифицированный лид или запись на сервис, не ухудшая точность, безопасность и удовлетворённость клиента».
Outcome против Output
Output: Telegram-бот, RAG, CRM-интеграция, три sub-workflow, админ-панель.
Outcome пользователя: быстрее получить релевантный ответ и следующий понятный шаг.
Outcome бизнеса: больше квалифицированных обращений, меньше ручной рутины, контролируемая стоимость обработки.
Guard: отсутствие критических ошибочных действий, утечек и неконтролируемых обещаний.
Современная продуктовая школа SVPG подчёркивает переход от «shipping output» к решению проблем клиентов и бизнеса, измеряемому outcomes. Teresa Torres разделяет discovery (решение, что строить) и delivery (построение, выпуск и сопровождение).
2. Исторический фундамент: продуктовая логика появилась не вчера
Современные Lean, Discovery и JTBD выросли из более длинной линии идей об эффективности, ценности, клиенте, обратной связи и эксперименте. Ниже — не «прямые предки» каждого современного фреймворка, а фундаментальные работы, которые помогают понять происхождение ключевых принципов.
| Год | Автор / работа | Что берём в продуктовый подход |
|---|---|---|
| 1776 | Адам Смит — The Wealth of Nations | Разделение труда, производительность, связь специализации с рынком. |
| 1832 | Чарльз Бэббидж — On the Economy of Machinery and Manufactures | Измерение операций, экономический эффект организации труда. |
| 1911 | Фредерик Тейлор — The Principles of Scientific Management | Наблюдать и измерять процесс до его изменения. |
| 1931 | Уолтер Шухарт — Economic Control of Quality | Вариативность, статистический контроль, цикл обучения через данные. |
| 1947 | Герберт Саймон — Administrative Behavior | Ограниченная рациональность: решения принимаются при неполной информации. |
| 1954 | Питер Друкер — The Practice of Management | Цели, клиент, ответственность и измеримый вклад. |
| 1962 | Эверетт Роджерс — Diffusion of Innovations | Принятие инноваций пользователями и роль наблюдаемой ценности. |
| 1984 | Элияху Голдратт — The Goal | Оптимизировать ограничение системы, а не локально удобный участок. |
| 1990 | Питер Сенге — The Fifth Discipline | Обратные связи и системное мышление. |
| 1993 | Хаммер и Чампи — Reengineering the Corporation | Не автоматизировать бессмысленный процесс — сначала переосмыслить его. |
Особенно полезен Адам Смит: уже в XVIII веке он связывал производительность с разделением труда и подчёркивал, что глубина специализации ограничена размером рынка. Для продуктового специалиста это напоминание: эффективность решения бессмысленна без реального контекста спроса.
3. Customer Discovery, JTBD и Value Proposition
3.1. Сначала понять клиента
Value Proposition Canvas предлагает описывать Customer Jobs, Pains и Gains, а затем связывать их с продуктом, pain relievers и gain creators. Критически важно не подгонять профиль клиента под уже придуманное решение: предположения должны проверяться разговорами, наблюдениями и данными.
3.2. JTBD: какую работу «нанимают» продукт выполнить
Jobs To Be Done переводит внимание с демографии и списка функций на ситуацию прогресса. Вопрос: что человек пытается сделать в конкретном контексте и почему существующие альтернативы его не устраивают? Классический пример Клейтона Кристенсена с milkshake показывает, что продукт конкурирует не только с похожими продуктами, а со всеми альтернативами выполнения той же работы.
Пример AutoSfera AI
| Элемент | Пример |
|---|---|
| Сегмент | Покупатель автомобиля, который уже рассматривает конкретный класс/модель. |
| Job | Быстро понять, подходит ли вариант и что делать дальше. |
| Pain | Долгое ожидание менеджера, противоречивые ответы, необходимость повторять данные. |
| Gain | Понятный ответ, подтверждённые характеристики, прозрачный следующий шаг. |
| Решение | AI-ассистент с RAG + передача в CRM + human escalation. |
| Не решаем | Не обещаем цену/наличие/условия, которых нет в проверенном источнике. |
Вопросы discovery-интервью
Расскажите о последнем случае, когда вы выбирали автомобиль или записывались на сервис.
На каком этапе возникло больше всего ожидания или неопределённости?
Что вы делали вместо обращения к менеджеру?
Какая информация была нужна, чтобы перейти к следующему шагу?
Что заставило бы вас прекратить диалог с цифровым ассистентом и потребовать человека?
4. Continuous Discovery и карта возможностей
Teresa Torres определяет continuous discovery как регулярные, как минимум еженедельные, контакты команды с клиентами и небольшие исследовательские активности ради желаемого outcome. Смысл не в количестве интервью, а в постоянной связи продуктовых решений с наблюдаемой реальностью.
Opportunity Solution Tree — логика
Зафиксировать желаемый outcome.
Собрать возможности/проблемы из интервью, поведения, поддержки, продаж и аналитики.
Разложить крупные возможности на более конкретные.
Выбрать перспективную возможность, а не любимую функцию.
Предложить несколько решений одной возможности.
Выявить предположения каждого решения и протестировать самые рискованные.
AutoSfera AI: пример дерева
Outcome: увеличить долю обращений, переходящих в полезный следующий шаг.
| Возможность | Возможные решения | Что проверить |
|---|---|---|
| Клиент долго ждёт первый ответ | Автоответ + RAG; triage; подсказка менеджеру | Нужен ли мгновенный ответ? Какой latency приемлем? |
| Клиент не понимает различия комплектаций | Сравнение; карточка различий; уточняющий диалог | Какие 3–5 параметров реально влияют на выбор? |
| Лид теряется между чатом и CRM | Автосоздание лида; подтверждение менеджером | Сколько лидов теряется сейчас? Цена ошибки дубля? |
| Низкое доверие к AI | Источники; уверенность; кнопка «менеджер» | Что именно повышает доверие пользователя? |
Главное правило: не превращать дерево в каталог функций. Возможность должна описывать потребность, препятствие или неудовлетворённый контекст пользователя, а решение — лишь один из вариантов ответа.
5. Гипотеза, Lean и MVP
Lean-подход полезен не лозунгом «делать быстрее», а сокращением цикла обучения. MVP — не дешёвая версия будущей платформы. Это минимальный способ получить достоверное свидетельство о ключевом предположении с приемлемым риском.
5.1. Формула продуктовой гипотезы
Если мы [изменение] для [сегмента] в [контексте], то [Primary-метрика] изменится с [baseline] до [цель] за [период], при этом [Guard-метрика] останется в допустимой границе.
Пример AutoSfera AI
Если дать AI-ассистенту право автоматически отвечать только на подтверждённые типовые вопросы о моделях и сервисе, а сложные случаи передавать человеку, то медианное время первого полезного ответа сократится относительно baseline, при этом доля критически неверных ответов не превысит заранее установленный порог. Конкретные числа должны быть согласованы после измерения baseline.
5.2. Лестница MVP
| Уровень | Что делаем | Что узнаём |
|---|---|---|
| 0. Concierge | Человек вручную имитирует будущую услугу | Есть ли вообще ценность и повторяемый Job? |
| 1. Wizard of Oz | Пользователь видит сервис, часть логики скрыто выполняется вручную | Как пользователь взаимодействует с решением? |
| 2. Shadow | AI формирует ответ, но не влияет на клиента | Качество и ошибки на реальном потоке. |
| 3. Assist | AI предлагает, человек утверждает | Экономия времени и принятие сотрудниками. |
| 4. Limited auto | Автоматизация только низкорисковых сценариев | Реальный эффект и guard-метрики. |
Для AutoSfera AI разумный MVP — один сквозной сценарий: входящее обращение → классификация → ответ по проверенной базе → создание/обновление лида → эскалация менеджеру при низкой уверенности. Это лучше, чем одновременно строить продажи, сервис, HR, аналитику и сложную мультиагентность.
6. Метрики: доказать ценность, а не активность
Метрика нужна не для отчётности, а для решения. До эксперимента команда должна знать, какое наблюдение заставит масштабировать, изменить или остановить решение.
| Слой | Примеры для AutoSfera AI | Зачем |
|---|---|---|
| North Star / outcome | Доля обращений с подтверждённым полезным следующим шагом | Связать продукт с ценностью. |
| Primary | Время до полезного ответа; конверсия в лид/запись | Проверить гипотезу. |
| Guard | Критические ошибки; утечки; неверные действия | Не оптимизировать ценой риска. |
| User | CSAT; доля запросов к оператору; исправления | Понять реальную полезность. |
| AI/RAG | Groundedness; полнота; Recall@k; отказ при отсутствии данных | Локализовать техническую причину. |
| Ops | p95 latency; uptime; ошибки API; стоимость диалога | Проверить эксплуатационность. |
| Business | Стоимость обработки; пропускная способность; выручка/экономия | Проверить экономический эффект. |
6.1. Не путать пилот и A/B-тест
Пилот отвечает: «можем ли мы безопасно и полезно применять решение в реальном процессе?». A/B-тест отвечает на более узкий причинный вопрос и требует корректного распределения, выборки, MDE и заранее определённого анализа. Не каждый MVP требует A/B-теста.
6.2. Решение после пилота
GO — ценность подтверждена, обязательные guard-пороги соблюдены, можно расширять.
ITERATE — сигнал ценности есть, но гипотеза/UX/данные/архитектура требуют исправления.
PIVOT — исходная проблема важна, но выбранное решение или сегмент не подтверждены.
STOP — нет ценности, неприемлемый риск, нет владельца процесса или экономика не сходится.
7. Продуктовый цикл AutoSfera AI: от идеи к доказательству
Контекст. Выбрать один сегмент: например, входящие обращения потенциальных покупателей.
As-Is. Измерить текущий процесс: объём, время ожидания, конверсию, повторные обращения, ручную нагрузку.
Discovery. Провести интервью с клиентами и менеджерами, разобрать реальные диалоги и причины потерь.
JTBD/VPC. Сформулировать Jobs, Pains, Gains и выбрать 1–2 наиболее ценные возможности.
Гипотеза. Зафиксировать изменение, Primary, Guard, baseline, цель и срок.
MVP. Реализовать минимальный сквозной сценарий без лишней автономности.
Offline/Shadow. Проверить качество на эталонном наборе и реальном потоке без влияния на клиента.
Assist/Canary. Дать ограниченному сегменту, сохранив human-in-the-loop и rollback.
Решение. GO / ITERATE / PIVOT / STOP по заранее согласованным критериям.
Continuous Discovery. Продолжать еженедельный контакт с клиентами и тестировать следующие возможности.
Антипаттерны AI-продукта
Начинать с вопроса «какую LLM возьмём?» вместо «какой outcome нужен?».
Считать наличие RAG или агентов ценностью само по себе.
Строить мультиагентность там, где достаточно одного детерминированного workflow.
Показывать красивое демо без baseline, тестового набора и критериев остановки.
Оптимизировать accuracy, игнорируя цену разных типов ошибок.
Пытаться автоматизировать весь процесс до проверки одного низкорискового сценария.
Собирать обратную связь только после релиза и только у внутренних стейкхолдеров.
Практическое задание перед воркшопом
За 20 минут заполните одну страницу: сегмент → Job → 3 pains → 3 gains → текущая альтернатива → один outcome → одна гипотеза → MVP → Primary → Guard → критерий GO. Сделайте это для одного сценария AutoSfera AI, не для всей платформы.
8. Что читать: фундамент + современная практика
Фундамент
| Автор / книга | Зачем читать |
|---|---|
| Adam Smith — The Wealth of Nations (1776) | Рынок, специализация, производительность, экономическая логика. |
| Charles Babbage — On the Economy of Machinery and Manufactures (1832) | Процесс, разделение операций, экономика механизации. |
| Frederick W. Taylor — The Principles of Scientific Management (1911) | Наблюдение и измерение процесса до изменений. |
| Herbert A. Simon — Administrative Behavior (1947) | Решения в условиях ограниченной рациональности. |
| Peter F. Drucker — The Practice of Management (1954) | Клиент, цели, ответственность, результат. |
| Everett M. Rogers — Diffusion of Innovations (1962) | Почему инновации принимают или отвергают. |
| Eliyahu M. Goldratt — The Goal (1984) | Системное ограничение и поток. |
Современный продуктовый слой
| Автор / материал | Ключевая идея |
|---|---|
| Clayton Christensen et al. — Competing Against Luck / JTBD | Понимать прогресс, ради которого клиент «нанимает» решение. |
| Eric Ries — The Lean Startup | Короткие циклы обучения и проверяемые предположения. |
| Alexander Osterwalder et al. — Value Proposition Design | Jobs, Pains, Gains и проверка ценностного предложения. |
| Marty Cagan — Inspired / Transformed + SVPG | Outcomes, empowered teams, discovery рисков. |
| Teresa Torres — Continuous Discovery Habits | Непрерывный discovery, weekly touchpoints, opportunity mapping. |
Актуальные онлайн-источники, использованные при подготовке
Product Talk — Getting Started with Discovery: https://www.producttalk.org/getting-started-with-discovery/
Product Talk — Customer Interviews / Continuous Discovery: https://www.producttalk.org/selecting-customers-for-customer-interviews/
SVPG — Product Model Concepts: https://www.svpg.com/product-model-concepts/
SVPG — Stakeholders and the Product Model: https://www.svpg.com/stakeholders-and-the-product-model/
Strategyzer — Value Proposition Canvas: https://www.strategyzer.com/library/the-value-proposition-canvas
Strategyzer — Value Proposition: https://www.strategyzer.com/value-proposition
Harvard Business Review — The Jobs to Be Done Theory of Innovation: https://hbr.org/podcast/2016/12/the-jobs-to-be-done-theory-of-innovation
Project Gutenberg — Adam Smith, The Wealth of Nations: https://www.gutenberg.org/files/3300/3300-h/3300-h.htm
9. Шпаргалка перед воркшопом
| Если спрашивают... | Отвечаем через... |
|---|---|
| Что такое продукт? | Не набор функций, а способ устойчиво создавать ценность для пользователя и бизнеса. |
| С чего начинать? | Сегмент → проблема/Job → baseline → outcome, а не стек. |
| Что такое discovery? | Работа по снижению неопределённости о том, что стоит строить и почему. |
| Что такое MVP? | Минимальный эксперимент/решение для проверки ключевого предположения. |
| Что такое JTBD? | Работа/прогресс, ради которого человек выбирает решение в конкретной ситуации. |
| Зачем метрики? | Чтобы заранее определить, какие данные изменят решение команды. |
| Почему одной accuracy мало? | Цена ошибок разная; нужны guard, user, ops и business metrics. |
| Когда pivot? | Проблема остаётся важной, но исходное решение/сегмент/механика не подтверждены. |
10 вопросов для самопроверки
Чем outcome отличается от output?
Почему нельзя начинать AI-продукт с выбора модели?
Что описывают Jobs, Pains и Gains?
Чем JTBD отличается от списка функций?
Чем discovery отличается от delivery?
Почему continuous discovery предполагает регулярный контакт с клиентами?
Как сформулировать проверяемую продуктовую гипотезу?
Почему MVP не равен «урезанной версии продукта»?
Какие четыре группы метрик минимум нужны AI-продукту?
В каком случае вы выберете ITERATE, PIVOT и STOP?
Ключевая мысль
Сильный AI/IT-специалист не продаёт технологию. Он превращает неопределённую проблему в проверяемую гипотезу, минимальный эксперимент и измеримый результат.
