Почему круто делать b2b-продукты

Предыстория:

Когда-то я писал про комплексы в b2b. Кратко: в b2b-продуктах (особенно в немассовых) многое иначе, чем в b2c. При этом на конференциях и на курсах вещают в основном люди, которые работают в b2c — продуктовое инфопространство строят в основном b2c-шники. Создаётся информационный перекос, в результате которого b2b-шникам кажется, что их продуктовые процессы далеки от правильных. Нет количественных метрик, нет когортного анализа, А/Б тестов и т.д.

Вот я и решил собрать списочек, почему b2b — это на самом деле очень круто.

1. Продукт важен в масштабах бизнеса. Стабильность некоторых b2b-продуктов является важной составляющей стабильности бизнеса.

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

3. Повышается важность знания отрасли, для которой создаётся продукт. Иногда надо потратить несколько месяцев, чтобы въехать в отрасль и вообще понять как продукт может дальше развиваться.

4. Пользовательские интерфейсы на порядок сложнее. Сделать сложное простым — настоящий вызов для продуктовых дизайнеров.

5. Юнит-экономика нереально сложна для расчёта. Нельзя закупить трафика и прикинуть конверсию в продажу. Хрен там, сложные продажи с циклом в несколько месяцев (а порой и лет).

6. Роль маркетинга и прямых продаж на особом уровне — во многих сегментах важны знакомства и нетворкинг, чтобы строить цепочки продаж. Прогнозировать продажи довольно сложная задача. Это тебе не рекламу покупать и конверсии мерять.

7. Петля виральности есть, но она может быть размером в несколько лет. Проработать вопрос виральности — сложный продуктовый вызов.

8. Нет серой массы условных усреднённых пользователей. Есть люди, которые работают с твоим продуктом и зачастую у этих людей разный вес в вопросах влияния на продуктовый роадмап.

9. Сложнее выносить конкурентов. Чтобы вынести конкурента надо не одного пользователя уговорить, а целый бизнес.

10. Бэклог — многомерное чудовище. Запрос одного крупного клиента может весить больше, чем запросы десяти но поменьше. Многие фреймворки приоритезации просто бессильны.

11. Придумать адекватные продуктовые метрики — негуглящийся вызов. Если продакт его осиливает — просто красава.

12. Высока роль качественных исследований — навык общения с бизнес-пользователями становится бесценным.

13. Нет мгновенных результатов: поменяли А, получили Б. Надо думать, думать и думать, чтобы спрогнозировать результат до изменений. Роль эксперимента ниже, чем способность принимать обдуманные решения.

В общем, в b2b сложно и ответственно, потому и круто.

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

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

Так вот, самая большая херня на свете, когда начинают изобретать регламенты под единичные случаи.
Нахамил Андрей из поддержки клиенту — пишут регламент работы всей поддержки.
Опаздывает один сотрудник на работу — пишут регламент под всех.
Срывает один сотрудник жёстко сроки — пишут регламент и KPI под всех.
Упал сервер впервые за 5 лет — пишут регламент о недопущении падений.
Удалил случайно Володя файл с сервера — регламент ...

У создания регламентов должна быть культура. В идеале, регламент нужен для регулирования часто повторяющихся инцидентов или для фиксации сложившихся процессов (для новичков). Тогда в нём есть смысл. Командам до 10 человек регламенты не особо нужны — пары заметок с договорённостями хватит.

Команда быстро растёт? Регламенты нужны, чтобы зафиксировать органически сложившиеся процессы для новеньких. Если команда должна расти очень-очень быстро, то за счёт регламентов можно снижать планку к сотрудникам, а не останавливать рост. Иными словами, если организация генерит много регламентов — она готовится к работе с большим количеством не самых эрудированных сотрудников. В госорганах, например, очень много регламентов.

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

Представьте: у вас есть два компьютера. У одного процессор помощнее — Янги, у другого послабее — Олди.

И вот вы даёте Янги и Олди примерно одни и те же задачи: какие-то данные обработать, вычисления провести и т.п. Янги и Олди справляются, но справляются они за разное время.

Янги успевает за 8 часов, а иногда и за 6. А Олди подольше: 10, иногда 12 часов. Порой Олди даже на выходных работает, чтобы успеть.

Однажды, вы увидели рекламу программы, которая позволяет общаться с компом — ИИ некий. Заинтересовались и поставили её на Олди.

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

Надо ли считать, что Олди заслуживает повышения?

