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

Если для того, чтобы решение «заработало», пользователи должны:

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

то такое решение не может быть основной MVP – это не базовая ценность, а зависимая функция.

Чтобы сформировать MVP, важно явно проговорить:

• На какую потребность направлено решение?
• Какую проблему вы решаете?
• Какое главное допущение вы проверяете? (что должно оказаться правдой, чтобы продукт имел смысл)

Это допущение связано с потребностями и способами их удовлетворения; если оно неверно, всё остальное не имеет смысла.

Когда вы перечисляете функции:
«В решении есть функции 1,2,3...»

Задайте себе вопросы:

• Для какой общей задачи это всё нужно?
• Точно ли нельзя начать с одной функции, которая уже даёт заметную ценность?

Когда вы говорите:
«Мы соберём всё в одном месте»

Спросите:

• Почему это важно?
• Какая реальная проблема за этим стоит?

Mipets: простое приложение с графиком кормления питомца (кот «Британская шиншилла») – базовый, но ценный сценарий: хозяин не забывает кормить животное по расписанию.

Тайный Санта (santa-secret.ru): сервис делает одно важное действие – организует тайный обмен подарками между людьми через «коробу» и жеребьёвку.
У продукта:

• узкий сценарий (тайный обмен)
• понятная основная ценность (простая организация жеребьёвки).

Цитата: Successful product launch is based on selection of narrow market and targeting it with a single
feature solution. This oftentimes contradicts a dream of engineers to build universal, scalable, all-cases-covering
solution (K. Bredyuk)

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

Плохие формулировки:

• «Алгоритм, который предлагает пользователям контент...»
• «Наше решение будет более удобным»

Вопросы к ним:

• Как алгоритм работает в первом приближении?
• За счет чего именно решение становится «более удобным»?

Фразы:

• «лучше»,
• «удобнее»,
• «интуитивно понятный интерфейс»

– это оценки,. а не описание решения.

Вместо этого нужно объяснить:

• какое поведение пользователя вы хотите изменить,
• как продукт это делает (через какие шаги, механизмы, подсказки).

В примере с приложением Thrive важно не просто заявить «мы помогаем менять поведение», а показать, за счёт чего:
через баланс мотивации, способности и триггеров (B=MAP: Behavior = Motivation + Ability + Prompts).

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

Позиционирование отвечает на вопрос: для какого рынка и для какой задачи мы делаем своё однофункциональное решение?

На примере B2B-продукта К. Бредюка:

Сначала фокус постепенно сужали:

• Generic approvals (любые согласования)
• Multi-step approvals (многошаговые согласования)
• Multi-step approvals for finance
• Multi-step approvals for Xero
• Multi-step approvals for Xero Bills
• Multi-step approvals for Xero Bills for SMB

После закрепления в нише – расширяли:

• approvals для Purchase Orders,
• сопоставление Bills и заказов,
• бюджетные проверки.

Вывод: сначала – узкая ниша и понятное позиционирование, потом – расширение.

Pianist Helper: сервис, который по ссылке на видео в RuTube отправляет набор скриншотов с разбором, и вокруг этого строит интерфейс (слайд-шоу, анимация).

Здесь позиционирование строится вокруг:

• конкретной аудитории (пианисты / учащиеся),
• конкретного сценария (учиться по видео),
• необычного формата (автоматические скриншоты и визуальный разбор).

Сравнение с существующими решениями нужно не для бизнес-аналитики, а для:

• проверки, что мы действительно делаем что-то новое, а не копию;
• оценки, имеет ли наш продукт смысл, учитывая уже существующие варианты решений;
• пояснения, чем наше решение лучше / отличающееся – на уровне задач и потребностей, а не «фич».

Сравнения в нашем контексте – это НЕ:

• не анализ рынков, денег и бизнес-моделей;
• не таблица со сравнением только «фич»;
• не перечисление того, что мы «собираем в одном месте»;
• не ранжирование по неопределённым качествам типа «удобнее», «лучше».

При сравнении важно учитывать:

