Мнение: Термин «минимальный жизнеспособный продукт» нужно заменить на «минимальное решение проблемы»
Менеджер по продуктам Скотт Селхорст опубликовал в своем блоге заметку, в которой призвал разработчиков оперировать понятием Minimum Valuable Problem (минимальное решение проблемы) вместо привычного Minimal Viable Product (минимально жизнеспособного продукта). Редакция vc.ru публикует перевод заметки Селхорста.
В избранное
Определить и создать хороший минимально жизнеспособный продукт гораздо труднее, чем это может показаться на первый взгляд. Задача не исчерпывается тем, чтобы найти и сделать ту самую «Вещь», которая нужна людям. Она включает в себя не только поиск минимального решения проблемы, но и всё то, что ему сопутствует. При этом важно действовать в обоих направлениях: «изнутри наружу» и «снаружи внутрь».
Верхушка айсберга
Рич Миронов в своей статье DIY illusion говорит о том, как важно фокусироваться именно на своих ключевых компетенциях, а не изобретать велосипед заново. Представьте, что ваша команда работает над мобильным приложением. И вдруг, когда встаёт вопрос о создании CRM для отслеживания ваших пользователей, вы начинаете с нуля создавать CRM. Или самостоятельно разрабатываете тикет-систему для управления процессом разработки фич и исправления багов.
Рич в своей статье говорит о микро-версии классической модели публично-частного партнёрства (BBO — build, buy, partner). Эта версия отлично накладывается на ситуацию, когда ваша команда определяет свои потребности в DevOps или другой инфраструктуре.
Если мы перейдём на более широкий организационный уровень, то получим классическую MBA-версию, и теперь предстоит решить, создаём ли мы новый продукт для того, чтбы дополнить наше портфолио? Или мы заключаем с кем-то партнёрство, чтобы использовать их продукт? А может смысл в том, чтобы приобрести нового партнёра (или нам нужен только продукт)?
Все эти вопросы отражают подход «изнутри-наружу». Но что если, размышляя над будущим продуктом, применить подход «снаружи-внутрь»? Ведь ваши пользователи тоже принимают решения build, buy, partner по поводу вашего продукта.
Рич в своей статье касается важного момента: работа, которую вам предстоит сделать (что бы вы под этим ни подразумевали), вмещает в себя гораздо больше, чем можно понять из поверхностного анализа. То же самое верно и для определения минимально жизнеспособного продукта. Ваши пользователи нуждаются в решении большего количества проблем, чем та единственная, на которой вы сосредоточились. Минимальное решение проблемы
Я собираюсь провести эксперимент с моей командой: в течение нескольких следующих недель мы будем обсуждать только минимальные решения проблем (вместо минимально жизнеспособных продуктов). Надеюсь, это поможет изменить мышление моих коллег.
Впервые я употребил этот термин вчера, во время переговоров с руководством. Я хотел пояснить, что наш продукт направлен именно на минимальное решение проблемы, но не получил по этому поводу ни одного комментария, не считая нескольких одобрительных кивков.
Мне запомнилась цитата saeedwkhan о том, что минимально жизнеспособный продукт в буквальном смысле является «самым меньшим, что вы можете сделать». Я полностью с этим согласен, и вообще люблю эту цитату. Может, кому-то из вас даже известно, кто её оригинальный автор.
Почему я так подчёркиваю разницу между продуктом и проблемой? На это есть две причины. Одна из них философская, другая — чисто практическая. Философский взгляд
Одна из ценностей, которую команды разработчиков от меня получают, — это мой «свежий взгляд» (точнее, взгляд со стороны) на то, что они делают или только планируют делать. Я помогаю команде перейти с позиции «изнутри-наружу» на позицию «снаружи-вовнутрь», другими словами — исходить из потребностей рынка. В контексте продукта это обычно означает следовать за проблемами, которые пытается решить конкретная группа пользователей. Именно введение термина «проблема» помогает мне, беседуя с командой, постепенно сдвинуть фокус их дискуссий. И чем больше я работаю, тем больше убеждаюсь в этом.
Я работаю с командами уже на самых ранних этапах разработки, и когда разработчики обсуждают будущий продукт, они часто говорят о том, что они делают или собираются сделать. Но для меня эти разговоры не имеют ценности, так как не касаются того, насколько этот продукт будет соответствовать потребностям рынка. Гораздо полезнее поговорить о той проблеме, которую мы собираемся решить.
Обсуждение того, для чего люди будут использовать будущий продукт, гораздо ценнее, чем беседы о том, как он будет работать и во что это нам обойдётся. Практическая польза
Огромную проблему коммуникации гениально иллюстрирует скетч Джеффа Паттона из его книги User Story Mapping.
Я на собственном опыте убедился, что когда люди обсуждают «продукт», беседа складывается очень легко: все радостно употребляют это слово, но никто не уточняет, что именно оно означает.
Когда же люди говорят о проблеме, они подразумевают под «продуктом» средство для её решения. В таком обсуждении проблема постоянно присутствует: её то и дело упоминают, определяют или, по крайней мере, ссылаются на неё, не чувствуя при этом никакого дискомфорта.
Я не знаю, почему так происходит, но это факт. Возможно, среди моих читателей есть когнитивный психолог, который захочет объяснить это различие. Что можно считать решением проблемы
Работая над своим собственным продуктом (Jiu Jitsu), я опирался на подход Гойко Аджика, описанный в его книге Impact Mapping. Этот подход помог мне быстро определить, что значит для моего пользователя решить его (или её) проблему. На самом деле метод Гойко не единственный, который позволяет это сделать, просто мне он понравился.
Фокусируясь на результатах, вы понимаете, что порой решение изначально поставленной проблемы может оказаться недостаточным. Возможно, ваш минимально жизнеспособный продукт решит только половину проблемы, стоящей перед пользователем. Выходит, вы создали только половину продукта. Конечно, бывают случаи, когда такое частичное решение вполне приемлемо (в разбиении пользовательских историй, при инкрементальном подходе и так далее). Но это скорее исключение, чем правило.
Скажите честно, как часто вы покупаете половину решения стоящей перед вами проблемы? Просите ли вы механика починить один из перегоревших стоп-сигналов, а второй — оставить на следующий ваш визит, через месяц?
Таким образом, определение минимального решения проблемы и является определением минимально жизнеспособного продукта.
Минимальное решение проблемы — это когда вы можете полностью решить эту проблему, пусть даже это будет в очень узком контексте, для небольшой группы пользователей или на каком-то ограниченном сегменте вашего рынка. Вы можете найти не самое лучшее решение или то, которое так и не станет по-настоящему конкурентоспособным. Но вы однозначно решили эту проблему для какого-то конкретного пользователя, в какой-то конкретной ситуации.
Помните: вы наращиваете свой доход, обслуживая по одному пользователю за раз. Да, это звучит банально, зато отлично работает. Допустим, тот самый единственный клиент выбирает одного из нескольких поставщиков. Как вы думаете, кого он выберет:
среднестатистического продавца, который является таким же среднестатистическим и для других пользователей
или идеального продавца для него лично, даже если он не является идеальным для других пользователей?
Пространство пользовательской проблемы
Представленная выше диаграмма показывает, как в реальности выглядит экосистема, связанная с каким-то конкретным продуктом (я затенил надписи, потому что это реальный пример). В левом верхнем углу обозначена проблема, которую нужно решить, — кандидат на минимальное решение проблемы.
Красные линии обозначают потребности: чтобы решить свою проблему, пользователю требуется помощь другого пользователя. Соответственно, этому «другому» приходится участвовать в решении проблемы первого пользователя. Возможно, между ними даже существует некая оперативная связь (например, «контролировать решение проблемы первой группой пользователей, чтобы мы могли точно настроить своё решение»). Вы сталкиваетесь с этим на каждом совещании, когда обсуждаете сервисную работу или многокомпонентные продукты.
Нарисовав подобную экосистему, мы можем обнаружить множество аспектов, связанных с адекватным решением пользовательской проблемы. На расположенном внизу рисунке пользователи, так или иначе вовлечённые в решение фокус-проблемы для фокус-пользователя, обозначены разными цветами. Эта сеть взаимозависимых проблем и является скрытой (подводной) частью нашего айсберга.
Луковичная диаграмма, построенная для той же самой проблемы, позволяет ясно увидеть (даже в этой отредактированной версии), что существует три системы (или три системных интерфейса), с помощью которых разные пользователи прямо или косвенно используют наш продукт для решения своих проблем. Мост через разрывы процесса
Описанный выше взгляд на проблемное пространство помогает нам убедиться в том, что мы действительно ищем минимальное решение проблемы (для меня это звучит лучше, чем «создавать жизнеспособный продукт»). Такой подход позволяет нам преодолеть разрыв между абстрактным мышлением продуктовой команды, конкретным мышлением инженеров-разработчиков и представлением руководителей проекта, которые тоже хотят понимать, что тут, в конце концов, происходит.
В избранное
—
Теги
Статьи по теме
В избранное
Определить и создать хороший минимально жизнеспособный продукт гораздо труднее, чем это может показаться на первый взгляд. Задача не исчерпывается тем, чтобы найти и сделать ту самую «Вещь», которая нужна людям. Она включает в себя не только поиск минимального решения проблемы, но и всё то, что ему сопутствует. При этом важно действовать в обоих направлениях: «изнутри наружу» и «снаружи внутрь».
Верхушка айсберга
Рич Миронов в своей статье DIY illusion говорит о том, как важно фокусироваться именно на своих ключевых компетенциях, а не изобретать велосипед заново. Представьте, что ваша команда работает над мобильным приложением. И вдруг, когда встаёт вопрос о создании CRM для отслеживания ваших пользователей, вы начинаете с нуля создавать CRM. Или самостоятельно разрабатываете тикет-систему для управления процессом разработки фич и исправления багов.
Рич в своей статье говорит о микро-версии классической модели публично-частного партнёрства (BBO — build, buy, partner). Эта версия отлично накладывается на ситуацию, когда ваша команда определяет свои потребности в DevOps или другой инфраструктуре.
Если мы перейдём на более широкий организационный уровень, то получим классическую MBA-версию, и теперь предстоит решить, создаём ли мы новый продукт для того, чтбы дополнить наше портфолио? Или мы заключаем с кем-то партнёрство, чтобы использовать их продукт? А может смысл в том, чтобы приобрести нового партнёра (или нам нужен только продукт)?
Все эти вопросы отражают подход «изнутри-наружу». Но что если, размышляя над будущим продуктом, применить подход «снаружи-внутрь»? Ведь ваши пользователи тоже принимают решения build, buy, partner по поводу вашего продукта.
Рич в своей статье касается важного момента: работа, которую вам предстоит сделать (что бы вы под этим ни подразумевали), вмещает в себя гораздо больше, чем можно понять из поверхностного анализа. То же самое верно и для определения минимально жизнеспособного продукта. Ваши пользователи нуждаются в решении большего количества проблем, чем та единственная, на которой вы сосредоточились. Минимальное решение проблемы
Я собираюсь провести эксперимент с моей командой: в течение нескольких следующих недель мы будем обсуждать только минимальные решения проблем (вместо минимально жизнеспособных продуктов). Надеюсь, это поможет изменить мышление моих коллег.
Впервые я употребил этот термин вчера, во время переговоров с руководством. Я хотел пояснить, что наш продукт направлен именно на минимальное решение проблемы, но не получил по этому поводу ни одного комментария, не считая нескольких одобрительных кивков.
Мне запомнилась цитата saeedwkhan о том, что минимально жизнеспособный продукт в буквальном смысле является «самым меньшим, что вы можете сделать». Я полностью с этим согласен, и вообще люблю эту цитату. Может, кому-то из вас даже известно, кто её оригинальный автор.
Почему я так подчёркиваю разницу между продуктом и проблемой? На это есть две причины. Одна из них философская, другая — чисто практическая. Философский взгляд
Одна из ценностей, которую команды разработчиков от меня получают, — это мой «свежий взгляд» (точнее, взгляд со стороны) на то, что они делают или только планируют делать. Я помогаю команде перейти с позиции «изнутри-наружу» на позицию «снаружи-вовнутрь», другими словами — исходить из потребностей рынка. В контексте продукта это обычно означает следовать за проблемами, которые пытается решить конкретная группа пользователей. Именно введение термина «проблема» помогает мне, беседуя с командой, постепенно сдвинуть фокус их дискуссий. И чем больше я работаю, тем больше убеждаюсь в этом.
Я работаю с командами уже на самых ранних этапах разработки, и когда разработчики обсуждают будущий продукт, они часто говорят о том, что они делают или собираются сделать. Но для меня эти разговоры не имеют ценности, так как не касаются того, насколько этот продукт будет соответствовать потребностям рынка. Гораздо полезнее поговорить о той проблеме, которую мы собираемся решить.
Обсуждение того, для чего люди будут использовать будущий продукт, гораздо ценнее, чем беседы о том, как он будет работать и во что это нам обойдётся. Практическая польза
Огромную проблему коммуникации гениально иллюстрирует скетч Джеффа Паттона из его книги User Story Mapping.
Я на собственном опыте убедился, что когда люди обсуждают «продукт», беседа складывается очень легко: все радостно употребляют это слово, но никто не уточняет, что именно оно означает.
Когда же люди говорят о проблеме, они подразумевают под «продуктом» средство для её решения. В таком обсуждении проблема постоянно присутствует: её то и дело упоминают, определяют или, по крайней мере, ссылаются на неё, не чувствуя при этом никакого дискомфорта.
Я не знаю, почему так происходит, но это факт. Возможно, среди моих читателей есть когнитивный психолог, который захочет объяснить это различие. Что можно считать решением проблемы
Работая над своим собственным продуктом (Jiu Jitsu), я опирался на подход Гойко Аджика, описанный в его книге Impact Mapping. Этот подход помог мне быстро определить, что значит для моего пользователя решить его (или её) проблему. На самом деле метод Гойко не единственный, который позволяет это сделать, просто мне он понравился.
Фокусируясь на результатах, вы понимаете, что порой решение изначально поставленной проблемы может оказаться недостаточным. Возможно, ваш минимально жизнеспособный продукт решит только половину проблемы, стоящей перед пользователем. Выходит, вы создали только половину продукта. Конечно, бывают случаи, когда такое частичное решение вполне приемлемо (в разбиении пользовательских историй, при инкрементальном подходе и так далее). Но это скорее исключение, чем правило.
Скажите честно, как часто вы покупаете половину решения стоящей перед вами проблемы? Просите ли вы механика починить один из перегоревших стоп-сигналов, а второй — оставить на следующий ваш визит, через месяц?
Таким образом, определение минимального решения проблемы и является определением минимально жизнеспособного продукта.
Минимальное решение проблемы — это когда вы можете полностью решить эту проблему, пусть даже это будет в очень узком контексте, для небольшой группы пользователей или на каком-то ограниченном сегменте вашего рынка. Вы можете найти не самое лучшее решение или то, которое так и не станет по-настоящему конкурентоспособным. Но вы однозначно решили эту проблему для какого-то конкретного пользователя, в какой-то конкретной ситуации.
Помните: вы наращиваете свой доход, обслуживая по одному пользователю за раз. Да, это звучит банально, зато отлично работает. Допустим, тот самый единственный клиент выбирает одного из нескольких поставщиков. Как вы думаете, кого он выберет:
среднестатистического продавца, который является таким же среднестатистическим и для других пользователей
или идеального продавца для него лично, даже если он не является идеальным для других пользователей?
Пространство пользовательской проблемы
Представленная выше диаграмма показывает, как в реальности выглядит экосистема, связанная с каким-то конкретным продуктом (я затенил надписи, потому что это реальный пример). В левом верхнем углу обозначена проблема, которую нужно решить, — кандидат на минимальное решение проблемы.
Красные линии обозначают потребности: чтобы решить свою проблему, пользователю требуется помощь другого пользователя. Соответственно, этому «другому» приходится участвовать в решении проблемы первого пользователя. Возможно, между ними даже существует некая оперативная связь (например, «контролировать решение проблемы первой группой пользователей, чтобы мы могли точно настроить своё решение»). Вы сталкиваетесь с этим на каждом совещании, когда обсуждаете сервисную работу или многокомпонентные продукты.
Нарисовав подобную экосистему, мы можем обнаружить множество аспектов, связанных с адекватным решением пользовательской проблемы. На расположенном внизу рисунке пользователи, так или иначе вовлечённые в решение фокус-проблемы для фокус-пользователя, обозначены разными цветами. Эта сеть взаимозависимых проблем и является скрытой (подводной) частью нашего айсберга.
Луковичная диаграмма, построенная для той же самой проблемы, позволяет ясно увидеть (даже в этой отредактированной версии), что существует три системы (или три системных интерфейса), с помощью которых разные пользователи прямо или косвенно используют наш продукт для решения своих проблем. Мост через разрывы процесса
Описанный выше взгляд на проблемное пространство помогает нам убедиться в том, что мы действительно ищем минимальное решение проблемы (для меня это звучит лучше, чем «создавать жизнеспособный продукт»). Такой подход позволяет нам преодолеть разрыв между абстрактным мышлением продуктовой команды, конкретным мышлением инженеров-разработчиков и представлением руководителей проекта, которые тоже хотят понимать, что тут, в конце концов, происходит.
В избранное
—
Теги
Статьи по теме
Ещё новости по теме:
18:20