В общем, теперь представьте, что Олди — это вы. Вы задерживаетесь на работе, работаете в выходные, постепенно перегораете. Но что, если это не из-за того, что задач много, а из-за того, что процессор слабенький?
Конечно же, вы не Олди — в отличие от Олди вы можете прокачать свой процессор самостоятельно, если объективно поймёте, что не тянете.

С — самокритичность важное качество.

#кактотак

— А это мы сделаем попозже!
— Не, не сделаем.

Вы же, наверняка, знаете, что если какие-то UI-мелочи не сделать сразу хорошо, то вероятность, что они в ближайшей перспективе вообще будут сделаны, стремится к нулю.

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

Но вы что-то отложили на после. Но “после” у любой мелочи приоритет становится ниже. Не до них.

К тому же каждая мелочь приобретает бОльшую трудоёмкость: взять в работу, отдать в тестирование, потестить, инструкции обновить ... Мелочь становится дороже в два-три раза точно. Экономия на мелочах не становится экономией.

Продукт начинает обрастать стремными местами. Но все они мелкие, не приоритетные, но их надо обслуживать: в бэклоге держать, спорить об их важности внутри команды и т.д.

В общем, у профессионалов UI-мелочи сразу сделаны хорошо. Экономить надо на крупном.

Как отдыхать в отпуске
===
Эту заметку я повторяю из года в год в отпускной сезон. Отдыхайте, чтобы работать.
===
Отпускной сезон вот-вот войдёт в свою активную фазу. Хочу поделиться с вами своими наблюдениями о грамотной организации отпускных процессов в команде.

Отпускникам
Главное правило: УХОДИ НА 100%

Нельзя:
⛔️ Делать в отпуске рабочие дела, до которых не доходили руки.

⛔️ Проверять рабочую почту — поставьте автоответ, что до такого-то числа вас нет.

⛔️ Участвовать в рабочих чатах — отключите уведомления и не заглядывайте.

⛔️ Ходить в гости на работу и видеться с коллегами (минимум рабочего).

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

Конечно, чтобы уйти в отпуск на 100%, необходимо к этому подготовиться.

✅ Если вы общаетесь с заказчиком — предупредите их за неделю об отпуске и предоставьте контакты того, кто вместо вас.

✅ Не берите большую задачу перед отпуском — если что-то пойдёт не так, то уйти на 100% будет сложнее.

✅ Заранее предупредите коллег об отпуске и о том, что им придётся делать вместо вас в этот период.

✅ Не пытайтесь за последнюю неделю перед отпуском сделать всё-всё и даже наперёд, выматывая себя. Работайте по приоритетам без авралов. Отдохнёте и доделаете.


Тем, кто остался
Главное правило: ОТПУСКНИКА НЕТ

⛔️ Если руководитель из-за какого-то форс-мажора вызывает отпускника, то стоимость форс-мажора должна быть больше ценности сотрудника. Иными словами: форс-мажор исправить важнее, чем потерять вызываемого сотрудника.

⛔️ Всякий раз, когда команда дёргает отпускника — она берёт у него в долг. Сумма долга при этом не известна: от "я продлю отпуск, так как меня вызывали" до "я решил уйти". Причём о том, что это долг отпускник может годами не говорить — будет сумму долга копить.

⛔️ Нельзя обижаться на отпускника из-за того, что он недоступен. Уважайте право на отдых.

#кактотак
из давно опубликованного

Про цель
Очень простое правило, о котором якобы все знают: чтобы чего-то достигнуть, надо поставить цель.

Просто представьте: человек хочет научиться метко кидать дротики. Ставит перед собой доску и кидает в неё. Вроде бы, всё верно. Но как понять, что он стал меткий? Надо выбрать цель на доске и оценивать относительно неё.

С дротиками, конечно, очевидно. Но моя практика показывает, что цель ставят не всегда.

“Учить английский, потому что сейчас это важно” — это не цель.
“Учить английский, чтобы через год написать на нём статью” — это цель.

“Давайте встретимся, обсудим макет дизайна” — это не цель.
“Давайте встретимся и составим финальный список требований к макету” — это цель.

Очень часто целей нет:
▫️ у встреч-обсуждений. Поболтали, но ничего не достигли. Я взял за правило писать в описании встречи список того, к чему мы должны по итогу прийти.

▫️у процессных задач, которые давно идут и все уже забыли, зачем это затевалось.

▫️у общекорпоративных встреч.

▫️ у обучения (см. выше про английский).

Важные свойства цели:
💡она должна быть известна до действия, а не по факту.
💡прогресс достижения цели должен быть измерим.

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