• прямых конкурентов – решают ту же задачу теми же способами;
• непрямых – решают ту же задачу другими способами;
• альтернативы – решают другую задачу, которая делает вашу задачу неактуальной (например, «не бронировать отели, а поехать в гости к родственникам»).

Пример Booking.com:

• Другие сервисы бронирования
• Трэвел-агенты
• Другие виды досуга в отпуск

Вместо таблицы «фич» используем матрицу задач:

И смотрим:

• Как решается задача в продукте;
• На какие контексты они направлены (для кого? в каких ситуациях?);
• Какие преимущества даёт каждое решение;
• Какие потребности удовлетворяются и какие – остаются без ответа.

На примере habit-трекеров (Flora, Stikk, Fabulous, Productiv) важен не список фич, а наличие/отсутствие аспекта ответственности (accountability).
Вывод: «у конкурентов мало или вообще нет аспекта взаимной ответственности; мы можем занять эту нишу».

Другой пример – сравнительная таблица доставки еды, где оцениваются:

• UX/UI;
• фильтры, сортировка, скорость загрузки, удобство оформления заказов и т.д..

После анализа вы должны уметь сформулировать:

• Мы удовлетворяем потребности, которую не удовлетворяют эти продукты/решения, потому что...
• Мы решаем проблему, которая не решена, а именно...
• Мы решаем проблему лучше, чем это и это решение, потому что...

При этом важно признать:

• Другие решения отличаются от нас чем-то (у них свои сильные стороны);
• Их сильные стороны – в этом, и с ними не обязательно нужно конкурировать напрямую.

Фактически мы описываем продукт по трём направлениям:

Пользователи, задачи, контекст

• Кто наши пользователи?
• В каких ситуациях они находятся?
• Какие задачи у них возникают?

Идея и ценность

• Какую идею мы предлагаем?
• В чём ценность этой идеи для пользователей?
• Как именно идея реализует эту ценность?

Сравнение с существующими способами

• Как люди решают эти задачи сейчас?
• Какие способы уже существуют?
• Чем наша идея отличается и почему она лучше / уместнее в выбранном контексте?

На примере mymind.com:

Сначала показываются конкретные проблемы:

• хаос с заметками,
• хаос с закладками и статьями,
• хаос с картинками и вдохновением.

Затем вводится решение:

• «Your own little knowledge base, containing everything you want to remember»
• «Welcome to your new mind».

Схема:
Проблемы (в реальном контексте) → Продукт как ответ → Формулировка ценности.

На примере Morty:

• Чёткая формулировка: «Morty is a mortgage marketplace».
• Далее – как именно продукт реализует эту ценность: выдаёт ипотечные решения через цифровую платформу, опираясь на крупнейших кредиторов.

На слайде показан треугольник:

• Продукт

↔ Ценность
↔ Пользователи, задачи, контекст.

Каждый элемент проверяется вопросами:

• Пользователи, задачи, контекст:

Правда ли у пользователей есть такая потребность / задача?

• Ценность:

Как именно мы реализуем ценность?

• Продукт:

Вписывается ли решение в контекст и деятельность пользователей?

На примере mymind.com:

Сначала показываются конкретные проблемы:

• хаос с заметками,
• хаос с закладками и статьями,
• хаос с картинками и вдохновением.

Затем вводится решение:

• «Your own little knowledge base, containing everything you want to remember»
• «Welcome to your new mind».

Схема:
Проблемы (в реальном контексте) → Продукт как ответ → Формулировка ценности.

На примере Morty:

• Чёткая формулировка: «Morty is a mortgage marketplace».
• Далее – как именно продукт реализует эту ценность: выдаёт ипотечные решения через цифровую платформу, опираясь на крупнейших кредиторов.

• Проблема:

«Студенты колледжа хуже достигают личных целей, чем академических».

• Сценарий: Joseph хочет раньше вставать, но постоянно срывается.
• Вопрос:

«Как мы можем сделать так, чтобы студенты чувствовали большую ответственность за свои личные цели?»

• Гипотеза:

«Если у них будут accountability partners, это значительно увеличит вероятность достижения целей».

Это и есть рискованное допущение: если оно неверно, то механика партнёров по ответственности не сработает, и весь продукт потеряет смысл.