Как описать проблему в презентации проекта: 3 способа, которые помогут вам лучше донести актуальность проекта
Вы наверняка знакомы с типовой структурой презентации проекта: в ней обязательно есть блок «Проблема». Он погружает зрителя в контекст и показывает, что ваш проект для чего-то нужен.
Откровенно говоря, я не уверена, что каждая презентация нуждается в этом блоке. Например, когда вы выходите на рынок с очень понятным продуктом (магазин женской одежды, бургерная, производство обуви), гораздо важнее показать, с каким «секретным ингредиентом» вы отожмете долю рынка у конкурентов.
Но если ваш продукт более инновационный, нужно погрузить зрителя в проблему.
В этой статье я разбираю 4 способа описывать проблему, которую решает продукт: 1 неправильный и 3 правильных с разной глубиной проработки.
Способ 1. Неправильный
Никогда и ни при каких обстоятельствах не описывайте проблему расплывчатой формулировкой типа:
- Проблема глобального потепления, проблема бездомных животных, проблема ожирения — это слишком абстрактно. Проект — это всегда про конкретную целевую аудиторию и их конкретную боль. Всё человечество не может быть целевой аудиторией.
- Отсутствие удобного приложения по управлению проектами, отсутствие онлайн-сервиса для оформления презентаций — скорее всего, вы заблуждаетесь о том, что чего-то не существует. Это показывает, что автор поверхностно проработал проект.
- Трудно найти нужную модель телефона, трудно реализовать проект, трудно определиться с профессией — Неясно, что лежит в формулировке «трудно». Сама формулировка субъективна: что для одного трудно, для другого просто.
Способ 2. Статистика из открытых источников
Это минимум по описанию проблемы, который должен быть в презентации.
Лучшие источники надежной статистики — это не новостные сводки, а ресурсы аналитических агентств и отчеты об исследованиях, например:
- Раздел «Аналитика» на сайте Российской ассоциации электронных коммуникаций
- Исследование российского рынка онлайн-образования Нетологии
- Исследования Яндекса
- Сайт Росстата
- Сайт СберИндекса и т.д.
Открытая статистика может показать, что проблема изучается и носит глобальный характер. Однако она все равно не объяснит, какую именно «боль» вы собрались решать, поэтому одной только открытой статистики для описания проблемы недостаточно.
Следующий уровень – это самостоятельные исследования целевой аудитории.
Способ 3. Изучаем ЦА: ожидание-реальность
В этом способе мы переходим от абстрактной проблемы к конкретной боли определенных людей.
Посмотрим на описание проблемы из книги «Принцип пирамиды Минто». Проблема – это ситуация, в которой вместо желаемого результата вы получите что-то другое. Этот разрыв между «хочу» и «получу» показывает на наличие проблемы.
Но просто заявить о наличии разрыва — это не значит доказать наличие проблемы. Например, я давно хочу на своем балконе выложить пол плиткой. Но плитки там до сих пор нет. Почему? Так я ничего для этого не делаю 😁
Чтобы понять, что этот разрыв действительно «болит» у целевой аудитории, проведите CustDev. Вот что нужно извлечь из результатов интервью:
- Что уже делает респондент, чтобы этот разрыв преодолеть?
- Сколько денег тратит на это?
- Что еще кроме денег тратит или недополучает (время, силы, эмоции, здоровье и т.д.)?
Покажите, что целевая аудитория уже тратит деньги, силы и время, чтобы как-то решить проблему.
А можно сделать еще шаг дальше — и во время CustDev задать вопрос «Какие способы вы уже используете, чтобы решить проблему?». Ответ на него приведет нас к четвертому способу описать проблему.
Способ 4. Решения уже есть, но не работают
Проблему можно описать как ситуацию безысходности, в которой что бы вы ни предприняли, ничего не помогает.
Например, вы просыпаетесь ночью от зубной боли. Пытаетесь отвлечься и не думать о ней – не помогает. Выпили таблетку, но боль не прошла. В единственной ночной стоматологии свободной записи нет. У вас есть друг-стоматолог, к которому можно обратиться, но он тусит в клубе с друзьями 😨
Решения-то есть, но ни одно из них вам не подходит!
Это, на мой взгляд, лучший способ описать проблему. И наиболее адекватный, потому что вы не отрицаете, что решения проблемы уже есть – просто в этой ситуации их не применить.
В таком описании проблемы есть 4 компонента:
- Описание желаемого результата: как ЦА поймет, что проблема решена (четкий список критериев).
- Существующие варианты решить проблему.
- Анализ, который показывает, что эти варианты не соответствуют критериям.
- Вывод: чего не хватает существующим способам, чтобы решить проблему.
Есть несколько общих формулировок проблем, созданных по этому принципу:
- Ни одно из существующих решений само по себе не позволяет достичь желаемого результата (сюда же входят случаи, когда какое-то решение позволяет достичь результат, но затраты неприемлемо высоки для ЦА).
- Одно или несколько существующих решений позволяют достичь результат, но есть какой-то непреодолимый барьер, из-за которого их использовать нельзя. Например, вы оказались в другой стране без интернета, и хотите открыть карту на смартфоне. Но без интернета карта не работает. А чтобы подключиться к WiFi, надо залогиниться по номеру телефона... а у вас нет симки местного оператора.
- Существующие решения в совокупности позволяют достичь желаемый результат, но по отдельности — нет. Приходится использовать все сразу, а это неудобно (разные интерфейсы), дорого (каждое решение оплачивается отдельно).
- Решения есть, но доступ к ним ограничен (например, только через VPN) или ограничено их использование (например, нельзя использовать ПО зарубежных производителей из-за программы импортозамещения).
Какая из этих формулировок описывает вашу проблему?
Что делать, если проблемы нет?
Я часто вижу, как сначала создается какое-то решение, а потом «натягивается» на проблему как сова на глобус. В итоге весь проект выглядит так себе. Я не завидую создателю проекта, который понимает, что проблемы не существует: больно осознавать, что работа была проделана впустую, и продукт на самом деле никому не нужен.
Лучшее, что можно сделать в этом случае — это пойти и подумать. Не о том, как все-таки описать проблему, которой нет, а о том, как все-таки определить конкретную боль, которую вы будете решать. Возможно, нужно будет немного или много переделать продукт — но по крайней мере вы будете делать реальный проект, а не иллюзорный.
Когда я работаю с проектными командами, мы обсуждаем в деталях каждый блок презентации. Моя задача — «извлечь» нужные знания о проекте, заставить команду задуматься о сути проекта и описать проект в презентации так, чтобы он привлек внимание зрителя.