Любую задачу надо доводить до состояния: "Если бы я работал один, то запустил бы этот итог в продакшн".

Дизайнер не должен рассчитывать, что кто-то будет смотреть его работу прежде чем показать заказчику.
Программист не должен рассчитывать, что есть QA, который всё найдёт.
Редактор не должен рассчитывать, что есть корректор и главред, которые поправят и дадут обратную связь.

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

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

#softskills из давно опубликованного

Когда сценарий для будущего блокбастера «Чужой» (1979) был почти готов, его авторы придумали к нему питч всего лишь из трех слов: «Челюсти в космосе».

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

Как оценивать задачи
Считаю одним из лучших профессиональных качеств — умение оценивать задачу. Любую задачу: описанную подробно, описанную абы как, сказанную устно … Это прям фундамент.

Но многие ссут оценивать: стелят, стелят соломку.

“Нууу, тут пока не понятно, я даже не знаю сколько примерно это может занять …”
“Да там такое легаси, что я даже боюсь предположить сколько времени надо …”.

Если хотите выглядеть профи — научитесь оценивать задачи. Делается это просто:

1. Не можете оценивать сходу — просите время на оценку: “Я сейчас не могу оценить — мне надо 2 часа, чтобы сделать оценку”.

2. Декомпозируйте — разбивайте большую задачу на составляющие и оценивайте их.

3. Оценивайте вилкой: от — до. ОТ = когда всё пойдёт хорошо. ДО = когда всё пойдёт капец как хреново (сбудутся все риски).

4. Докиньте сверху 10-20% (некоторые накидывают до
100%).

5. Если брали время на оценку, то предоставьте док с декомпозицией и оценкой, а не просто: “Нууу, тут хреналион часов”. Тому, кто хотел оценку будет важно понимать, какие задачи много весят — возможно их можно заменить/отложить/купить.

6. Если оценить просят здесь и сейчас: “Прикинь хотя бы примерно”, значит важно понимать порядок оценки (неделя, месяц, год, жизнь). Прикиньте минимальную оценку, умножьте её на два и скажите: Не меньше чем “Х”. Этого часто достаточно, чтобы принять решение.

7. Надо следовать своим оценкам. А если что-то идёт не так, то своевременно переоценивать.

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

​​Big screen first

Когда речь заходит об интерфейсах для постоянной работы: корпоративные системы (b2b- сегмент). То здесь часто важно помнить не про mobile first, а про “купили сотрудникам широкоформатные мониторы, чтобы они глаза не ломали” (big screen first) .

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

Так вот, под большой монитор адаптировать порой сложнее, чем под мобильник.
Собрал несколько мыслей на тему — что делать с формами на широкоформатном мониторе:

🤦‍♂️1. Не надо растягивать поля. Самый большой капец — сделать полностью адаптивную форму. Было у вас в строке поле для ввода ИНН и вдруг оно превращается в длиннююющее поле для ввода ИНН.

🤦‍♂️2. pop-up не поможет. Pop-up сам по себе хреновое решение для отображения форм ввода информации, на которых больше 2-3 полей. Pop-up на большом экране становится и вовсе ужасен — куча свободного места слева и справа, нажатие на которое приводит к закрытию окна. А если вдруг вы сделали, что ваш pop-up не закрывается при тычке за его зоной, то пользователь всё равно боится нажать мимо, так как это паттерн.

🤷‍♂️ 3. Если есть возможность заморочиться — можно перекомпоновать поля. Было 2 поля в строке, а сделать при определённом размере экрана 3 (пример условный). Это лучше чем растянуть, но так себе — неудобно считывать форму (широкая).

🕺4. Масштабировать поля лишь частично, а остальное место (справа, как правило) оставлять пустым. Да, возможно, полэкрана будет пустым, но форма будет считываться и нормально заполняться. Если боитесь пустоты: можете на пустом месте пасхалку вывести, поздравив пользователя с хорошим монитором, или какие-то подсказки, или персонажа и т.п.

В общем, если вы делаете продукт для офисных работников — потестите формы на заполнение на широких (порой неприлично широких) мониторах, а не только на своём ноуте.

#UX давно не было 😉

Не суетись

Если вы смотрели Шрек-2, то вспомните сцену, в которой Шрек, Фиона и осёл ехали в гости к родителям Фионы. Осёл каждые пять минут спрашивал: "Уже приехали?", "Ну что, уже приехали?", "А сейчас приехали?" ...

Излишняя суета порой накрывает менеджеров (всех мастей): "Ну что, доделал?", "Нарисовал?", "Написал?", "Прошла модерация? А когда? А как ускорить?", "А можешь задержаться?", "Пообедаешь поскорее, чтобы успеть?".

Обычно волны суеты накрывают, когда что-то идёт не по плану: срывается срок, вылезла какая-то гадость на проде, сервак лёг, срочный запрос в поддержку и т.д.

Помню, накрытый волной суеты, ходишь вокруг да около программиста и уточняешь, как тот осёл: Нашёл причину ошибки? А скоро найдёшь? Ну ок, скоро вернусь.

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

Вряд ли, рушится Мир и надо дышать в спину программисту (дизайнеру/копирайтеру ...) — у меня Мир не рушился (хотя казалось иное), в 100% случаев можно было меньше суетиться. Твоих коллег на дольше хватит, если они работают в спокойном режиме.

На что можно заменить суету:
— доверие к исполнителю. Обозначить всю важность ситуации и попросить к определённому сроку предоставить статус по проблеме.

— приготовить план "Б". Часто суетиться и дышать в спину уже поздно — надо готовить вторую версию плана: думать, где можно срезать углы; думать, что делать, если всё же не успеем; думать, что сказать заказчику и т.д.

— обозначить, каким качеством можно пожертвовать ... и как его потом вернуть. Качество, утерянное в авральном режиме, должно быть зафиксировано и возвращено при выходе из этого режима.

— успокоиться самому: "Будет ли важна эта проблема через год?" Обычно, такой вопрос снимает волну суеты и помогает думать яснее.

В общем, менеджер — это оплот спокойствия, а не источник задёрганности.

Вокруг шум. Пусть так
Ни кипишуй. Всё ништяк
(Каста)

#softskills #продакту из давно опубликованного

Обещания на любом лэндинге vs факт

Комитмент

Меня бесит низкий комитмент в работу среди многих ИТ-специалистов. Простите за англицизм, но слово комитмент хорошее, чтобы обозначить термин “готовность взять на себя обязательства”.

Низкий комитмент проявляется следующим образом: сотрудник не планирует достигнуть результата внутри компании, а приходит “попробовать поработать”. Высокая востребованность некоторых ИТшников приводит к тому, что сотрудник, прыгая по работам быстрее “вырастает” (ему так может казаться). Зачем комититься здесь, если тебя только что на лучшие условия позвали? Для меня всё, что меньше 2 лет — низкий комитмент.

Низкий комитмент — это прям боль для тех, кто формирует команду. Тратится время на погружение — некоторые роли по полгода разгоняются. А потом бац: “Спасибо, было приятно работать, но пора двигаться дальше.” Куда дальше? Ты же тут ещё даже двигаться нормально не начал?

Может показаться, что низкий комитмент — это наши реалии. Мол поколение такое, отрасль и т.п.. И да, и нет. С низким комитментом надо работать: менеджеры, тимлиды и HR должны всё время думать над тем, как повышать срок эффективной жизни сотрудника.

Есть гигиенический минимум для повышения комитмента:

1. Не относиться поверхностно к отбору сотрудников.
Если есть сомнения в надёжности намерений — скорее всего так и будет. Если человек за год сменил несколько работ — скорее всего и у вас не задержится. Если соискатель не пытается понять куда его зовут: не задаёт вопросы про работу, команду, технологии — значит он не комитится, а идёт попробовать.

2. Быть честным.
Не надо расписывать свою работу как рай на земле, если это не так. Если у вас говнокод и легаси — так и говорите. Если у вас текучка — так и говорите. Если вы душнила — так и говорите. У сотрудника мог быть высокий комитмент в описанный вами рай на земле, но нулевой в шарагу, в которую он в итоге попал.

3. Запрашивать комитмент.
Если для вас важно, чтобы сотрудник задержался у вас — так ему об этом и говорите. Уточняйте, что для него важно. Взвешивайте свои возможности: можете ли вы это важное обеспечить.

Конечно, в ИТ не будет трудовых династий и работы на одном месте до пенсии — это не нужно. Но серьёзность намерений можно и нужно повышать.

Прокрастинация при умственной деятельности

Я вот о чём подумал: чем больше работаешь, тем больше прокрастинация.

Может быть, вы замечали, что короткие рабочие недели (между майскими, например) насыщены — ты сидишь и фигачишь 3-4 дня, зная что впереди выходные.

Или обратный эффект: чем больше времени в день ты работаешь, тем больше отвлекаешься от важного (прокрастинируешь). Например, ты работаешь не 7-8 часов, а 10-12 — объём отвлечений будет в разы больше (наблюдение за собой и не только).

Мозг устаёт и хочет переключаться, прыгать по задачам. При этом прокрастинация — это не только видосики смотреть или каналы в телеге читать (привет, привет). Это и переключаться на менее важные рабочие дела с более важных: полдня в чатах переписываться, запрашивать статусы работ и т.п. (загрузка мозга слабыми задачами вместо сильных).

Чем меньше времени в день для работы, тем более эффективным будет это время. У меня обычно большие вопросы к линейным специалистам, которые работают по 10-12 часов — скорее всего они малоэффективно работают. И чем дольше они работают по много, тем ниже эффективность этой работы. Исключение — люди с огромной внутренней мотивацией: основатели или специалисты, для которых работа находится в моменте вызова (получили новую должность на вырост). Но исключением они являются лишь какой-то промежуток времени — батарейка всё равно сядет.

В целом, мерять работу количеством времени, которое ты ей посвящаешь — это не про умственную деятельность (см. заметку про Олди и Янги).

Здоровая цель: как успеть сделать много за мало времени. Эта цель про эффективность.

Нездоровая цель: где найти время, чтобы успеть много. Это цель про увеличение крайне ограниченного ресурса.

Тезисы о UX в b2b-продуктах

🥚 UI уже в целом нормальный у большинства b2b-продуктов. Надо постараться, чтобы сильно накосячить с UI.

🥚 Продукт не должен требовать больше, чем пользователи делают без продукта. Продукт должен высвобождать время — он сам делает многое.

🥚 Чем сложнее процесс, который автоматизирует продукт, тем сильнее пользователи ждут возможность самокастомизации (сами настраивают продукт под свои потребности).

🥚 Эстетическое удовольствие от работы в продукте важно (Tone of Voice и приятные мелочи), но это вишенка на торте.

🥚 В организациях работают люди, а люди не любят читать инструкции — ждут, что будет очевидно даже в сложных местах.

🥚 Ну и золотое правило: последствия любого действия в продукте должны быть чётко ясны до его выполнения.

Ну всё — теперь есть о чём поговорить на вечеринке 😉

Контроль рабочего времени и активностей

Однажды я собеседовался в одной компании и у меня спросили: “Мы ставим специальную программу на компьютер, которая анализирует ваши действия. Как вы к этому относитесь?”

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

Если хотите скриншотить экран фрилансера, которому платите по часам — ваше право. Но сотрудники в штате — нет.

Почему?

Я прихожу в команду, чтобы думать о продукте, чтобы достигать итога, чтобы приносить ценность компании.

Я не прихожу в команду, чтобы работать 8 часов, вставать и идти делать свои дела, забыв полностью про работу. Я так не умею.

Кто оценит, когда гуляя по улице, я продумываю идеи по продукту и делаю это эффективнее, чем сидя за компом? Тоже самое у программистов — кто оценит, если он придумает эффективный алгоритм, когда будет плавать в бассейне?

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

А зачем работать со слабыми?

MVP умер?

Если хорошенько подумать над каноническим понятием минимального жизнеспособного продукта (MVP), то можно понять, что он практически не актуален для современных ИТ-реалий. Кто вообще не в теме: MVP — это версия продукта, которая создаётся для тестирования гипотезы востребованности продукта.

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

Так вот, большинство литературных примеров MVP относятся к древним (по меркам ИТ-развития) временам: доска объявлений через Эксель, Airbnb через факс, потоковая музыка, которая стала Spotify, Zappos, который продавал через интернет магазин чужую обувь и т.п.

Но помимо древности литературные примеры MVP объединяет то, что тестировалась уникальная (новейшая) модель продукта. Нет (или почти нет) примеров MVP, когда продукт выводился на конкурентный рынок.

Но жизнь такова, что сейчас 99,99% продуктов выводятся на конкурентный рынок. Цифровая революция во многих сферах уже прошла. Нельзя прийти к заказчику и предлагать ему нефункциональную CRM (любую другую систему) — он уже видел кучу функциональных CRM.

Если ваш продукт относится к 0,01% уникальных продуктов — вопросов нет: вы придумали что-то совершенно новое и можете это донести в минимальном жизнеспособном виде.

Если у вас продукт относится к 99,99% продуктов, имеющих конкурентов — для вас MVP скорее мёртв (сорян). Надо создать что-то, что будет лучше конкурентов (хотя бы не сильно хуже).

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

В общем, MVP в 99,99% случаев мёртв. Конечно, примерами ИТ-древности можно восхититься, но на практике почти никому они не помогут.

#продакту